Hi
(i know about Haskell standard, but how many programs relies on 32-bit
Ints?)
The standard demands the range [-2^29 .. 2^29 - 1]
You don't have a problem, some were reserved for you already.
Thanks
Neil
___
Glasgow-haskell-users mailing list
Gl
On Thu, Aug 03, 2006 at 02:12:15AM +0400, Bulat Ziganshin wrote:
> the main condition is to use some special Int30# type instead of Int#
> (which we got used to be 32 bits long). i.e. for the type [Char},
> where Char= C# Int30# it will be ok, but for [Int] it will be bad
> (i know about Haskell st
Hello John,
Thursday, August 3, 2006, 1:25:45 AM, you wrote:
>> 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
>> require
On Wed, Aug 02, 2006 at 01:06:48PM +0100, Simon Marlow wrote:
> 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 bi
Hello Simon,
Wednesday, August 2, 2006, 4:06:48 PM, you 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 i
L PROTECTED]
| On Behalf Of John Meacham
| Sent: 01 August 2006 02:20
| To: glasgow-haskell-users@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 facto
On Tue, Aug 01, 2006 at 02:57:31PM +0400, Bulat Ziganshin wrote:
> John, Integer values in many cases used just to keep small numbers
> which can be larger than 2^32 (2^64) in rare cases. For example,
> "type FileSize = Integer" used in IO library. so it's important to
> keep operations on small In
Sent: 01 August 2006 02:20
| To: glasgow-haskell-users@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 x
Hello John,
Tuesday, August 1, 2006, 5:19:37 AM, you wrote:
> 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 com
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of John Meacham
| Sent: 01 August 2006 02:20
| To: glasgow-haskell-users@haskell.org
| Subject: Re: returning to cost of Integer
|
| > >However because Int is often unboxable where as Integer is never
| > >unboxable th
> >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
A more clever representation of Integer could unbox numbers in big
range.
But that would require some runtime support, I think.
-- Lennart
On Jul 31, 2006, at 11:19 , Duncan Coutts wrote:
On Mon, 2006-07-31 at 14:32 +0400, Serge D. Mechveliani wrote:
Dear GHC developers,
Long ago y
On Mon, 2006-07-31 at 14:32 +0400, Serge D. Mechveliani wrote:
> Dear GHC developers,
>
> Long ago you wrote that GHC has made Integer only about 3/2 times
> slower than Int.
> I tested this once, and then all this time I have been relying on this.
> Now, with
> ghc-6.4.1 compi
Dear GHC developers,
Long ago you wrote that GHC has made Integer only about 3/2 times
slower than Int.
I tested this once, and then all this time I have been relying on this.
Now, with
ghc-6.4.1 compiled for Linux - i386-unknown,
running under Debian Linux
14 matches
Mail list logo
