Лисп/Оптимизация: различия между версиями
Ashikbot (обсуждение | вклад) м Категоризация по запросу на w:ВП:РДБ |
Se0808 (обсуждение | вклад) мНет описания правки |
||
Строка 1: | Строка 1: | ||
<div style="max-width:52em;margin:1em auto 0 4%;"> |
|||
Поразвлекавшись с [[Лисп/Рекурсия|рекурсией]] и повертев списочные структуры, новоприбывшие в Лисп порою не находят привычных средств разработки. Наша задача показать, что на Лиспе можно решать прикладные задачи, ещё даже не изучая специальных библиотек или программных комплексов. |
Поразвлекавшись с [[Лисп/Рекурсия|рекурсией]] и повертев списочные структуры, новоприбывшие в Лисп порою не находят привычных средств разработки. Наша задача показать, что на Лиспе можно решать прикладные задачи, ещё даже не изучая специальных библиотек или программных комплексов. |
||
Строка 24: | Строка 23: | ||
Из вышесказанного следует, что мы сделаем "вылазку в тыл врага" и покажем, что на Лиспе можно писать мощные высокопроизводительные продукты. |
Из вышесказанного следует, что мы сделаем "вылазку в тыл врага" и покажем, что на Лиспе можно писать мощные высокопроизводительные продукты. |
||
[[Категория:Лисп|Оптимизация]] |
[[Категория:Лисп|Оптимизация]] |
Версия от 11:48, 22 ноября 2010
Поразвлекавшись с рекурсией и повертев списочные структуры, новоприбывшие в Лисп порою не находят привычных средств разработки. Наша задача показать, что на Лиспе можно решать прикладные задачи, ещё даже не изучая специальных библиотек или программных комплексов.
В качестве еще одного аргумента против Лиспа приводится его жуткая тормознутость. На заре языкостроения он действительно не мог конкурировать с фортраном, несмотря на то, что производил очень чистый и короткий машинный код, в лучших традициях MIT. Проблема была в Garbage Collector’е — «сборщике мусора», концептуальным новшеством, впервые появившемся в Лиспе. Но прогресс требует жертв, и сборщик мусора в лиспе был действительно ресурсоемким. Но тот же прогресс не стоял на месте, и используя опыт java и др, разработчики сильно сократили время сборки мусора. Большинство реализаций лиспа, например, sbcl, выводят статистику использования памяти и ресурсов процессора по вызову функции time, которая в качестве аргумента принимает любую вычислимую форму.
>> (defun ! (n)
(if (<= n 1)
1
(* n (! (- n 1))))) ; вычисление факториала, довольно ресурсоемкая функция
<< !
>> (time (and (! 10000) (print 'completed)))
<< Evaluation took:
0.216 seconds of real time
0.185958 seconds of total run time (0.185958 user, 0.000000 system)
[ Run times consist of 0.029 seconds GC time, and 0.157 seconds non-GC time. ]
86.11% CPU
401,695,742 processor cycles
69,584,840 bytes consed
COMPLETED
Как видите, на сборку мусора было затрачено намного меньше времени (GC time), чем на вычисление факториала (non-GC time).
Также, вы можете ознакомится с независимыми тестами, например, с [[1]], где sbcl - не самая быстрая реализация лиспа, лишь немного уступает оптимизирующему компилятору фортрана от Интел. То есть, лисп сейчас - один из самых шустрых языков!
Из вышесказанного следует, что мы сделаем "вылазку в тыл врага" и покажем, что на Лиспе можно писать мощные высокопроизводительные продукты.