Это определение типа ST. Специальные кортежи используются для возврата нескольких значений напря-
мую, без создания промежуточного кортежа в куче. В этом случае значения будут сохранены в регистрах
или на стеке. Для использования специальных значений необходимо активировать расширения MagicHash и
UnboxedTuples
Разработчики различных библиотек могут предоставлять несколько вариантов своих данных: ленивые
версии и незапакованные. Например в ST-массив незапакованных значений STUArray s i a эквивалентен
массиву значений в C. В таком массиве можно хранить лишь примитивные типы.
10.8 Краткое содержание
Эта глава была посвящена компилятору GHC. Мы говорим Haskell подразумеваем GHC, говорим GHC
подразумеваем Haskell. К сожалению на данный момент у этого компилятора нет достойных конкурентов.
А может и к счастью, ведь если бы не было GHC, у нас была бы бурная конкуренция среди компиляторов
поплоше. Мы бы не знали, что они не так хороши. Но у нас не было бы программ, которые способны тягаться
по скорости с С. И мы бы говорили: ну декларативное программирование, что поделаешь, за радость аб-
стракций приходится платить. Но есть GHC! Всё-таки это очень трудно: написать компилятор для ленивого
языка
Отметим другие компиляторы: Hugs разработан Марком Джонсом (написан на C), nhc98 основанный
Николасом Райомо (Niklas Rojemo) этот компилятор задумывался как легковесный и простой в установке, он
разрабатывался при поддержке 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-выражений. Переведите и пример
без утечки памяти, а также промежуточный вариант, который не сработал. Для этого вам понадобится
выразить энергичный образец через функцию 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. Эта функция также будет встроенной, необходимо заменить
все вызовы на определение.
• Набейте руку в профилировании, пусть это станет привычкой. Вы долго писали большую программу и
теперь вы можете узнать много подробностей из её жизни, что происходит с ней во время вычисления
кода. Вернитесь к прошлой главе и попрофилируйте разные примеры. В конце главы мы рассматрива-
ли пример с поиском корней, там мы создавали большой список промежуточных результатов и в нём
искали решение. Я говорил, что такие алгоритмы очень эффективны при ленивой стратегии вычис-
лений, но так ли это? Будьте критичны, не верьте на слово, ведь теперь у вас есть инструменты для
проверки моих туманных гипотез.
