- 1 frag / 2 deaths
- Участник
Отличный вброс. Ну и насчет векторизации я тоже недоумеваю давно
kipar
> По ссылке в #0 тоже распараллеливает, доводит до 0.7сек
Такой страшный говнокод у него. CUDA, господи. Я дописал одну строчку перед циклом:
#pragma omp parallel for reduction(+:res)
и стало 1.4 секунды
Aroch
> самое смешное почти во всех тестах результат теста разный
Одинаковый он,... в зависимости от настроек, fp:fast одно значение, fp:precise другое... а автор статьи не умеет в одинаковые настройки сишечки и vb. К слову, разницы в результате/времени выполнения между sin и sinf я не заметил.
Aroch
> Ну и да, очередной тест
который ничего не тестирует, и в котором нет простора для работы оптимизатора в компиляторе.
0iStalker
> разницы в результате/времени выполнения между sin и sinf я не заметил.
sinf вроде всю жизнь был дефайном преобразовывающим результат sin() к float, а параметр к double.
entryway
> > По ссылке в #0 тоже распараллеливает, доводит до 0.7сек
> Такой страшный говнокод у него. CUDA, господи. Я дописал одну строчку перед циклом:
> #pragma omp parallel for reduction(+:res)
> и стало 1.4 секунды
А-а, так у него восемь ядер. У меня четыре. На восьми должно быть примерно как у него с простым как валенок кодом:
int main() { double res=0.0; unsigned int dw = GetTickCount( ); #pragma omp parallel for reduction( +:res) for ( int i = 1; i <= 200000000; i++) res+=sin( ( double)i); printf( "Result: %f after %d", res, ( GetTickCount( )-dw)); }
А пояснить для тех кто не шарит? Железо уже не подходит для ВБ6?
Ren
> А пояснить для тех кто не шарит?
Представь соревнование жонглёров, - тест первый - подбрасывают/ловят один предмет, много можно понять о мастерстве в данном случае? Вот и тут, точно такой же случай оценивается.
0iStalker
> Представь соревнование жонглёров, - тест первый - подбрасывают/ловят один
> предмет, много можно понять о мастерстве в данном случае? Вот и тут, точно
> такой же случай оценивается.
Да нет, то что одного теста недостаточно для выявления общей производительности, - это ясно. Статья то к чему ведет? Я дочитал до того что басик справился быстрее всех, а дальше пошло специальное слишком.
Ren
Он сказал что басик быстрее всех в однопоточке, потом взял и сделал в нем многопоточку, уделав матлаб. А потом решил сравнить с видеокартами, но видеокарты тоже слили, большей частью из-за того что не заточены под вычисление синуса двойной точности и при вычислении длящемся секунду разные служебные операции начинают вносить вклад.
Странно, что кто-то не начал пилить свой самый точный и самый быстрый синус двойной точности.
Бейсик, наверное, использует fsin инструкцию, которая не точная. Поэтому работает быстро и с ошибками.
Из дизасм кода на бейсике?
Mingw с оптимизациями отработал быстрее теста Mikle на пару секунд.
Кроме добавления math.h код не трогал, но таки да — от VB6 такой прыткости не ожидал.
CPU Disasm
Address Hex dump Command Comments
00401680 /$ 83EC 0C SUB ESP,0C ; SinTest.00401680(guessed void)
00401683 |. 33C0 XOR EAX,EAX
00401685 |. 894424 04 MOV DWORD PTR SS:[LOCAL.1],EAX
00401689 |. 894424 08 MOV DWORD PTR SS:[LOCAL.0],EAX
0040168D |. DD4424 04 FLD QWORD PTR SS:[LOCAL.1]
00401691 |. B8 01000000 MOV EAX,1
00401696 |. 894424 00 MOV DWORD PTR SS:[LOCAL.2],EAX
0040169A |> DB4424 00 /FILD DWORD PTR SS:[LOCAL.2]
0040169E |. 40 |INC EAX
0040169F |. 3D 00C2EB0B |CMP EAX,0BEBC200
004016A4 |. 894424 00 |MOV DWORD PTR SS:[LOCAL.2],EAX
004016A8 |. D9FE |FSIN
004016AA |. DEC1 |FADDP ST(1),ST
004016AC |.^ 7E EC \JLE SHORT 0040169A
004016AE |. 83C4 0C ADD ESP,0C
004016B1 \. C3 RETN
the trick
Простой код без излишеств но и без хитростей
Можно перевернуть цикл и внутри вместо константы будет сравнение с нулем, хотя вряд ли это даст больше доли процента. И от перестановки результат может фатально измениться, плавающий питух он такой, ни один компилятор на такое не пойдет.
Тема в архиве.