2011-08-01 11 views
8

aşağıdaki iki program değişken st üzerinde katılık bayrağı sadece farklılıkSıkı bayrak neden bellek kullanımını artırıyor? bu iki program Derleme ve çalışan

$ cat testStrictL.hs

module Main (main) where 

import qualified Data.Vector as V 
import qualified Data.Vector.Generic as GV 
import qualified Data.Vector.Mutable as MV 

len = 5000000 

testL = do 
    mv <- MV.new len 
    let go i = do 
      if i >= len then return() else 
      do let st = show (i+10000000) -- no strictness flag 
       MV.write mv i st 
       go (i+1) 
    go 0 
    v <- GV.unsafeFreeze mv :: IO (V.Vector String) 
    return v 

main = 
    do 
    v <- testL 
    print (V.length v) 
    mapM_ print $ V.toList $ V.slice 4000000 5 v 

$ cat testStrictS.hs

module Main (main) where 

import qualified Data.Vector as V 
import qualified Data.Vector.Generic as GV 
import qualified Data.Vector.Mutable as MV 

len = 5000000 

testS = do 
    mv <- MV.new len 
    let go i = do 
      if i >= len then return() else 
      do let !st = show (i+10000000) -- this has the strictness flag 
       MV.write mv i st 
       go (i+1) 
    go 0 
    v <- GV.unsafeFreeze mv :: IO (V.Vector String) 
    return v 

main = 
    do 
    v <- testS 
    print (V.length v) 
    mapM_ print $ V.toList $ V.slice 4000000 5 v 

Ghc 7.03 ile Ubuntu 10.10 aşağıdaki sonuçları elde edin:

 
$ ghc --make testStrictL.hs -O3 -rtsopts 
[2 of 2] Compiling Main    (testStrictL.hs, testStrictL.o) 
Linking testStrictL ... 
$ ghc --make testStrictS.hs -O3 -rtsopts 
[2 of 2] Compiling Main    (testStrictS.hs, testStrictS.o) 
Linking testStrictS ... 
$ ./testStrictS +RTS -sstderr 
./testStrictS +RTS -sstderr 
5000000 
"14000000" 
"14000001" 
"14000002" 
"14000003" 
"14000004" 
    824,145,164 bytes allocated in the heap 
    1,531,590,312 bytes copied during GC 
    349,989,148 bytes maximum residency (6 sample(s)) 
     1,464,492 bytes maximum slop 
      656 MB total memory in use (0 MB lost due to fragmentation) 

    Generation 0: 1526 collections,  0 parallel, 5.96s, 6.04s elapsed 
    Generation 1:  6 collections,  0 parallel, 2.79s, 4.36s elapsed 

    INIT time 0.00s ( 0.00s elapsed) 
    MUT time 1.77s ( 2.64s elapsed) 
    GC time 8.76s (10.40s elapsed) 
    EXIT time 0.00s ( 0.13s elapsed) 
    Total time 10.52s (13.04s elapsed) 

    %GC time  83.2% (79.8% elapsed) 

    Alloc rate 466,113,027 bytes per MUT second 

    Productivity 16.8% of total user, 13.6% of total elapsed 

$ ./testStrictL +RTS -sstderr 
./testStrictL +RTS -sstderr 
5000000 
"14000000" 
"14000001" 
"14000002" 
"14000003" 
"14000004" 
     81,091,372 bytes allocated in the heap 
    143,799,376 bytes copied during GC 
     44,653,636 bytes maximum residency (3 sample(s)) 
     1,005,516 bytes maximum slop 
       79 MB total memory in use (0 MB lost due to fragmentation) 

    Generation 0: 112 collections,  0 parallel, 0.54s, 0.59s elapsed 
    Generation 1:  3 collections,  0 parallel, 0.41s, 0.45s elapsed 

    INIT time 0.00s ( 0.03s elapsed) 
    MUT time 0.12s ( 0.18s elapsed) 
    GC time 0.95s ( 1.04s elapsed) 
    EXIT time 0.00s ( 0.06s elapsed) 
    Total time 1.06s ( 1.24s elapsed) 

    %GC time  89.1% (83.3% elapsed) 

    Alloc rate 699,015,343 bytes per MUT second 

    Productivity 10.9% of total user, 9.3% of total elapsed 

Birisi, lütfen neden sertlik bayrağının programın o kadar çok bellek kullanmasına neden olduğunu açıklayabilir mi? Bu basit örnek benim programlarımı neden 5 milyon satırlık büyük dosyaları okurken ve kayıtların vektörlerini oluştururken o kadar çok bellek kullandığını anlama girişimlerimden geldi.

+1

Sıkılık, yürütme sırasını kısıtlar - bu onun tam anlamı. Bu optimizasyon seçeneklerini sınırlar. Bir cevap değil, çünkü benim Haskell-fu tam olarak ne olduğunu söyleyecek kadar güçlü değil, ama benim tahminim, sıkılığın 'go' kuyruk-yinelemeli olarak daha verimli bir şekilde yeniden kullanılmasını sağlayan bir optimizasyonu engelliyor olmasıydı. döngü. – Steve314

+0

GHC'nin yakın tarihli bir sürümünü kullanıyorsanız, LLVM arka ucunun orijinal GHC arka ucu yerine kullanılması gerektiğini belirtebilirsiniz. Bu muhtemelen en üst düzey optimizasyon kararlarını etkilemez, ancak düşük seviyeli üretilen kod için tamamen farklı bir iyileştirici seçecektir. – Steve314

cevap

8

Buradaki sorun esas olduğunu kullandığınız nedeniyle tek Char s olmayan bir katı liste olarak kendi temsil bellek öbek üzerinde karakterlerin başına 5 kelime gerektirir tipi ([Char] için bir takma ad) String (sıkı durumda tamamlama dizeleri 8 karakterden oluşan oysa temelde, (paylaşılan) değerlendirme işlevlerinin show . (+10000000) işaret bir unevaluated thunk ve değişen tamsayı depolamak, bazı bellek izi karşılaştırmalar) tembel durumda

için de this blog article bakınız Materyalize edilmiş gibi görünüyor (genellikle patlama modeli sadece en dıştaki liste oluşturucu :'u, yani bir tembel'in ilk karakterini zorlar, değerlendirilmek üzere), daha fazla yığın alanı gerektiren dizeleri daha uzun hale getirir. uzunluğundaki 8-şeritli dizilerin saklanması, böylece 32-bit'de yaklaşık ~ 763 MiB'ye karşılık gelen 5000000 * 8 * 5 = 200000000 sözcük gerektirir. Char rakamları paylaşılırsa, yalnızca 3/5 değerine, yani gözlemlenen bellek yükünüzle eşleşecek şekilde görünen ~ 458 MiB'ye ihtiyacınız vardır.

String ürününü Data.ByteString.ByteString gibi daha kompakt bir şeyle değiştirirseniz, düz bir String kullanıldığında bellek yükünün yaklaşık bir kat daha düşük olacağını fark edersiniz.

+0

Cevabınız için teşekkürler hvr. Data.ByteString.Char8 veya Data.Text kullanarak büyük bir düşük bellek yükü almadım, sadece yaklaşık yarısı ama yine de büyük bir gelişme. – user449050

+1

@ user449050, Ben sadece iyileştirme biraz daha önemli olduğu, 64-bit denedim, 32-bit aynı faktör olmadığını dikkate almamıştım. – hvr

İlgili konular