thedeemon: (Default)
[personal profile] thedeemon
Читаю статью про F# в очередном номере ПФП, а там стандартный набор бреда про сабж:
В противоположность жадному подходу существует стратегия ленивых вычислений, которая позволяет вычислять значение выражения только тогда, когда оно становится необходимо. Преимуществами такого подхода являются:
• производительность, поскольку неиспользуемые значения просто не вычисляются;
• возможность работать с бесконечными или очень большими последовательностями, так как они никогда не загружаются в память полностью;
• декларативность кода. Использование ленивых вычислений избавляет программиста от необходимости следить за порядком вычислений, что делает код проще.


По пунктам:
1.
а) Что-то я не припомню, чтобы программисты на неленивых языках стали бы вычислять какие-то значения, которые потом не используют. Обычно все-таки люди достаточно разумны, чтобы их программы вычисляли ровно столько, сколько нужно.
б) Ленивость создает накладные расходы, причем существенные. Если две программы делают одно и то же, ленивый вариант никак не будет производительнее энергичного. Почему-то большинство проблем с производительностью программ на Хаскеле решают именно расстановкой всяких ! и $!, убирающих ленивость. И оптимизатор тем же занимается.

2.
С бесконечными структурами ни ленивые, ни энергичные программы работать не могут, они всегда работают с конечной их частью. Насчет больших последовательностей - в неленивых языках они доступны в виде итераторов, энуменаторов и т.п., но это несколько другая вещь, т.к. значения обрабатываются по очереди и не хранятся в памяти, в отличие от ленивых списков и структур. Если же что-то в памяти хранить, то из-за накладных расходов на ленивость ленивые языки принципиально могут хранить меньше данных в тех же объемах памяти, чем неленивые.

3.
От необходимости следить за порядком вычислений избавляет исключительно чистота, а не ленивость. Если код не весь чист (содержит побочные эффекты), то ровно наоборот - ленивость заставляет думать о порядке вычислений гораздо больше обычного, т.к. программа ведет себя не так, как обычно подсказывает интуиция. В строгих же языках порядок вычислений настолько прост и понятен, что задумываться не заставляет.

Date: 2010-05-22 06:12 pm (UTC)
From: [identity profile] thesz.livejournal.com
>Что-то я не припомню, чтобы программисты на неленивых языках стали бы вычислять какие-то значения, которые потом не используют. Обычно все-таки люди достаточно разумны, чтобы их программы вычисляли ровно столько, сколько нужно.

Это если они об этом помнят. И база кода небольшая. И народу работает мало.

Нарушь хоть одно из условий, и всё.

Date: 2010-05-22 06:18 pm (UTC)
From: [identity profile] soonts.livejournal.com
Как только эти ненужные вычисления начнут отнимать существенное время, сразу засветятся в vTune или любом другом используемом профайлере. Это произойдёт даже если много народу работают над большой базой кода и никто ничего не помнит. После этого, если есть какие-то требования к производительности (например это real-time игра, или серверное приложение), алгоритм будет оптимизирован.

Date: 2010-05-22 06:59 pm (UTC)
From: [identity profile] thesz.livejournal.com
Собственно, я про пользу ленивых вычислений.

Мой любимый пример: одну и ту же штуку под названием CollisionEnvironment, что получалась в результате выборки по миру, требовали несколько систем, причём одна из них - в нескольких местах, и не всегда в каждом из них. Я как-то справился, получив пятикратное ускорение, но на этом примере я люблю демонстрировать пользу ленивых вычислений - вместо "if (ce == null) ce = вычисление" можно было бы просто создать выборку "ce=вычисление", которая бы выполнилась только тогда, когда надо. И не более одного раза.

До этого считалось, что в физике с AI особых проблем с производительностью нет. ;)

Profile

thedeemon: (Default)
Dmitry Popov

December 2025

S M T W T F S
 12 3456
789101112 13
14151617181920
21222324252627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 30th, 2026 08:53 pm
Powered by Dreamwidth Studios