Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread John Meacham
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 ./hs.out
./hs.out  0.33s user 0.00s system 96% cpu 0.347 total

Yay! it is good to see my goal of C-equivalent performance starting to
come true :)

John




-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread Ketil Malde
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread John Meacham
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 require many extensions, jhc falls somewhat
  short. It is getting better though. Of course, help is always
  appreciated. :)
 
 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
more likely it is to depend on some library that depends on a ghc
extension. However, base is almost 1 lines and jhc can compile that
into a library without too much effort nowadays, so it might scale.
If you try and find it fails, then please submit a bug report to
j...@haskell.org. Too many bugs go unreported I find.

If the haskell code has an interface that is strict and unboxable (i.e.
only unboxable values passed, such as a video codec passing floats might
be) then compiling it with jhc and foreign exporting the functions then
foreign importing them into ghc for the bulk of the program would
probably work. Probably not worth the effort, but could be an
interesting experiment.

JOhn

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread Alberto G. Corona
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 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 require many extensions, jhc falls somewhat
   short. It is getting better though. Of course, help is always
   appreciated. :)
 
  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
 more likely it is to depend on some library that depends on a ghc
 extension. However, base is almost 1 lines and jhc can compile that
 into a library without too much effort nowadays, so it might scale.
 If you try and find it fails, then please submit a bug report to
 j...@haskell.org. Too many bugs go unreported I find.

 If the haskell code has an interface that is strict and unboxable (i.e.
 only unboxable values passed, such as a video codec passing floats might
 be) then compiling it with jhc and foreign exporting the functions then
 foreign importing them into ghc for the bulk of the program would
 probably work. Probably not worth the effort, but could be an
 interesting experiment.

JOhn

 --
 John Meacham - ⑆repetae.net⑆john⑈
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread John Meacham
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, the
  more likely it is to depend on some library that depends on a ghc
  extension.
 
 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. I don't see a reason it wouldn't
compile to be as fast as C, with the caveat that the strictness analyzer
needs to be able to find all the unboxables. It sometimes needs some
help with well placed 'seq' statements, but that is true of ghc as well.
jhc does suffer a lot more than ghc though when it can't make things strict. 

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread John Meacham
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 initial announcement. 

more up to date info is

in the manual: http://repetae.net/computer/jhc/manual.html
the becoming a developer page: http://repetae.net/computer/jhc/development.shtml
and the how do i just try it out page: 
http://repetae.net/computer/jhc/building.shtml


I guess it isn't clear that that original document is no longer up to date. I
will put a big warning on it.

John

-- 
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread Alberto G. Corona
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: http://repetae.net/computer/jhc/manual.html
 the becoming a developer page: 
 http://repetae.net/computer/jhc/development.shtml
 and the how do i just try it out page: 
 http://repetae.net/computer/jhc/building.shtml


 I guess it isn't clear that that original document is no longer up to date. I
 will put a big warning on it.

John

 --
 John Meacham - ⑆repetae.net⑆john⑈
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] speed: ghc vs gcc vs jhc

2009-02-20 Thread Don Stewart
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 a test case for jhc.
 
 Crypto library has a lot of native haskell code computing hashes and
 encrypting data
 
 hopefully people will show other examples
 
 btw, Galois Cryptol has haskell backend, are you know? with jhс
 compilation it can probably generate as fast code as C backend does.
 it will be very interesting for us and even look as something close to
 production usage. i have crossposted message to Don

That's a very interesting idea. The output from Cryptol is self
contained enough, and simple, numerical code, that JHC probably could
handle it -- it doesn't require extensive libraries or runtime support,
for example. This warrents investigation.

Thanks for the suggestion!

-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe