Performance difference between ghc and ghci
Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar. Regards, Kashyap
In general code compiled with GHC will be a lot faster than code
interpreted by GHCI. You can also call compiled code from within GHCI,
in which case you would hardly see a performance difference.
On 22 February 2011 08:26, C K Kashyap
Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar. Regards, Kashyap
Roel van Dijk schrieb:
In general code compiled with GHC will be a lot faster than code interpreted by GHCI. You can also call compiled code from within GHCI, in which case you would hardly see a performance difference.
$ ghci -fobject-code compiles modules before loading into the interpreter environment. However expressions entered into GHCi will not be compiled with optimization.
On 2/22/11 2:26 AM, C K Kashyap wrote:
Hi, Is there a runtime performance difference between a haskell program running under GHCI vs in its compiled form? Especially for a long running program - as in, ignoring the initial setup time. If I understand right, in both case tree reduction is what is happening and performance should be similar.
GHCi doesn't perform any optimizations, so whenever you're running interpreted bytecode there's a significant performance hit. However, if you compile the code, you can run the compiled/optimized version from GHCi as well. -- Live well, ~wren
GHCi doesn't perform any optimizations, so whenever you're running interpreted bytecode there's a significant performance hit. However, if you compile the code, you can run the compiled/optimized version from GHCi as well.
--
I missed out the optimization bit .... yes, that would make a difference. However beyond that is it not just about graph reduction which should be the same?
Hi, C K Kashyap wrote:
I missed out the optimization bit .... yes, that would make a difference. However beyond that is it not just about graph reduction which should be the same?
Even if the number of reduction steps is the same, the bytecode interpreter is still slower than compiled code, because it takes more processor cycles per reduction step. This interpretative overhead could be avoided, for example, using just-in-time compilation à la Smalltalk or Java. Tillmann
participants (5)
-
C K Kashyap -
Henning Thielemann -
Roel van Dijk -
Tillmann Rendel -
wren ng thornton