Oleg_SK, во-первых, твой пример с файлом, состоящим "из последовательности блоков данных, размеры которых кратны размеру страницы." СЛИШКОМ надуман. Ну где ты видел такие файлы?! Во-вторых, если делать всё через MMF, то никакого физического копирования страниц памяти не будет. Как только ты прочитаешь файл, он тут же попадет в системный кэш. И при дальнейших операциях система будет брать его куски оттуда. Она просто будет переотображать его на разные виртуальные адреса без физическоко копирования. Т.е. фактически она будет делать именно то, что ты хочешь. Строго говоря, я не буду утверждать этого на 100%. Но на 99.99% уверен, что это именно так. Почитай у Соломона 11 главу про диспетчер кэша.

Oleg_SK

Не думал, что мой вопрос вызовит столь развёрнутый ответ :).
Всё, что я хотел сказать - если в алгоритме требуется двигать область памяти, то алгоритм этот нужно исправить.

Сам процессор даже не имеет команд для перемещения данных.
Для копирования - сколько угодно.
Вообще, что такое перемещение? Копирование, с последующим обнулением - тогда смысл обнулять?
Это я к тому, что смысл копировать данные был всегда, а смысла перемещать - никогда не было.
Это как бы аксиома.


Теперь к вашему примеру.
Подобные (?) вещи появились ещё тогда, когда компьютер начал отображать инфу на ЭЛТ (а может и раньше).
Текстовые видооконтроллеры используют подобный принцип - гдето хранятся "картинки" символов (скажем 8 байт),
а "на экран" помещают только байт - код символа, по этому коду знакогенератор ищет картинку в таблице.
Тут сразу 2 преимущества - уменьшается экранная память,
и ускоряется процесс "помещения" символа на экран (1 байт вместо 8)
По такому же принципу работают спрайтовые и тайловые видеоконтроллеры.

Здесь смысл очевиден - скорость возрастает (минимум) в разы, как и в вашем случае.
Это показывает, что сама идея хорошая.

НО. Везде эмулируется копирование, т.е. создаются "двойники" заранее определённых данных в разных частях экрана (реально-то отображаются одна и таже картинка, а не одинаковые картинки расположенные в различных участках памяти)


Теперь к файлам. На скорую руку предложу так (если MMF договорились не использовать):
(S - размер файла, P - позиция куда встявить)

1. В памяти выделяется буфер, размером S-P;
2. Загружаем во входной буфер файл начиная с P;
3. Удаляем кусок файла с P;
4. Дописываем вставляемый блок;
5. Дописываем S-P;
6. Освобождаем буфер.


Хотя это далеко не лучший способ.
Если файл требует частой вставки данных "в середину" - значит это неправильный файл :)
Для таких целей надо разработать более подходящий сегментированный формат.
Например Pertable Executable ;)
В начале файла - каталог с описанием секций, определяющий их порядок на диске и в памяти.
Теперь, если надо вставить данные в середину, то можно просто добавить секцию.
И, кстати, система тут уже может использовать "Kernel-mode FASTEST data block copiing".
Например, когда отображает секции одной dll в разные процессы.


А перемещение данных никогда не нужно.
IMHO, кто-то слишком умный придумал название MemMove для варианта MemCopy, отсюда и заморочки.


ЗЫ: меня - на ты :)

[ S_T_A_S_: кто-то слишком умный придумал название MemMove для варианта MemCopy, отсюда и заморочки. ]

MemMove может копировать перекрывающиеся блоки, а MemCopy нет. В этом существенная разница.

Four-F

Конечно, разница есть.
Для того, что бы при копировании блоки не перетирались,
надо определить в каком направлении копировать - от младших байт к старшим, или от старших байт к младшим.
Если использовать REP MOVS, то в случае, если DESTINATION > SOURCE, надо прибавить ECX к EDI & ESI и установить флаг направления.
Но смысл - он останется прежний.
Будет выполнено копирование. Если блоки перекрываются, то содержимое источника изменится - вот и всё.
Этот смысл не видно в С, там же абстракция.
Тем более, если смотреть толко на название.

Oleg_SK
Как S_T_A_S_ исчерпывающе объяснил перемещение никому не надо, но если так уж хочется - то мжно сделать так:
#define MEMORY_REQUESTED 100000000
ULONG_PTR NumberOfPages;
ULONG_PTR *aPFNs;
AllocateUserPhysicalPages( GetCurrentProcess(), &NumberOfPages, aPFNs );

void *lpMem1 = VirtualAlloc( NULL, MEMORY_REQUESTED, MEM_RESERVE | MEM_PHYSICAL, PAGE_READWRITE );

void *lpMem2 = VirtualAlloc( NULL, MEMORY_REQUESTED, MEM_RESERVE | MEM_PHYSICAL, PAGE_READWRITE );

MapUserPhysicalPages( lpMem1, NumberOfPages, aPFNs );
MapUserPhysicalPages( lpMem2, NumberOfPages, aPFNs );

Пожалуйста - юзай одну память в 2х местах. Можешь в одном месте удалять а в другом создавать - будет перемещение. Но зачем тебе это надо, так и не понял.

Oleg_SK
D. Solomon M.Russinovich/ Windows 2000 Inside/ Chapter 7/ about AWE/

при чтении спецификации на чипы памяти IBMN612404GT3B
мысля одна в голову пришла... сразу говорю, я не претендую на то, что она пришла мне первому ;) но на _этом_ форуме она не встречалась.
итак быстрое копирование памяти. максимально быстрое. как формула один. и еще быстрее. а ведь DDR поддерживает возможность копирования из чипа в чип! что может быть быстеее? нафиг гонять память между процессором и DIMM'ами через чипсет? когда можно дать команду на копирование и все ;) минусы - требуется низкий уровень для обращения к чипу и что хуже всего... придется иметь дело с _физическими_ адресами, но при работе с большими объемами данных выигрыш стоит того. ИМХО конечно.
вопрос - нет ли у кого указанного модуля? тогда я вышлю тестик. или какие модули у вас стоят, тогда я скачаю спецификации и посмотрю как там это реализовано. память желательно от IBM. другие описывают ее менее подробно ;(

kaspersky
> память желательно от IBM.

А где ж ее взять, в основном везде модули от Samsung,
у меня например ;-)

а я поклонник IBM, а против сам-сунь-и-высунь-га у мя предубеждение.
впрочем, этот прием работает на любом чипе. сначала оправляем на один банк cmd read, и тут же на другой cmd write, если CAS > tDQSS, а если tDQSS > CAS, то сначала cmd WRITE, а потом cmd READ. ну и... шина-то данных на запись/чтения общая ;)
на ней появляются прочитанные данные и в это же время другая микруха готова их записать.
кстати этот способ копирования работает асинхронно от процессора, т.е. как копирование памяти через DMA, которые было на XT, но потом исчезло начиная с AT.

Мдя, похоже на то, что идея действительно мертворожденная… Чем больше думаю, тем больше убеждаюсь в этом. Стыдно признаться, но я раньше как-то не задумывался о том: зачем вообще нужно перемещение как таковое? Теперь же, благодаря вашим постам, мне пришлось это сделать. Я пришел к выводу: при правильном алгоритме, операция перемещения блоков данных не потребуется. Спасибо, что образумили ламера!

Благодарю всех за участие. Хочу также отдельно сказать СПАСИБО:
· volodya ’у, Four-F’у и S_T_A_S_’у – за интересные посты;
· volodya ’у, Four-F’у и CARDINAL ’у – за интересные ссылки;
· semen’у – за приведенный код.