Дмитрий Дагаев писал(а): Тем, кто считает, что режим с оптимизациями является ненормальным
Вот вы это кому только что сказали?
Я как раз всегда говорил, что режим с оптимизациями является основным, и сравнивать нужно "с оптимизациями".
Дмитрий Дагаев писал(а): 1) qsort: All configurations have positive runs, except the
Windows 7 platform which shows 100% negative.
Читайте, пожалуйста, полностью. Или вы ссылаетесь на статью только ради того, чтобы сослаться?
Цитата: Windows 7 platform which shows 100% negative. This is due
to the text output format and different end-of-line characters:
Windows uses CR+LF, while Linux uses only LF. When
using diff -b or diff --strip-trailing-cr 3
, or
dos2unix on output files, they show no difference with the
absolute reference. They should be considered false negatives
since the benchmark runs correctly, only the testing procedure
is inappropriate. A better testing framework should either use
different files for different platforms, or specify what utility is
to be used for comparison, with the appropriate set of flags.
Перевожу на русский: отрицательный результат для qsort теста оказалось лишь проблемой запускатора тестов. Сам код отработал верно. Проблема в том, что проверяющая система не ожидала, что в Windows строки будут разделяться символами CR+LF.
Иными словами, они прямо пишут, что проблемы вообще нет. Отсортировалось правильно во всех случаях.
И эта проблема "с форматом перевода строк" отмечена во многих Windows тестах. Наверняка, авторы исходного кода вообще никогда на Windows не запускались. Какое это отношение имеет к замерам? Да никакого. Какое это отношение имеет к оптимизациям? Тоже никакого.
Дмитрий Дагаев писал(а): По остальным тестам корректности есть и 40%, и 100% негативных прогонов.
По факту, в предложенной вами работе сплошная вода.
Ну какой толк от того, что "из-за перевода строк бенчмарк показывает негативные результаты на Windows"?
Если бы они поправили очевидные огрехи в самом коде, тогда ещё можно было обсуждать.
Посмотрите же хотя бы на таблицу, которую вы доблестно процитировали.
Большинство "отрицательных значений" вообще не зависит от значения -O. О чём это говорит? О том, что исходный код в принципе не работал, и оптимизации на него никак не влияют.
Есть ровно 2 случая, когда от изменения -O "изменился" результат.
Это susan_c и rsynth.
Про susan_c сказано, что результат другой из-за "ошибок округления" (т.е. по-другому округлилось значение).
По rsynth снова разница в плавающей точке.
Какой вывод можно сделать?
Статья НЕ подтверждает того, что от -O1/O2/O3/Os что-то портится.
В статье авторы что-то там измерили, и таким образом установили, что:
1) На Windows перевод строки CR+LF, а на Linux это просто LF
2) Операции с плавающей точкой могут выдавать тот или иной ответ в зависимости от того какие команды процессора используются.
3) Использование неинициализированных переменных это плохо
Для кого-то эти пункты стали откровением?
Кто-то не знал, что нужно инициализировать переменные перед обращением?
Кто-то не знал, что вычисления с плавающей точкой не всегда гарантируют побитовый результат?
|