Какова расплата за функциональность?

Я имею в виду потерю производительности. Понятно, что это зависит от задачи. Но ведь существуют классические программы для тестирования, например - http://parallel.ru/computers/benchmarks/perf.html

0

Не понял связи между производительностью и функциональностью.
Производительность процессора определяется возможностями процессора и его скоростью. Функциональность (если правильно понял в контексте раздела форума) это стиль программирования.
Если есть хороший компилятор, то одна и та же сферическая программа-тест скомпилируется в один и тот же код, на каком бы языке она не была написана.
Другое дело, что компиляторы пока ещё не настолько мощные, чтоб функциональные элементы оптимально преобразовывать, скажем, в asm.
Да и глупо писать такой тест, скажем, на Haskell, слишком много от компилятора зависит. С С/Паскаль/Фортран проще: легким взглядом на код можно оценить, где сколько операций будет делать проц. (хотя бы примерно)

Прим.: такая же, да наоборот, ситуация с data-flow архитектурами, хотя, опять же, многое от компилятора зависит.

0

Сообщение от Mysterious Light Не понял связи между производительностью и функциональностью.

Чем выше уровень абстракции - тем ниже производительность. Вопрос лишь в том, насколько ниже?

Производительность процессора определяется возможностями процессора и его скоростью. Функциональность (если правильно понял в контексте раздела форума) это стиль программирования.

Действительно, эти тесты изначально предназначаются для тестирования скорости процессора. Мы компилируем одну и ту же программу и запускаем на двух разных процессорах. Где она выполнилась быстрее - тот процессор лучше. Но что мешает сделать ровно наоборот? Скомпилировать две программы и запустить на одном и том же процессоре. Какой код выполнится быстрее - тот компилятор эффективнее. Понятно, что тут многое будет зависеть от реализации (т.е. от кодера), но тесты классические, и наверняка можно их реализовать очень качественно. Да я и не настаиваю именно на этих тестах. Это просто для примера. Можете взять любой алгоритм и реализовать дважды - на любом императивном языке и на любом функциональном. Опять же, слишком много факторов (какую задачу выберем, какие языки выберем, какой алгоритм, кто это будет писать). Но хоть какая-то точка отсчёта.

Если есть хороший компилятор, то одна и та же сферическая программа-тест скомпилируется в один и тот же код, на каком бы языке она не была написана.

Это не хороший компилятор, это некий чисто умозрительный идеализированный компилятор.

Другое дело, что компиляторы пока ещё не настолько мощные, чтоб функциональные элементы оптимально преобразовывать, скажем, в asm.

Вот именно это меня и интересует. Насколько они неоптимальные? Насколько медленнее будет расчёт? Возьмём для примера задачу типа "проще не придумаешь". Скажем, нахождение корней квадратного уравнения. Запрограммируем на Фортране и на Хаскелле. Зациклим на час и подсчитаем число циклов.

Да и глупо писать такой тест, скажем, на Haskell, слишком много от компилятора зависит. С С/Паскаль/Фортран проще: легким взглядом на код можно оценить, где сколько операций будет делать проц. (хотя бы примерно) Прим.: такая же, да наоборот, ситуация с data-flow архитектурами, хотя, опять же, многое от компилятора зависит.

Я искренне надеюсь, что кто-то поймёт эти умные слова и даже извлечёт из них какую-то пользу. Я задал простой вопрос и надеялся получить простой ответ. Скажем, время расчёта возрастает на 20-200 процентов в зависимости от задачи. Даже такой гигантский разброс - уже хоть какая-то конкретика.

0

Первая моя программа имела вид (ghci)
> let factorial 1 = 1; factorial x = x * factorial (x-1)
> :m +System.Time
> do x <- getClockTime; print $ factorial 50000; y <- getClockTime; return$ tdSec$ diffClockTimes y x
Вывод: собственно, 50000! за 20 секунд. Тогда впечатлило.

Более-менее сложная программа уже будет подтормаживать.

P.S. знаю, что никаких конкретных коэффициентов не привел. Больше хотел повторить свою мысль: всё зависит от того, насколько компилятор может оптимизировать выходной код.

0