Вопрос по haskell, optimization – Оптимизация GHC: гипотеза Коллатца

12

Я написал код дляProject Euler's Challenge 14, в обоихHaskell а такжеC ++ (идеально ссылки). Они оба помнят любые вычисления, которые они ранее делали в массиве.

С помощьюghc -O2 а такжеg++ -O3 соответственно C ++ работает в 10-15 раз быстрее, чем версия на Haskell.

Хотя я понимаю, что версия на Haskell может работать медленнее, и что Haskell является более приятным языком для написания, было бы неплохо узнать некоторые изменения кода, которые я могу внести в версию на Haskell, чтобы она работала быстрее (в идеале с коэффициентом 2 или 3 версии C ++)?

Код на Haskell находится здесь:

import Data.Array
import Data.Word
import Data.List

collatz_array = 
  let
    upperbound = 1000000
    a = array (1, upperbound) [(i :: Word64, f i :: Int) | i <- [1..upperbound]]
    f i = i `seq`
      let
        check_f i = i `seq` if i <= upperbound then a ! i else f i
      in
        if (i == 1) then 0 else (check_f ((if (even i) then i else 3 * i + 1) `div` 2)) + 1
  in a

main = 
  putStrLn $ show $ 
   foldl1' (\(x1,x2) (y1,y2) -> if (x2 >= y2) then (x1, x2) else (y1, y2)) $! (assocs collatz_array)

Edit:

Теперь я также сделал версию, использующую неупакованные изменяемые массивы. Это все еще в 5 раз медленнее, чем версия C ++, но это значительное улучшение. Код на IdeoneВот.

Я хотел бы знать улучшения в версии изменяемого массива, которые приближают ее к версии C ++.

Не используйтеdivиспользоватьquot. augustss
Вашseq не имеет значения; обе ваши функции являются строгими вi, Раньше GHC был довольно плох в 64-битной арифметике на 32-битных платформах, но я не знаю, какую платформу вы используете. augustss
не объясняет вашу проблему с производительностью, но ни ваш C ++ (по крайней мере, то, что опубликовал nanothief), ни код на Haskell не дают правильного ответа. Я не могу скомпилировать ваш C ++, но у меня есть чистое решение на Haskell примерно такой же длины, что и ваш код, который примерно на 25% быстрее на моей машине и дает правильный результат. В этот момент примерно половина времени выглядит как накладные расходы, связанные с запуском программы на Haskell. Philip JF
@PhilipJF Как далеко код не дает правильный результат? Обратите внимание, что Клинтон использует немного другой шаг, а именно для нечетныхnон идет прямо к(3*n+1)/2 вместо того, чтобы сделать два шага для этого. Таким образом он получает различные длины цепей, но начальные точки самых длинных цепочек одинаковы. Daniel Fischer
Просто к вашему сведению, составление с-fllvm улучшает производительность на ~ 10% на моей машине. Greg E.

Ваш Ответ

2   ответа
2

который становится довольно старым. На GHC версии 7.4.1 разница намного меньше.

С GHC:

$ ghc -O2 euler14.hs && time ./euler14
(837799,329)
./euler14  0.63s user 0.04s system 98% cpu 0.685 total

С g ++ 4.7.0:

$ g++ --std=c++0x -O3 euler14.cpp && time ./a.out
8400511 429
./a.out  0.24s user 0.01s system 99% cpu 0.252 total

Для меня версия GHC только в 2,7 раза медленнее, чем версия C ++. Кроме того, две программы не дают одинакового результата ... (плохой знак, особенно для сравнительного анализа)

К сожалению, я разместил тест на 10 миллионов, а не на 1 миллион. Ссылка исправлена. Обратите внимание, что версия c ++ работала в 10 миллионов раз в 2,7 раза быстрее, чем Haskell - 1 миллион. Clinton
4

You use a fold to find the maximal chain length, for that the array has to be converted to an association list, that takes time and allocation the C++ version doesn't need. You use even and div for testing resp dividing by 2. These are slow. g++ optimises both operations to the faster bit operations (on platforms where that is supposedly faster, at least), but GHC doesn't do these low-level optimisations (yet), so for the time being, they have to be done by hand. You use readArray and writeArray. The extra bounds-checking that isn't done in the C++ code also takes time, once the other problems are dealt with, that amounts to a significant portion of the running time (ca. 25% on my box), since there are done a lot of reads and writes in the algorithm.

Включив это в реализацию, я получаю

import Data.Array.ST
import Data.Array.Base
import Control.Monad.ST
import Data.Bits

collatz_array :: ST s (STUArray s Int Int)
collatz_array = do
    let upper = 10000000
    arr <- newArray (0,upper) 0
    unsafeWrite arr 2 1
    let check i
            | upper < i = return arr
            | i .&. 1 == 0 = do
                l <- unsafeRead arr (i `shiftR` 1)
                unsafeWrite arr i (l+1)
                check (i+1)
            | otherwise = do
                let j = (3*i+1) `shiftR` 1
                    find k l
                        | upper < k = find (next k) $! l+1
                        | k < i     = do
                            m <- unsafeRead arr k
                            return (m+l)
                        | otherwise = do
                            m <- unsafeRead arr k
                            if m == 0
                              then do
                                  n <- find (next k) 1
                                  unsafeWrite arr k n
                                  return (n+l)
                              else return (m+l)
                          where
                            next h
                                | h .&. 1 == 0 = h `shiftR` 1
                                | otherwise = (3*h+1) `shiftR` 1
                l <- find j 1
                unsafeWrite arr i l
                check (i+1)
    check 3

collatz_max :: ST s (Int,Int)
collatz_max = do
    car <- collatz_array
    (_,upper) <- getBounds car
    let find w m i
            | upper < i = return (w,m)
            | otherwise = do
                l <- unsafeRead car i
                if m < l
                  then find i l (i+1)
                  else find w m (i+1)
    find 1 0 2

main :: IO ()
main = print (runST collatz_max)

И сроки (оба по 10 миллионов)

$ time ./cccoll
8400511 429

real    0m0.210s
user    0m0.200s
sys     0m0.009s
$ time ./stcoll
(8400511,429)

real    0m0.341s
user    0m0.307s
sys     0m0.033s

что не выглядит слишком плохо.

Important note: Этот код работает только на 64-битном GHC (поэтому, в частности, в Windows вам нужен ghc-7.6.1 или новее, предыдущие GHC были 32-битными даже в 64-битной Windows), поскольку элементы промежуточных цепочек превышают 32-битный диапазон , В 32-битных системах нужно было бы использоватьInteger или 64-битный целочисленный тип (Int64 или жеWord64) для следования цепочкам при значительных затратах производительности, поскольку примитивные 64-битные операции (арифметика и сдвиги) реализованы как внешние вызовы функций C в 32-битных GHC (fast иностранные звонки, но все же намного медленнее, чем прямая машина опс).

(3*h+1) shiftR` 1` такой же, как(shiftR h 1) + h + 1 что может быть быстрее на некоторых машинах
В самом деле. Не дает достоверно измеримых различий на моем, так что, если есть различие, оно меньше, чем естественное дрожание здесь. Но на машинах с медленным умножением это определенно то, что нужно попробовать.

Похожие вопросы