- return [](){};
- Постоялец
Aroch
Попробуйка это: [file=101654]
Hardcode
Твой 15.078 сек.
Мой 8.765 сек.
kipar
что собственно и требовалось доказать, только до Zefick'a всё равно видимо не дойдет в чём был подвох и будет с тем же упрямством считать fake'овый результат как наилучший, с++ хэйтер это видимо не излечимо.
Дошло:)
Aroch, ты путаешь fsin и sinf().
Aroch
> будет с тем же упрямством считать fake'овый результат как наилучший, с++ хэйтер
> это видимо не излечимо.
Теперь посмотрим на твою реакцию на новый файл Mikle )
Mikle
1.3293337215613
8.024313
Hardcode
1.329333721550061
10.31200048979372
kipar
> Теперь посмотрим на твою реакцию на новый файл Mikle )
результаты разные, на что собственно изначально и обращаешь внимание, если планируется использовать результат как один из ключей в каком-нибудь шифровании где каждый знак будет иметь значение, то сразу не подходит.
Mikle
> ты путаешь fsin и sinf().
верно.
Aroch
> что собственно и требовалось доказать,
Так ЧТО ИМЕННО тебе требовалось доказать?
Aroch
> 1.3293337215613
> 1.329333721550061
Опять ошибка в 13 цифре и ответ на VB ближе к правильному. Может хватит уже устраивать клоунаду?
Странно, что такое, уже и параметры поменяли и в даблах считаем, а всё равно что-то не сходится :-7
> с++ хэйтер это видимо не излечимо.
Где ты нашёл хейтерство?
Прикольно, что ICC 10.1, опередив барсик на изначальном диапазоне, сливает на диапазоне 10000000000..10200000000. У меня 20 секунд считает.
Zefick
> Так ЧТО ИМЕННО тебе требовалось доказать?
то что ты не видишь разницы между результатами, открой уже глаза, если тебе важен только ответ, то как тебе такой "тест":
double calc_sum_sin_from_1kkk_to_1kkk10kk() { return 1.3293337215591164558667569229068009099619001423469967776861949091777072119895812294603577287762853663612; } int main( ) { double result=0; int t=GetTickTime( ); result=calc_sum_sin_from_1kkk_to_1kkk10kk( ); dt=GetTickTime( ) - t; }
Aroch
> результаты разные, на что собственно изначально и обращаешь внимание, если
> планируется использовать результат как один из ключей в каком-нибудь шифровании
> где каждый знак будет иметь значение, то сразу не подходит.
Но пока получается что на vb и быстрее, и точнее.
А для шифрования - надо или нормальные алгоритмы использовать или следить как флаги выставлены (да и то, на разных архитектурах по-разному будет), так что только отказ от плавающего питуха.
Так что - записывать тебя в неизлечимых фанатов C++ или все-таки признаешь поражение?
Aroch
> ты не видишь разницы между результатами
С чего ты взял? В статье десять разных результатов, тут уже показали не меньшее количество и я не говорил, что они одинаковые. Так что почему это я не вижу?
И ещё раз - чего ты пытался добиться, когда менял параметры?
kipar
> Так что - записывать тебя в неизлечимых фанатов C++ или все-таки признаешь
> поражение?
можешь записывать, с таким же успехом можно тестировать на каком языке быстрее вызов функции считающей 2*2, при этом на каждом реализовав её по своему, в одном выдать сразу 4, в другом 2+2 в третьем 2*2 в четвертом 3+2 и то правдивее тест будет, хоть результаты не будут отличаться кроме четвертого :)
Mikle
какое в барсике fpu control word?
Zefick
> В статье десять разных результатов
и тебя это нисколько не смущает верно? :) То есть автор тестил у кого используется самая быстрая реализация синуса, причем без каких либо критериев к точности, но зачем то обозвав этот тестом между пакетами/языками. И ты это всерьёз продолжаешь воспринимать? Ну тогда мой вариант теста учитывай тоже, ок?
> чего ты пытался добиться, когда менял параметры?
ты уже мне свои слова приписываешь? rofl
Тема в архиве.