подразумеваем Haskell. К сожалению на данный момент у этого компилятора нет достойных конкурентов.
А может и к счастью, ведь если бы не было GHC, у нас была бы бурная конкуренция среди компиляторов
поплоше. Мы бы не знали, что они не так хороши. Но у нас не было бы программ, которые способны тягаться
по скорости с С. И мы бы говорили: ну декларативное программирование, что поделаешь, за радость аб-
стракций приходится платить. Но есть GHC! Всё-таки это очень трудно: написать компилятор для ленивого
языка
Отметим другие компиляторы: Hugs разработан Марком Джонсом (написан на C), nhc98 основанный
Николасом Райомо (Niklas Röjemo) этот компилятор задумывался как легковесный и простой в установке, он
разрабатывался при поддержке NUTEK, Йоркского университета и Технического университета Чалмерса. От
этого компилятора отпочковался YHC, Йоркский компилятор. UHC – компилятор Утрехтского университета,
разработан для тестирования интересных идей в теории типов. JHC (Джон Мичэм, John Meacham) и LHC
(Дэвид Химмельступ и Остин Сипп, David Himmelstrup, Austin Seipp) компиляторы предназначенные для
проведения более сложных оптимизаций программ с помощью преобразований дерева программы.
В этой главе мы узнали как вычисляются программы в GHC. Мы узнали об этапах компиляции. Снача-
ла проводится синтаксический анализ программы и проверка типов, затем код Haskell переводится на язык
Core. Это сильно урезанная версия Haskell. После этого проводятся оптимизации, которые преобразуют де-
рево программы. На последнем этапе Core переводится на ещё более низкоуровневый, но всё ещё функцио-
нальный язык STG, который превращается в низкоуровневый код и исполняется вычислителем. Посмотреть
на текст вашей программы в Core и STG можно с помощью флагов ddump-simpl ddump-stg при этом лучше
воспользоваться флагом ddump-suppress-all для пропуска многочисленных деталей. Хардкорные разработ-
чики Haskell смотрят Core для того чтобы понять насколько строгой оказалась та или иная функция, как
аргументы размещаются в памяти. Но это уже высший пилотаж искусства оптимизации на Haskell.
Мы узнали о том как работает сборщик мусора и научились просматривать разные параметры работы
программы. У нас появилось несколько критериев оценки производительности программ: минимум глубоких
очисток и отсутствие горбов на графике изменения кучи. Мы потренировались в охоте за утечками памяти
и посмотрели как разные типы профилирования могут подсказать нам в каком месте затаилась ошибка.
Отметим, что не стоит в каждой медленной программе искать утечку памяти. Так в примере concat у нас не
было утечек памяти, просто один из алгоритмов работал очень плохо и через профилирование функций мы
узнали какой.
Также мы познакомились с новыми прагмами оптимизации программ. Это встраиваемые функции INLINE,
правила преобразования выражений RULE и встраиваемые конструкторы UNPACK. Разработчики GHC отмеча-
ют, что грамотное использование прагмы INLINE может существенно повысить скорость программы. Если
мы встраиваем функцию, которая используется очень часто, нам не нужно создавать лишних отложенных
вычислений при её вызовах.
178 | Глава 10: Реализация Haskell в GHC
Надеюсь, что содержание этой главы упростит понимание программ. Как они вычисляются, куда идёт
память, почему она висит в куче. При оптимизации программ предпочитайте изменение алгоритма перед
настройкой параметров компилятора под плохой алгоритм. Вспомните самый первый пример, увеличением
памяти под сборку мусора нам удалось вытянуть ленивую версию sum, но ведь строгая версия требовала в
100 раз меньше памяти, причём её запросы не зависели от величины списка. Если бы мы остановились на
ленивой версии, вполне могло бы так статься, что первый год нас бы устраивали результаты, но потом наши
аппетиты могли возрасти. И вдруг программа, так тщательно настроенная, взорвалась. За год мы, конечно,
многое позабыли о её внутренностях, искать ошибку было бы гораздо труднее. Впрочем не так безнадёжно:
включаем auto-all, caf-all с флагом prof и смотрим отчёт после флага p.
10.9 Упражнения
• Попытайтесь понять причину утечки памяти в примере с функцией sum2 на уровне STG. Не запоминайте
этот пример, вроде, ага, тут у нас копятся отложенные вычисления в аргументе. Переведите на STG и
посмотрите в каком месте происходит слишком много вызовов let-выражений. Переведите и пример
без утечки памяти, а также промежуточный вариант, который не сработал. Для этого вам понадобится