Oh I've again sent mail to wrong address
-- Forwarded Message --
On Saturday 21 February 2009 02:42:11 you wrote:
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:
Hello Khudyakov,
Sunday, February 22, 2009, 12:58:59 AM, you wrote:
you could even pass it in a test data set to which it must be optimized;
after the program is compiled, the compiler runs and profiles it, measures
the results, and does another pass to make it faster.
it supported in gcc4
Ahem. Seems like you've included time spent on the runtime loading.
My results:
MigMit:~ MigMit$ gcc -o test -O3 -funroll-loops test.c time ./test
-1243309312
real0m0.066s
user0m0.063s
sys 0m0.002s
MigMit:~ MigMit$ rm test; ghc -O2 --make test.hs time ./test
Linking test ...
Forget it, my bad.
On 20 Feb 2009, at 16:48, Miguel Mitrofanov wrote:
Ahem. Seems like you've included time spent on the runtime loading.
My results:
MigMit:~ MigMit$ gcc -o test -O3 -funroll-loops test.c time ./test
-1243309312
real0m0.066s
user0m0.063s
sys 0m0.002s
MigMit:~
Test.hs
import Prelude hiding (sum, enumFromTo)
import Data.List.Stream (sum, unfoldr)
enumFromTo m n = unfoldr f m
where f k | k = n= Just (k,k+1)
| otherwise = Nothing
main = print . sum $ enumFromTo 1 (10^9 :: Int)
snip
do...@zeke % time ./Test
Sorry for replying to myself, but I got suspicious about the 6ms runtime of
the 64-bit C++ code on my machine. So I looked at the assembly and found this:
.LCFI1:
movabsq
On Fri, Feb 20, 2009 at 6:39 AM, Dan Doel dan.d...@gmail.com wrote:
Sorry for replying to myself, but I got suspicious about the 6ms runtime of
the 64-bit C++ code on my machine. So I looked at the assembly and found
this:
.LCFI1:
movabsq $45, %rsi
On Friday 20 February 2009 10:52:03 am David Leimbach wrote:
The GCC optimizer must know that you can't return a value to user space of
that large as a return result.
In Haskell you're printing it... why not print it in C++?
I actually changed my local copy to print out the result (since I
bulat.ziganshin:
Hello haskell-cafe,
since there are no objective tests comparing ghc to gcc, i made my own
one. these are 3 programs, calculating sum in c++ and haskell:
Wonderful. Thank you!
main = print $ sum[1..10^9::Int]
This won't be comparable to your loop below, as 'sum' is a
bulat.ziganshin:
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
Am Freitag, 20. Februar 2009 18:10 schrieb Bulat Ziganshin:
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
Don't forget jhc:
on my machine (with 'print' equivalent added to C one to be fair, and
10^9 changed to 1000*1000*1000 just like the C one)
ghc: (-O2)
time ./foo
./foo 2.26s user 0.00s system 99% cpu 2.273 total
gcc:
time ./a.out
./a.out 0.34s user 0.00s system 99% cpu 0.341 total
jhc:
time
Bulat Ziganshin bulat.zigans...@gmail.com writes:
Don't forget jhc:
i was pretty sure that jhc will be as fast as gcc :) unfortunately,
jhc isn't our production compiler
Neither is GCC :-)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
On Friday 20 February 2009 16:29:29 Bulat Ziganshin wrote:
Hello haskell-cafe,
since there are no objective tests comparing ghc to gcc, i made my own
one. these are 3 programs, calculating sum in c++ and haskell:
main = print $ sum[1..10^9::Int]
... skipped ...
The discussion is mostly
On Sat, Feb 21, 2009 at 02:24:59AM +0300, Bulat Ziganshin wrote:
Hello John,
Saturday, February 21, 2009, 2:14:25 AM, you wrote:
Heh. He probably meant something more like jhc is not a production
compiler which is true for a lot of projects. For projects of
substantial size or that
Peter Verswyvelen bugf...@gmail.com writes:
you could even pass it in a test data set to which it must be optimized;
after the program is compiled,
the compiler runs and profiles it, measures the results, and does another
pass to make it faster.
some C++ compilers can already do this
John,
please update the section All is not well in jhc-land because now
things are better isn´t?
2009/2/21 John Meacham j...@repetae.net
On Sat, Feb 21, 2009 at 02:24:59AM +0300, Bulat Ziganshin wrote:
Hello John,
Saturday, February 21, 2009, 2:14:25 AM, you wrote:
Heh. He probably
On Sat, Feb 21, 2009 at 03:21:03AM +0300, Bulat Ziganshin 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,
On Sat, Feb 21, 2009 at 01:20:14AM +0100, Alberto G. Corona wrote:
John,
please update the section All is not well in jhc-land because now
things are better isn´t?
Ah, are you refering to this page?
http://repetae.net/computer/jhc/jhc.shtml
That is just there for historical reasons as my
But it is very misleading. It would be nice to have a log or
something similar to inform about the current state
://repetae.net/computer/jhc/jhc.shtml
That is just there for historical reasons as my initial announcement.
more up to date info is
in the manual:
bulat.ziganshin:
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
21 matches
Mail list logo
