[Beowulf] Java vs C++ for interfacing to parallel library
gdjacobs at gmail.com
Sun Aug 20 11:15:01 PDT 2006
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
> 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
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.
Geoffrey D. Jacobs
Go to the Chinese Restaurant,
Order the Special
More information about the Beowulf