[computer-go] Language

[Álvaro Begué]

On Nov 14, 2007 10:25 AM, steve uurtamo <apoxonpoo at yahoo.com> 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.


I just wanted to point out that free() is not a system call. The heap is
handled by the C library, and the OS is mostly not involved in it.

Anyway, go programmers should probably not be using a whole lot of dynamic
memory allocation, and certainly not enough to make the performance of
free() matter at all.


Álvaro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20071114/6a84202e/attachment.htm