Учебник по Haskell

очистки оказалось, что нам всё же не хватает места. Мы найдём все живые объекты, подсчитаем сколько ме-

ста они занимают и запросим у системы этот объём памяти. Скопируем все живые объекты на новое место, а

старую память будем считать свободной. Так например, если у нас было выделено 30 Мб памяти и оказалось,

что живые объекты занимают 10 Мб, мы выделим ещё 10 Мб, скопируем туда все живые объекты и общий

объём памяти станет равным 40 Мб.

Мы можем оптимизировать сборку мусора. Есть такая гипотеза, что большинство объектов имеют очень

короткую жизнь. Это промежуточные данные, локальные переменные. Нам нужен лишь результат функции,

но на подходе к результату мы сгенерируем много разовой информации. Ускорить очистку можно так. Мы

выделим совсем небольшой участок памяти внутри нашей кучи, его принято называть яслями (nursery area),

и будем выделять и собирать новые объекты только в нём, как только этот участок заполнится мы скопируем

все живые объекты из яслей в остальную память и снова будем наполнять ясли. Как только вся память закон-

чится мы поступим так же как и в предыдущем сценарии. Когда заканчивается место в яслях, мы проводим

поверхностную очистку (minor GC), а когда заканчивается вся память в текущей куче, мы проводим глубокую

очистку (major GC). Эта схема соответствует сборке с двумя поколениями.

10.6 Статистика выполнения программы

Процесс управления памятью скрыт от программиста. Но при этом в GHC есть развитые средства косвен-

ной диагностики работы программы. Пока мы пользовались самым простым способом проверки. Мы вклю-

чали флаг s в интерпретаторе. Пришло время познакомиться и с другими.

Управление памятью. Сборщик мусора | 163

Статистика вычислителя

Для начала научимся смотреть статистику работы вычислителя. Посмотреть статистику можно с помо-

щью флагов s[file] и S[file]. Эти флаги предназначены для вычислителя низкого уровня (realtime system

или RTS, далее просто вычислитель), они заключаются в окружение +RTS ... -RTS, если флаги идут в кон-

це строки и считается, что все последующие флаги предназначены для RTS мы можем просто написать ghc

–make file.hs +RTS ... Например скомпилируем такую программу:

module Main where

main = print $ sum [1 .. 1e5]

Теперь скомпилируем:

$ ghc --make sum.hs -rtsopts -fforce-recomp

Флаг rtsopts позволяет передавать скомпилированной программе флаги для вычислителя низкого уров-

ня, далее для краткости мы будем называть его просто вычислителем. С флагом fforce-recomp программа

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

s[file], в этом примере мы перенаправляем выход в поток stderr):

$ ./sum +RTS -sstderr

5.00005e9

14,145,284 bytes allocated in the heap

11,110,432 bytes copied during GC

2,865,704 bytes maximum residency (3 sample(s))

460,248 bytes maximum slop

7 MB total memory in use (0 MB lost due to fragmentation)

Tot time (elapsed)

Avg pause

Max pause

Gen

0

21 colls,

0 par

0.00s

0.01s

0.0006s

0.0036s

Gen

1

3 colls,

0 par

0.01s

0.01s

0.0026s

0.0051s

INIT

time

0.00s

(

0.00s elapsed)

MUT

time

0.01s

(

0.01s elapsed)

GC

time

0.01s

(

0.02s elapsed)

EXIT

time

0.00s

(

0.00s elapsed)

Total

time

0.02s

(

0.03s elapsed)

%GC

time

60.0%

(69.5% elapsed)

Alloc rate

1,767,939,507 bytes per MUT second

Productivity

40.0% of total user, 26.0% of total elapsed

Был распечатан результат и отчёт о работе программы. Разберёмся с показателями:

bytes allocated in the heap

-- число байтов выделенных в куче

-- за всё время работы программы

bytes copied during GC

-- число скопированных байтов

-- за всё время работы программы

bytes maximum residency

-- в каком объёме памяти работала программа

-- в скобках указано число глубоких очисток

bytes maximum slop

-- максимум потерь памяти из-за фрагментации

total memory in use

-- сколько всего памяти было запрошено у ОС

Показатель bytes maximum residency измеряется только при глубокой очистке, поскольку новая память

выделяется именно в этот момент. Размер памяти выделенной в куче гораздо больше общего объёма памяти.

Так происходит потому, что этот показатель указывает на общее число памяти в куче за всё время работы

программы. Ведь мы переиспользуем не нужную нам память. По этому показателю можно судить о том,

сколько замыканий (объектов) было выделено в куче.

Следующие две строчки говорят о числе сборок мусора. Мы видим, что GC выполнил 21 поверхностную

очистку (поколение 0) и 3 глубоких (покколение 1). Дальше идут показатели скорости. INIT и EXIT – это

164 | Глава 10: Реализация Haskell в GHC

инициализация и завершение программы. MUT – это полезная нагрузка, время, которая наша программа тра-

тила на изменение (MUTation) значений. GC – время сборки мусора. Далее GHC сообщил нам о том, что мы

провели 60% времени в сборке мусора. Это очень плохо. Продуктивность программы очень низкая. Затратна

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

этой программы:

module Main where

import Data.List(foldl’)

sum’ = foldl’ (+) 0