Hello Miguel,
Friday, February 20, 2009, 4:48:15 PM, you wrote:
Ahem. Seems like you've included time spent on the runtime loading.
for C, i've used additional 100x loop
sys 0m0.002s
sys 0m0.017s
While 3.201 vs. 0.066 seem to be a huge difference, 0.017 vs. 0.002 is
not that bad.
Hello Dan,
Friday, February 20, 2009, 5:39:25 PM, you wrote:
Not that I'd be sad if GHC could reduce that whole constant at compile time,
but GCC isn't doing 1 billion adds in 6 (or even 60) milliseconds.
yes, that's what was done actually:
22 0020 8D44D01C leal
Hello David,
Friday, February 20, 2009, 6:52:03 PM, you wrote:
In Haskell you're printing it... why not print it in C++?
in order to omit #include stdio line
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Hey guys, what about the LLVM bindings? They seem nice for tight loops this one.
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Don,
Friday, February 20, 2009, 7:41:33 PM, you wrote:
main = print $ sum[1..10^9::Int]
This won't be comparable to your loop below, as 'sum' is a left fold
(which doesn't fuse under build/foldr).
You should use the list implementation from the stream-fusion package (or
uvector) if
Hello John,
Saturday, February 21, 2009, 1:33:12 AM, you wrote:
Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote:
Hello John,
Saturday, February 21, 2009, 1:33:12 AM, you wrote:
Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
Why not? There's nothing stopping you from choosing
On Fri, Feb 20, 2009 at 11:52:27PM +0100, Thomas Davie wrote:
On 20 Feb 2009, at 23:44, Bulat Ziganshin wrote:
Hello John,
Saturday, February 21, 2009, 1:33:12 AM, you wrote:
Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production
Hello Khudyakov,
Saturday, February 21, 2009, 2:07:39 AM, you wrote:
I have another question. Why shouldn't compiler realize that `sum [1..10^9]'
is constant and thus evaluate it at compile time?
since we expect that compilation will be done in reasonable amount of
time. you cannot guarantee
On Sat, Feb 21, 2009 at 12:22 AM, Bulat Ziganshin bulat.zigans...@gmail.com
wrote:
Hello Khudyakov,
Saturday, February 21, 2009, 2:07:39 AM, you wrote:
I have another question. Why shouldn't compiler realize that `sum
[1..10^9]'
is constant and thus evaluate it at compile time?
since
Hello John,
Saturday, February 21, 2009, 2:49:25 AM, you wrote:
what is substantial size? can jhc be used for video codec, i.e.
probably no extensions - just raw computations, and thousands or tens
of thousands LOCs?
Perhaps. A bigger issue in practice is that the larger a program is, the
Hello Xiao-Yong,
Saturday, February 21, 2009, 3:16:28 AM, you wrote:
some C++ compilers can already do this (profile based optimization).
Rumor says firefox needs profile based optimization to run
faster. Or it is not a rumor at all.
why it's rumor? PGO is natural optimization technique,
Hello John,
Saturday, February 21, 2009, 3:42:24 AM, you wrote:
this is true for *application* code, but for codec you may have lots of
code that just compute, compute, compute
Yes indeed. If there is code like this out there for haskell, I would
love to add it as a test case for jhc.
13 matches
Mail list logo
