[Beowulf] Java vs C++ for interfacing to parallel library

[Joe Landman]

Geoff Jacobs wrote:

> *throws on his scalliwag hat*
> And also many inappropriate languages, such as Intercal, APL, BrainF***,
> or even Perl when you're on a caffeine buzz.
> *removes hat*

Hey ... I like that +/vector is a sum reduction over a variable named
vector, and it can do it on the outermost index.

Don't knock APL, it was designed for calculation.  That it was also as
arcane in its syntax as possible, as well as being insanely terse in its
implementation.  Still, any language that allows you to model a physical
system in 4 lines of code and gives you meaningful answers cannot be all
bad.

I ... just ... dont ... want ... to  ... use ... it  ...... again.  Ever.

As for Perl, I have written several HPC apps in it.  You use Perl as the
wrapper/glue for the parts written in C/others.  Use it to interface to
the OS, and do all the things you shouldn't be doing in C/others anyway.
 Works really well.  About 6 years ago we were demonstrating something
like 80x on 84 CPUs, and around 200x on 256 CPUs with it.  Don't knock
the language, it is incredibly powerful.  I just would not use it for
time sensitive calculations, just as I would not use Java, Python, or
Ruby for such things.  But for stitching together applications?  Its
hard to beat.  Python is pretty good at this too, and NumPy and other
tools make this simple.  I see lots of Perl bashing from people who
raise what they perceive to to be its negatives, though their points
could be made about any language for the most part, and their
specificity to Perl is incorrect at best.  Just shows the commenter's
biases.

> I don't see what the question is. We don't know the requirements for the
> software to be written, so it's sorta hard to evaluate against them. If

We know something of the task.  As it is in implementat decision phase,
it would be good to understand the code issues, design, goals, ...

> the library is handling most of the computation, I can't see how using a
> VM language will really be of concern.

Performance, or specifically, lack of it.  Microbenchmarks of the
language not-withstanding, OO languages tend to have an abstraction
penalty (C++) compared to non-OO.  The abstraction makes programming
easier, and it makes getting performance harder.  Then there are the
preferred implementation decisions such as object factories and
inheritance which pretty much prevent you from insuring that you have
well aligned data structures, which SSE requires for good performance,
or simple function pointer to function mapping.  If you call a function
many times, and you have to walk a pointer tree over your set of objects
that you are iterating over for each calculation, this makes these
function calls expensive.  You have to start using tricks to effectively
unwind the inheritance trees, see if you have overloaded the functions,
before you can finally dispatch them.  Optimizing these pointer trees,
which usually only exist at run time, is a nightmare if you have to deal
with multiple inheritance and overloading.

> If you have access to a trained Java programmer who's a whiz with JNI,
> go for it. If the people you can lay your hands on use C++, use that.

I would suggest waiting until you have a good strong idea of what
algorithms the code is going to use, how it will be implemented.  If you
can use libraries that do all the heavy lifting and do it well, you can
likely stitch your application together using stuff that already works
well.  Then you might be able to use the OO language to build the app
from there.

-- 
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web  : http://www.scalableinformatics.com
phone: +1 734 786 8423
fax  : +1 734 786 8452 or +1 866 888 3112
cell : +1 734 612 4615