returning to cost of Integer

[Simon Marlow]

Lennart Augustsson wrote:
> Actually, you can keep it to one test for add/subtract if you
> use a single word that is either a number or a pointer, the
> pointer being tagged in lowest bit.  Then you can add first
> and check for tags after.  Having tags is rare, so the machine
> should be told so, if possible.  This way you can keep the
> overhead for bignums really low.  But it requires very special
> handling of bignums and I'm not sure it's worth it.

I like this idea - I remember discussing just such a scheme with John Launchbury 
recently.  It has a lot in common with the semi-tagging scheme we've wanted to 
implement for some time, where the idea is that you use the low bits of a 
pointer to store the tag of the constructor it points to, if evaluated.  If the 
contents of the constructor itself can be packed into the other 30 bits, then 
there's no need for a pointer at all.  For enumerated types, you can use all 31 
bits for the tag, since only 1 bit is required to indicate evaluated/unevaluated 
and no pointer is needed.

Cheers,
	Simon

>     -- Lennart
> 
> On Aug 1, 2006, at 03:02 , Simon Peyton-Jones wrote:
> 
>> If there was an alternative small/big rep, no matter how encoded,  
>> it'd still entail conditionals (2 for addition say) to check for  that 
>> path.  And the conditionals also hurt optimisations.
>>
>> But both possibilities would be an interesting thing to try.
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow- 
>> haskell-users-bounces at haskell.org]
>> | On Behalf Of John Meacham
>> | Sent: 01 August 2006 02:20
>> | To: glasgow-haskell-users at haskell.org
>> | Subject: Re: returning to cost of Integer
>> |
>> | > >However because Int is often unboxable where as Integer is never
>> | > >unboxable there are certainly programs where the factor is  much 
>> much
>> | > >greater than x2 or x3. If the Int can be unboxed into an Int#  
>> then the
>> | > >operations are very quick indeed as they are simple machine
>> | > >primitives.
>> |
>> | This has made me wonder whether we are better off getting rid of the
>> | small integer optimization and turning Integer into a straight
>> | unboxable ForeignPtr to a GMP number. this would also mean we  could 
>> use
>> | the standard GMP that comes with the system since ForeignPtr will  take
>> | care of GCing Integers itself. This was my plan with jhc, but at the
>> | moment, Integer is still just intmax_t.
>> |
>> | Another option would be to keep the small integer optimization  but 
>> make
>> | it CPR
>> |
>> | data Integer = Integer Int# !(Ptr MPZ)
>> |
>> | where if the Ptr is NULL then the Int# contains the value...
>> |
>> |         John
>> |
>> | --
>> | John Meacham - ⑆repetae.net⑆john⑈
>> | _______________________________________________
>> | Glasgow-haskell-users mailing list
>> | Glasgow-haskell-users at haskell.org
>> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users