On Wed, 2007-11-14 at 07:25 -0800, steve uurtamo wrote: > > And it's not fast either. Free() has a reputation of being > > slow, and that's not surprising if you look at the way it is > > almost always implemented: scanning a list of addresses in > > order to amalgamate the newly freed memory with adjacent free > > areas. > > this is a burden for the OS, not a defect in the language. as far > as the executing code is concerned, it's just releasing responsibility > for the block attached to the pointer. the OS can merrily insertion > sort it for all i care, but that's being handled elsewhere and isn't a > function of the language. heck, the kernel could tell me that it's done > within 2 microseconds and then give me an error on my next malloc > because it isn't really done putting it back into place. but that's fine > with me, because of the way that i use memory. i don't mind having > to make friends with the OS. it follows pretty clearly-defined rules.
No, sorry, this has nothing to do with the OS, but only with the implementation within the stdlib library. The kernel gets involved only when malloc() has exhausted its free list and is requesting another big block of memory via the brk() system call, which happens infrequently. So it *is* a function of (the implementation of) the language. > having garbage collection happen at random times would really, really > make it difficult for me to profile. the reality is that the way > i use memory, i know when i need it and when i need to get rid of > it, and very frequently, once i've gotten all that i need, i don't need to > ask for more for a really long time and can point to the exact place > where i'm going to ditch it. That's my point: Not all uses of memory follow the pattern you are describing. > > My personal experience is: if you can tolerate the 5-10% loss > > in execution speed, a real garbage collector is invaluable. > > it sounds like you're working on more sophisticated code than i > am, from the way that you describe using garbage collection. i'm > just a speed junkie who needs to use all of my ram to do scientific > computing and i don't mind counting all of my own beans. The type of software I had in mind was an interactive system, running for days (or even months) without restarting, together with the possibility of creating function closures. I find it hard to imagine how you can do that without a garbage collector. I realized such a system in plain C, but I wrote my own garbage collector for it - I just saw no other way to determine when objects created by the user's processes could be freed. Hellwig _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
