RE: Bools are not unboxed

2004-10-06 Thread Simon Marlow
On 06 October 2004 11:36, Josef Svenningsson wrote: > Simon Marlow wrote: > >> On 06 October 2004 00:53, John Meacham wrote: >> >> >> >>> This seems like it could be nicely generalized such that all >>> enumeration types unbox to the unboxed integer of their offset. so >>> >>> data Perhaps =

Re: Bools are not unboxed

2004-10-06 Thread Josef Svenningsson
Simon Marlow wrote: On 06 October 2004 00:53, John Meacham wrote: This seems like it could be nicely generalized such that all enumeration types unbox to the unboxed integer of their offset. so data Perhaps = Yes | Maybe | No can unbox to an Int# with 0# == Yes 1# == Maybe and 2# == No. Yes

RE: Bools are not unboxed

2004-10-06 Thread Simon Marlow
On 06 October 2004 00:53, John Meacham wrote: > On Tue, Oct 05, 2004 at 01:48:30PM +0100, Simon Marlow wrote: >> It would probably be better to return 0#/1# instead of a Bool from >> the comparison primops, because this would expose slightly more >> detail to the simplifier and might result in sli

Re: Bools are not unboxed

2004-10-05 Thread John Meacham
On Tue, Oct 05, 2004 at 01:48:30PM +0100, Simon Marlow wrote: > It would probably be better to return 0#/1# instead of a Bool from the > comparison primops, because this would expose slightly more detail to > the simplifier and might result in slightly better code in some cases > (but no dramatic i

RE: Bools are not unboxed

2004-10-05 Thread Simon Marlow
On 03 October 2004 14:07, Tomasz Zielonka wrote: > Then I noticed the cause: > GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other > primitive comparison operators. > > Would it be difficult to add Bool unboxing to GHC? > Maybe it would suffice to use preallocated False and

RE: Bools are not unboxed

2004-10-04 Thread Simon Peyton-Jones
| > for :: Int -> IO () -> IO () | > for 0 _ = return () | > for n x = x >> for (n - 1) x Good example (allocates lots of silly thunks). I'd come across this before, and fixed the HEAD, but the 6.2 branch is still doing badly. We'll try to fix that. | Playing with the code generate

Re: Bools are not unboxed

2004-10-03 Thread Tomasz Zielonka
On Sun, Oct 03, 2004 at 04:03:55PM +0200, Carsten Schultz wrote: > Hi Tomasz! Hi Carsten! > > To my surprise, it was much slower and made many allocations: > [... > > Then I noticed the cause: > > GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other > > primitive comparison

Re: Bools are not unboxed

2004-10-03 Thread Carsten Schultz
Hi Tomasz! On Sun, Oct 03, 2004 at 03:07:01PM +0200, Tomasz Zielonka wrote: > Hello! > > I was playing with monadic looping a'la replicateM_ and I created this > function: > > for :: Int -> IO () -> IO () > for 0 _ = return () > for n x = x >> for (n - 1) x > > Compiled with -O2, it

Re: Bools are not unboxed

2004-10-03 Thread Tomasz Zielonka
On Sun, Oct 03, 2004 at 03:07:01PM +0200, Tomasz Zielonka wrote: > Then I noticed the cause: > GHC.Prim.<# returns a boxed, heap allocated Bool, and so do other > primitive comparison operators. > > Would it be difficult to add Bool unboxing to GHC? > Maybe it would suffice to use preallo

Bools are not unboxed

2004-10-03 Thread Tomasz Zielonka
Hello! I was playing with monadic looping a'la replicateM_ and I created this function: for :: Int -> IO () -> IO () for 0 _ = return () for n x = x >> for (n - 1) x Compiled with -O2, it is really fast and makes no unnecessary allocations. Tested with this main main = for 1