Рассуждения о производительности в Haskell

рассуждения о производительности, как правило, трудно в Haskell и ленивых языках в целом, хотя и не невозможно. Некоторые методы описаны в Чисто Функциональные Структуры Данных (а также онлайн в предыдущей версии).

другой способ обеспечить производительность-исправить порядок оценки, используя аннотации или продолжение прохождения стиле. Так ты получаешь контроль над ситуацией. оцененный.

в вашем примере вы можете вычислить числа "снизу вверх" и передать предыдущие два числа на каждую итерацию:

fib n = fib_iter(1,1,n)
    where
      fib_iter(a,b,0) = a
      fib_iter(a,b,1) = a
      fib_iter(a,b,n) = fib_iter(a+b,a,n-1)

это приводит к линейному алгоритму времени.

всякий раз, когда у вас есть алгоритм динамического программирования, где каждый результат зависит от N предыдущих результатов, вы можете использовать этот метод. В противном случае вам придется использовать массив или что-то совершенно другое.

ваша реализация fib2 использует memoization, но каждый раз, когда вы вызываете fib2, он перестраивает" весь " результат. Включите профилирование времени и размера ghci:

Prelude> :set +s

Если бы он делал memoisation" между " вызовами, последующие вызовы были бы быстрее и не использовали бы память. Позвоните в fib2 20000 дважды и убедитесь сами.

по сравнению с более идиоматической версией, где вы определяете точную математическую идентичность:

-- the infinite list of all fibs numbers.
fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

memoFib n = fibs !! n

фактически используйте memoisation, явный как ты видишь. Если вы запустите memoFib 20000 дважды, вы увидите время и пространство, занятое в первый раз, тогда второй вызов будет мгновенным и не займет памяти. Никакой магии и никаких неявных мемоизация как комментарий, возможно, намекал на.

теперь о вашем первоначальном вопросе: оптимизация и рассуждения о производительности в Haskell...

Я бы не назвал себя экспертом в Haskell, я использую его только в течение 3 лет, 2 из которых на моем рабочем месте, но мне пришлось оптимизировать и получить поймите, как рассуждать о его эффективности.

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

проверьте это сравнение foldl против выражения производится

foldl фактически хранит " как " вычислить значение, т. е. лениво. В некоторых случаях вы экономите время и пространство, будучи ленивыми, как "бесконечные" выдумки. Этот бесконечные "выдумки" не генерируют все из них, но знают, как. Когда вы знаете,что вам понадобится ценность, вы можете просто получить ее "строго"... Вот где строгость аннотации полезны, чтобы вернуть вам контроль.

Я помню, что много раз читал, что в lisp вам нужно "минимизировать" консинг.

понимание того, что строго оценивается и как заставить его важно, но также понимание того, сколько "разгрома" вы делаете с памятью. Помните, Хаскелл неизменяемый, это означает, что обновление "переменной" фактически создает копию с модификацией. Добавление с помощью (:) намного эффективнее, чем добавление с помощью ( ++ ), потому что (:) не копирует память в отличие от (++). Всякий раз, когда большой атомные блок обновляется (даже для одного символа) весь блок должен быть скопирован для представления "обновленной" версии. Способ структурирования и обновления данных может оказать большое влияние на производительность. Профилировщик ghc-ваш друг и воля помочь вам определить это. Конечно, сборщик мусора работает быстро, но ничего не делать быстрее!

Ура

помимо проблемы memoization, fib1 также использует не-tailcall рекурсию. Рекурсия Tailcall может быть автоматически пересчитана в простой goto и работать очень хорошо, но рекурсия в fib1 не может быть оптимизирована таким образом, потому что вам нужен кадр стека из каждого экземпляра fib1 для вычисления результата. Если вы переписали fib1 для передачи текущего итога в качестве аргумента, что позволяет хвостовому вызову вместо необходимости сохранять кадр стека для окончательного добавления, производительность значительно улучшится. Но не так сильно, как мемоизированную пример, конечно :)

поскольку распределение является основной стоимостью в любом функциональном языке, важной частью понимания производительности является понимание того, когда объекты распределяются, как долго они живут, когда они умирают, и когда они возвращаются. Чтобы получить эту информацию, вам нужно профилировщик кучи. Это важный инструмент, и, к счастью, GHC поставляется с хорошим.

для получения дополнительной информации прочитайте Колин Рансимен'ы.