=_a6OH Text.Parsec.Prim 20.6 13.0 tokenPrimEx Text.Parsec.Prim 16.5 20.8 fmap_a6Qj Text.Parsec.Prim 15.5 3.6
Hi, I've put together a parser that works like this: - the full input is read into a strict ByteString; - such string is split into a number of lines; - each line is fed (independently) to a parser based on Parsec (version 3). Running the serial version of the parser (compiled with -O2 optimizations) on a rather large file, I get the following: $ ./Parser +RTS -s 2,175,464,100 bytes allocated in the heap 49,293,632 bytes copied during GC 5,297,560 bytes maximum residency (6 sample(s)) 1,406,800 bytes maximum slop 16 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 4140 collections, 0 parallel, 0.39s, 0.42s elapsed Generation 1: 6 collections, 0 parallel, 0.05s, 0.07s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 1.93s ( 1.99s elapsed) GC time 0.44s ( 0.48s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.37s ( 2.47s elapsed) %GC time 18.7% (19.5% elapsed) Alloc rate 1,127,336,508 bytes per MUT second Productivity 81.2% of total user, 78.1% of total elapsed The profile report: COST CENTRE MODULE %time %alloc parserBind Text.Parsec.Prim 12.4 9.3 mplus_a6KS Text.Parsec.Prim 10.3 10.6 notFollowedBy Text.Parsec.Combinator 3.1 4.4 [...] shows that the biggest part of the execution time is spent in the parser (not in the read & line split operations, as expected). Given that each line is parsed independently, I used the following code: map parse lines `using` parListChunk 250 rnf to spark a separate computation for each group of 250 lines. I made the datatype used by the parser an instance of NFData, so that the "rnf" strategy should force a complete evaluation. The threaded version running on 2 cores is moderately faster than the serial one: $ ./Parser +RTS -s -N2 2,377,165,256 bytes allocated in the heap 36,320,944 bytes copied during GC 6,020,720 bytes maximum residency (6 sample(s)) 6,933,928 bytes maximum slop 21 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 2410 collections, 0 parallel, 0.33s, 0.34s elapsed Generation 1: 6 collections, 4 parallel, 0.06s, 0.05s elapsed Parallel GC work balance: 1.83 (2314641 / 1265968, ideal 2) Task 0 (worker) : MUT time: 2.43s ( 1.19s elapsed) GC time: 0.02s ( 0.02s elapsed) Task 1 (worker) : MUT time: 2.15s ( 1.19s elapsed) GC time: 0.29s ( 0.30s elapsed) Task 2 (worker) : MUT time: 2.37s ( 1.19s elapsed) GC time: 0.07s ( 0.08s elapsed) Task 3 (worker) : MUT time: 2.45s ( 1.19s elapsed) GC time: 0.00s ( 0.00s elapsed) INIT time 0.00s ( 0.00s elapsed) MUT time 2.06s ( 1.19s elapsed) GC time 0.39s ( 0.39s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.45s ( 1.58s elapsed) %GC time 15.7% (24.9% elapsed) Alloc rate 1,151,990,234 bytes per MUT second Productivity 84.2% of total user, 130.2% of total elapsed The speedup is smaller than what I was expecting given that each unit of work (250 input lines) is completely independent from the others. Changing the size of each work unit did not help; garbage collection times are small enough that increasing the minimum heap size did not produce any speedup either. Is there anything else I can do to understand why the parallel map does not provide a significant speedup? Thanks, AB