Simon Marlow wrote:

I'm not keen on using explicit unboxed values in these benchmarks, since it looks so ugly. In most cases you can convince GHC to do the unboxing for you, and I'm pretty sure it should be the case here too. Just use ordinary Ints.

The syntax is not so pleasing, but it is consistant.

It's interesting you're getting some benefit from using integers instead of enumerations. We've known for a while that enumerations in GHC aren't optimised as well as they could be.

So what I am seeing was well known.

So, at least for now, this is a useful trick: instead of

data T = A | B | C

write

newtype T = T Int

a = T 1 b = T 2 c = T 3

and then GHC will be able to unbox T in a constructor field (ie. {-# UNPACK #-} !T will work), and it will also be able to unbox T in a strict argument position.

I have never used UNPACK or -funbox-strict-fields before. I tried several variations -- all slower. I never declare "data Foo = Foo Color" so "Foo {-# UNPACK #-} !Color" is not possible right now. I do make a tuple of (Color,MVar Color) and put this into an MVar. Replacing this with data ID = ID {-# UNPACK #-} !Color !(MVar Color) has made things a bit worse.

Of course you do lose the ability to do pattern matching.

Which may cause other speed issues. But I set "complement _ _ = red" to remove any performance hit there.

Cheers, Simon

So I cannot seem to benefit form UNPACK or -funbox-strict-fields at the moment. -- Chris

Simon Marlow wrote:

Hi Chris,

Rather than try to explain what I'm going on about, I decided to tweak the code a bit myself. My version is about 10% faster than yours, and doesn't use any explicit unboxery. I've put it in the wiki after your version.

http://www.haskell.org/hawiki/ChameneosEntry

Could someone upload this to the shootout?

Cheers, Simon

So no one else tries to submit this: I have just sent it to the shootout. -- Chris

Summary of things entered and of things being worked on. Donald Bruce Stewart wrote:

haskell:

...

Simon Marlow wrote:

...

Hi Chris,

Rather than try to explain what I'm going on about, I decided to tweak the code a bit myself. My version is about 10% faster than yours, and doesn't use any explicit unboxery. I've put it in the wiki after your version.

http://www.haskell.org/hawiki/ChameneosEntry

Could someone upload this to the shootout?

Cheers, Simon

So no one else tries to submit this: I have just sent it to the shootout.

Perhaps we should submit some of the other entires on the wiki too?

-- Don

I updated their wiki pages before, but the following submissions are in the pipeline. I am using https://alioth.debian.org/tracker/index.php?group_id=30402&atid=411646 as a way to query the Category == Haskell GHC State == Any Order by == ID Descending On 6 Jan, I submitted: sum-file was submitted (using Simon style implicit unboxery) fasta was submitted (using Simon style implicit unboxery and which should fix the memory leak) chameneos was submitted (where Simon made the unboxing implicit) On 5 Jan: pidigit was submitted (Branimir Maksimovic's) On 4 Jan: regex-dna was submitted (by Don, but you knew that, Don) etc. Things that are on the wiki at http://haskell.org/hawiki/ShootoutEntry but that have not been submitted: Fannkuch entry by Bertram Felgenhauer K-nucleotide (if it become space competitive) Reverse Complement (if it becomes space competitive) Harmonic entry Mandelbrot entry N-Body entry I have not tackled the space problems of K-nucleotide and Rev-Comp, but it seems that Haskell has a powerful need for better string array capabilities in its standard library. I am hopeful they can be revisited once that new version arrives (and the fata benchmark as well). I think after updating sum-file and fasta that I know understand how to tweak things with -funbox-strict-fields. Thanks Simon! -- Chris

dons:

haskell:

...

Summary of things entered and of things being worked on.

Things that are on the wiki at http://haskell.org/hawiki/ShootoutEntry but that have not been submitted:

Fannkuch entry by Bertram Felgenhauer Mandelbrot entry

I've done some benchmarking of the current entries for fannkuch and mandelbrot, and have proposed final entries for these two tests. Perhaps you'd like to confirm the speed improvments, and submit them, Chris?

And a proposed entry for harmonic is ready to be submitted, too, once you test on your setup. -- Don

neubauer:

dons@cse.unsw.edu.au (Donald Bruce Stewart) writes:

...

...

...

Fannkuch entry by Bertram Felgenhauer Mandelbrot entry

I've done some benchmarking of the current entries for fannkuch and mandelbrot, and have proposed final entries for these two tests.

Using >>= of the list monad in the current Fannkuch proposal (permutations) hides some costly ++ applications that can be also optimized away:

Instead of writting

permutations l = foldr perm' [l] [2..length l] where perm' n l = l >>= take n . iterate (rotate n)

saying something like

permutations l = foldr perm' [l] [2..length l]

perm' n = foldr (takeIter n (rotate n)) []

takeIter :: Int -> (a -> a) -> a -> [a] -> [a] takeIter 0 f x rest = rest takeIter n f x rest = x : takeIter (n-1) f (f x) rest

gains us another 5% or so.

Ah! Good idea Matthias. I've updated the proposed entry on the wiki. Cheers, Don

dons:

haskell:

...

Summary of things entered and of things being worked on.

Donald Bruce Stewart wrote:

...

haskell:

...

Simon Marlow wrote:

...

Hi Chris,

Rather than try to explain what I'm going on about, I decided to tweak the code a bit myself. My version is about 10% faster than yours, and doesn't use any explicit unboxery. I've put it in the wiki after your version.

http://www.haskell.org/hawiki/ChameneosEntry

Could someone upload this to the shootout?

Cheers, Simon

So no one else tries to submit this: I have just sent it to the shootout.

Perhaps we should submit some of the other entires on the wiki too?

-- Don

I updated their wiki pages before, but the following submissions are in the pipeline. I am using

https://alioth.debian.org/tracker/index.php?group_id=30402&atid=411646

as a way to query the Category == Haskell GHC State == Any Order by == ID Descending

On 6 Jan, I submitted: sum-file was submitted (using Simon style implicit unboxery) fasta was submitted (using Simon style implicit unboxery and which should fix the memory leak) chameneos was submitted (where Simon made the unboxing implicit) On 5 Jan: pidigit was submitted (Branimir Maksimovic's)

By the way, this pidigit seems to be several times slower than the one already submitted.

My apologies to the author, it's only a few percent, not several times slower. -- Don

bmaxa:

This pidigit program is not mine, but original authors of algorithm. I've just added print function. It is idiomatic Haskell, pi is pure function that generates inifinite list of digits, and on two machinas I've tested p4 2.4 ghz and amd athlon 64 3000 it's about some small percentage ( 5%) faster then one submited for benchmark. Who knows on test machines could be some percentage slower, but what is important is that it is not optimised in any way and does not use monads, but is very fast.

Yes, it's quite interesting that it performs so well, with only a little wrapping code. Cheers, Don

Bulat Ziganshin wrote:

the same is for Int32 (and i think other fixed-width integrals). i just noticed that one simple loop in my program allocates 2.5 times more data and works 2 times slower when loop variable switched from Int to Int32

There's no reason that Int32 should be slower than Int, unless there are specialisations for Int but not Int32. This ceratinly isn't related to the issues that affect enumerations, incedentally. If you have Int code that is a lot slower when you switch to Int32, and you aren't using any overloading function that have specialisations for Int, then it could be a performance bug. Please submit a report.

it is very likely that Joels unpickling code suffers from this problem - all data in his program are defined with fixed-width types

it is also likely that HashTable package suffers from this problem - it uses Int32 to represent hash keys

Highly unlikely, I've peered at the code generated for HashTable and it doesn't have any issues like this.

btw, i just noticed one more "feature" that is documented nowhere - (explicit) inlining of default class methods doesn't work, so that:

...

class C where f :: ... f = ... {-# INLINE f -#}

instance C T where

doesn't inline `f`, so i need to switch to:

...

class C where f :: ...

...

instance C T where f = ... {-# INLINE f -#}

This should work, and indeed I just tried it on a small example and it seems to work fine. Can you provide a repro case? Cheers, Simon

Nice comment. Aaron Denney wrote:

On 2006-01-06, Chris Kuklewicz wrote:

...

http://www.haskell.org/hawiki/ChameneosEntry

I note that

# Like the erlang entry, this uses a separate thread to match up two # chameneos in the meeting room.

Which seems to me to be against the spirit of the benchmark, which describes itself as a "symmetrical thread rendez-vous". Having this manager thread makes it assymetrical. Yes, the Erlang entry does it (and it does appear to be the totally idiomatic way to do this, as one of the common things to do is model persistent objects as processes), but that doesn't necessarily mean that it is "right" to do so.

I think the intent is to have something like the Java model where each thread calls some function to do the rendezvous and synchronize and do wakeups on shared data -- essentially move what the manager thread does into each color thread.

Note: I'm not saying that the seperate thread handling the rendezvous data structure isn't a very good and clear approach to the problem, just that it doesn't seem to be what the benchmark intended (unless built-in to the concurrency primitives provided by the language or language implementation).

One could make an MVar version which did not use a meeting thread, and I welcome someone to do that. I have no proof that the current solution is really the fastest architecture. When I started writing solutions, I made an STM based version without the separate meeting place thread . This is posted on the wiki (scroll down to the bottom two pieces) in a normal and over-annotated form. So it is possible to use idiomatic Haskell (STM) to create a solution. But some of the entries used a manager thread, so I wrote an MVar + Chan version which instantly was faster than the STM one. Since then I focused on speeding up the MVar version, till not it is the winning version. If I can use Simon Marlow's UNBOXED ideas, then I may submit an ever faster version. It is possible to submit the STM version as well and they will include it as a demonstration, but I have not bothered. Someone else could submit it if they cared to. If you think about it, you will realize that if inter-process synchronization is a bottleneck then STM will be slower. By definition STM aborts and throws away work if a commit fails. Also, MVars have wake-only-one-waiting-thread (FIFO) semantics whereas TVars and TMVars and TChans (and all STM constructs) have wake-all-waiting-thread semantics, even if only one can proceed. -- Chris

Aaron Denney wrote:

On 2006-01-06, Chris Kuklewicz wrote:

...

One could make an MVar version which did not use a meeting thread, and I welcome someone to do that. I have no proof that the current solution is really the fastest architecture.

I've done so -- on my machine it's comparable (within 1%) of the meeting thread version. It's been posted on the wiki. Comments and speed-up ideas welcome.

The old version with the meeting place thread has been disqualified (along with Erlang submissions). I have Aaron's wiki posting and tweaked it, posting it back to the wiki. The speed is the same, or perhaps faster, than the old code. I will submit this in a day or so assuming no other contribution.

--- Aaron Denney wrote:

On 2006-01-11, Chris Kuklewicz wrote:

...

Aaron Denney wrote: The old version with the meeting place thread has been disqualified (along with Erlang submissions).

Is this reasoning explained and clarified anywhere, or did they just move both to the "interesting alternatives"? The forums there seem to be useless, and the mailing list does not appear to be used anymore.

"The forums there seem to be useless" because...? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--- Aaron Denney wrote:

...

"The forums there seem to be useless" because...?

Because I can't find anything relevant (and I did look). I can't even tell where such an announcement would have been made.

Ah! Useful for finding an announcement - maybe not. otoh the forums do allow Q&A without subscription. In this case, there was no announcement - just a notification to Einar Karttunen - but if you look at the programs on the website you'll find this note: http://shootout.alioth.debian.org/gp4/benchmark.php?test=chameneos&lang=ghc&id=2#about And that was already commented on by folk on this mailing-list. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--- Aaron Denney wrote: Are we off-topic for this mailing-list? I'd just like to respond to this:

Anyways, your shootout, your hard work, your rules, but having rulings on what's acceptable be easier to find would be nice.

People here have made the effort to develop programs for the shootout - I appreciate /their/ hard work. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com