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 [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell On 11/25/06, Marcus G. Daniels <[EMAIL PROTECTED]> 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
============================================================ 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
