Быстрая запись в память. MOVNTQ/SFENCE

Тема в разделе "WASM.ASSEMBLER", создана пользователем BuilderPower, 14 июн 2008.

  1. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    Далее подразумевается, что из памяти читаются или в память записываются достаточно большие объемы данных (сотни мегабайт) - много большие объема кэша процессора. Несмотря на достаточную пропускную способность шины, каждое обращение к памяти происходит с задержками на два порядка превышающими задержки при работе процессора с регистрами или кэшем. Чтобы была понятнее суть проблемы, опишу как я понимаю способы оптимизации работы с памятью.

    Механизм Prefetch
    С быстрым линейным чтением у современных процессоров (IA-32 aka x86-32) проблем особых нет, поскольку обеспечить предварительное кэширование достаточно легко как программно (либо косвенно используя инструкции prefetchnta, prefetcht0, ... либо напрямую командами mov, заставляя процессор кэшировать 32 (64, 128) байта), так и аппаратно (линейное чтение процессоры сами прекрасно распознают и стараются заранее кэшировать в большинстве случаев). При этом, за счет непрерывного предварительного кэширования без особых трудностей удается использовать практически всю пропускную способность шины памяти - в зависимости от чипсета, процессора и памяти линейная скорость чтения может составлять 80..99% от эффективной пропускной способности. Процессор может загружать в кэш строку данных из памяти параллельно выполняя независимые от этих данных вычислительные операции.

    Механизм Write-Back
    С быстрой линейной записью дела обстоят не так гладко (рассматривается случай, когда записываемые данные не будут использоваться в ближайшие X тактов). Поскольку работает кэширование, то обычная запись (с использованием команд mov, movq, movdq, movdqu/movdqa, movups/movaps, ...) будет выполняться паралелльно с синхронизацией линий кэша. Т.е. в случае записи в область памяти, которой нет в кэше (фактический кэш-промах, а при линейной записи больших объемов данных эта ситуация будет случаться через каждые 32, 64 или 128 байт в зависимости от длины кэш линии процессора и алгоритма кэширования) - вся строка памяти (32, 64 или 128 байт) будет считана в кэш, т.е. в итоге во время записи все области памяти будут так или иначе хотя бы один раз считаны в кэш. Из-за этого теряется как минимум половина пропускной способности шины плюс простои из-за задержек синхронизации, обращения к памяти и пр. Но этот механизм полезен в большинстве случаев, когда данные используются повторно.

    Механизм Write-Combining
    Для таких случаев (когда записываемые данные не будут использоваться в ближайшее время) процессору дается подсказка, что данные не нужны (Non-Temporal Hint), при этом от процессора ожидается, что при кэш-промахе он не будет кэшировать строку памяти, занимая часть пропускной способности шины. Такую подсказку процессор получает через команды movntq, movntdq, movntps, ... , после использования которых (по завершении цикла записи) командой sfence от процессора требуется дописать в память все, что еще возможно не записалось (для гарантии), и синхронизировать содержимое кэша если нужно.

    Пример кода на ассемблере, выполняющий линейную запись в память с претензией на высокую скорость (TestWrite):

    Код (Text):
    1.   // EDI - указатель на буфер памяти, в который осуществляется запись
    2.   // ECX - объем записываемых данных, кратный 64 байтам (запись хвоста - любым методом)
    3.  
    4.   // Записываем 64-байтные блоки в цикле (значение регистров MMX не важно)
    5.   shr       ECX, 6
    6. @writeblock:
    7.   movntq  qword [EDI], MM0
    8.   movntq  qword [EDI+8], MM1
    9.   movntq  qword [EDI+16], MM2
    10.   movntq  qword [EDI+24], MM3
    11.   movntq  qword [EDI+32], MM4
    12.   movntq  qword [EDI+40], MM5
    13.   movntq  qword [EDI+48], MM6
    14.   movntq  qword [EDI+56], MM7
    15.  
    16.   // Наращиваем указатель 64-байтных блоков и уменьшаем счетчик блоков
    17.   add       EDI, 64
    18.   dec       ECX
    19.   jnz        @writeblock
    20.  
    21.   sfence
    22.   emms
    Аналогично, вместо "movntq qword [EDI], MM0" можно использовать "movntps dqword [EDI], XMM0", записывая по 128-бит за раз. Впрочем, скорость записи при этом практически такая же, поскольку от процессора данные передаются по 64-битной шине.

    В большинстве случаев, на большинстве систем импользование Non-Temporal подсказок процессору обеспечивает значительный прирост (до двух-трех раз) скорости записи. Но не всегда, и на всех. Тонкость в том, что "подсказки" называются так совсем не случайно - в зависимости от обстоятельств и различных параметров процессор волен игнорировать все подсказки и делать так, как считает нужным/оптимальным ему в данный момент (впрочем, строго достигая алгоритмического результата всех команд).

    Например, подсказки по кэшированию (Prefetch) данных процессор волен игнорировать в зависимости от обстоятельств (например, если замечает что последние прекэшированные данные не использовались). В этом случае у программиста имеется надежный способ заполнить кэш линии процессора используя в цикле прекэширования вместо PrefetchNTA [ESI+X] команды mov EBX, dword [ESI+X]. Накладных расходов (по сравнению со временем чтения из ОЗУ) совсем немного, а процессор железно выполнит команду mov, при этом загрузив из ОЗУ целую кэш линию (32, 64 или 128 байт в зависимости от процессора). Игнорировать mov он не может.

    С подсказками записи в обход кэша (movntq, movntdq, movntps, ...) все несколько сложнее. Нет никакой гарантии, что каждом новом случае они всегда будут выполняться так как предполагается. Прямой равносильной замены этим командам нет. Разве что принудительное отключение кэша процессора (через BIOS) позволит гарантировать, что запись через movq (movdq, movdqu/movdqa, movups/movaps, ...) будет идти прямо в память (это как правило в два раза быстрее чем использование movq (для больших объемов данных) со включенным кэшем). Но даже при этом при не будет достигнута большая часть пропускной способности из-за больших задержек работы с памятью, а выигранная скорость записи не компенсирует задержек работы без кэша.

    Вот и получается, что максимальное использование пропускной способности памяти при записи возможно только при использовании команд-подсказок (movntq, movntdq, movntps, ...), что-либо гарантировать при использовании которых - сложно.

    Это было краткое введение) А теперь суть проблемы:
    Имеется система (печатная машинка) 6BTM(i440BX)+CelTualatin-256(B-1 Step, CPUID 6B4)+SDR SDRAM(512MB PC133), прекрасно работающая в настоящий момент. На данной системе скорость линейного чтения стабильно достигает 97-99% (1035-1055 Мбайт/с) от эффективной пропускной способности шины памяти (133.3MHz x 64-bit = 1066 Мбайт/с).

    С другой стороны, скорость линейной записи так же достигает 97-99% от эффективной пропускной способности... но не стабильно... и не всегда. Подробнее ниже.


    Подробности обычной записи:
    Собственно, обычная кэшируемая запись, реализуемая через, например, rep stosd (либо через mov, movq, movdq, ... в данном случае не важно, поскольку все варианты имеют приблизительно одинаковую скорость):

    Код (Text):
    1.   // EDI - указатель на буфер памяти, в который осуществляется запись
    2.   // ECX - объем записываемых данных, кратный 4 байтам (запись хвоста - через stosb, например)
    3.   // Заполняем 4-байтовые блоки памяти содержимым EAX
    4.   shr    ECX,2
    5.   rep    stosd
    Скорость заполнения памяти: 215 Мбайт/с (20% от пропускной способности). Аналогичная скорость (плюс минус) достигается при использовании различных вариантов mov и развернутых циклов. Очевидно, что скорость ограничивается неэффективным использованием пропускной способности шины памяти (в том числе кэшированием всего буфера за счет механизма write-back) и задержками самой памяти.

    Предположительно происходит следующее (в режиме записи объема данных много большего размера кэша): при записи очередных новых 32 байт, происходит очередной кэш-промах (когда данные записываются в некэшируемую область памяти) и процессор считывает из памяти 32 байта (для PIII) в кэш линию, что занимает порядка ~10+X тактов шины памяти SDRAM. В то же время, прежде чем произвести запись, процессор вынужден освобождать кэш линии, синхронизируя с их содержимым соотвествующие области памяти - т.е. в среднем записывать в память 32 байта перед каждым чтением, что занимает еще дополнительно ~10-X предварительных тактов шины памяти (процессор может заполнять при кэш-промахе по две кэш линии или при записи скидывать еще больше - от этого суть сильно не меняется). Пренебрегая скоростью записи из регистра в кэш (на порядки быстрее), получаем оценочное значение в 20 тактов шины памяти на каждые 32 записываемых байта. Т.е. для 133.3 МГц шины памяти, скорость такого режима записи составит ровно (32_байта/20_тактов)*133.3 = 213 Мбайт/с.

    ПРОВЕРКА: Принудительно запрещаем через BIOS использование кэша процессора (полностью, т.е. и L1, и L2, при этом процессор не сможет использовать ни кэш инстркуций, ни кэш данных - обычные программы будут работать на порядки медленней) - скорость записи возрастает до 335 Мбайт/с (31% от пропускной способности). Предположительно имеем порядка 12-13 тактов шины памяти (требующих участия процессора) на запись каждых 32-байт (вероятный размер буфера записи; буфер записи используется даже при отключенном кэше).

    Откуда взяты цифры 10-13 тактов шины памяти для записи/чтения (90..100 нс):
    - по временной диаграмме работы SDRAM примерно столько тактов пройдет пока процессор считает или запишет 32 байта (4x64-бит) нужной кэш линии ( 2+ (rRP=2)+(tRCD=2)+(tCL=2)+4+1? );
    - время доступа к памяти по тестам - порядка 80 нс, т.е. как раз в районе 10 ( 2+(rRP=2)+(tRCD=2)+(tCL=2)+1+1? ) тактов шины памяти;

    Временная диаграмма цикла чтения SDRAM 2-2-2:
    [​IMG]

    Общая картина: при таком режиме записи происходит множество отдельных обращений к памяти, каждое из которых простаивает порядка 2/3 времени из-за задержек памяти.




    К чему весь этот рассказ:
    Поскольку в нашем случае используется линейная запись, а данные нам не нужны сразу после этой процедуры, то логичным будет использование команд movntq, movntdq, movntps, ... , дающих процессору подсказку и возможность наиболее эффективным способом организовать быструю запись (см. выше пример кода на ассемблере (с использованием movntq), выполняющий линейную запись в память с претензией на высокую скорость).

    При этом (с использованием movntq), скорость записи действительно возрастает до 97-99% от эффективной пропускной способности (1066 Мбайт/с для PC133 SDRAM), т.е. превышая порог Гигабайт/с. Но на данной системе (6BTM(i440BX)+CelTualatin-256(B-1 Step, CPUID 6B4)+SDR SDRAM(512MB PC133)) скорость записи очень часто падает до все тех же 215 Мбайт/с, которые получаются с помощью "rep stosd", или "mov dword [ESI+X], EAX", или "movq qword [ESI+X], MM0" и прочих вариантов, проходящих по механизму Write-Back.

    Замечена следующая СТРАННОСТЬ_0xF7:
    - первые N проходов (N-зависит от объема данных) записи всегда быстрые (1000+ Мбайт/с);
    - потом M проходов (обычно M>N в несколько раз) скорость падает до 215+ Мбайт/c (бывают промежуточные значения 300+, 400+, 800+);
    - снова порядка ~N проходов быстрые;

    Пробуя разные варианты, удалось выяснить, что если вводить принудительные задержки между проходами - то проходы записи всегда будут быстрыми (1000+ Мбайт/с), т.е. если выполнять непрерывную запись достаточно редко. Следующий цикл всегда дает быстрые проходы записи:

    for i:=1 to Cnt do begin
    TestWrite(Ptr, 32*1024*1024);
    Sleep(200);
    end;

    Задержка 200 мс (с небольшим запасом) на каждые записываемые 32 Мбайта (или 100 мс на 16 Мб, или 400 мс на 64 Мб). Если ставить меньше - через несколько проходов начинается СТРАННОСТЬ_0xF7 (см. выше). TestWrite - процедура, использующая команды movntq внутри цикла, и одну команду sfence перед возвратом управления (см. пример в начале топика).

    Гипотеза_0x01:
    Процессор время от времени (по обстоятельствам видимо) игнорирует Non-temporal "подсказки" и пишет по механизму Write-Back.

    Гипотеза_0x02:
    Процессор некорректно выполняет sfence, и к моменту новой порции Non-temporal данных оказывается не готов из-за чего скорость записи падает до скорости в режиме обычной записи.

    На описываемой системе СТРАННОСТЬ_0xF7 проявляется очень выраженно и стабильно. Из-за этого даже все (!) тесты памяти на запись показывают результаты, которые раз на раз не приходятся (т.к. M>N в разы, то в чаще всего тестах именно цифра 200-240 Мбайт/с, а иногда 1040 Мбайт/c, ... неплохой разброс плюс минус в пять раз)...

    На других системах, в том числе с DDR и DDR2 СТРАННОСТЬ_0xF7 судя по всему так же дает о себе знать, но не так явно и стабильно. Т.е. последовательные замеры времени записи там так же изменяются, но не так сильно (обычно от 10% до 50%).
     
  2. SII

    SII Воин против дзена

    Публикаций:
    0
    Регистрация:
    31 окт 2007
    Сообщения:
    1.483
    Адрес:
    Подмосковье
    А как с многозадачностью? Время от времени текущий поток снимается с процессора по инициативе Винды даже в том случае, если других пользовательских потоков нет. При этом могут "сыпаться" и кэши, и TLB, что, есно, будет существенно тормозить работу...
     
  3. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    SII
    От многозадачности и переключения потоков скорость плавает совсем немного - обычно в пределах 10%. В свою очередь СТРАННОСТЬ_0xF7 проявляет себя даже в реал тайм приоритете, и когда все процессы кроме системных выгружены (тестировалось на Win98/WinXP).


    Касательно СТРАННОСТИ_0xF7 - для того, чтобы каждый проход записи был быстрым - приходится вводить задержку, такую что бы среднняя скорость записи за много проходов (с задержками) не превышала все ту же цифру - порядка 200-250 Мбайт/с (20-25% от пропускной способности шины памяти SDR SDRAM).

    Сделал небольшую тестовую программу (см. вложение MEM_0xF7.zip, 16 кб с исходником под Delphi), использующую ассемблерные функции записи в память (с инструкциями MOVQ и MOVNTQ). По окончании тестирования программа создает лог-файл с результатами. Имеет три параметра запуска: объем буфера (в МБ), число проходов, задержка между проходами (в мс).

    Результаты следующие - при задержке 200 мс на запись каждых 64 МБайт памяти имеем стабильно высокую скорость записи (почти всегда):

    Система_A (i440BX+Tualatin-256+SDRAM-PC133):
    Код (Text):
    1. Memory Write Test 0xF7 (64 MB, 16 Passes, Delay 200 ms)
    2.  
    3. [PASS#]         [MOVQ]          [MOVNTQ]
    4.  
    5. Pass 1:         225 MB/s        989 MB/s
    6. Pass 2:         227 MB/s        989 MB/s
    7. Pass 3:         227 MB/s        989 MB/s
    8. ...
    9. ... такая же скорость в каждом проходе ...
    10. ...
    11. Pass 15:        227 MB/s        989 MB/s
    12. Pass 16:        227 MB/s        989 MB/s
    13.  
    14. Min:            225 MB/s        989 MB/s
    15. Max:            227 MB/s        989 MB/s
    16.  
    17. Dif:            0%              0%
    С уменьшением задержки до 150 мс, скорость записи падает до скорости обычной кэшируемой записи:

    Код (Text):
    1. Memory Write Test 0xF7 (64 MB, 16 Passes, Delay 150 ms)
    2.  
    3. [PASS#]         [MOVQ]          [MOVNTQ]
    4.  
    5. Pass 1:         225 MB/s        989 MB/s
    6. Pass 2:         227 MB/s        989 MB/s
    7. Pass 3:         227 MB/s        990 MB/s
    8. Pass 4:         227 MB/s        989 MB/s
    9. Pass 5:         217 MB/s        218 MB/s
    10. Pass 6:         217 MB/s        218 MB/s
    11. ...
    12. ... такая же скорость в оставшихся проходах ...
    13. ...
    14. Pass 15:        217 MB/s        218 MB/s
    15. Pass 16:        217 MB/s        218 MB/s
    16.  
    17. Min:            217 MB/s        218 MB/s
    18. Max:            227 MB/s        990 MB/s
    19.  
    20. Dif:            4%              354%
    Причем скорость падает не окончательно - на такой задержке она может меняться от запуска к запуску:

    Код (Text):
    1. Memory Write Test 0xF7 (64 MB, 16 Passes, Delay 150 ms)
    2.  
    3. [PASS#]         [MOVQ]          [MOVNTQ]
    4.  
    5. Pass 1:         216 MB/s        218 MB/s
    6. Pass 2:         217 MB/s        218 MB/s
    7. ...
    8. ... в проходах 3-11 скорость такая же ...
    9. ...
    10. Pass 12:        217 MB/s        218 MB/s
    11. Pass 13:        217 MB/s        218 MB/s
    12. Pass 14:        217 MB/s        329 MB/s
    13. Pass 15:        227 MB/s        989 MB/s
    14. Pass 16:        227 MB/s        990 MB/s
    15.  
    16. Min:            216 MB/s        218 MB/s
    17. Max:            227 MB/s        990 MB/s
    18.  
    19. Dif:            5%              354%
    При задержке менее 100 мс (на каждые 64 МБ) скорость будет почти сегда низкой, за исключением редких всплесков под максимум. Для 64 МБ задержка выше 250 мс позволяет всегда иметь высокую скорость записи, аналогично для 256 - это уже порядка секунды (а для 16 - 20-30 мс), т.е. в любом случае средняя скорость записи не превысит порога 20-22% от пропускной способности шины. Т.е. имеем СТРАННОСТЬ_0xF7 во всей красе.

    На большинстве других машин ничего такого не наблюдается, скорость записи колеблется всего лишь в пределах 20%, а часто - менее 5% (это уже зависит от количества процессов в системе и их активности). Например:

    Система_B:
    Код (Text):
    1. Memory Write Test 0xF7 (256 MB, 16 Passes, Delay 0 ms)
    2.  
    3. [PASS#]         [MOVQ]          [MOVNTQ]
    4.  
    5. Pass 1:         502 MB/s        2 193 MB/s
    6. Pass 2:         512 MB/s        2 197 MB/s
    7. ...
    8. ... примерно такая же скорость в каждом проходе ...
    9. ...
    10. Pass 15:        496 MB/s        2 191 MB/s
    11. Pass 16:        498 MB/s        2 261 MB/s
    12.  
    13. Min:            460 MB/s        1 946 MB/s
    14. Max:            512 MB/s        2 261 MB/s
    15.  
    16. Dif:            11%             16%
    Система_C:

    Код (Text):
    1. Memory Write Test 0xF7 (256 MB, 16 Passes, Delay 0 ms)
    2.  
    3. [PASS#]         [MOVQ]          [MOVNTQ]
    4.  
    5. Pass 1:         1 516 MB/s      3 356 MB/s
    6. Pass 2:         1 496 MB/s      3 316 MB/s
    7. ...
    8. ... примерно такая же скорость в каждом проходе ...
    9. ...
    10. Pass 15:        1 520 MB/s      3 378 MB/s
    11. Pass 16:        1 525 MB/s      3 303 MB/s
    12.  
    13. Min:            1 470 MB/s      3 296 MB/s
    14. Max:            1 530 MB/s      3 389 MB/s
    15.  
    16. Dif:            4%              2%
    Ссылка на тестовую программу MEM_0xF7 (16 кб, с исходниками) ниже:
     
  4. max7C4

    max7C4 New Member

    Публикаций:
    0
    Регистрация:
    17 мар 2008
    Сообщения:
    1.203
    А ты не подумал, что система не собирается все эти мегабайты держать в памяти и большую часть страниц запихнет в файл подакчки. Таким образом пропускная способность шины разделится на работу программы и работу системы с файлом подкачки (т.е. с диском).
     
  5. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    Механизм своппинга страниц в данном случае не играет никакой роли пока объемы используемой для буферов памяти не превышают размеров свободной физической памяти. В случае же своппирования (при использовании объемов буфера, превышающего объем свободной физической памяти), скорость падает катастрофически из-за заметных даже на глаз операций считывания/записи на диск.

    ПРОВЕРКА:
    - Чтение из буфера, в который планируется запись, всегда идет быстро на пределе пропускной способности;
    - Обращений к диску ни в процессе цикла чтения, ни в процессе цикла записи - нет;
    - Отключение файла подкачки ничего не меняет;

    Интересно посмотреть какие результаты теста MEM_0xF7 (ссылка выше) будут на других системах схожей конфигурации (т.е. либо процессор Tualatin, либо память SDRAM, либо вообще любая другая система с проявляющейся СТРАННОСТЬЮ_0xF7).
     
  6. dead_body

    dead_body wasm.ru

    Публикаций:
    0
    Регистрация:
    3 сен 2004
    Сообщения:
    603
    Адрес:
    Украина;г.Харьков;г.Н.Каховка
    Сделал бы что бы без комиляции можно было бы параметры менять, а то под рукой дельфи нету, что бы попробовать разные, а от одного прогона с одними параметрами толку -0.
     
  7. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    dead_body
    Так и сделано - смотри файл MEM_0xF7.bat - там прописаны параметры запуска. Программа имеет три параметра, разделенных пробелами. Каждый параметр интерпретируется как десятичное число с игнорированием прочих символов (дефисов, слешей и пр.).

    Первый параметр - объем буфера записи (в мегабайтах), в который будет производиться запись. Чем больше, тем точнее результаты каждого прохода (но естесственно потребуется больше времени). Размер буфера не должен превышать объем свободной физической памяти, иначе будет своппинг с диска.

    Второй параметр - число проходов записи в буфер. Скорость замеряется для каждого прохода. При этом в каждом проходе тестируется скорость записи в буфер в двух режимах: сначала весь буфер записывается в цикле через MOVQ, затем весь буфер записывается в цикле через MOVNTQ. В каждом случае скорость замеряется отдельно.

    Третий параметр - задержка в мс после каждого цикла записи (по два цикла записи на каждый проход). Значение 0 - отсутсвие задержки между циклами записи. Все должно работать быстро с нулевой задержкой, но когда проявляется СТРАННОСТЬ_0xF7 задержка в несколько сотен мс позволяет добиться высокой скорости во всех проходах.

    Пример:
    MEM_0xF7.exe -512 -16 -500

    Будет выполнено 16 проходов записи. В каждом проходе будет два раза осуществлена запись 512 Мбайт в память: в цикле через MOVQ и в цикле через MOVNTQ. После каждого цикла будет выжидаться задержка 500 мс (пол секунды), прежде чем начнется следующий цикл записи.

    По окончании теста в каталоге с программой (MEM_0xF7.exe) будет создан отчет "MEM_0xF7.log", содержащий результаты тестирования: скорости записи в каждом проходе, минимальное и максимальное значения, а так же разницу между ними в процентах (100*Max/Min - 100).
     
  8. Clerk

    Clerk Забанен

    Публикаций:
    0
    Регистрация:
    4 янв 2008
    Сообщения:
    6.689
    Адрес:
    РБ, Могилёв
    BuilderPower
    Вы сильно ошибаетесь, сужествует понятие кванта и приоритета.
     
  9. max7C4

    max7C4 New Member

    Публикаций:
    0
    Регистрация:
    17 мар 2008
    Сообщения:
    1.203
    да вот и нет. Винда станет сливать страницы раньше. Механизма работы с файлом подкачки у нее не самый лучший, но все равно. Попробуй остановить всю работу с диском со стороны приложений и запустить свою же прогу с выделением памяти как минимум в 25-75% от свободной (в зависимости от общего количества). И что же мы увидим. О чудо. Диск ожил! Странно почему это вдруг...
     
  10. dead_body

    dead_body wasm.ru

    Публикаций:
    0
    Регистрация:
    3 сен 2004
    Сообщения:
    603
    Адрес:
    Украина;г.Харьков;г.Н.Каховка
    BuilderPower
    тебе какие замеры сделать?( тут вот один из замеров привожу, система 2.00 к2д,4 Гб ДДР2-800(?), Виста СП1, своп 256(вроде не использовался))

    CPU Frequency: ~1 978 MHz
    Memory Write Test 0xF7 (1 024 MB, 16 Passes, Delay 0 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 1 150 MB/s 2 652 MB/s
    Pass 2: 1 403 MB/s 2 644 MB/s
    Pass 3: 1 260 MB/s 2 622 MB/s
    Pass 4: 1 370 MB/s 2 686 MB/s
    Pass 5: 1 441 MB/s 2 585 MB/s
    Pass 6: 1 420 MB/s 2 730 MB/s
    Pass 7: 1 448 MB/s 2 724 MB/s
    Pass 8: 1 383 MB/s 2 721 MB/s
    Pass 9: 1 412 MB/s 2 614 MB/s
    Pass 10: 1 434 MB/s 2 650 MB/s
    Pass 11: 1 427 MB/s 2 664 MB/s
    Pass 12: 1 451 MB/s 2 618 MB/s
    Pass 13: 1 305 MB/s 2 647 MB/s
    Pass 14: 1 310 MB/s 2 618 MB/s
    Pass 15: 1 343 MB/s 2 674 MB/s
    Pass 16: 1 435 MB/s 1 977 MB/s

    Min: 1 150 MB/s 1 977 MB/s
    Max: 1 451 MB/s 2 730 MB/s

    Dif: 26% 38%

    CPU Frequency: ~2 002 MHz
    Memory Write Test 0xF7 (1 024 MB, 16 Passes, Delay 100 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 1 401 MB/s 2 702 MB/s
    Pass 2: 1 398 MB/s 2 738 MB/s
    Pass 3: 1 426 MB/s 2 681 MB/s
    Pass 4: 1 431 MB/s 2 574 MB/s
    Pass 5: 1 399 MB/s 2 711 MB/s
    Pass 6: 1 388 MB/s 2 637 MB/s
    Pass 7: 1 403 MB/s 2 668 MB/s
    Pass 8: 1 413 MB/s 2 692 MB/s
    Pass 9: 1 427 MB/s 2 638 MB/s
    Pass 10: 1 438 MB/s 2 731 MB/s
    Pass 11: 1 454 MB/s 2 680 MB/s
    Pass 12: 1 411 MB/s 2 663 MB/s
    Pass 13: 1 456 MB/s 2 568 MB/s
    Pass 14: 1 440 MB/s 2 691 MB/s
    Pass 15: 1 454 MB/s 2 788 MB/s
    Pass 16: 1 382 MB/s 2 737 MB/s

    Min: 1 382 MB/s 2 568 MB/s
    Max: 1 456 MB/s 2 788 MB/s

    Dif: 5% 8%

    CPU Frequency: ~2 006 MHz
    Memory Write Test 0xF7 (1 024 MB, 16 Passes, Delay 200 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 1 458 MB/s 2 705 MB/s
    Pass 2: 1 481 MB/s 2 758 MB/s
    Pass 3: 1 501 MB/s 2 438 MB/s
    Pass 4: 1 470 MB/s 2 802 MB/s
    Pass 5: 1 389 MB/s 2 826 MB/s
    Pass 6: 1 515 MB/s 2 897 MB/s
    Pass 7: 1 518 MB/s 2 870 MB/s
    Pass 8: 1 521 MB/s 2 975 MB/s
    Pass 9: 1 548 MB/s 2 851 MB/s
    Pass 10: 1 511 MB/s 2 823 MB/s
    Pass 11: 1 535 MB/s 2 851 MB/s
    Pass 12: 1 356 MB/s 2 423 MB/s
    Pass 13: 1 445 MB/s 2 676 MB/s
    Pass 14: 1 359 MB/s 2 486 MB/s
    Pass 15: 1 459 MB/s 2 710 MB/s
    Pass 16: 1 359 MB/s 2 650 MB/s

    Min: 1 356 MB/s 2 423 MB/s
    Max: 1 548 MB/s 2 975 MB/s

    Dif: 14% 22%
     
  11. bugaga

    bugaga New Member

    Публикаций:
    0
    Регистрация:
    1 июл 2007
    Сообщения:
    361
    Pentium (почти 3) целерон-туалатин, 100MGz FSB:
    CPU Frequency: ~1 284 MHz
    Memory Write Test 0xF7 (128 MB, 16 Passes, Delay 0 ms)
    Гдето валялся копермайн P-III -1000 тока втыкать влом (ну тормознее он гамает хотя пропускная по ОЗУ несколько выше).
     
  12. max7C4

    max7C4 New Member

    Публикаций:
    0
    Регистрация:
    17 мар 2008
    Сообщения:
    1.203
    Ну не знаю. Вот у меня другое получается. Система 2,4 к2к 1024 ддр3-1066 xp-sp2 своп 512
    CPU Frequency: ~2 383 MHz
    Memory Write Test 0xF7 (128 MB, 16 Passes, Delay 0 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 2 120 MB/s 4 229 MB/s
    Pass 2: 2 155 MB/s 4 390 MB/s
    Pass 3: 2 194 MB/s 4 127 MB/s
    Pass 4: 2 153 MB/s 4 386 MB/s
    Pass 5: 2 138 MB/s 4 225 MB/s
    Pass 6: 2 180 MB/s 4 218 MB/s
    Pass 7: 2 117 MB/s 4 378 MB/s
    Pass 8: 1 895 MB/s 4 215 MB/s
    Pass 9: 2 192 MB/s 4 182 MB/s
    Pass 10: 1 970 MB/s 4 252 MB/s
    Pass 11: 2 151 MB/s 4 370 MB/s
    Pass 12: 2 167 MB/s 4 208 MB/s
    Pass 13: 2 149 MB/s 4 377 MB/s
    Pass 14: 2 191 MB/s 4 166 MB/s
    Pass 15: 2 148 MB/s 4 367 MB/s
    Pass 16: 2 194 MB/s 4 185 MB/s

    Min: 1 895 MB/s 4 127 MB/s
    Max: 2 194 MB/s 4 390 MB/s

    Dif: 15% 6%

    CPU Frequency: ~2 386 MHz
    Memory Write Test 0xF7 (128 MB, 16 Passes, Delay 200 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 1 993 MB/s 4 471 MB/s
    Pass 2: 2 125 MB/s 4 277 MB/s
    Pass 3: 2 106 MB/s 4 210 MB/s
    Pass 4: 2 138 MB/s 4 285 MB/s
    Pass 5: 2 129 MB/s 4 273 MB/s
    Pass 6: 2 128 MB/s 4 266 MB/s
    Pass 7: 2 093 MB/s 4 317 MB/s
    Pass 8: 2 110 MB/s 4 291 MB/s
    Pass 9: 2 096 MB/s 4 434 MB/s
    Pass 10: 2 086 MB/s 4 329 MB/s
    Pass 11: 1 962 MB/s 4 331 MB/s
    Pass 12: 2 101 MB/s 4 320 MB/s
    Pass 13: 2 121 MB/s 4 349 MB/s
    Pass 14: 1 992 MB/s 4 326 MB/s
    Pass 15: 2 125 MB/s 4 269 MB/s
    Pass 16: 2 100 MB/s 3 717 MB/s

    Min: 1 962 MB/s 3 717 MB/s
    Max: 2 138 MB/s 4 471 MB/s

    Dif: 8% 20%

    CPU Frequency: ~2 390 MHz
    Memory Write Test 0xF7 (512 MB, 16 Passes, Delay 0 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 1 980 MB/s 4 372 MB/s
    Pass 2: 2 089 MB/s 4 349 MB/s
    Pass 3: 2 099 MB/s 4 372 MB/s
    Pass 4: 2 030 MB/s 4 256 MB/s
    Pass 5: 2 073 MB/s 4 351 MB/s
    Pass 6: 2 097 MB/s 4 321 MB/s
    Pass 7: 2 043 MB/s 4 338 MB/s
    Pass 8: 2 026 MB/s 4 336 MB/s
    Pass 9: 2 118 MB/s 4 404 MB/s
    Pass 10: 2 066 MB/s 4 357 MB/s
    Pass 11: 2 058 MB/s 4 386 MB/s
    Pass 12: 2 115 MB/s 4 261 MB/s
    Pass 13: 2 108 MB/s 4 355 MB/s
    Pass 14: 2 095 MB/s 4 316 MB/s
    Pass 15: 2 108 MB/s 4 258 MB/s
    Pass 16: 2 106 MB/s 4 324 MB/s

    Min: 1 980 MB/s 4 256 MB/s
    Max: 2 118 MB/s 4 404 MB/s

    Dif: 6% 3%

    CPU Frequency: ~2 391 MHz
    Memory Write Test 0xF7 (512 MB, 16 Passes, Delay 200 ms)

    [PASS#] [MOVQ] [MOVNTQ]

    Pass 1: 2 044 MB/s 4 385 MB/s
    Pass 2: 2 109 MB/s 4 262 MB/s
    Pass 3: 2 111 MB/s 4 439 MB/s
    Pass 4: 2 040 MB/s 4 344 MB/s
    Pass 5: 2 117 MB/s 4 044 MB/s
    Pass 6: 2 110 MB/s 4 407 MB/s
    Pass 7: 2 060 MB/s 4 453 MB/s
    Pass 8: 2 062 MB/s 4 362 MB/s
    Pass 9: 2 096 MB/s 4 345 MB/s
    Pass 10: 2 114 MB/s 4 411 MB/s
    Pass 11: 2 111 MB/s 4 420 MB/s
    Pass 12: 1 989 MB/s 4 350 MB/s
    Pass 13: 2 119 MB/s 4 058 MB/s
    Pass 14: 2 118 MB/s 4 429 MB/s
    Pass 15: 2 080 MB/s 4 418 MB/s
    Pass 16: 2 096 MB/s 4 443 MB/s

    Min: 1 989 MB/s 4 044 MB/s
    Max: 2 119 MB/s 4 453 MB/s

    Dif: 6% 10%

    Вот тут винда что-то сливает на диск. Не знаю что, но он помигивает и в диспетчере задач появляются выгружаемые страницы у твоей проги и у других прог, а без задержки такого не происходит. Хотя 512 Мб - это 68% от свободной памяти.
     
  13. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    Clerk
    Согласен, в зависимости от системы, от числа процессов, их активности и приоритета - разброс по скорости работы с памятью может быть и большим. В идеале когда, активны только основные системные процессы, приоритет основного процесса (программы, тестирующей память) не играет практически никакой роли, поскольку процесс может спокойно использовать практически все временные и процессорные ресурсы в "свои" кванты времени (которые будут занимать более 95-97% от общего времени работы процессора из-за низкой активности других процессов). Так что разброс по скорости записи в память в нескольких проходах может быть как нулевым (в идеале), так и очень большим (до нескольких раз, в случае если другие задачи активно используют процессор или память (а шину памяти еще могут и разные периферийные устройства в режиме DMA занимать)).

    max7C4
    В оживании диска, нет ничего необычного. Прежде чем будет произведено обращение к страницам памяти, необходимо через диспетчер виртуальной памяти ОС выделить своему процессу часть виртуальной памяти (в виртуальном адресном пространстве этого процесса). При этом диспетчер памяти резервирует для использвоания набор виртуальных адресов. А после этого выделяет для зарезервированной памяти место в файле подкачки (как правило, незанятое место в файле подкачке всегда есть - остается только застолбить его за собой - никакой реальной перезаписи этой области при этом не происходит, до тех пор пока страничные фрэймы из физической памяти не потребуется выгружать на диск). Конечно, при этом придется сделать некоторые записи (в гораздо меньшем объеме чем размер выделенной памяти) в том и числе внутри файла подкачки и при этом возможно обращение к диску, но только в момент выделения.

    Поскольку для тестирования используется размер памяти, не превышающий объема свободной физической памяти (за вычетом некоторого запаса), то все зарезервированные за нами и выделенные страницы являются действительными, т.е. находятся в физической памяти и доступны немедленно.

    В момент работы теста никаких обращений к диску быть не должно (кроме обращений при запуске, когда память только выделяется). Если это не так - следует выделять для тестирования меньший объем памяти, выгружать мешающие несистемные процессы. Можно так же попробовать отключить файл подкачки.

    При запуске программа 1 секунду определяеляет примерную частоту процессора (точность порядка ~1%, так что на каждый ГГц частоты разброс может быть плюс минус ~10 МГц), используемую для определения времени тестов. Так что выделение памяти и, соответсвенно, кратковременное обращение системы к диску (если понадобится) будет через секунду после запуска.

    Кстати, результаты записи у тебя более-менее стабильные. Если не учитывать редкие проседания скорости, то разброс результатов укладывается в 10%. Просто современные процессоры иногда любят без нужды фоново кэшировать наперед то что им кажется нужным, используя для этого "широкие" возможности многоканальности и памяти DDR.

    Под "проседаниями" скорости имеются в виду подобные случаи:
    Код (Text):
    1. Pass 1:          1 993 MB/s        4 471 MB/s
    2. ...
    3. Pass 16:          2 100 MB/s        3 717 MB/s
    dead_body
    В твоем случае все в порядке. Разброс результатов в пределах нормы (для многозадачной системы), за исключением, быть может, подобных случаев (спишем на случайные системные процессы, не вовремя занявшие ресурсы):

    Код (Text):
    1. Pass 1:          1 150 MB/s        2 652 MB/s
    2. ...
    3. Pass 16:          1 435 MB/s        1 977 MB/s
    bugaga
    Неплохая стабильность результатов (на необремененной процессами системе так и должно быть). Хотя для MOVQ (и MOVNTQ) результат не превышет 17% (и 80%) от пропускной способности 100 Мгц, 64-битной шины памяти.

    Выставил FSB=100MHz на системе "i440BX+CelTualatin+SDRAM". В качественном отношении ничего не изменилось. Скорость записи через MOVQ - порядка 20-22% от пропускной способности шины памяти. А скорость работы MOVNTQ без задержек между циклами - всегда падает до уровня записи MOVQ. Примечательно, что в моменты когда MOVNTQ работает как положено (занимая более 93% от пропускной способности шины), запись через MOVQ так же происходит немного быстрее:

    Код (Text):
    1. CPU Frequency: ~1 201 MHz
    2. Memory Write Test 0xF7 (64 MB, 16 Passes, Delay 0 ms)
    3.  
    4. [PASS#]         [MOVQ]          [MOVNTQ]
    5.  
    6. Pass 1:         181 MB/s        745 MB/s
    7. Pass 2:         183 MB/s        745 MB/s
    8. Pass 3:         183 MB/s        316 MB/s
    9. Pass 4:         162 MB/s        163 MB/s
    10. Pass 5:         162 MB/s        163 MB/s
    11. ...
    12. ... в проходах 6-14 скорость такая же ...
    13. ...
    14. Pass 15:        162 MB/s        163 MB/s
    15. Pass 16:        162 MB/s        163 MB/s
    16.  
    17. Min:            162 MB/s        163 MB/s
    18. Max:            183 MB/s        745 MB/s
    19.  
    20. Dif:            12%             357%
    Аналогично, с недостаточными задержками для конкретного объема записываемых данных "всплески" скорости у MOVNTQ очень редки (СТРАННОСТЬ_0xF7):

    Код (Text):
    1. CPU Frequency: ~1 202 MHz
    2. Memory Write Test 0xF7 (256 MB, 16 Passes, Delay 1 000 ms)
    3.  
    4. [PASS#]         [MOVQ]          [MOVNTQ]
    5.  
    6. Pass 1:         165 MB/s        164 MB/s
    7. Pass 2:         162 MB/s        164 MB/s
    8. ...
    9. ... в проходах 3-10 скорость такая же ...
    10. ...
    11. Pass 11:        162 MB/s        164 MB/s
    12. Pass 12:        162 MB/s        164 MB/s
    13. Pass 13:        163 MB/s        751 MB/s
    14. Pass 14:        162 MB/s        164 MB/s
    15. Pass 15:        162 MB/s        164 MB/s
    16. Pass 16:        162 MB/s        164 MB/s
    17.  
    18. Min:            162 MB/s        164 MB/s
    19. Max:            165 MB/s        751 MB/s
    20.  
    21. Dif:            1%              357%
     
  14. max7C4

    max7C4 New Member

    Публикаций:
    0
    Регистрация:
    17 мар 2008
    Сообщения:
    1.203
    Кратковременно! Не знал, что мерцающая, как бешеная, лампочка диска от запуска (где-то через секунду) и до сообщения с результатами тестов - это одно кратковременное обращение. Но это происходит только при введение задержки ;)

    P.S. Можешь не рассказывать. Код я видел.
     
  15. bugaga

    bugaga New Member

    Публикаций:
    0
    Регистрация:
    1 июл 2007
    Сообщения:
    361
    BuilderPower
    Параллельно исследуя кой какие "странности", решил немного поизвращаться под Win95, нагружая кой какой активной работёнкой: OpenGL демки (одна из которых отлаживалась в довольно увесистой IDE D6), WinAmp, ну и тестовая прога MOVQ/MOVNTQ, для которой при отрубленой подкачке (paging=off в system.ini) нашлось 128MB (из 256Mb имеющихся).

    И тут загадка в том что, планировщик Win95 ничего о SSE регистрах не знает.

    Тем не менее при его активации, (прогой, прописаной в autoexec.bat)
    Код (Text):
    1.     C:\sseon.com      FRO --------       a16    
    2.  00000000: 0F20E0       mov         eax,cr4
    3.  00000003: 80CC02       or          ah,002
    4.  00000006: 0F22E0       mov         cr4,eax
    5.  00000009: C3           retn
    в OpenGL дровах Nvidia (видяха GF4MX440) врубаеться код активно юзающий SSE,
    (в которые ушел дебагер дельфей (на прилагаемом скрине)).

    По идеи (и дабы не быть глюкам), при смене задач должны сохраняться/востанавливаться и XMM регистры, а чето все работает.

    Cтранно, блин..

    зы: Хотя в целом, особого прироста скоросте в рендеринге увеситсых OpenGL сцен, скажем в "Return To Castle Wolfenstеin" (QuakeIII движок), при активации SSE я чето не особо заметил.
     
  16. Black_mirror

    Black_mirror Active Member

    Публикаций:
    0
    Регистрация:
    14 окт 2002
    Сообщения:
    1.036
    BuilderPower
    Запускал аналогичную програмку под досом, записывал кусок в 1 Гб. Для замеров использовал rdtsc, какая частота проца и памяти не знаю(он просто в режиме пониженной производительности по умолчанию грузится). Со STOSD было в основном 3632xxxxh тактов, иногда провалы до 362Dxxxxh, c MOVNTQ было 1711xxxxh тактов, иногда провалы до 170Cxxxxh. В процентах это не более одной десятой. Если ставить задержки, то иногда идёт несколько провалов подряд, а потом всё нормально, хотя общее количество провалов особо не меняется, не исчезают даже при очень больших задержках, Возможно что иногда процессор уходит в SMM для обслуживания или эмуляции каких либо девайсов.
    Попробуй на этом странном компе поотрубать в биосе встроенные модемы или аудио, на некоторых платах часть их функций выполняется процессором программно.
     
  17. BuilderPower

    BuilderPower New Member

    Публикаций:
    0
    Регистрация:
    14 июн 2008
    Сообщения:
    6
    bugaga
    При нагрузке на процессор со стороны других потоков вполне логично, что будут такие колебания в скорости, поскольку начинают появляться моменты, когда шина памяти готова к передаче новой информации, а процессор еще занят - и пропускная способность может проседать хоть в десятки раз. Другое дело, если бы такое было при работе только одного "тяжелого" потока пишущего в память без задержек (как в тесте MEM_0xF7).

    А заметное ускорение рендеринга увесистых OpenGL сцен при активации SSE будет возможно только в случае, когда ограничивающим фактором является процессор, а не пропускная способность шин "процессор-[чипсет]-память", "процессор-чипсет-AGP". К тому же что бы что-то ускорилось от SSE, в драйверах и в программе рендеринга должна использоваться грамотная оптимизация под SSE.

    В свою очередь движок Quake III использует технологии которые были до 1999 года. Логично предположить, что никакой оптимизации под SSE там даже близко не было, поскольку в том же году только-только вышли первые процессоры Pentium III с поддержкой SSE.

    Black_mirror
    Даже в "голом досе" будут небольшие колебания (доли процента) скорости хотя бы по аппаратным причинам. Никто не отменял логику самого процессора - когда он сочтет нужным он может кэшировать наперед некоторые области памяти (если не данных, то кода). Так же вероятно обращение других устройств к памяти.

    На 6BTM(i440BX) никаких встроеных модемов, сетевых и аудио карт - нет. Все таки это плата 1998 года, тогда такой моды еще не было. Из встроенного только - контроллер UDMA33 в южном мосте чипсета 440BX. Отключение PCI устройств (с выниманием из слота) ничего принципального не изменяет. Аналогично, никакие настройки BIOS'а на проявление СТРАННОСТИ_0xF7 не влияют.
     
  18. leo

    leo Active Member

    Публикаций:
    0
    Регистрация:
    4 авг 2004
    Сообщения:
    2.542
    Адрес:
    Russia
    BuilderPower
    Замечания по "теоретической части":
    Не надо идиализировать процессор - это простая железяка с элементарной жестко прошитой логикой, поэтому высказывания типа "если сочтет нужным\оптимальным" совершенно не уместны. Любые обращения к памяти, в т.ч.prefetchX и movntX, всегда выполняются по цепочке хит-тестов store_buffers->L1->L2->bus_queue, поэтому prefetchX и movntX могут "не выполниться как предполагается" только в том случае, когда соответствующая им линейка адресов уже находится в кэше или в очереди на загрузку в кэш. Плюс к этому prefetchX на некоторых процах (ниже P4 Prescott) не грузят данные при промахе TLB.
    Логика работы movntX "сожнее" только в том плане, что
    1) записываемые данные накапливаются в WC-буферах размером с линейку кэша и если буфер заполнен полностью, то он целиком сбрасывается в ОЗУ, если же не полностью то запись в ОЗУ производится отдельными пакетами и ес-но медленнее, чем целиком;
    2) набор WC-буферов используется как для NT-записи, так и для обычных WB записей для временного хранения данных пока соответствующая им линейка не загрузиится в кэш из ОЗУ (поэтому не рекомендуется мешать movntX с обычными записями, ну и ес-но с чтением данных из той же линейки).
    Поэтому если производится последовательная movnt-запись большого блока, соответсвующих адресов нет в кэше и нет мешающих wb-записей, то заполнение и сброс в ОЗУ WC-буферов должны производиться со стороны процессора "ровно и гладко" без всяких эксцессов и чудес. То, что у тебя после movq в кэше оседают последние 256К данных погоды не делает, т.к. основной объем данных в режиме movnt пишется нормально. Хотя не понятно, зачем нужно "интерливить" тесты c movq и movnt - раз тебе с movq все понятно, то лучше их или убрать совсем или хотя бы не чередовать с movnt.

    Вывод: Процессор - "пенек" и сам по себе влиять чудным образом на одинаковые проходы тестов он не может (если только не перегревается и не снижает частоту или не уходит в тайм-аут :D ). Поэтому странная "странность_0хF7" может быть связана либо с подпольной деятельностью винды (свопинг или переключение потоков), либо что-то с чипами памяти (например, перезарядка неиспользуемых банков памяти; кстати у DDR\DDR2 независимых банков больше, чем у SDRAM, поэтому возможно их презарядка меньше сказывается на скорости записи).
    PS: Для чистоты эксперимента все же лучше 1) убрать movq, 2) задать реал-тайм приоритет процессу, 3) до кучи - записывать разности тиков в заранее выделенный массив, а расчеты и и формирование строки для вывода делать по окончании теста, 4) не спорить о возможности\невозможности свопинга, а проверить по счетчикам производительности (аль еще как :)
     
  19. bugaga

    bugaga New Member

    Публикаций:
    0
    Регистрация:
    1 июл 2007
    Сообщения:
    361
    В принципе еще прерывания от железа и их обработчики, могут вносить свой вклад в копилку странностей, ибо операции ввода/вывода в порты, оч. тормозные (что от чипсетов очень сильно зависит).
    BuilderPower
    Самое странное как на ней пашет Сeleron T :) А то помниться, попытки запустить его на GA-6BX7 (вроде класса 440Bx), тишина полнейшая. Да и плата сама по себе, не сказать что стабильная (глюки с отображением частоты CPU, зависоны на 133mhz). Вобщем тот еще дом с привидениями.

    Смены видюхи :-D Стоит воткнуть допустим GF2MX400, как тормоза заметно подскочат, несмотря на то что в дровах рубаються пачками XMM скаляры. На вскидку - выигрыш которые они дают в этом случае, процентов 15 от силы.

    p.s Впрочем, все это относиться к мега-надстройке на дос-ом, 95-ому мастдаю.

    Хм.. надо подумать насчет подмены значения CPUID в w2k насчет фич всяких и вкусностей.

    Вон думал с HAL.DLL подерживающим 1-метровые страницы на гаме FAR CRY винда хотя бы меньши будет винт теребить свопом. А куда там - фигли 256мб RAM всего. Из за того что PAK-и zip-ованые, используються в игрухе. А вот у GTA San Andreas полет нормальный, даже при наглухо вырубленом свопе.
     
  20. PROFi

    PROFi New Member

    Публикаций:
    0
    Регистрация:
    13 июл 2003
    Сообщения:
    690
    BuilderPower

    Дело видимо в регенерации памяти - той которая не используется. Есть ли зависимость от объема установленой памяти? Числа планок памяти?