Sterling Clover wrote:
Um... you do realize that the code is only supposed to match against
very specific lines in sample data sets that Bray provides, right? If
your access log doesn't have lines exactly like those (and why would
it?) then there's no reason to expect a result.
--S
On Nov
http://www.tbray.org/tmp/o10k.ap is the basic data set. For heavier
duty testing, folks seem to be appending it to itself 99 more times
to yield a o1000k.ap dataset. I'd be curious for comments on my
code or other suggestions to speed things up -- the strictness
semantics of the
s.clover:
http://www.tbray.org/tmp/o10k.ap is the basic data set. For heavier
duty testing, folks seem to be appending it to itself 99 more times
to yield a o1000k.ap dataset. I'd be curious for comments on my
code or other suggestions to speed things up -- the strictness
semantics of
Sterling Clover wrote:
Maps are a good choice for parallelism because they merge
efficiently, but for the iterative aspect their performance leaves a lot
to be desired.
This is not consistent with my observations, I must say.
What I've found to dominate the benchmark are straightforward
I hacked together a version that I'm pretty happy with today. Started
off trying an algorithm with channels and forking, then realized that
in Haskell thanks to referential transparency we can get parallelism
almost for free, and redid it all in Control.Parallel (below).
Unfortunately, I
Sterling Clover wrote:
I hacked together a version that I'm pretty happy with today. Started
off trying an algorithm with channels and forking, then realized that
in Haskell thanks to referential transparency we can get parallelism
almost for free, and redid it all in Control.Parallel (below).
Um... you do realize that the code is only supposed to match against
very specific lines in sample data sets that Bray provides, right? If
your access log doesn't have lines exactly like those (and why would
it?) then there's no reason to expect a result.
--S
On Nov 9, 2007, at 11:19 PM,
Haskell is conspicuously absent from the languages used to tackle Tim
Bray's Wide Finder problem (http://www.tbray.org/ongoing/When/200x/
2007/10/30/WF-Results?updated).
So far we have Ocaml, Erlang, Python, Ruby, etc...
Bryan quickly wrote a program on his blog (http://www.serpentine.com/
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of manu
Haskell is conspicuously absent from the languages used to tackle Tim
Bray's Wide Finder problem
(http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results?updated).
So far we have Ocaml, Erlang, Python, Ruby, etc...
