MD5. Оптимизировать... раза в три.

либо это рам-диск, либо рейд-массив солидный, либо с запятой опечатка - за 12 секунд 700 мб тоже далеко не всякий винт потянет, но уже ближе к реальности

 

masquer
Нет. Обычный трехсотгиговый винчестер... без RAID. Собственно я все понял/объяснил в предыдущем посте.
P.S. Т.е. не совсем все, т.к. остался один открытый вопрос.

 

Не верю, что ни у кого нет идей, почему асм-вставка не работает быстрее после того, как файл скэширован. Имхо такое могло бы быть возможно, только если бы я распараллелил чтение из файла и вычисление хэша, и вычисление хэша при этом занимало бы не меньше, чем чтение из файла. Или я не прав? Объясните чайнику, в чем дело.

 

l_inc
просто ни у кого нет идей почему у тебя чтение 700Мб файла занимает 1.2 сек

 

А если промэпить файл?

 

а если файл больше 2 Гб?

 

Проверять размер, если больше то не мэпить. Я думаю что файлы больше 2 ГБ будут встречаться реже.

 

Лучше проверять результаты мэппинга, а не размер файлов, т.к. даже далеко не всякий файл до 2х Гб в размере и далеко не на каждой системе отмеппится... Непрерывное виртальное адресное пространство тоже не резиновое...

 

Код (Text):

1.     @@:
2.         ROL ECX,1
3.     ADD AL,-1
4.     JNZ @B
5. ; -- Можно заменить на --
6. xchg    eax, ecx
7. rol     eax, cl
8. xchg    eax, ecx

Не много, но все же..

 

flankerx

Как это нету? А как же предложение t00x прекрасно подтверждаемое экспериментальными данными?
im1111

Но если я чтение с винчестера без подсчета MD5 запускаю, то кэширование виндой файла влияет 15-кратно на скорость работы не зависимо от того, промаппировал я файл или нет, а вместе с подсчетом практически не влияет (это для старого варианта... для варианта KeSqueer см. ниже). Почему маппинг должен как-то повлиять? Кроме того меня слегка отпугивает аргумент asmfan:

KeSqueer
НИФИГА СЕБЕ НЕМНОГО!!! КЛАССНО! Вся вставка более чем вдвое быстрее заработала... (24,3 сек снизилось до 11,2 секунд) А я... тупица... знал же, что сравнительно долго работать будет... а значения большого не придал... не думал, чтобы аж настолько. Спасибо. Но теперь экспериментальные данные меня вообще в тупик ставят:
Вариант с

Код (Text):

1. @@:
2.     ROL ECX,1
3. ADD AL,-1
4. JNZ @B

(старый вариант)
Разница между временем кэшированного и некэшированного виндой файла - максимум 1-1,5 секунды.
Вариант с

Код (Text):

1. XCHG EAX,ECX
2. ROL EAX,CL
3. XCHG EAX,ECX

(новый вариант)
Разница между временем кэшированного и некэшированного виндой файла - в два раза!!! Т.е. 8 сек (кэшированный) - 16,2 сек (некэшированный). 11 сек (кэшированный) - 22,5 сек (некэшированный). Это все для семисот мегабайт, но при разных состояниях системы (уж сильно зависимо время работы проги от состояния системы).
ИМХО единственный вариант, который может согласоваться с экспериментальными данными - это винда сама распараллеливает чтение данных из файла и расчет MD5. Такое возможно?
И что еще более странно: время работы проги-пустышки (без подсчета MD5) для некэшированных файлов на несколько секунд больше, чем время работы проги с вариантом, предложенным KeSqueer (разумеется тоже для некэшированных файлов). А для кэшированных: пустышка - 1-1,2 сек; вариант KeSqueer - 8-11 сек.
(все данные для семьсотметровых файлов)

 

Что-то предположение о кешировании 700-мбайтного файла мне кажется не очень реальным... Сколько у тебя оперативки в системе?

Нет.

 

flankerx
2 ГБ. Поэтому ИМХО вполне реально. Мало того: два 700-метровых файла тоже полноценно кэшируются... иначе те скорости, которые я получаю экспериментально, никак не объяснить.

Ну тогда как же объяснить все выше полученное?

Я тут еще заменил кое-что, избавился от 8-битных регистров (не считая ROL), убрал пару лиших команд и выиграл на этом еще до двух секунд. Сейчас нахожусь где-то на 7-10 секундах (для кэшированного файла). Т.е. еще бы раза в два и будет что-то, что уже можно будет использовать в других прогах (хотя это еще не 2-3 секунды, как у eXpress CheckSum Calculator'а). Прикладываю, что получилось.
P.S. Ой. Забыл комментарии к процедуре CP поменять, но думаю и так понятно.

 

ну еще можно такое позаменять:

Код (Text):

1. or      reg1, -1
2. xor     reg1, reg2

на

Код (Text):

1. mov     reg1, reg2
2. not     reg1

 

KeSqueer
Хм... на этом я вообще никакого прироста производительности не получаю. Хотя я думал, что первый вариант работает быстрее, поэтому его использовал. Но раз второй вариант на байт меньше занимает, оставлю его.

 

l_inc
на сколько возросла производительность?

 

t00x
За счет каких изменений? (т.е. я вроде все приросты производительности приводил)

 

l_inc
с 20 до 7-10 секунд?
а виртуальный диск не пробовали использовать ?

 

t00x
В смысле? RAM-диск создать? Если да, то чем это лучше обычного чтения в память? Или это просто в качестве теста на производительность? Или чего я не понимаю?

 

l_inc
да, протестить с RAM-диска.

 

t00x
Попробовал на RAM-диске. Результаты те же, что и на скэшированном с винчестера файле.
Единственное что... когда я слегка подзабил оперативную память (при наличии RAM-диска), то повторный подсчет для одного того же файла с винчестера перестал (или почти перестал) давать прирост в скорости, но это и понятно: винда перестала кэшировать файл.