Да, надо ещё какой-то тест, а то атлон показывает себя в плохом свете В аттаче алго шифрования TEA, намного медленне RC4 из-за кол-ва раундов и оперирует только двордами, тоже для 10Кб (PIII ~770000 \ P4 ~830000 тактов) _1002906394__xtea.zip
bogrus я просто убрал всё выравнивание и вот что получил( ты без нопов пробовал ?). Камень - Duron 900 dr_dred понятно что твой код гораздо приемлемей использовать т.к скорость не зависит от степени, но всё же у меня работает медленней (твой 267 тиков, мой 252). И я не смеюсь ! 1012556557__Untitled_1.gif
bogrus надо просто выводить среднее число тактов, увеличить кол-во проходов (1000-2000), т.к. неудобно сравнивать
TEA для 10Кб (AXP2000+ @1666MHz) --------------------------- 00404490 / 109 bytes / 10 passes --------------------------- 000000000000000000720217 000000000000000000656676 000000000000000000666861 000000000000000000656656 000000000000000000656656 000000000000000000674645 000000000000000000656669 000000000000000000667777 000000000000000000656656 000000000000000000656656 --------------------------- ЗЫ: зачем аттачить картинки? В XP можно сделать Ctrl+C
Sonic На дюроне это может не страшно, убрав нопы перед циклом ты сократишь результат всего на несколько тактов, а убрав их в PIII ты можешь увеличить весь результат в несколько раз! из-за постоянных пенальти, конечно это зависит от тестируемого кода и камня, но лучше перестраховатся (данных это тоже касается), мы ведь хотим при тестах максимально снизить погрешность а выжать максимум Имхо не надо, меня например часто интересует результат первого прохода (когда данные ещё не в кеше), остальные проходы почти одинаковы и полезны для определения как та или иная инструкция поведет себя в конвеере (без учета промахов кеша и т.д.), вообще обычно достаточно 3-5 проходов для определения картины S_T_A_S_ В w2ksp4 тоже кстати, короче Intel\AMD ничья
Извини, Sonic, я по соим результатам писал. 267, 252? У меня сейчас челюсть упадет. У меня 1120(мое), 3017(твое (_Math)) при подсчете 2<sup>32</sup>. Это же разница в 5-15 раз! Какой у тебя процессор? А rdtsc вообще что считает - число тактов на 1 процесс или сколько вообще тактов совершил процессор? Может эта команда вообде не считает такты FPU, или наоборот только их? Или это у разных процессоров по-своему?
Вот ещё AES. Фактически измеряется режим ECB, но режимы с обратной связью не должны сильно отличаться. Точность теста невысокая и измеряются не такты, а скорость, поэтому результаты будут зависить от частоты CPU. Код (Text): key | key expansions/sec | encryption, bytes/sec | decryption, bytes/sec 128 bit | 1157368 | 63072240 | 63310249 192 bit | 972705 | 51150048 | 53601329 256 bit | 818560 | 46603377 | 46733192 474487223__aes.exe
dr_dred я ошибалься процедурка отличная, я думал она возводит только в целые степени, буду всячески использовать. А такты такие как есть 267 на Duron 900 _884847055__Math.exe
Sonic > "log2(1/value) используется т.к. вроде при использовании FYL2X -2*sqrt(2)<=ST(0)<=2*sqrt(2)" Логарифм орицательного числа - это нечто новое ST(0) должно быть просто положительным числом (non-zero psitive number), поэтому никакого деления тут не нужно. > "А такты такие как есть 267 на Duron 900" > "Сколько тактов занимает его выполнение на вашей машине ? " Ты откуда такие цифры взял, для niter = один-два-три или ты уже нечто другое изобрел ) А получаемую точность при малых niter смотрел ? А у нас вот что получается: Код (Text): Метод P3 P4 1234567890123456 < число знаков, qword дает 15-16 ----- ---- ----- ----------------------- calc.exe 48.5029301283327386 = 2^(5.6) std+agner 217 812 48.5029301283327<font color="red]266</font><!--color--> std 239 824 48.5029301283327<font color="red]266</font><!--color--> Sonic32 1360 2384 48.5029301283327<font color="red]266</font><!--color--> Sonic28 1217 2196 48.5029301283327<font color="red]110</font><!--color--> Sonic24 1045 1984 48.502930128<font color="red]2925078</font><!--color--> Sonic20 873 1874 48.502930<font color="red]0728178969</font><!--color--> Sonic16 701 1512 48.502<font color="red]8933136016717</font><!--color--> где std - стандартный метод вычисления std+agner - стандартный метод с заменой FSCALE на целочисленное вычисление 2^i по Агнеру Фогу Sonic32 и т.д. - "супер" метод _QPower c соответствующим значением niter P3 - Pentium III Coppermine (CPUID 6.8.6) 800MHz P4 - Pentium 4 Northwood (CPUID 15.2.7) 1.8 GHz > "Как можно оптимизировать прилогаемый код ?" Выбросить в корзину и использовать стандартный алгоритм )) Если вооружиться табличкой латентностей от А.Фога, то увидим что якобы большие задержки FRNDINT и FSCALE на самом деле не такие большие по сравнению с FDIV\FIDIV, поэтому уже пара-тройка делений сводит на нет все старания что-то "оптимизировать"
Ты всё перепутал 267 для проги, что прилогается. Sonic32 у меня отработал за 1140 _1918312627__Math.exe
Сейчас-то уж точно у меня челюсть выпадет. Провел небольшой эксперимент. В начале процедуры убрал finit, а в конце добавил ffree st(1) ffree st(2) Получилось , что процедура стала работать в 4 раза быстрее (теперь 405 тактов вместо 1500). Не знаю, прокатит-ли это с втоим процессором. Попробуй, но, так как ты еще используешь st(3) (в _math) и st(4) (в math), то их тоже освободи перед ret'ом. В аттаче то, что получилось у меня. p.s. все же незачем делать -power и 1/value. Результат тот же, но тактов меньше. _523635404__Math.zip
[offtop] пожалуйста, не прицепляйте аттачи с русскими буквами в названиях - броузеры вроде IE и Opera их не качают [/offtop]
dr_dred > "В аттаче то, что получилось у меня" Ну, молодец, наконец то ты пришел к стандарному коду (у меня в табличке он значится как std). Садись, пять )) PS: А чтобы "челюсти не выпадали" загляни в таблички латентностей FPU в IA-32 и pentopt.pdf от Агнера Фога. Тогда будешь иметь представление: что оносительно быстро, а что медленно на PII/PIII и P4 и на сколько Sonic Ну а тебе, милый, следует трояк влепить )) 1) Ты водишь общественность за нос, меняя на ходу алгоритмы, да еще не прилагаешь исходники - одни "супер" ехе-хе 2) В итоге все равно получась фигня, и dr_dred тебе уже указал на ошибки - до стандартного метода ты не дотянул и используешь дурной стиль: вместо нормального освобождения стека fpu суешь finit где не надо (я, кстати, в своем тесте эти твои выкрутасы выкинул для чистоты эксперимента). ================ И вообще я не понял смысл этого топика - думал какой-то супербыстрый метод возведения в степень изобрели или вычитали, а тут какие-то контрольные работы (( Вот если "изобрести" быстрый метод определения того, что степень целая и перескакивать на быстрый метод умножения, то было бы интересно для общего развития
Мне кажется очищать регистры надо в начале, по этому поводу вопрос можно ли использовать для этого вместо finit emms ? Скорость реально растёт и ошибок вроде нет. И ещё, в прилагаемом примере результат записывается в t, если же записывать результат в x, скорость возрастает в 2 раза – 103 такта !!!, почему так ? _1608906440__Math.zip
Sonic > "если же записывать результат в x, скорость возрастает в 2 раза – 103 такта !!!, почему так ? " А ты в Math_t возьми x = 1.0 и получишь такой же результат )) Тебе уже объясняли ситуацию, только тогда у тебя cтепень была > 1 и число Х нарастало до бесконечности. А теперь ты взял степень = 0.5 и пытаешься крутить цикл аж 16348 раз. Но X "быстро" становится 1й и логарифм в fyl2x вычисляется "мгновенно" (ты же не считаешь Intel и AMD идиотами )) > "Мне кажется очищать регистры надо в начале" Ага, а как такие суперфункции использовать - только для вывода числа на экран или в файл ? А если надо вызвать функцию внутри кода для последующих FPU вычислений, то после call еще и finit\emms вызывать чтобы не нарваться на исключение ? Все таки по нормальному каждая функция должна сама убирать за собой мусор перед возвратом, чтобы не загадить последубщий код, а finit делается в проге один раз при инициализации. > "можно ли использовать для этого вместо finit emms ? Скорость реально растёт и ошибок вроде нет" Ну если тебе в лом использовать ffree\fstp, то тогда конечно лучше emms, чем finit. EMMS просто помечает все регистры FPU как свободные. FINIT еще сбрасывает control и status регистры. А control-word между прочим управляет точностью, округлением и маскировкой исключений. А маскировать три важных исключения (инвалидная операция, деление на 0 и переполнение) не рекомендуется - хлопот не оберешься при поиске возможных глюков. А вот FINIT их старательно маскирует. Поэтому в "серьезных" прогах FINIT делают один раз и затем устанавливают свое значение Control Word. Поэтому запихивать finit внутрь функции - имхо нонсенс, если эта функция не только для баловства )) PS: А зачем ты в очередном варианте frndint на fistp+fild заменил - думаешь так быстрее ?
После всех include и includelib добавьте include \masm32\include\debug.inc includelib \masm32\lib\debug.lib Задайте edi значение 40h. Потом shr speed,6. Перед ret'ом в qpower'е пропишите DumpFPU Запустите скомпилированную программу и сообщите результаты. Поэксперементируйте с emms, finit, fstp st(1). Судя по дампу, нужно в начале ставить finit, в конце одну инструкцию fstp st(1) (в моей программе). Но скорость больше, когда finit отсутствует, а в конце две команды fstp st(1). Что-то до меня никак не допрет, почему так происходит. p.s. о возможности отладки я знал, но никогда не пользовался. Если такие файлы (debug.inc и debug.lib) отсутствуют, в masm32 есть папка vkdebug, в ней setup. math_x 1500 ticks math_t 1100 ticks
