deployable and open source ABMs

[Marcus G. Daniels-3]

Hi,

For those of you that are interested in deployable agent models with
good performance, here's an intriguing development:  A just-in-time
native code compiler for JavaScript bytecode.  

http://www.mozilla.org/projects/tamarin
http://www.adobe.com/devnet/actionscript

Look ma, no hands!   (no Flash plugin, no Java plugin)

[Douglas Roberts-2]

I guess we need a definition of "good performance" here.  Languages with
garbage collectors are not known for exceptional performance.  From the
Tamarin project home page:

"The Tamarin project is just getting started so the roadmap is not yet fully
developed, but some of the technical goals include:

   1. Integrating the Tamarin VM and garbage collector within
   SpiderMonkey
   2. ... "

--Doug

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

On 11/25/06, Marcus G. Daniels <mgd at santafe.edu> wrote:

>
> Hi,
>
> For those of you that are interested in deployable agent models with
> good performance, here's an intriguing development:  A just-in-time
> native code compiler for JavaScript bytecode.
>
> http://www.mozilla.org/projects/tamarin
> http://www.adobe.com/devnet/actionscript
>
> Look ma, no hands!   (no Flash plugin, no Java plugin)
>
>
> ============================================================
> 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/728b82a5/attachment.html

[Marcus G. Daniels-3]

Hi Doug,
> I guess we need a definition of "good performance" here.  Languages
> with garbage collectors are not known for exceptional performance.
Well, I am in the camp that use C variants are best for serious
simulation as it factors out the uncertainties of garbage collection and
bytecodes interpreters/JITs.  But, given that Java is so popular, and
that a common (but shallow) motive for its use is to make it easy to
show customers simulations, then the possibility of a truly dynamic
language that is embedded in a browser seems like an interesting step
forward for demos or small scale simulations.

cheers,

Marcus

[Douglas Roberts-2]

Hi, Marcus.

I'm presently involved in discussions of the technical issues of building
ABMs in Java for HPC computing environments in another arena. However, I
suspect that when are talking about deploying Tamarin projects, we are not
talking about deploying them on Teragrid resources or (just) on HPC Linux
clusters.

HPC brings several of Java's performance characteristics into the spotlight
when considering it as the implementation language for distributed memory
ABM simulations.  Here are a few of those issues:


   1. There are no supported sophisticated message passing toolkits, such
   as mpi,  that would allow the Java developer to take full advantage of a
   message passing HPC platform.  Mpi provides the HPC developer with a large
   collection of message passing functions: broadcast, scatter/gather,
   blocking/non-blocking sends, message data serialization, etc..  None of
   these tools are available to the pure Java developer.
   2. Similarly, there are few, if any Java support packages that would
   allow the Java developer to utilize high speed interconnect frameworks, such
   as Myrinet and Infiniband on distributed HPC platforms.  Message passing
   operations in a Java-based application, therefore, will be many times slower
   than those implemented in a language environment better suited to HPC.
   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.
   4. Java cannot be optimized to any specific HPC platform as
   efficiently as is possible with the above-mentioned languages, because the
   HPC language compilers usually are optimized for the specific platform that
   they are installed on.   This introduces yet another performance penalty for
   the Java application.

Add them all up, and the performance penalty for pure Java HPC applications
is huge.

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


On 11/25/06, Marcus G. Daniels <mgd at santafe.edu> wrote:

>
> Hi Doug,
> > I guess we need a definition of "good performance" here.  Languages
> > with garbage collectors are not known for exceptional performance.
> Well, I am in the camp that use C variants are best for serious
> simulation as it factors out the uncertainties of garbage collection and
> bytecodes interpreters/JITs.  But, given that Java is so popular, and
> that a common (but shallow) motive for its use is to make it easy to
> show customers simulations, then the possibility of a truly dynamic
> language that is embedded in a browser seems like an interesting step
> forward for demos or small scale simulations.
>
> cheers,
>
> Marcus
>
> ============================================================
> 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/f515dcb2/attachment.html

[Martin C. Martin-2]

Marcus G. Daniels wrote:
> Well, I am in the camp that use C variants are best for serious
> simulation as it factors out the uncertainties of garbage collection and
> bytecodes interpreters/JITs.

It is said that C programmers know that memory management is too
important to be left to the computer, and the LISP programmers (and
presumably Java programmers) know that memory management is too
important to be left to the programmer.

>  But, given that Java is so popular, and
> that a common (but shallow) motive for its use is to make it easy to
> show customers simulations, then the possibility of a truly dynamic
> language that is embedded in a browser seems like an interesting step
> forward for demos or small scale simulations.
>
> cheers,
>
> Marcus

[Douglas Roberts-2]

As a former Lisp programmer who now works exclusively in C++, I always feel
horribly conflicted.

;-}


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

On 11/25/06, Martin C. Martin <martin at martincmartin.com> wrote:

>
>
>
> Marcus G. Daniels wrote:
> > Well, I am in the camp that use C variants are best for serious
> > simulation as it factors out the uncertainties of garbage collection and
> > bytecodes interpreters/JITs.
>
> It is said that C programmers know that memory management is too
> important to be left to the computer, and the LISP programmers (and
> presumably Java programmers) know that memory management is too
> important to be left to the programmer.
>
> >  But, given that Java is so popular, and
> > that a common (but shallow) motive for its use is to make it easy to
> > show customers simulations, then the possibility of a truly dynamic
> > language that is embedded in a browser seems like an interesting step
> > forward for demos or small scale simulations.
> >
> > cheers,
> >
> > Marcus
>
>
> ============================================================
> 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/82938089/attachment.html

[Marcus G. Daniels-3]

Doug wrote:

 > HPC brings several of Java's performance characteristics into the
spotlight when considering it as the implementation language for
distributed memory ABM simulations.

I agree with your reasons.   Another basic disconnect between the HPC
and Java communities boils down to "What do you know with confidence is
happening on any given CPU?"  I'll dare say that, overwhelmingly, the
answer to that question for most Java users is pretty much nothing at
all.   And [gasp] they *want it that way*.

It's possible to learn about a particular virtual machine so that when
looking at a low-level or hardware (e.g. VTune) profile it all makes
sense.  It's possible to study runtime dumps to get a feel for garbage
collection costs and take steps to reduce them.   It's even possible to
glue MPI onto a Java program via JNI using GCC's Java native code
compiler and have `normal' Unix executable.   My claim is that in most
parts of science-related Java Culture, this is all taboo and basically
never done.

[Marcus G. Daniels-3]

Guess y'all saw this:

http://www.nytimes.com/cnet/CNET_2100-1010_3-6137770.html?_r=1&oref=slogin

So much for Fortress, I guess.  Fortress is Sun's
we-can-do-HPC-because-Java-ain't-it language.

I rather like the looks of IBM's effort, X10, in spite of the fact it
superficially resembles Java.
I suppose it will eventually target the Cell processor but also I like
it because it reminds me of Swarm (e.g. `clocks').

http://domino.research.ibm.com/comm/research_projects.nsf/pages/x10.index.html

Also, Cray's got some cool compiler technology, so I fully expect Chapel
(http://chapel.cs.washington.edu) will be realized too.  

(Geez, they better, with each of these companies getting $250 million.)

[Marcus G. Daniels-3]

Here is one weakness of native code ahead-of-time compilers relative to
just-in-time compilers embedded in runtimes.  I think it is relevant to
HPC applications.

Consider a program made up of some source code which references a third
party library providing a wide variety of features.  The third party and
the program author are at different organizations and are not sharing
source code.

Few non-local dynamics of a program can be deduced by an ahead-of-time
compiler, just because it is hard to do that.  Without tolerating huge
code bloat and stressing caches, the compiler can't just inline
everything.  Worse, it can't even see everything because the libraries
are separately compiled and then linked.  (Most compiled object code
just advertises a vector of opaque entry points to the linker, which
itself is dumb.)

Now imagine that certain callers in the program result in a predictable
complement of internal routines in the library always being called, and
that there is an public interface intermediate between the two (e.g. a
message dispatch).   The compiler would need to see all of that context
to ensure that the native code would be generated such that branch
prediction on the CPU would never get confused, but it cannot due to the
organization of the typical HPC toolchain.

A CLR or JVM runtime, however, can watch the dynamics of the program and
make experiments on code generation strategies as the code runs.  The
ones that pay off can be cached & reused.   Here, cross-module inlining
is the desired optimization.

Given the other disadvantages of Java for HPC, I'm not arguing that this
makes up for them, but it's possibly worth thinking about how to learn
from Java approaches in HPC applications.

One way to try that is using a package like Dynamo.  What Dynamo does is
treat the non-branching sequences of real instructions as chunks to
thread together into native code.  These cached native code chunks can
be selected-for as in a JVM.

http://www.cag.lcs.mit.edu/dynamorio

(Dynamo worked for me in Fedora 5 x86, no luck in Windows, maybe due to
data execution prevention.)