Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
Aaron Denney wrote: On 2006-01-06, Chris Kuklewicz [EMAIL PROTECTED] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] wrote: On 2006-01-11, Chris Kuklewicz [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
--- Aaron Denney [EMAIL PROTECTED] 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 QA 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=chameneoslang=ghcid=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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
Hello Simon,
Friday, January 06, 2006, 7:11:41 PM, you 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.
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.
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
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
can that be fixed, at least for enums and Int32/Word32 (Int64/Word64)?
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 -#}
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
Nice comment. Aaron Denney wrote: On 2006-01-06, Chris Kuklewicz [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Chameneos
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
