On Thu, May 10, 2007 at 05:52:55PM +0100, Andrew Coppin wrote:
Wait a sec... Are you trying to tell me that it is *faster* to take the source, type check it, convert it to Core, perform 25,000 Core-to-Core transformations, convert Core to C, call GCC, link the result together, dynamically load it, execute it, extract the result and confirm that it type checks, and display it....... then it is to just directly execute an interpreted expression? I find that highly surprising.
It's pretty fast, actually. But your interactive expression still needs to do most of that, except it compiles cmm to bytecode instead of to C (old default; handed off to gcc afterward) or directly to asm (modern ghc). In particular, you are doing both core transformations and type checking no matter what --- and they take *far* more time than the compile and link. Truly.
Interesting. On my system, the link stage typically takes far longer than compilation. (Compilation takes 4 - 5 seconds per module, linking takes another 15 seconds or so. Depending on how big the program is. Use -O2 to make the compilation stage take round about 30 seconds per module instead.)
1. Lambdabot is running on a fairly fast machine - idle 2Ghz p4. 2. runplugs uses GHCi's custom dynamic linker which can load .o files directly, so the link phase simply doesn't exist. 3. most user expressions are very short, and the compiler proper runs in approximate linear time. 4. IRC lag is on the order of 2-10 seconds, so people don't notice the 1.5s it takes to compile. Also, they can't hear Don's fans. 5. Lambdabot uses -O2, which makes it an order of magnitude faster than GHCi on longer running expressions. Stefan