Chameneos

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Chameneos

haskell-2
Your "case" tweak was for an older version of Chameneos that used an
older Ch channel implementation.

But I was inspired by your improvement to use Int# instead of data
Color, and I posted a version that seems faster than the winning one
that was submitted. http://www.haskell.org/hawiki/ChameneosEntry

It still has to box the Int# to put it into the MVar channels.  But the
fastest complement is now (3# -# a -# b) and "if (other ==# faded)" is
faster than the previous "case other of Faded -> ; _ ->".  At least on
OS X / G4.

Also, thanks for cleaning up the SumFile code.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

Simon Marlow
Chris Kuklewicz wrote:

> Your "case" tweak was for an older version of Chameneos that used an
> older Ch channel implementation.
>
> But I was inspired by your improvement to use Int# instead of data
> Color, and I posted a version that seems faster than the winning one
> that was submitted. http://www.haskell.org/hawiki/ChameneosEntry
>
> It still has to box the Int# to put it into the MVar channels.  But the
> fastest complement is now (3# -# a -# b) and "if (other ==# faded)" is
> faster than the previous "case other of Faded -> ; _ ->".  At least on
> OS X / G4.
>
> Also, thanks for cleaning up the SumFile code.

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.  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.

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

Cheers,
        Simon

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

Aaron Denney
In reply to this post by haskell-2
On 2006-01-06, Chris Kuklewicz <[hidden email]> 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).

--
Aaron Denney
-><-

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Chameneos

haskell-2
Nice comment.

Aaron Denney wrote:

> On 2006-01-06, Chris Kuklewicz <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

haskell-2
In reply to this post by Simon Marlow
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

Simon Marlow
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

Chris Kuklewicz wrote:

> 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.
>

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

haskell-2
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

Josh Goldfoot
In reply to this post by haskell-2
The use of arithmetic to determine the chameneos compliments may be prohibited by the shootout rules.  Although the benchmark does not address the issue, the C# code, which was written by Isaac Gouy (one of the main shootout administrators) contains these comments before its complement code:
 
   // don't use arithmetic
   // use if-else or switch/case or pattern-match

If I recall correctly, Gouy's C# code has served as a sort of supplement for other benchmarks; rather than fully describe the benchmark, they'll say something like "implement it like this C# program."  However, I do note that the current Python entry uses arithmetic.  That might have been allowed only because Python doesn't allow enums.  (Or does it?)

----- Original Message ----
From: Chris Kuklewicz <[hidden email]>
To: Donald Bruce Stewart <[hidden email]>; Haskell Cafe <[hidden email]>
Sent: Friday, January 06, 2006 6:04:02 AM
Subject: [Haskell-cafe] Chameneos


Your "case" tweak was for an older version of Chameneos that used an
older Ch channel implementation.

But I was inspired by your improvement to use Int# instead of data
Color, and I posted a version that seems faster than the winning one
that was submitted. http://www.haskell.org/hawiki/ChameneosEntry

It still has to box the Int# to put it into the MVar channels.  But the
fastest complement is now (3# -# a -# b) and "if (other ==# faded)" is
faster than the previous "case other of Faded -> ; _ ->".  At least on
OS X / G4.

Also, thanks for cleaning up the SumFile code.
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Chameneos

Donald Bruce Stewart
In reply to this post by haskell-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Shootout summary

haskell-2
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Shootout summary

Donald Bruce Stewart
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?

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Donald Bruce Stewart
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Shootout summary

Donald Bruce Stewart
In reply to this post by haskell-2
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.

-- Don
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Donald Bruce Stewart
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Branimir Maksimovic-2

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.

Greetings, Bane.

>From: [hidden email] (Donald Bruce Stewart)
>To: Chris Kuklewicz <[hidden email]>
>CC: Haskell Cafe <[hidden email]>
>Subject: Re: [Haskell-cafe] Re: Shootout summary
>Date: Sat, 7 Jan 2006 16:10:06 +1100
>
>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
>_______________________________________________
>Haskell-Cafe mailing list
>[hidden email]
>http://www.haskell.org/mailman/listinfo/haskell-cafe

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Donald Bruce Stewart
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Chameneos

Bulat Ziganshin
In reply to this post by Simon Marlow
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,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Matthias Neubauer
In reply to this post by Donald Bruce Stewart
[hidden email] (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.

-Matthias

--
Matthias Neubauer                                       |
Universität Freiburg, Institut für Informatik           | tel +49 761 203 8060
Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: Shootout summary

Donald Bruce Stewart
neubauer:

> [hidden email] (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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Chameneos

Aaron Denney
In reply to this post by haskell-2
On 2006-01-06, Chris Kuklewicz <[hidden email]> 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.

--
Aaron Denney
-><-

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12