Лисп/Оптимизация: различия между версиями

Содержимое удалено Содержимое добавлено
мНет описания правки
м викификация, оформление
Строка 1:
Поразвлекавшись с [[Лисп/Рекурсия|рекурсией]] и повертев списочные структуры, новоприбывшие в Лисп порою не находят привычных средств разработки. Наша задача показать, что на Лиспе можно решать прикладные задачи, ещё даже не изучая специальных библиотек или программных комплексов.
 
В качестве еще одного аргумента против Лиспа приводится его жуткая тормознутость. На заре языкостроения он действительно не мог конкурировать с фортраном, несмотря на то, что производил очень чистый и короткий машинный код, в лучших традициях MIT. Проблема была в [[w:Сборка_мусора|Garbage Collector’е]] — «сборщике мусора», концептуальным новшеством, впервые появившемся в Лиспе. Но прогресс требует жертв, и сборщик мусора в лиспе был действительно ресурсоемким. Но тот же прогресс не стоял на месте, и используя опыт javaJava и др, разработчики сильно сократили время сборки мусора. Большинство реализаций лиспа, например, sbclSBCL, выводят статистику использования памяти и ресурсов процессора по вызову функции time, которая в качестве аргумента принимает любую вычислимую форму.
<source lang="lisp">
>> (defun ! (n)
Строка 20:
Как видите, на сборку мусора было затрачено намного меньше времени (GC time), чем на вычисление факториала (non-GC time).
 
Также, вы можете ознакомится с независимыми тестами, например, с [[http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=sbcl&lang2=ifc| этим]], где sbclSBCL - не самая быстрая реализация лиспа, лишь немного уступает оптимизирующему компилятору фортрана от Интел. То есть, лисп сейчас - один из самых шустрых языков!
 
Из вышесказанного следует, что мы сделаем "вылазку в тыл врага" и покажем, что на Лиспе можно писать мощные высокопроизводительные продукты.