Всегда гарантированный порядок оценки " seq "(со странным поведением "pseq" дополнительно)

ответы до сих пор сосредоточены на seq и pseq проблемы с производительностью, но я думаю, что вы изначально хотели узнать, какой из двух вы должны использовать.

короткий ответ: хотя оба должны генерировать почти одинаково выполняющийся код на практике (по крайней мере, когда включены соответствующие флаги оптимизации), примитив seq, а не pseq, это правильный выбор для вашей ситуации. Используя pseq не-идиоматические, запутанным и потенциально контрпродуктивно с точки зрения производительности, и ваша причина его использования основана на ошибочном понимании того, что означает его гарантия порядка оценки и что она подразумевает в отношении производительности. Хотя нет никаких гарантий производительности для разных наборов флагов компилятора (тем более для других компиляторов), если вы когда-либо сталкивались с ситуацией, когда seq версия вышеуказанного кода работает значительно медленнее, чем pseq версия используя " качество продукции" флаги оптимизации с компилятором GHC, вы должны считать его ошибкой GHC и подать отчет об ошибке.

длинный ответ, конечно, длиннее...

во-первых, давайте уточним, что seq и pseq are семантически идентичны в том смысле, что они оба удовлетворяют уравнениям:

seq _|_ b = _|_
seq a b = b -- if a is not _|_
pseq _|_ b = _|_
pseq a b = b -- if a is not _|_

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

кроме того, в вашем конкретном seq - на основе версии функции sum, это не слишком сложно увидеть, что нет никакой ситуации, в которой seq вызывается с неопределенным первым аргументом, но определенным вторым аргумент (при условии использования стандартного числового типа), поэтому вы даже не используя семантические свойства seq. Вы можете переопределить seq as seq a b = b и имеют точно такую же семантику. Конечно, вы знаете это-вот почему ваша первая версия не использовала seq. Вместо этого, вы используете seq для случайного побочного эффекта производительности, поэтому мы вышли из области семантических гарантий и вернулись в область конкретной реализации компилятора GHC и производительности характеристики (где на самом деле нет гарантии говорить).

во-вторых, это подводит нас к назначение of seq. Он редко используется для его семантических свойств, потому что эти свойства не очень полезны. Кому нужны вычисления?--22--> вернуться b за исключением что он не должен завершаться, если какое-то несвязанное выражение a не удалось завершить? (Исключения - каламбур не предназначен -- будут такие вещи, как обработка исключений, где вы могли бы использовать seq или deepSeq который основан на seq чтобы принудительно оценить неконтролируемое или контролируемое выражение перед началом оценки другого выражения.)

вместо seq a b предназначен для принудительной оценки a к слабой головной нормальной форме перед возвращением результата b предотвратить накопление thunks. Идея в том, если у вас есть выражение b что создает thunk, который потенциально может накапливаться поверх другого недооцененного thunk, представленного a, вы можете предотвратить это накопление с помощью seq a b. "Гарантия" слабая: GHC гарантирует, что он понимает, что вы не хотите a чтобы остаться недооцененным thunk, когда seq a b's значение потребовано. Технически, это не гарантирует, что a будет "оценено перед" b, что бы это ни значило, но тебе не нужна эта гарантия. когда вы беспокойство о том, что без этой гарантии GHC может сначала оценить рекурсивный вызов и все еще накапливать удары, так же смешно, как беспокоиться о том, что pseq a b может оценить свой первый аргумент, а затем подождать 15 минут (просто чтобы убедиться, что первый аргумент был оценен!), прежде чем оценивать его второй.

это ситуация, когда вы должны доверять GHC, чтобы сделать правильную вещь. Вам может показаться, что единственный способ реализовать преимущество производительности seq a b для a быть оцененным к WHNF перед оценкой b начинается, но возможно, что есть оптимизации в той или иной ситуации, которые технически начинают оценивать b (или даже полностью оценить b в WHNF) при отъезде a unevaluated в течение короткого времени, чтобы улучшить производительность, сохраняя при этом семантику seq a b. Используя pseq вместо этого вы можете запретить GHC делать такие оптимизации. (В sum ситуации, программы, есть несомненно, нет такой оптимизации, но в более сложном использовании seq, там может быть.)

в-третьих, важно понимать, что pseq на самом деле for. Это было впервые описано в Марлоу 2009 в контексте параллельного программирования. Предположим, мы хотим распараллелить два дорогостоящих вычисления foo и bar а затем объединить (скажем, добавить) их результаты:

foo `par` (bar `seq` foo+bar)  -- parens redundant but included for clarity

намерение здесь в том, что -- когда это требуется значение выражения - оно создает искру для вычисления foo параллельно, а затем, через seq выражение лица, приступает к оценке bar к WHNF (т. е., это числовое значение, скажем), прежде чем окончательно оценить foo+bar который будет ждать искры для foo перед добавлением и возвратом результатов.

здесь возможно, что GHC распознает это для определенного числового типа (1) foo+bar автоматически не завершается, если bar делает, удовлетворяющих формальная семантическая гарантия seq; и (2) оценке foo+bar к WHNF автоматически принудит оценку bar к WHNF предотвращая любое накопление thunk и таким образом удовлетворяя неофициальную гарантию реализации seq. В этой ситуации GHC может свободно оптимизировать seq отсюда выход:

foo `par` foo+bar

особенно если он чувствует, что было бы более эффективным, чтобы начать оценку foo+bar перед окончанием оценки bar to WHNF.

что GHC не достаточно умен, чтобы понять, что-если оценка foo на foo+bar начнется перед foo Искра запланирована, искра будет шипеть, и никакое параллельное выполнение не произойдет.

это действительно только в этом случае, когда вам нужно явно отложить требование значения искрящегося выражения, чтобы позволить ему быть запланированным до того, как основной поток "догонит" , что вам нужна дополнительная гарантия pseq и готовы иметь GHC forgo дополнительные возможности оптимизации, разрешенные более слабой гарантией seq:

foo `par` (bar `pseq` foo+bar)

здесь pseq предотвратит GHC от внедрения любой оптимизации, которая может позволить foo+bar чтобы начать оценку (потенциально шипящий foo spark) перед bar находится в WHNF (который, мы надеемся, позволяет достаточно времени для Искры быть запланированным).

результат таков, если вы используете pseq для всего, кроме параллельного программирования, ты неправильно его используешь. (Ну, может быть, есть некоторые странные ситуации, но...) Если все, что вы хотите сделать, это заставить строгую оценку и / или оценку thunk улучшить производительность в непараллельном коде, используя seq (или $!, который определяется в терминах seq или строгие типы данных Haskell, которые определены в терминах $!) - это правильный подход.

(или, если верить бенчмаркам @Kindaro, возможно, беспощадный бенчмаркинг с конкретными версиями компилятора и флаги-это правильный подход.)