[[e-mail]: Re: deployable and open source ABMs]

[Russell Standish]

 ----- Forwarded message from friam-owner at redfish.com -----

X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on
        hells-dell.boundaryrider.com.au
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME
        autolearn=no version=3.1.3
X-Original-To: rks at localhost
Delivered-To: rks at localhost.bigpond.net.au
Envelope-to: lists at hpcoders.com.au
Delivery-date: Sun, 26 Nov 2006 09:51:06 +1100
Subject: Re: [FRIAM] deployable and open source ABMs
From: [hidden email]
To: lists at hpcoders.com.au
Date: Sat, 25 Nov 2006 17:51:41 -0500
Precedence: bulk
X-BeenThere: friam at redfish.com
X-Mailman-Version: 2.1.9.cp1
List-Id: The Friday Morning Applied Complexity Coffee Group
        <friam_redfish.com.redfish.com>
X-List-Administrivia: yes
Errors-To: friam-bounces at redfish.com
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - madrid.hostgo.com
X-AntiAbuse: Original Domain - hpcoders.com.au
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - redfish.com
X-Source:
X-Source-Args:
X-Source-Dir:

Your email addresss was not recognized as a subscriber to the FRIAM
list. It's possible you are subscribed under a different address. If
you would like to send emails to the list from this email address,
please send an email to friam-admin at redfish.com with a list of emails
that you would like to be permitted. Sorry for the hassle but we're
trying to prevent spam emails from getting on the list. Thanks.


Date: Sun, 26 Nov 2006 09:50:49 +1100
From: Russell Standish <[hidden email]>
To: The Friday Morning Applied Complexity Coffee Group <friam at redfish.com>
Subject: Re: [FRIAM] deployable and open source ABMs
Mail-Followup-To: The Friday Morning Applied Complexity Coffee Group
        <friam at redfish.com>
In-Reply-To: <f16528920611251153h5668effas7c32a37699fabbbf at mail.gmail.com>
User-Agent: Mutt/1.4.2.1i

On Sat, Nov 25, 2006 at 12:53:18PM -0700, Douglas Roberts wrote:
>   3. Java's performance, because of it's garbage collection design, will
>   always be inferior to that of C, Fortran, or C++, which, as you point out,
>   are the languages of choice for HPC implementations.

I heard this one said before, but don't really understand it. Sure
unpredictability of garbage collection is problematic for interactive
applications, but for batch processing runs this is not a factor.

Isn't GC no more or less expensive than C++'s delete operator? Or is
the issue that in C++ one can supply one's own allocators for objects,
optimising it for certain cases (eg all objects being the same size
for instance).

Cheers

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------




----- End forwarded message -----

--

----------------------------------------------------------------------------
A/Prof Russell Standish                  Phone [phone] (mobile)
Mathematics                        
UNSW SYDNEY 2052                 hpcoder at hpcoders.com.au
Australia                                http://www.hpcoders.com.au
----------------------------------------------------------------------------

[Douglas Roberts-2]

No, not true.  It is because the C++ developer is responsible for freeing
memory that has been allocated (new, free operators) that C++ does not need
a garbage collector.

In java , memory deallocation is automatic -- it is done by the garbage
collector.  Keeping track of memory that is no longer referenced by the
running program and therefore needs to be freed is an expensive operation
that C++ is not burdened with. See

http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html

for more on this topic.

--Doug

--
Doug Roberts, RTI International
droberts at rti.org
doug at parrot-farm.net
505-455-7333 - Office
505-670-8195 - Cell

> Date: Sun, 26 Nov 2006 09:50:49 +1100
> From: Russell Standish <lists at hpcoders.com.au>
> To: The Friday Morning Applied Complexity Coffee Group <friam at redfish.com>
> Subject: Re: [FRIAM] deployable and open source ABMs
> Mail-Followup-To: The Friday Morning Applied Complexity Coffee Group
>         <friam at redfish.com>
> In-Reply-To: <f16528920611251153h5668effas7c32a37699fabbbf at mail.gmail.com>
> User-Agent: Mutt/1.4.2.1i
>
> On Sat, Nov 25, 2006 at 12:53:18PM -0700, Douglas Roberts wrote:
> >   3. Java's performance, because of it's garbage collection design, will
> >   always be inferior to that of C, Fortran, or C++, which, as you point
> out,
> >   are the languages of choice for HPC implementations.
>
> I heard this one said before, but don't really understand it. Sure
> unpredictability of garbage collection is problematic for interactive
> applications, but for batch processing runs this is not a factor.
>
> Isn't GC no more or less expensive than C++'s delete operator? Or is
> the issue that in C++ one can supply one's own allocators for objects,
> optimising it for certain cases (eg all objects being the same size
> for instance).
>
> Cheers
>
>
> ----------------------------------------------------------------------------
> A/Prof Russell Standish                  Phone [phone] (mobile)
> Mathematics
> UNSW SYDNEY 2052                         hpcoder at hpcoders.com.au
> Australia                                http://www.hpcoders.com.au
>
> ----------------------------------------------------------------------------
>
>
>
>
> ----- End forwarded message -----
>
> --
>
>
> ----------------------------------------------------------------------------
> A/Prof Russell Standish                  Phone [phone] (mobile)
> Mathematics
> UNSW SYDNEY 2052                         hpcoder at hpcoders.com.au
> Australia                                http://www.hpcoders.com.au
>
> ----------------------------------------------------------------------------
>
>
> ============================================================
> 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/20061125/4979c8b5/attachment.html

[Marcus G. Daniels-3]

Russell Standish wrote:
> I heard this one said before, but don't really understand it. Sure
> unpredictability of garbage collection is problematic for interactive
> applications, but for batch processing runs this is not a factor.
>  
I'd again say it is an issue of transparency.   Can the programmer, who
may be trying very hard to keep CPU pipelines full and memory latencies
low, anticipate when the garbage collector will want to do work, and
what that will do to the stability of cache lines?  In a multithreaded
garbage collector, the changes it makes won't necessarily be on allocations.

[Martin C. Martin-2]

Douglas Roberts wrote:

> No, not true.  It is because the C++ developer is responsible for
> freeing memory that has been allocated (new, free operators) that C++
> does not need a garbage collector.
>
> In java , memory deallocation is automatic -- it is done by the garbage
> collector.  Keeping track of memory that is no longer referenced by the
> running program and therefore needs to be freed is an expensive
> operation that C++ is not burdened with.  See
>
> http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html

 >
 > for more on this topic.

In 1996 Java certainly had many performance problems, and many of those
have been addressed over the last 10 years.  O'Reilly's "Java
Performance Tuning" describes the changes from 1.2 to 1.3 as "dramatic."
  An article describing the new 1.3 garbage collector is:

www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html

If you're curious how long it's taking in a given app, you can run it
with -verbosegc or -Xloggc:<filename>.  There are various free, open
source tools to visualize the results, such as GCViewer:

http://tagtraum.com/gcviewer.html

The wikipedia has a good article on garbage collection.  In the section
on performance, it talks about why automatic GC can be slower than
explicit memory management, but also why it can be faster:

"Despite these issues, for many practical purposes,
allocation/deallocation-intensive algorithms implemented in modern
garbage collected languages can actually be faster than their
equivalents using explicit memory management (at least without heroic
optimizations by an expert programmer). A major reason for this is that
the garbage collector allows the runtime system to amortize allocation
and deallocation operations in a potentially advantageous fashion."

It goes on to give an example.

It's also quite possible to explicitly manage memory in a GC language
like Java or LISP.  You can allocate an array of objects of your
favourite type, the have a factory method that returns references to
array elements, and a "delete" method so your manager knows when it can
be reused.  At the company I work for, ITA Software, our airfare search
engine is written mostly in LISP, with core parts in C++.  We use
techniques like that to manage the few classes that are
allocated/deallocated frequently, and use the garbage collector for the
rest.  Garbage collection is only a few percent of our runtime.

- Martin

[Roger Critchlow-2]

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 --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/friam_redfish.com/attachments/20061126/78bf04a4/attachment.html

[Douglas Roberts-2]

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

[Marcus G. Daniels-3]

Douglas Roberts wrote:
> 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.
>
Seems like if we had a really spiffy general JIT virtual machine
software we could run these fine operating systems on modern hardware.  

P.S. I can't help root for the PL/1 GCC project.   Would love to tell
the sysadmins at work that I'm running Multics on my PC.

http://pl1gcc.sourceforge.net/

[Douglas Roberts-2]

Changes in v0.0.13:

   - ...

Changed syntax in v0.0.13:

   - added %GOTO label  <-------------------

Whee!

--
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, Marcus G. Daniels <mgd at santafe.edu> wrote:

>
> Douglas Roberts wrote:
> > 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.
> >
> Seems like if we had a really spiffy general JIT virtual machine
> software we could run these fine operating systems on modern hardware.
>
> P.S. I can't help root for the PL/1 GCC project.   Would love to tell
> the sysadmins at work that I'm running Multics on my PC.
>
> http://pl1gcc.sourceforge.net/
>
>
> ============================================================
> 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/a3caed4f/attachment.html