Jon Harrop wrote:
On Wednesday 04 June 2008 11:05:52 Luke Palmer wrote:
Given unbounded time and space, you will still arrive at the same result
regardless of the complexity.
Given that the set of computers with unbounded time and space is empty, is
it
not fruitless to discuss its
On Tue, 3 Jun 2008, Don Stewart wrote:
I wrote up the second part of the tour of understanding low level
performance in GHC here,
http://reddit.com/r/programming/info/6lx36/comments/
Follows on from the discussion last week about various performance
related things.
Now the difficult
On Wed, 2008-06-04 at 09:32 +0200, Henning Thielemann wrote:
On Tue, 3 Jun 2008, Don Stewart wrote:
I wrote up the second part of the tour of understanding low level
performance in GHC here,
http://reddit.com/r/programming/info/6lx36/comments/
Follows on from the discussion
[Forgot to post to the list, sorry]
2008/6/4 Duncan Coutts [EMAIL PROTECTED]:
On Wed, 2008-06-04 at 09:32 +0200, Henning Thielemann wrote:
On Tue, 3 Jun 2008, Don Stewart wrote:
I wrote up the second part of the tour of understanding low level
performance in GHC here,
Henning Thielemann [EMAIL PROTECTED] writes:
Now the difficult question: How to write the 'mean' function in terms of
'sum' and 'length' while getting the same performance?
Write a RULE pragma converting
\xs - (foldl' f y0 xs,foldl' g z0 xs)
into
\xs - foldl' (\(y,z) x - (f y x,g z x))
On Wed, 4 Jun 2008, Duncan Coutts wrote:
On Wed, 2008-06-04 at 09:32 +0200, Henning Thielemann wrote:
Now the difficult question: How to write the 'mean' function in terms of
'sum' and 'length' while getting the same performance?
There's another rather harder fusion transformation that
On Wed, Jun 4, 2008 at 9:48 AM, Loup Vaillant [EMAIL PROTECTED] wrote:
I see a problem with this particular fusion, though: It changes the
space complexity of the program, from linear to constant. Therefore,
with some programs, relying on this optimization can be a matter of
correctness, not
I wonder what can be said about stable optimizations which are
insensitive to their environments in some sense.
http://citeseer.ist.psu.edu/veldhuizen02guaranteed.html
Ganesh
==
Please access the attached hyperlink for
On Wednesday 04 June 2008 11:05:52 Luke Palmer wrote:
To me, time and space complexity is not about correctness but
performance.
IRL the specification often dictates the complexity. If your code fails to
satisfy the spec then it is wrong. Are you saying that Haskell code can never
satisfy any
On Wed, 4 Jun 2008, Luke Palmer wrote:
On Wed, Jun 4, 2008 at 9:48 AM, Loup Vaillant [EMAIL PROTECTED] wrote:
I see a problem with this particular fusion, though: It changes the
space complexity of the program, from linear to constant. Therefore,
with some programs, relying on this
Jon Harrop wrote:
IRL the specification often dictates the complexity. If your code fails to
satisfy the spec then it is wrong. Are you saying that Haskell code can never
satisfy any such specification?
In addition to RL, it it should and it can in theory too:
On Jun 4, 2008, at 5:51 AM, Henning Thielemann wrote:
How about assisting the compiler with a helper function named
'parallel' ?
parallel :: ([a] - b, [a] - c) - [a] - (b,c)
parallel (f,g) xs = (f xs, g xs)
mean xs =
uncurry (/) $ parallel (sum,length) xs
? We could state RULES in terms
I wrote up the second part of the tour of understanding low level
performance in GHC here,
http://reddit.com/r/programming/info/6lx36/comments/
Follows on from the discussion last week about various performance
related things.
Enjoy.
-- Don
___
I think it's hard to overstate how awesome the RULES pragma is.
Thanks for the example.
-- ryan
On 6/3/08, Don Stewart [EMAIL PROTECTED] wrote:
I wrote up the second part of the tour of understanding low level
performance in GHC here,
On Wednesday 14 November 2007 00:14, Don Stewart wrote:
Trying out some of the great language shootout programs with ghc 6.8 is
producing nice results. For example, our classic cache-hammering,
bitwise sieve benchmark is out of the box 10% faster with the new
compiler. The (already rather
Trying out some of the great language shootout programs with ghc 6.8 is
producing nice results. For example, our classic cache-hammering,
bitwise sieve benchmark is out of the box 10% faster with the new
compiler. The (already rather good) benchmark is here (the
same speed as the OCaml version
16 matches
Mail list logo