Donald Bruce Stewart wrote:
Yeah, there's some known low level issues in the code generator
regarding heap and stack checks inside loops, and the use of registers
on x86.
But note this updated paper,
http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html
Add another core to your machine and
Donald:
Yeah, there's some known low level issues in the code generator
regarding heap and stack checks inside loops, and the use of registers
on x86.
But note this updated paper,
http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html
Add another core to your machine and it is no longer 4x
bf3:
Donald:
Yeah, there's some known low level issues in the code generator
regarding heap and stack checks inside loops, and the use of registers
on x86.
But note this updated paper,
http://www.cse.unsw.edu.au/~chak/papers/CLPKM07.html
Add another core to your machine and it is no
Donald Bruce Stewart wrote:
bf3:
Maybe this is yet another newbie stupid question, but do you mean that
GHC does automatic multi-threading? (Haskell seems very suitable for
that) Otherwise adding an extra core does not really help does it?
No, though that would be nice! You do have to
andrewcoppin:
Donald Bruce Stewart wrote:
bf3:
Maybe this is yet another newbie stupid question, but do you mean that
GHC does automatic multi-threading? (Haskell seems very suitable for
that) Otherwise adding an extra core does not really help does it?
No, though that would be nice!
Add another core to your machine and it is no longer 4x slower :)
Add 15 more cores and its really no longer 4x slower :
Maybe this is yet another newbie stupid question, but do you mean that
GHC does automatic multi-threading? (Haskell seems very suitable for
No, though that would be nice!
Am Freitag, 13. Juli 2007 15:03 schrieb peterv:
You see, in C++ I can write:
[snip]
So basically a wrapper around a fixed-size array of any length.
Implementations of (+), (-), dot, length, normalize, etc... then work on
vectors of any size, without the overhead of storing the size, and
Hello Donald,
Saturday, July 14, 2007, 6:01:21 AM, you wrote:
don't forget that laziness by itself makes programs an orders of
magnitude slower :)
Or orders of magnitude faster, depending on your data structure. :)
compared to naive implementation - yes, it's possible. compared to
handmade
]
Sent: Friday, July 13, 2007 6:43 PM
To: peterv
Cc: 'Lukas Mai'; haskell-cafe@haskell.org
Subject: Re[2]: [Haskell-cafe] Newbie question about tuples
Hello peterv,
Friday, July 13, 2007, 5:03:00 PM, you wrote:
think the latest compilers are much better). Now when implementing
something
like
Lukas Mai wrote:
You may be interested in
http://okmij.org/ftp/Haskell/number-parameterized-types.html
Thanks for that! It's all fascinating stuff...
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Thanks Bulat, but now you scattered my hopes that GHC would magically do all
these optimizations for me ;-)
I must say that although the performance of Haskell is not really a concern to
me, I was a bit disappointed that even with all the tricks of the state monad,
unboxing, and
bf3:
Thanks Bulat, but now you scattered my hopes that GHC would magically do all
these optimizations for me ;-)
I must say that although the performance of Haskell is not really a concern
to me, I was a bit disappointed that even with all the tricks of the state
monad, unboxing, and
Am Donnerstag, 12. Juli 2007 20:14 schrieb Andrew Coppin:
The only thing the libraries provide, as far as I can tell, is the fact
that tuples are all Functors. (In other words, you can apply some
function to all the elements to get a new tuple.) I think that's about
it. I doubt you can use
://ubiety.uwaterloo.ca/~tveldhui/papers/Expression-Templates/exprtmpl.ht
ml... Well at least I hope so :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lukas Mai
Sent: Friday, July 13, 2007 09:20
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Newbie question
On Friday 13 July 2007, peterv wrote:
I'm beginning to see that my old implementation in C++ clutters my Haskell
design.
You see, in C++ I can write:
// A vector is an array of fixed-length N and elements of type T
templatetypename T, int N struct Vector
{
T Element[N];
friend T
* possible?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jonathan Cast
Sent: Friday, July 13, 2007 16:21
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Newbie question about tuples
On Friday 13 July 2007, peterv wrote:
I'm beginning to see
peterv wrote:
with guaranteed termination, of course
Just out of curiosity (not Haskell related): I always get confused when
people speak about guaranteed termination; what about the halting problem?
In which context can one check for guaranteed termination, as the halting
problem says it's
Hello peterv,
Friday, July 13, 2007, 5:03:00 PM, you wrote:
think the latest compilers are much better). Now when implementing something
like this in Haskell, I would guess that its laziness would allow to
interleave many of the math operations, reordering them to be as optimal
as possible,
PROTECTED]
Sent: Friday, July 13, 2007 6:43 PM
To: peterv
Cc: 'Lukas Mai'; haskell-cafe@haskell.org
Subject: Re[2]: [Haskell-cafe] Newbie question about tuples
Hello peterv,
Friday, July 13, 2007, 5:03:00 PM, you wrote:
think the latest compilers are much better). Now when implementing
Lukas Mai wrote:
Am Donnerstag, 12. Juli 2007 20:14 schrieb Andrew Coppin:
The only thing the libraries provide, as far as I can tell, is the fact
that tuples are all Functors. (In other words, you can apply some
function to all the elements to get a new tuple.) I think that's about
it. I
peterv wrote:
with guaranteed termination, of course
Just out of curiosity (not Haskell related): I always get confused when
people speak about guaranteed termination; what about the halting problem?
In which context can one check for guaranteed termination, as the halting
problem says
Andrew Coppin wrote:
Lukas Mai wrote:
Am Donnerstag, 12. Juli 2007 20:14 schrieb Andrew Coppin:
The only thing the libraries provide, as far as I can tell, is the fact
that tuples are all Functors. (In other words, you can apply some
function to all the elements to get a new tuple.) I think
bulat.ziganshin:
Hello peterv,
Friday, July 13, 2007, 5:03:00 PM, you wrote:
think the latest compilers are much better). Now when implementing something
like this in Haskell, I would guess that its laziness would allow to
interleave many of the math operations, reordering them to be
Hi,
I have a couple of questions about tuples.
Q1) Is it possible to treat a tuple of N elements in a generic way? So
instead of writing functions like lift1 e1, lift2 (e1,e2), lift3 (e1,e2,e3)
just one function liftN that works on tuples of any length?
Q2) (Maybe related to Q1) Can I convert
Hi Peter,
2007/7/12, peterv [EMAIL PROTECTED]:
Q1) Is it possible to treat a tuple of N elements in a generic way? So
instead of writing functions like lift1 e1, lift2 (e1,e2), lift3 (e1,e2,e3)
just one function liftN that works on tuples of any length?
Q2) (Maybe related to Q1) Can I convert
peterv wrote:
Hi,
I have a couple of questions about tuples.
Q1) Is it possible to treat a tuple of N elements in a generic way? So
instead of writing functions like lift1 e1, lift2 (e1,e2), lift3 (e1,e2,e3)
just one function liftN that works on tuples of any length?
The only thing the
On Thu, 12 Jul 2007, Andrew Coppin wrote:
peterv wrote:
Q3) Suppose I want to declare an instance of Num on all tuple types having
(Num instances) as elements; is this possible?
I tried
instance Num a = Num (a,a) where .
but this fails
I also tried
peterv wrote:
Hi,
I have a couple of questions about tuples.
Q1) Is it possible to treat a tuple of N elements in a generic way? So
instead of writing functions like lift1 e1, lift2 (e1,e2), lift3
(e1,e2,e3) just one function liftN that works on tuples of any length?
If you have instances
28 matches
Mail list logo
