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 factor is much
much
| greater than x2 or x3
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 bits
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
required to
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
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
: [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 there are certainly programs
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 comes
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 x3. If the Int can be unboxed
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
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
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 compiled
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
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
13 matches
Mail list logo
