"+RTS -A" parameter and CPU cache size

Bulat Ziganshin bulat.ziganshin at gmail.com
Fri Jun 16 10:51:06 EDT 2006


Hello Simon,

Friday, June 16, 2006, 4:50:15 PM, you wrote:

>>>> char *ghc_rts_opts = "-A10m";
>>> Do you have some evidence that -A10m is a good default?  Better than
>>> -A6m, or -A16m, for example?  GHC currently runs with -H6m by
>>> default. 
>> 
>> of course, "-a6m" is not worser than "-a10m". but "-h" is not a good
>> alternative because after memory usage grows above 6 mb, ghc starts to
>> do minor GCs after each 256 kb allocated. with "-A6m" number of minor
>> GCs will be dramatically cut off
>> 
>> i just quickly tested non-optimized compilation of my program with
>> "-A6m" and with "-H6m" (ghc 6.4.2.20060609) - wall clock time of
>> compilation was 63 seconds against 76 seconds, while memory usage was
>> 70 mb against 68 mb 

> What I'm getting at is what you think the best value for -A might be.
> I'm aware of the problem exposed by using -H on its own.  So -A6m is no
> worse than -A10m?  In that case, -A6m is clearly to be preferred; but is
> there a better point between 6m and 256k?

i think that when "-A" is larger than cpu cache, it's increasing
should decrease GC times. there is no "best point", it's just
memory/speed compromise. when -A is large enough, GC times should be a
small percent of total execution time, so it should be no much
difference between 6m or 16m settings. but 16m should be slightly
faster than 6m, and 32m should be slightly faster than 16m

i've just tested GHC with "-A6m" and "-A16m" and it was only 1 second
faster with second setting (of total 60 seconds)


>> btw, now i use "+RTS -c" in my compilations - it works fine. i'm
>> happy :) 

> Doesn't that increase GC time significantly?

of course, but it's much better than running out of physical memory.
to be exact, i use "-A10m -M256m -c20" for my 256mb of RAM (i disable
these options when i do above mentioned tests)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Glasgow-haskell-users mailing list