Вобщем задался изучить программирования с исползованием fasm. В качестве задачи выбрал реализовать хэширование файла. В чем заговоздка, файл будет не более 4Гб! Точное число это макс.число умещающееся в 32 бита! Проецировать файл размером 3Гб о-го-го! значит открывать и считвать его данные, но куда? Правильно в буфер. Каков должен быть размер данного буфера? Почему не могу определиться: 1. Выделить большой не рационально испоьзовать память 2. Маленький буфер, слишком много циклов при обработке больших файлов Совет от PolASoft использватать 4Кб на буфер вполне логичен, но может быть все таке есть решение дающее однозначный ответ на этот вопрос?
Поясни, зачем тебе нужно хэшировать такие здоровые файлы? Может проще считать хэш-функции начального куска (надо только его размер выбрать)? Ведь я так понимаю, чем длиннее файл, тем он уникальнее...
1. Пытаемся создать модель с функцией полезности, максимум которой будем достигать. 2. Обнаруживаем, что количественной меры для фразы "нерационально использовать память" нет. 3. Задумываемся над этим фактом и осознаем, что для загруженного под завязку ОЗУ на компьютере со 128 Мб и для простаивающего 1 Гб ОЗУ рациональной длиной буфера будет разная величина. 4. Хочешь ли ты озабочиваться получением объема ОЗУ и доли свободного места в ней при каждом запуске программы ? Наверное - нет. 5. Тогда выбери какое-нибудь не слишком маленькое и не слишком большое значение, и забудь о своей проблеме. А если по делу - я обычно беру 16 кб для подобных вещей (хеширование, блочное шифрование и т.п.).
EvilsInterrupt leo мне как-то говорил, что смысла создавать буфер размером более 64Kb нет, и он прав. Имненно при таком размере буфера достигается макс. производительность.
Мнда... а что далать, если нужно обрабатывать большое файлы(2Гб к примеру) целиком? Ведь бывают же такие ситуации...
При выборе размера надо еще учесть: 1. Размер буфера упреждающего чтения операционки (если таковой поддерживается) 2. Размер буфера, используемого в реализациях функции чтения на разных языках программирования 3. Особенности кэширования данных на компьютере
OlegA11 Некоторые серверные версии винды потдерживают до 64Gb памяти. Видимо там это можно сделать без проблем. Это что касается 32bit'ных Windows.
S_T_A_S_ распечатать в хекс виде на эран? Тяжеловато просмотреть около миллиона экранов (80 х 25 символов)
EvilsInterrupt если не мапить, сколько ты времени потратишь на пересчет своего файла, не забывай, что проще это сделать через мап, поскольку все что для этого необходима за тебя плдумает ос, почитай лучше Руссиновича главы о памяти и файловых системах, сам всё поймешь
Я вот тута задумался еще вот над чем, если проецировать, то с помощью MapViewOfFile я получу указатель на область. Учитывая факт что данные надо еще подготовить, а это тпроцесс заключается в их дополнении в конце и именуется он словом padding соглассно доке FIPS180-2. Вот и подумал а можно ли данные разбить на 2 региона? так сказать, если поделить основную часть на n байт то это pMem1, а конечные m байт данных это pMem2, причем так чтобы в этом регионе еще бы добавилось в конце k байт указанных мною! Пока я это делаю так: работаю с n байт, а m байт копирую в другой буфер, дополняю и обрабатываю, но это слишком, на мой взгляд, не удобно. Есть ли способ лучше?
CARDINAL Громадный респект за совет, я почитал и понял. свою dll тебе первому вышлю, чтобы твой взор первым глянул, а если найду тебя в базе по асям и мылам ))
Глянь, например, RFC1320/1321 и посмотри как там реализованы MD4/MD5. Тебе совсем не обязательно чтобы блоки данных располагались в памяти непрерывно; тебе также абсолютно не нужно дописывать в конец данных padding...
flankerx Я обязательно гляну, то что ты предложил. Но пока передо мной FIPS180-2 и открыта она на стр.12. Там то и сказано,что данные "5.1 Padding the Messaage", было бы неплохо для собрания прояснить то, что ты хотел сказать. зы: Глянул, тут: http://www.protocols.ru/modules.php?name=Downloads&l_op=getit&lid=183 http://www.protocols.ru/modules.php?name=Downloads&l_op=getit&lid=182 И в обоих сказано, что добавлять надо и этот алгоритм подобен SHA-256!
EvilsInterrupt Да, padding нужен... Но ты все же глянь в указанные RFC на предмет того, как его можно добавить без каких-либо сложных извращений (см. собственное сообщение от Мар 18, 2006 11:42:24)...
А в чем проблема с дополнением? Всего-то нужен буфер 128 байт, и скопировать последний кусов в него... Можно и без буфера, но сложность возрастет, а скорость упадет =)
S_T_A_S_ Именно так щас и делаю! блин, но привык как то уж по тупому на пролом парсить подряд идущие байты! Вот пока не прочитаю то что сказал Cardonala окончательно не определюсь чего надо делать лучше! А пока ставлю LiveKD )
