J0ker, эти строчки - nop. они ничего не делают. И таких строчек в том коде много. Вы вообще смотрели тот код который выложили? Да там оптимизацией и не пахнет.

Добавлено через 6 минут
По оптимизации - вот это вот
004016DE  push        ecx  
004016DF  fld         dword ptr [esp+38h] 
004016E3  fstp        dword ptr [esp] 
004016E6  call        00401650 
заменяется на
push dword ptr [esp+38h]  
call 00401650
и т.д. и т.п.

не верите? проверьте в ольке 

да неужели?
а давайте проверим - вот конкретно эти строчки

вы мысль улавливаете, да?  

Добавлено через 1 минуту и 32 секунды

только если нет преобразования типов
ага   

J0ker, уловил. Только в чем смысл округления 80-разрядного значения в стеке сопроцессора до 32-разрядного? Я чтото не представляю себе жизненных случаев где это может пригодиться.

Добавлено @ 23:33
мм... развечто при сравнении... так тогда и надо округлять перед сравнением, а не всегда и везде, иначе какая это оптимизация %)


так или иначе, разговор начался с копирования float в стек, *уже округленного* float в стек.

Это сообщение отредактировал(а) GoldFinch - 8.12.2008, 23:35

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

Добавлено через 10 минут

это вы знаете, что у вас там float, а процессору это нужно доказать   

Так я и не понял с этими отрезаниями.....
У меня в памяти есть 32-разрядный float. Готовый, правильный, безо всяких подвохов float. Почему компилятор не копирует его в стек командой push [mem32], а генерит fld [mem32] / fstp [mem32] ?? В стеке же оказывается одно и тоже значение...

кто невмещает? в С++ нет 10-байтового вещественного чтоли?

Добавлено через 2 минуты и 56 секунд
действительно нет.... везде есть, а в С++ нет.... как же так %)

c'est la vie

что доказать????
004016DE  push        ecx  ; sub esp,SizeOf(dword)
004016DF  fld         dword ptr [esp+38h] 
004016E3  fstp        dword ptr [esp] 
004016E6  call        00401650 
float и dword это одно и то же, что тут доказывать процессору?

опа, вот и я не прав
long double в стандарте оказывается... проморгал 

Добавлено через 2 минуты и 34 секунды

я ж вам уже сказал - что у вас там лежит в памяти известно только вам

Итак, it's a showdown!!!

Алгоритм - интегрирование методом трапеций. Интегрируется косинус, при этом специально не используется его свойство периодичности. В общем, смотри код:


Код, кстати, кроссплатформенней некуда. Компилировал с помощью MinGW со следующими параметрами=:

g++ -msse3 -mfancy-math-387 -m80387 -mhard-float -mtune=pentium4 -march=pentium4 -mthreads -mfp-ret-in-387 -mieee-fp -O3 -funroll-loops  -o showdown.exe showdown.cpp

После этого прогнал через strip:
strip -s showdown.exe

Прикладываю экзешник. Удачи, чувак   

Присоединённый файл ( Кол-во скачиваний: 7 )
 showdown.rar 89,97 Kb

Kallikanzarid, ты бы перед тем как выкладывать код с бинарником, убедился бы в их качестве
код - неудобный, хз как у вас а меня еще в школе учили в конце консольной программы вставлять паузу.
функция - неоптимизирована, про использование for я вообще промолчу... 

а самое главное, в бинарнике видно что компилятор заинлайнил cosint() и заменил ее аргументы константами.
получилось както так:

так и было задумано?) а что сразу так не написал?)))

GoldFinch,

1) За годы практики я убедился, встроенная в саму программу пауза - это зло. Намного лучше создавать для этой цели .bat-файл.
2) Я специально ничего не оптимизировал, чтобы функция выполнялась достаточно долго, и чтобы компилятор мог проявить себя в раскрутке циклов и т. д.
3) for и правда не самый оптимальный (и, к тому же, накапливающий погрешность), но мы ведь спорили об оптимизации FPU-кода, так? Вот я и стараюсь загрузить его по максимуму.
4) Инлайн есть гут  Оптимизирующий компилятор ведь должен оптимизировать, так? Но в любом случае я сомневаюсь, что один дополнительный вызов бы сделал погоду.
5) Да, так и было задумано 

Добавлено через 3 минуты и 8 секунд
float вместо double я тоже использовал в своих корыстных целях, дабы векторизация дала прирост x4, а не x2. Хотя этот алгоритм не особенно хорош для SSE, так что, может быть, код там использует только FPU. Хз, я через BIEW не прогонял.

Решение "в лоб", без FPU-оптимизации, бинарник (2кб) в архиве


на моем компе код Kallikanzarid'а работает 704мс, мой код работает 563мс, 20% разница
P4 3ГГц, WinXPSp2

Это сообщение отредактировал(а) GoldFinch - 9.12.2008, 17:14

Присоединённый файл ( Кол-во скачиваний: 5 )
 response.rar 2,30 Kb

Хорошо... но недостаточно!
Я немного подправил код, сделав цикл целочисленным. Это скостило совсем немного, зато точность возрасла до твоей. Зато потом я дорвался до документации GCC, хехе. В общем, качай.

Присоединённый файл ( Кол-во скачиваний: 4 )
 showdown.rar 91,33 Kb

Kallikanzarid, я те советую воспользоваться OpenMP
и пусть GoldFinch, попробует угнаться   

Kallikanzarid, осталось время измерять не +-10%
какбэ clock() вызывает GetSystemTimeAsFileTime, а это очень плохой метод измерения, да и увеличивать время измерения увеличивая время работы тестируемого алгоритма не самый лучший подход

кстати, что это у тя прога весит 275кб и требует несистемную дллку msvcrt.dll? а зачем у тя в архиве дллка mingwm10.dll, для весу?

ЗЫ: между прочим, мы начинали разговор именно о MSVC

Это сообщение отредактировал(а) GoldFinch - 9.12.2008, 19:38