RE: Help! Is there a space leak here?
[Prompted by Sergey's message about the strange dates: The mess in my headers is entirely my fault. I have not had a chance to properly finish the upgrades to this machines: internationalization and the rest. Please forgive me for this mess] On Tue, 22 Feb 2000, Mark P Jones wrote: > Jan: I don't think you're being very fair. I stand corrected. But my remarks were out of love to Hugs, not otherwise, you know! :-) > Do you really > know that the failures you demonstrated were due to a bug > in Hugs? Is it possible that they might have been caused > by bugs in the program that you were running? No I don't know it. I had barely enough time to put all those pieces together in a nice tutorial fashion, so I could not examine them properly before the demonstration I was giving. But this program came from a reputable source, akin to Hugs itself, after all! :-) I did not have any reason to suspect major problems there. > Or perhaps > you simply didn't have Hugs configured with a big enough > heap for the size of the bigger problems that you tried? I run the examples first on one of my resourceless machines here and fiddling with the heap size would not help. Later, the demo was being run on a 256Mb machine where I had a comfort to set a heap size to quite a large value. Yet, it did not help. > If it truly was a bug in Hugs, I hope that you reported > it so that the Hugs maintainers could do something to fix > it? No Mark, I did not. I got caught up in some other problems and forgot all about it. One of these days I am going to re-examine it again. This particular program is quite big and I remember one other curious thing about it: evaluation of simple expressions (2*3, say) under Hawk prompt were significantly slower than under Hugs prompt. Jan
RE: Help! Is there a space leak here?
| Both simulations run fine for small values of | counter "n" but fail badly when "n" becomes big, | 40,000 say. I happened to have a presentation | on the subject of Hawk about two months ago, and | the audience was not much impressed when they saw | Hugs failing on such simple (in their view) | examples. I knew beforehand what would happen for | large "n" and I tried to restrict my presentation | to small n's, but unfortunately the audience was | very inquisitive. You see, those people are accustomed | to running their tests for hours a time, so it | was natural for them to ask for some big values | of n. | | Not a good publicity for Hugs, unfortunately. Jan: I don't think you're being very fair. Do you really know that the failures you demonstrated were due to a bug in Hugs? Is it possible that they might have been caused by bugs in the program that you were running? Or perhaps you simply didn't have Hugs configured with a big enough heap for the size of the bigger problems that you tried? If it truly was a bug in Hugs, I hope that you reported it so that the Hugs maintainers could do something to fix it? Joe: As you've observed, the space behavior of Haskell programs is often very subtle, and hard to understand. I glanced quickly over your program but didn't see any immediate signs of problems. My first suggestion would be that you try using the rudimentary heap profiler that Hugs provides to see if this gives some insight into the source of the leak. (You'll probably need to be able to recompile Hugs with profiling enabled for this.) Failing that, it might be worth trying to put together a complete example (program and data) that demonstrates the problem. I find it rather hard to think about examples like this in the abstract. Having code that I can actually run, can make a big difference in situations like this. (I'm not actually promising that I'll have time to investigate it myself, but I might, and so might some other readers on this list.) All the best, Mark
Re: Help! Is there a space leak here?
On Sun, 6 Feb 2000, Joe English wrote: > This turns out not to be the case; testing with Hugs > invariably fails with a "Garbage collection fails to > reclaim sufficient space" on even moderately sized > documents (5000 nodes or so). If I remember correctly, one of the past postings explained that the current version of Hugs does not properly handle the tail optimizations. You will probably get a good explanation of this from someone else. The reason I am answering your post is such that I run into similar problems when executing one of the examples from Hawk distribution. It deals with the concrete and symbolic simulation of one of the intel microprocessors. It supposed to simulate an evaluation of a sequence of instructions, such as the implementation of multiplications via additions. In the concrete case it boils down to evaluation of "7 * n", in a symbolic case it is "i * n", where "n" is a running counter. Although it looks quite simplistic here, the implementation of those simulations is highly recursive. Both simulations run fine for small values of counter "n" but fail badly when "n" becomes big, 40,000 say. I happened to have a presentation on the subject of Hawk about two months ago, and the audience was not much impressed when they saw Hugs failing on such simple (in their view) examples. I knew beforehand what would happen for large "n" and I tried to restrict my presentation to small n's, but unfortunately the audience was very inquisitive. You see, those people are accustomed to running their tests for hours a time, so it was natural for them to ask for some big values of n. Not a good publicity for Hugs, unfortunately. Jan
