Re: [Haskell-beginners] Lazy vs Strict ponderings...
2) Don't worry about memory leaks until they actually appear. If they do, use a profiling tool to find out what's going on. Most likely, one of the two things above happened in an interesting way.
At the risk of sounding stupid in Haskell mode, how would I be aware of this other than obvious messages or seg-faults about memory getting low ?
It is likely that, if you develop a medium to large sized application for a customer, memory leaks will appear at the customers site. It will often be very difficult to reproduce the situation and find the leak.
That scares me enough to not want to use Haskell for serious application development. With 26 years in the trade I have had too many times when a fault cannot be reproduced and despite an 'obvious fault in the source' being fixed and the problem never coming back, without being able to reproduce and thus confirm that you have eliminated the problem, you can't ever relax on a Saturday night! LOL I hate the word 'random' when clients describe problems too!
If you want to produce quality software, it is best to be sure what you are doing during the whole development process. There should be a set of guidelines, on how to prevent space leaks.
I guess "being sure..." comes with experience of the language, like any other. I can 'think' in quite a few languages with complete confidence, knowing that things will just work. I guess Haskell is a bigger elephant sandwich! There is something beautiful about its syntax and the fact that everything is (or can be) so precise and concise, sometimes a little too concise for me to read. It *makes* me want to be in that club just so I can have that level of understaning about my job. I learned BASIC and UCSD-PASCAL at age 11 and I have never stopped being fascinated about *what* computing is all about. Sometimes I think that a CPU *is* a perfectly enlightened consciousness always in the *now*. Time for my medication and music therapy.....
See also "On the reliability of programs", http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
Will do, thanks. Sean
sean@objitsu.com wrote:
2) Don't worry about memory leaks until they actually appear. If they do, use a profiling tool to find out what's going on. Most likely, one of the two things above happened in an interesting way.
At the risk of sounding stupid in Haskell mode, how would I be aware of this other than obvious messages or seg-faults about memory getting low ?
The usual sign is that GHC is requesting more RAM from the OS than it should. For instance, if you expect your program to run in constant space, but GHCs memory usage keeps growing by 100 MB every twenty seconds, then you have a space leak. You can also run a profile preemptively and look at the graph. http://book.realworldhaskell.org/read/profiling-and-optimization.html
It is likely that, if you develop a medium to large sized application for a customer, memory leaks will appear at the customers site. It will often be very difficult to reproduce the situation and find the leak.
That scares me enough to not want to use Haskell for serious application development. With 26 years in the trade I have had too many times when a fault cannot be reproduced and despite an 'obvious fault in the source' being fixed and the problem never coming back, without being able to reproduce and thus confirm that you have eliminated the problem, you can't ever relax on a Saturday night! LOL
I hate the word 'random' when clients describe problems too!
That were the fears that I wanted to address with "don't worry". :D You see, the thing is this: any kind of error can happen at the customer's site, be it memory leaks, dangling pointers, division by zero or all the nasty bugs you put in your code. The programming language you choose influences both the kind of errors and the frequency of errors. Choosing Haskell over an imperative language like C, Pascal or Java drastically reduces logic bugs, and hence the total frequency of errors, even though you might be slightly worse off on the memory leak side, because laziness introduces a complication there. But that is a small price to pay for the general reduction in errors.
See also "On the reliability of programs", http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
Dijkstra would be very happy about how close mathematics and Haskell are. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com
On Sunday 20 March 2011 10:37:23, Heinrich Apfelmus wrote:
sean@objitsu.com wrote:
2) Don't worry about memory leaks until they actually appear. If they do, use a profiling tool to find out what's going on. Most likely, one of the two things above happened in an interesting way.
At the risk of sounding stupid in Haskell mode, how would I be aware of this other than obvious messages or seg-faults about memory getting low ?
The usual sign is that GHC is requesting more RAM from the OS than it should. For instance, if you expect your program to run in constant space, but GHCs memory usage keeps growing by 100 MB every twenty seconds, then you have a space leak. You can also run a profile preemptively and look at the graph.
http://book.realworldhaskell.org/read/profiling-and-optimization.html
Before profiling, I'd first a) watch in top [whatever the corresponding utility is called on Windows] b) run with +RTS -s (requires to link with the -rtsopts flag in GHC >= 7) to see whether there's a problem. Important in the +RTS -s output are (for this) - GC time - maximum residency - total memory in use The total allocation figure is rather irrelevant, don't worry if that's high but the above are small. If the memory usage is much higher than you'd expect, you likely have a memory leak (but be aware that datatypes like lists and trees have fairly large overhead). If GC time is large but memory usage is small enough, you have a problem which is technically not a memory leak, but requires similar diagnosis and remedies. If the above indicates a problem, unless it's obvious where the problem must be (and it rarely is), profile to locate it. However, the interaction of profiling and optimisations is quite complicated (some optimisations are impossible when compiling for profiling if they would eliminate a cost-centre) and compiling for profiling can occasionally change the time/space behaviour of a programme. So it might be that the profiling run doesn't show a problem present in the production build (indicates that some optimisation is in fact a pessimisation in your case) or shows a problem not present in the production build (some optimisation eliminating the leak is prevented by profiling bookkeeping). Both effects are rare, though. Nevertheless I like to confirm the existence of a problem before profiling.
It is likely that, if you develop a medium to large sized application for a customer, memory leaks will appear at the customers site. It will often be very difficult to reproduce the situation and find the leak.
That scares me enough to not want to use Haskell for serious application development. With 26 years in the trade I have had too many times when a fault cannot be reproduced and despite an 'obvious fault in the source' being fixed and the problem never coming back, without being able to reproduce and thus confirm that you have eliminated the problem, you can't ever relax on a Saturday night! LOL
I hate the word 'random' when clients describe problems too!
The good thing is that most common space leaks are pretty reliable, so you shouldn't hear that word too often ;)
That were the fears that I wanted to address with "don't worry". :D
You see, the thing is this: any kind of error can happen at the customer's site, be it memory leaks, dangling pointers, division by zero or all the nasty bugs you put in your code. The programming language you choose influences both the kind of errors and the frequency of errors. Choosing Haskell over an imperative language like C, Pascal or Java drastically reduces logic bugs, and hence the total frequency of errors, even though you might be slightly worse off on the memory leak side, because laziness introduces a complication there.
A small caveat. Before you've gathered the experience to avoid the common traps, you can be more than 'slightly worse off on the memory leak side', so it's probably a good idea to hone your skills on smaller projects first.
But that is a small price to pay for the general reduction in errors.
See also "On the reliability of programs", http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html
Dijkstra would be very happy about how close mathematics and Haskell are.
Regards, Heinrich Apfelmus
On Sunday 20 March 2011 09:09:04, sean@objitsu.com wrote:
If you want to produce quality software, it is best to be sure what you are doing during the whole development process. There should be a set of guidelines, on how to prevent space leaks.
I guess "being sure..." comes with experience of the language, like any other.
Yes, possibly even more so (since your experience with C doesn't help much with coming to grips with a [mostly] pure lazy [non-strict, strictly speaking] functional language)
I can 'think' in quite a few languages with complete confidence, knowing that things will just work. I guess Haskell is a bigger elephant sandwich!
Not so much bigger, more a different kind of animal.
On Sunday 20 March 2011 17:12:45, Sean Charles wrote:
[snip]
Not so much bigger, more a different kind of animal.
And I am a vegetarian! LOL
But you were the first to mention elephant sandwiches.
Can we pretend Haskell is a really big aubergine or something ? I think that might help ...
:)
I'd rather think of it as a cauliflower (has more structure than an aubergine).
But you were the first to mention elephant sandwiches. That's true. I cannot deny this.
Can we pretend Haskell is a really big aubergine or something ? I think that might help ...
:) I'd rather think of it as a cauliflower (has more structure than an aubergine). Romanesco then. Feels right for Haskell
:)
participants (4)
-
Daniel Fischer -
Heinrich Apfelmus -
Sean Charles -
sean＠objitsu.com