[FRIAM] [friam-owner at redfish.com: Re: deployable and open source ABMs]

[Douglas Roberts]

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
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell


On 11/26/06, Roger Critchlow <rec at elf.org> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20061126/f8150cc8/attachment.html