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 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
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