> 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.
i guess if i had some multithreaded request handler dealing with...
no, i can't even imagine what i might desperately want garbage
collection for.
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.
i like knowing exactly how much memory i'm using, because i
often need to use nearly all of it, for very long periods of time.
how do i know how much i'm using? because everything has a very
clearly defined size, and when i need more, i know that i can get it
without placing an undue burden on the system (via going into swap).
for me the strict typing of C means that i always know the maximal-size
problem i can handle using whatever algorithm i've implemented. if i get
desperate, i can pack bits. but i don't have to try to worry (or calculate)
what
the hell happens when i do a new(), or when some object is implicitly created
or cast. sure, i could use an object-oriented language in the same way, but
then i wouldn't really be using the language as its intended to be used
(flexibly
overloading operators, implicitly creating and casting objects from here to
creation, then taking a breather from time to time to let the memory management
catch up).
> 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.
(in the real world i used perl, because development time is
about 1/3 that of C. just don't try to calculate anything with it.)
s.
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how.
http://overview.mail.yahoo.com/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
