Compiled program running (extremely) slower than interpreted equivalent (no results produced)
Hello, I have a (fairly complicated) Haskell program. The main aspect I believe is relevant about it is that it produces an infinite output (something like an infinite list evaluated lazily, except I use my own data structures with better properties). What I want is to see how fast the elements in the "list" are produced and check that they are correct, without reaching any particular point. Producing even just a couple elements of this list takes A LOT of computations. I normally run everything interpreted, and this works fine. However, it is a tad too slow and I wanted to profile it, for which I need to compile it. Here is my typical way to run it interpreted: * stack ghci +RTS -M500m -RTS * :load CESQResolverEval.hs * main This produces 4-5 outputs within a few seconds. When I try to compile it: * stack ghc --rts-options "-M500m" CESQResolverEval.hs * stack exec ./CESQResolverEval This dies. Moreover, if I run without the RTS options and/or let it run for a while, it completely kills my computer and I have to restart it. I initially thought it may be a thing with output flushing but: * I added a stdout flush after each individual element of the "list", and it changes nothing. * I even tried changing what main does so that it stops after the first result. This works when interpreted (takes less than a second), but still the program produces nothing and kills my CPU when compiled. Maybe relevant is that loading my program into GHCi takes about 30 seconds. The only thing I've been able to find online is this: https://www.reddit.com/r/haskell/comments/3hu3sd/how_is_it_possible_that_com... But that seems to be about complicated flags and their implications. As you can see, my flags are fairly simple. Anyone has any idea what this could be about, or how to avoid it? My purpose is to profile the program to see where most of the time is being spent, but I cannot do that without compiling it, and if the compiled code is running much slower than the interpreted code, then it seems absurd to even try to profile this (it must not be doing the same that the interpreted code is doing?). Thanks in advance, Juan. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.
On Fri, Jul 16, 2021 at 01:10:36AM +0000, CASANOVA Juan wrote:
Here is my typical way to run it interpreted:
* stack ghci +RTS -M500m -RTS * :load CESQResolverEval.hs * main
This produces 4-5 outputs within a few seconds.
When I try to compile it:
* stack ghc --rts-options "-M500m" CESQResolverEval.hs * stack exec ./CESQResolverEval
This dies. Moreover, if I run without the RTS options and/or let it run for a while, it completely kills my computer and I have to restart it.
Sounds like you have a space leak. I don't know why the space leak would be exhibited in 'stack ghci' but not 'stack ghc'. The first thing I would try would be to compile with '-O0', '-O1' and '-O2' and see if any of those make a difference (I don't know what 'stack ghc' uses by default.). Tom
I can't be sure without looking at your program directly, but deleting all build artifacts (*.hi, *.o, the executable file, and *.hi-boot files if there's) before compiling might resolve the issue. What "stack ghc" does is starting GHC with appropriate configuration (mostly which packages are to be used.) It does not recompile modules when compilation flags were changed, just only when the source file it depends on is changed after last compilation. This means GHC might have compiled module A with -O0, B with -O2, C with profiling on, etc. This mix is known to make optimizations fail often. 2021年7月16日(金) 18:06 Tom Ellis <tom-lists-haskell-cafe-2017@jaguarpaw.co.uk>:
On Fri, Jul 16, 2021 at 01:10:36AM +0000, CASANOVA Juan wrote:
Here is my typical way to run it interpreted:
* stack ghci +RTS -M500m -RTS * :load CESQResolverEval.hs * main
This produces 4-5 outputs within a few seconds.
When I try to compile it:
* stack ghc --rts-options "-M500m" CESQResolverEval.hs * stack exec ./CESQResolverEval
This dies. Moreover, if I run without the RTS options and/or let it run for a while, it completely kills my computer and I have to restart it.
Sounds like you have a space leak. I don't know why the space leak would be exhibited in 'stack ghci' but not 'stack ghc'. The first thing I would try would be to compile with '-O0', '-O1' and '-O2' and see if any of those make a difference (I don't know what 'stack ghc' uses by default.).
Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- /* Koji Miyazato <viercc@gmail.com> */
Well, thanks for the tips. Just for the sake of acknowledgment... it turns out it was something even more stupid. The program I was running was not the one I had just compiled, but rather an old version. The way I was compiling it it was producing no executable, only the .hi and .o files, so the executable was an old version from a previous compile, that did not produce any results. Once I re-compiled it properly, it worked fine, and is slightly faster than the interpreted version. Your comments were still useful and will be taken into account in the following days, though. So thank you again. Juan. ________________________________ From: 宮里洸司 <viercc@gmail.com> Sent: 16 July 2021 11:30 To: Haskell Cafe <haskell-cafe@haskell.org>; CASANOVA Juan <Juan.Casanova@ed.ac.uk> Subject: Re: [Haskell-cafe] Compiled program running (extremely) slower than interpreted equivalent (no results produced) This email was sent to you by someone outside the University. You should only click on links or attachments if you are certain that the email is genuine and the content is safe. I can't be sure without looking at your program directly, but deleting all build artifacts (*.hi, *.o, the executable file, and *.hi-boot files if there's) before compiling might resolve the issue. What "stack ghc" does is starting GHC with appropriate configuration (mostly which packages are to be used.) It does not recompile modules when compilation flags were changed, just only when the source file it depends on is changed after last compilation. This means GHC might have compiled module A with -O0, B with -O2, C with profiling on, etc. This mix is known to make optimizations fail often. 2021年7月16日(金) 18:06 Tom Ellis <tom-lists-haskell-cafe-2017@jaguarpaw.co.uk>:
On Fri, Jul 16, 2021 at 01:10:36AM +0000, CASANOVA Juan wrote:
Here is my typical way to run it interpreted:
* stack ghci +RTS -M500m -RTS * :load CESQResolverEval.hs * main
This produces 4-5 outputs within a few seconds.
When I try to compile it:
* stack ghc --rts-options "-M500m" CESQResolverEval.hs * stack exec ./CESQResolverEval
This dies. Moreover, if I run without the RTS options and/or let it run for a while, it completely kills my computer and I have to restart it.
Sounds like you have a space leak. I don't know why the space leak would be exhibited in 'stack ghci' but not 'stack ghc'. The first thing I would try would be to compile with '-O0', '-O1' and '-O2' and see if any of those make a difference (I don't know what 'stack ghc' uses by default.).
Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- /* Koji Miyazato <viercc@gmail.com> */ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhun Eideann, claraichte an Alba, aireamh claraidh SC005336.
participants (3)
-
CASANOVA Juan -
Tom Ellis -
宮里洸司