Здравствуйте. При хэшировании нужно: 1. После процесса хэширования файл д.быть таким же посодержанию что и до хэширования 2. Хэширование должно быть как можно более быстрым Чтобы захэшировать файл, я его с проектировал на память и через MapViewOfFile получил указатель! Как я понял из ISBN_5-469-01174-7,5-7502-0085-x: 1. куда бы я не обратился,данную область память предоставит мне ОС сама! 2. К тому же она не будет записывать данные из спроецированного файла в файл подкачки! Все вроде бы хорошо но передо мной встала такая ситуация: По документации FIPS180-2 работа идет с порядком, где старшие разряды начинаются с кране-левого разряда цифры и в сторону "право" разряды теряют свой вес к пр.1: Пр.1: 100d - это сотня Когда же начинается реализация алгоритма для процессоров x86, то естественно львинная доля выпадает на работу команд с регистрами, а здесь уже вступает особенность, что при попадании значений в регистры порядок байт меняется! Если в памяти было: 01 02 03 04 то в регистре будет уже: 04030201 А это уже другая цифра!!! Чтобы легко было конверить из одного порядка в другой можно применить команду bswap, но тогда таких команд будет довольно много! Вопрос: Можно ли как то обойтись без команды bswap ? По Асе получил: 1й хороший чувак: я думаю, нет. тем более, что BSWAP очень быстрая, хорошо распаралелливается и пр. 2й хороший чувак: можно без неё, но я использовал ЗЫ: Перед окончательной реализацией хочется послушать еще советов!
Пока сделал так: Контстанты и хэши закинул в секцию экспорта, fasm.exe когда создает dll все dword`ы, так сказать bswap`ит! В итоге часть данных уже так как надо! Когда подоготавливаю рабочие слова стр. 19 FIPS180-2, то в цикле 0 =< t =< 16, кидаю 512битный блок в W так чтобы: 1. dword`ы прошлии через bswap В итоге, вся арифметика становится нормальной! Можно ли избавиться от 1. ?
Это Реализация на фасме! Вычисление хэша sha256calculate, получилось быстрее чем считает WinHEX 12.2 SR-11 )) Рулез, протестируйте пожалуйста! Вот экпортируемая функция: sha256calculate,hFile,pHash,Count Здесь: hFile - Хэндл открытого файла подвергаемый хэшированию pHash - указатель на 32Байтную область памяти, здесь в результате функции будет хэш Count - Размер файла в байтах! Если кто-то еще может оптимизировать, буду только рад! _1103617469__hash.rar
EvilsInterrupt > "c проектировал на память и через MapViewOfFile получил указатель!" Не слушаешь ты добрых советов При последовательном чтении маппинг не дает никаких преимуществ по сравнению с блочным чтением, кроме кажущейся простоты. А вот минусы есть. Во-первых, файлы >= 2Гб просто невозможно спроектировать целиком - MapViewOfFile просто вернет Null (интересно, что ты при этом будешь делать - сам выдашь тысячу извинений изверю или предоставишь ОС "отправить отчет" в Microsoft о твоей неста(де)бильной программе ) Во-вторых, маппинг нормально работает, когда размер MapView меньше размера доступной физ.памяти, а если больше то кранты . Не знаю как эдвансед-серверы руководят маппингом, а вот ХРюша просто тупо засирает практически все ОЗУ и когда свободной памяти начинает не хватать, она кидается выбрасывать в файл подкачки все, что по ее неразумному мнению мешает твоему маппингу. Так что не беспокойся, твои данные в своп не улетят - улетит все остальное. Разве это не тупость - держать 256, 512 и т.п. метров ненужных давно обработанных данных и выгружать код и данные которые могут скоро понадобиться ?!! Ну и разумеется возникающие при этом тормоза зависят от того, сколько у тебя в системе параллельных процессов висит - открой парочку pdf-чиков со своей документаций и запусти обработку файла раза в два превышающего размер ОЗУ - тут даже системный монитор включать не нужно, по дикому верещанию диска и ужасно тормозного оживления системы после такого стресса поймешь, что к чему. Вывод: ОС сделает за тебя не все, а то что сделает, то не самым лучшим образом. Поэтому для надежности лучше проецировать файл "разумными" кусками. Ну а если кусками, то это ничем не проще и не лучше чем обычное блочное чтение. Теретически это хуже, т.к. при каждом Unmap\Map ты освобождаешь один блок памяти и выделяешь новый, каждый раз наступая на грабли отказа страниц при чтении, хотя практически время обработки этих отказов достаточно мало по сравнению с временем чтения данных из файла.
leo Блин, знаю что читать и читать книги, что и делаю, как жалко что знания не за один день приходят! )) Спасибо, буду думать
leo И блин, как уж так можно дать сначала прянник через CreateFileMapping,MapViwOfFile, а потом забрать, еще раз прочитал твой пост! Блин, кроме как Сволочами их больше ни как не назовешь!
