Учебник по Haskell

разработан для тестирования интересных идей в теории типов. 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-выражений. Переведите и пример

без утечки памяти, а также промежуточный вариант, который не сработал. Для этого вам понадобится

выразить энергичный образец через функцию seq.

Подсказка: За счёт семантики case-выражений нам не нужно специальных конструкций для того чтобы

реализовать seq в STG:

seq = FUN( a b ->

case a of

x -> b

)

При этом вызов функции seq будет встроен. Необходимо будет заменить в коде все вызовы seq на пра-

вую часть определения (без FUN). Также обратите внимание на то, что плюс не является примитивной

функцией:

plusInt = FUN( ma mb ->

case ma of

I# a -> case mb of

I# b -> case (primitivePlus a b) of

res -> I# res

)

В этой функции всплыла на поверхность одна тонкость. Если бы мы писали это выражение в Haskell,

то мы бы сразу вернули результат (I#(primitivePlus a b)), но мы пишем в STG и конструктор может

принять только атомарное выражение. Тогда мы могли бы подумать и сохранить его по старинке в

let-выражении:

-> let v = primitivePlus a b

in

I# v

Но это не правильное выражение в STG! Конструкция в правой части let-выражения должна быть объ-

ектом кучи, а у нас там простое выражение. Но было бы плохо добавить к нему THUNK, поскольку это

выражение содержит вызов примитивной функции на незапакованных значениях. Эта операция выпол-

няется очень быстро. Было бы плохо создавать для неё специальный объект на куче. Поэтому мы сразу

вычисляем это выражение в третьем case. Эта функция также будет встроенной, необходимо заменить

все вызовы на определение.