Hello Anakim,
Wednesday, September 9, 2009, 11:58:58 PM, you wrote:
> foresee. I guess a possible solution would be to base parMap on
> different 'par' primitive; one that sparks a number of computations
> equal to the number of available OS threads and then blocks until at
> least one of them is
Actually you can still do the same trick, you just need a smarter delimiter
-- ironically the same one I use in Kata. ;) Look for non-backslashed
newlines rather than newlines in general and start there.
You need a little bit of book-keeping in case a backslash and newline
straddle the chunk bound
Hi Edward,
I read your slides a few weeks ago when they were posted on Reddit and
found your approach very interesting. In fact it provided the
inspiration for the parser I've written.
I did not use the same strategy, however, because parsing makefiles
poses its own challenges. The make syntax is
ekmett:
>
>
> On Wed, Sep 9, 2009 at 12:16 PM, Don Stewart wrote:
>
> ekmett:
> > Hi Anakim,
> >
> > Nice to see someone else working in this space.
> >
> > I have also been working on a set of parallel parsing techniques, which
> can use
> > small Parsec par
On Wed, Sep 9, 2009 at 12:16 PM, Don Stewart wrote:
> ekmett:
> > Hi Anakim,
> >
> > Nice to see someone else working in this space.
> >
> > I have also been working on a set of parallel parsing techniques, which
> can use
> > small Parsec parsers for local context sensitivity.
> >
> > See the se
ekmett:
> Hi Anakim,
>
> Nice to see someone else working in this space.
>
> I have also been working on a set of parallel parsing techniques, which can
> use
> small Parsec parsers for local context sensitivity.
>
> See the second set of slides in http://comonad.com/reader/2009/
> iteratees
Hi Anakim,
Nice to see someone else working in this space.
I have also been working on a set of parallel parsing techniques, which can
use small Parsec parsers for local context sensitivity.
See the second set of slides in
http://comonad.com/reader/2009/iteratees-parsec-and-monoid/ for an overvi
> Very interesting idea!
>
> I think the big thing would be to measure it with GHC HEAD so you can
> see how effectively the sparks are being converted into threads.
>
> Is there a package and test case somewhere we can try out?
At this point the parser is just a proof of concept. For those brave
Hello Anakim,
Wednesday, September 9, 2009, 5:35:32 PM, you wrote:
> MUT time1.93s ( 1.99s elapsed)
> MUT time2.06s ( 1.19s elapsed)
the speedup is very good. usually you don't get 2x faster execution
because cores compete for the access to memory
ps: are you sure that you
akborder:
>
> 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 m
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
optimiza
11 matches
Mail list logo
