While *I* was falling asleep last night I realized that I was thinking about naked women bringing me bottles of ice-cold Negra Modelo, with freshly-sliced lime wedges. One of us probably has a serious problem.
;-} BTW, I was one of those who rebooted my Symbolics 3600 as soon as it started a garbage collect; there was still plenty of time to get a cup of coffee. -- Doug Roberts, RTI International [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell On 11/26/06, Roger Critchlow <[EMAIL PROTECTED]> wrote:
While falling asleep last night I realized that I use the same techniques to finesse memory allocators whether I'm programming in lisp, java, or c. When memory allocation sucks, it sucks no matter what general solution your programming environment provides, and if you don't work around the problem, then your performance sucks. I worked with a bunch of lisp programmers who used Symbolics lisp machine processors. They never let the garbage collector run. They kept the memory allocation statistics up on their desktops and when the system got close to a gc, they rebooted the system because it was faster than running the gc. More generic programmers might have just taken more coffee breaks. I've worked on any number of c projects where malloc overhead was the determinant of program performance, and no rewrite of malloc could solve that. So we wrote pool allocators for the allocation chunks required and limited our use of malloc to allocation of 1000's of pooled objects at once. More generic programmers never consider that I've written java programs where I knew before I typed a single character that I was not going to define a class to represent a key data object: the object was going to be a 32 bit int with bit fields, the principle data structure would be arrays of ints, and there would never be any garbage for the system to collect. More generic programmers blithely define a class and a collection class and suffer the consequences. You argue about the relative merits of the programming systems based on their generic properties, and you get a generic conclusion about their merits. But for any programming environment, no matter how subtly constructed, there exists a class of programmers ignorant enough to screw everything up. I can write the same pool suballocators in lisp and c, and if I size the pools correctly and the resources are available both languages will run a program that uses them faster than a program that depends on the generic memory allocation facilities. Given enough time, I can find a sequence of malloc/new/free/delete calls which will kill a generic c/c++ allocator and make it run worse than a garbage collector. The argument for GC in Java was that generic programmers made fewer memory allocation errors when absolved of explicit allocation management. That's true. But they don't make better use of memory just because it's being automatically managed, they still make terrible design decisions that would probably suck with explicit allocation management if you could ever plug all the memory leaks and see them run. I don't think that the level of abstraction in a programming environment is inherently good or bad, the basic question is whether the programmers understand how computer programs really work and really fail to work. If they understand that, then they can probably figure out how the abstractions provided by their programming environment will interact with the programs they write. -- rec -- ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
