Есть ли планы по версионированию бенчмарка? Ведь всегда есть что улучшать.
Кажется, отсутствие версионирования в GLUE привело к тому, что разъяснение о битых строчках в QQP пришлось включать в FAQ, а некоторые результаты QNLI теперь считаются недействительными из-за уточнений описания задания.
Теперь аккуратнее к рендерингу страниц в виртуалках надо будет относиться. Успел уже встретиться(Ubuntu+Nvidia drivers+VirtualBox 2d/3d acceleration+WinXP+Chrome 30)(изображение перевёрнуто):
Эффект есть, а цифр нет. В итоге непонятно «необходимо отказаться от всех используемых аккумуляторов» или «для более эффективного использования аккумуляторов, необходимо обновить прошивку зарядников».
Да, одним. Нет, не разогнан — 3.1 GHz FX-8120. Лень Wine устанавливать, удалять потом :-[
Лучше что-нибудь кросплатформенное.
Могу также сказать, что до 100'000'000, возможно cos(), на домашнем i5-760(тоже линукс) на JavaScript в Chrome 26-27 считалось за 4.2 с, в firefox 20 за 5.8 с. Как идея для добавления результатов.
Было бы очень удобно, если бы в конце статьи была табличка со всеми результатами.
Также недавно провёл пару тестов чтобы составить представление о том, как меняется результат вычисления от реализации численного метода. Результаты кода на ассемблере, gcc и icc хоть и незначительно, но отличались — 13 одинаковых знаков при всех промежуточных вычислениях в long double.
Зря вы так про интеловский компилятор. У меня 8 ядерный AMD. icpc version 13.1.1
icpc 200000000.c -o 200000000
Result: 1.250230424176175914 3.02 c (среднее по 5)
icpc 200000000.c -o 200000000 -parallel 0.626 c (среднее по 5) в 4.82 раза быстрее
правда результат скачет от
1.2502304241755670677 до
1.2502304241755675118
что конечно досадно, но это, пожалуй, отдельный разговор.
немного изменил код для Linux
смотреть исходник
#include <iostream>
#include <math.h>
#include <sys/time.h>
using namespace std;
unsigned long int time_delta(struct timeval *from, struct timeval *to) {
unsigned long int delta = to->tv_sec * 1000000l + to->tv_usec;
return delta - (from->tv_sec * 1000000l + from->tv_usec);
}
int main()
{
struct timeval start, end;
double res=0.0;
gettimeofday(&start, 0);
for (int i = 1; i <= 200000000; i++)
res+=sin(i);
gettimeofday(&end, 0);
cout.precision(20);
cout << "Result: " << res << " time: " << time_delta(&start, &end)/1000000.0 << "s" << endl;
}
В багзилле редхата говорят, что это поможет только от доступного в данный момент эксплоита.
Our testing shows that this is not sufficient to avoid the issue in general, but it is currently sufficient mitigation against the publicly available (unmodified) exploits.
Гм…
1) только при скроле мышью, при простой прокрутке такого не возникает. И в фулскрине заметнее.
2) несколько преувеличил. Он «отвисает» через некоторое время. И в более новых версиях(только 3.4 смотрел), проблема менее заметна.
Кажется, отсутствие версионирования в GLUE привело к тому, что разъяснение о битых строчках в QQP пришлось включать в FAQ, а некоторые результаты QNLI теперь считаются недействительными из-за уточнений описания задания.
Chrome Version 29.0.1547.57
в Ubuntu 13.04 не упали.
Лучше что-нибудь кросплатформенное.
Могу также сказать, что до 100'000'000, возможно cos(), на домашнем i5-760(тоже линукс) на JavaScript в Chrome 26-27 считалось за 4.2 с, в firefox 20 за 5.8 с. Как идея для добавления результатов.
Было бы очень удобно, если бы в конце статьи была табличка со всеми результатами.
Также недавно провёл пару тестов чтобы составить представление о том, как меняется результат вычисления от реализации численного метода. Результаты кода на ассемблере, gcc и icc хоть и незначительно, но отличались — 13 одинаковых знаков при всех промежуточных вычислениях в long double.
icpc 200000000.c -o 200000000
Result: 1.250230424176175914
3.02 c (среднее по 5)
icpc 200000000.c -o 200000000 -parallel
0.626 c (среднее по 5) в 4.82 раза быстрее
правда результат скачет от
1.2502304241755670677 до
1.2502304241755675118
что конечно досадно, но это, пожалуй, отдельный разговор.
немного изменил код для Linux
или [/зануда]
просто немного неточный перевод
Вот бы ещё кто-нибудь на Stm32F4Discovery с HS USB анализатор сделал…
1) только при скроле мышью, при простой прокрутке такого не возникает. И в фулскрине заметнее.
2) несколько преувеличил. Он «отвисает» через некоторое время. И в более новых версиях(только 3.4 смотрел), проблема менее заметна.