Haskell, performance
Пока что я просто восхищен хаскельной декларативностью и мне в реальной жизни не надо на нем ничего писать, однако чувство того, что я не понимаю, что там внутри временами гложет.
Вот на Си++ я примерно понимаю что происходит. Да, оптимизатор может сильно изменить мою программу при компиляции, но все же более-менее понятно как все работает.
В интерпретируемых языках все менее прозрачно, например может быть такой эффект:
В нашем движке, экспортированные из C++ для python 3d-вектора имеют методы length и lengthSquared. И в документации постулируется, что лучше вызывать lengthSquared когда надо сравнить длины векторов, типа это быстрей и корень не извлекается. Проверил это, и получил сюрприз - lengthSquared оказался на 5% медленней чем length. Объяснение простое - все поля/методы объекта в python это строки в хеш-таблице. Строка "lengthSquared" длинней чем "length". И суета с длиной идентификатора в хеш-таблице оказалась важней чем наличие квадратного корня. Вывод - в динамическом ЯП неважно что звать, вычисление "сложного" синуса или тупое сложение. Если хотим выжать сколько-то (десятков) процентов скорости не переписывая на C - стоит класть методы объектов в локальные переменные, ls = Point3d.lengthSquared; ls(dir1) < ls(dir2);
Тем не менее можно докопаться, открыв исходники интерпретатора.
Что происходит в недрах хаскелла моему мозгу пока непостижимо. Понятно, что есть книжка о том, как оно устроено внутри:
The Implementation of Functional Programming Languages
но мне бы сначала с языком разобраться. В Си++ понимание того, что происходит приходило по мере изучения самого языка, а тут такого нет.
Имеется набор инструментов для оценки производительности, но все же ответ на вопрос "где тормозит?" дать непросто.
Вот тут, например, что тормозит?
http://jdevelop.livejournal.com/1871816.html
Вот на Си++ я примерно понимаю что происходит. Да, оптимизатор может сильно изменить мою программу при компиляции, но все же более-менее понятно как все работает.
В интерпретируемых языках все менее прозрачно, например может быть такой эффект:
В нашем движке, экспортированные из C++ для python 3d-вектора имеют методы length и lengthSquared. И в документации постулируется, что лучше вызывать lengthSquared когда надо сравнить длины векторов, типа это быстрей и корень не извлекается. Проверил это, и получил сюрприз - lengthSquared оказался на 5% медленней чем length. Объяснение простое - все поля/методы объекта в python это строки в хеш-таблице. Строка "lengthSquared" длинней чем "length". И суета с длиной идентификатора в хеш-таблице оказалась важней чем наличие квадратного корня. Вывод - в динамическом ЯП неважно что звать, вычисление "сложного" синуса или тупое сложение. Если хотим выжать сколько-то (десятков) процентов скорости не переписывая на C - стоит класть методы объектов в локальные переменные, ls = Point3d.lengthSquared; ls(dir1) < ls(dir2);
Тем не менее можно докопаться, открыв исходники интерпретатора.
Что происходит в недрах хаскелла моему мозгу пока непостижимо. Понятно, что есть книжка о том, как оно устроено внутри:
The Implementation of Functional Programming Languages
но мне бы сначала с языком разобраться. В Си++ понимание того, что происходит приходило по мере изучения самого языка, а тут такого нет.
Имеется набор инструментов для оценки производительности, но все же ответ на вопрос "где тормозит?" дать непросто.
Вот тут, например, что тормозит?
http://jdevelop.livejournal.com/1871816.html