On 4/06/2013, at 4:22 PM, Rustom Mody wrote:
>
>
> On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe
> wrote:
>
> On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> > If the Int type had either of these semantics by default, many many
> > performance sensitive libraries would suddenly hav
On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe wrote:
>
> On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> > If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance. Every single o
On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:
> If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance. Every single operation that was branchless before
> would have a branch *ev
GHC is not the spec, I am talking about GHC Haskell, not Haskell the
standard that I don't use.
On 32bit machines, GHC Int is 32bits. On 64bit GHC on 64bit machines Int is
64 bits.
If you have another well engineered suitable for wide use Haskell compiler
in mind, I'd love to try it out, but with
On Jun 3, 2013, at 00:23 , Carter Schonwald wrote:
> Int is "native register sized integer"
Actually it's not. Read the definition. Int is only guaranteed to be 29 bits.
Here's *one* _actual_ data point (from a 2.8 GHz i7, 64-bit code):
time ./fib
fib(43) = 701408733
3.27 real
Tommy, respectfully,
I have quite a few bits of code where a bad branch predictor in a tight
inner loops makes code 10x slower.
you are welcome to do your own experimentation so that you too can learn by
branches are bad in tight loops. (even if the branch predictor is doing
its job, there will
On Jun 2, 2013, at 23:58 , Carter Schonwald wrote:
> Indeed, as Dan says, theres the safeint library and the Integer type.
>
> If the Int type had either of these semantics by default, many many
> performance sensitive libraries would suddenly have substantially less
> compelling performance.
Indeed, as Dan says, theres the safeint library and the Integer type.
If the Int type had either of these semantics by default, many many
performance sensitive libraries would suddenly have substantially less
compelling performance. Every single operation that was branchless before
would have a b
There is a package that implements an Int that throws an exception on
overflow:
http://hackage.haskell.org/package/safeint
Since Int's existence is pretty much all about trading for performance, I
wouldn't recommend holding your breath on the above becoming the default.
If you want things to
There was a quite long discussion here:
http://conal.net/blog/posts/notions-of-purity-in-haskell
On 2 June 2013 22:02, Tommy Thorn wrote:
...
> I wish this fatal flaw would be reconsidered for the next major revision.
>
___
Haskell-Cafe mailing list
H
On Jun 2, 2013, at 14:13 , Kata wrote:
> In addition to Haskell already having an arbitrary-width integer type called
> Integer
But I wasn't asking for arbitrary-width. I was asking for explicit failures
(overflow) rather
than C-like silent corruption.
> , consider the case where you have som
On Sunday, June 2, 2013 at 5:02 PM, Tommy Thorn wrote:
> On Jun 2, 2013, at 12:52 , Henry Laxen (mailto:nadine.and.he...@pobox.com)> wrote:
>
> > Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I
> > changed everything from Int to Integer, and now both agree. Thanks for the
On Sun, Jun 2, 2013 at 11:02 PM, Tommy Thorn wrote:
> On Jun 2, 2013, at 12:52 , Henry Laxen wrote:
>
> > Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I
> > changed everything from Int to Integer, and now both agree. Thanks for
> the
> > pointer.
>
> Isn't that just t
On Jun 2, 2013, at 12:52 , Henry Laxen wrote:
> Yes, that was it. The dell was a 32 bit system, and the desktop a 64. I
> changed everything from Int to Integer, and now both agree. Thanks for the
> pointer.
Isn't that just terrible? I hate the fact that Haskell was defined to neither
trap
14 matches
Mail list logo
