Once in a while I show some comparisons of code translated in
different languages.
A challenge from Reddit-Dailyprogrammer:
http://www.reddit.com/r/dailyprogrammer/comments/ywm28/8272012_challenge_92_difficult_bags_and_balls/
The purpose of this post of mine is to compare a nice looking
Haske
Did you time the runs?
Non-lazy D version, compiled as -O -inline -release, and ran with pick(6,
11):
real0m8.587s
user0m8.497s
sys0m0.012s
Lazy D version, compiled as -O -inline -release, and ran with pick(6, 11):
real0m4.195s
user0m4.168s
sys0m0.008s
Haskell version
Caligo:
Did you time the runs?
I didn't time them. My timings (compiling with GHC -O3) are
similar to your ones.
If you want a better comparison, this Haskell code is closer to
the D/Python versions (the run-time is similar, maybe it's a bit
faster):
pick :: Int -> Int -> [String]
pick
Am Wed, 29 Aug 2012 13:56:12 +0200
schrieb "bearophile" :
> It runs the (8, 13) case (40_489 solutions) in less than half
> second, about eleven times faster than the Haskell version.
>
> I think the Haskell run-time is re-using some thunks of precedent
> lazy computations, so I think Haskell i
Marco Leise:
Haskell isn't half
bad with the optimizing compiler. The native efficiency is
comparable to D until you really start to optimize.
Lot of people say similar things, but saying it again and again
doesn't make them true. So far I have seen no evidence of this.
The few times where
On Tuesday, 28 August 2012 at 22:53:46 UTC, bearophile wrote:
The purpose of this post of mine is to compare a nice looking
Haskell solution of this problem to its Python/D translation.
This means this post is about language design matters and it's
not about problem solving :-)
...
There is
Peter Alexander:
In general, it is not possible to have both full expressiveness
and full performance.
The ShedSkin compiler has shown me that in some important cases
this is not true. But even if in this case you are right, I am OK
with that, because I write both performance-critical D code
