Тривиальные математические проблемы как языковые ориентиры

Question

Почему люди настаивают на использовании тривиальных математических задач, таких как поиск чисел в последовательности Фибоначчи для языковых тестов? Разве они обычно не оптимизируются под релятивистские скорости? Разве бремя узких мест обычно не возникает в операциях ввода-вывода, системных вызовах API, операциях со строками и структурами, обработке больших объемов данных, абстрактных объектно-ориентированных вещах и т. Д.

Answer 1

Это возврат к старым временам, когда технология компиляции для того, что мы теперь называем базовой математикой, все еще быстро развивалась.

Теперь эволюция компилятора больше сосредоточена на использовании новых инструкций для нишевых операций, 64-битной математики и так далее.

Микро-тесты, такие как те, что вы упомянули, были полезны, однако, при оценке эффективности компилятора горячей точки при первом запуске Java и при оценке эффективности .NET по сравнению с C / C ++.

Ваше предположение, что ввод-вывод и системные вызовы являются вероятными узкими местами, является правильным, по крайней мере, для некоторого пространства проблем. Но я заметил, что вы предложили строковые операции. Нерелевантный микро-эталон одного человека - это показатель важности другого человека.

РЕДАКТИРОВАТЬ: PS, я также помню, как использовал linpack и другие микро-тесты для сравнения версий JVM и для сравнения поставщиков JVM. С v4 до v5 произошел большой скачок в производительности, я думаю, JIT-компилятор стал более эффективным. Кроме того, JVM от IBM в то время опережал Sun на Windows-x86.

Answer 2

Поскольку, если вы хотите сравнить язык / компилятор, эти «математические проблемы» являются хорошими показателями «чистой скорости» сгенерированного кода. Либо они используют итеративное решение, которое представляет собой узкий цикл и указывает, насколько хорошо компилятор может передавать инструкции процессору, либо они используют рекурсивное решение, которое указывает, как оно обрабатывает рекурсивные вызовы коротких функций (встраивание, хвостовая рекурсия). и т. д.) (хотя для этого обычно используется и функция Аккермана).

Обычно набор тестов для языка содержит тесты, сравнивающие и другие части, например. Сжатие gzip, поиск текста, создание объекта, вызов виртуальной функции, тесты выброса / перехвата исключений.

Другие вещи, которые вы заметили, системные вызовы и ввод-вывод обычно не включаются, потому что

• системные вызовы на самом деле не такие медленные - приложения не проводят значительную часть времени в ядре, за исключением тестирования, специально предназначенного для них или когда что-то серьезно не так с программой

• производительность системного вызова и ввода-вывода зависит не от языка, а от операционной системы и оборудования

Answer 3

Я думаю, что простой, хорошо зарекомендовавший себя алгоритм исключил бы вероятность того, что эталонный тест смещен (либо по незнанию, либо по злому умыслу) в пользу одного языка. Очень сложно написать сложную программу на двух разных языках одинаково. Например, для проверки эффективности многопоточного приложения в c # vs java потребуются разработчики, обладающие навыками многопоточной разработки на обоих языках, и все равно возникнут вопросы о том, правильно ли приложение для эталонных тестов представляет общий случай, или же оно искажает особый случай, когда хорошо работает только один язык.

Answer 4

В те времена, когда сито eratosthanes было популярным тестом для компиляторов C, я подумал, что было бы забавно, если бы один из авторов компилятора распознал код sieve и заменил его предварительно вычисленным поиском.