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

[Geoff Jacobs]

Joe Landman wrote:
> 
> 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.

Biased? Perhaps.

I think the compressed syntax as well as the broad semantics, which are
a benefit to the implementer, really hamper ongoing maintenance of
software written in Perl.

>> 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.

Even on microbenchmarks, Java bytecode tends to see a significant
performance hit compared to native languages (although not always). And,
as you point out, C++ has it's own performance considerations.

If the overwhelming majority of CPU cycles are spent in native C
subroutines, the performance hit of using Java or C++ will be greatly
mitigated. Implementing a numerical kernel in C would be fairly easy if
there is significant computation to be done outside of PETSc.

>> 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.

Absolutely.

-- 
Geoffrey D. Jacobs

Go to the Chinese Restaurant,
Order the Special