Hezaurus kirjoitti:Jopa java on tänään riittävän nopea ollakseen ihan yhtä hyvä valinta matemaattiseen mallinnukseen kuin Fortran. Tärkeintähän noissa on nykyään massiivinen rinnakkaisuus ja siinä tärkeintä itse toteutustapa eikä toteutuskieli.
Onko tästä jossakin uudehdoja linkkejä? Olen ymmärtänyt että mm. kompleksilukujen natiivituen puuttuminen Javasta aiheuttaa jonkin verran harmia. Hyvin koodattu Java-koodi näyttää pärähtävän kätevästi moniydinprossujen kaikille ytimille eli siinä suhteessa rinnakkaisuus toimii.
GAIA DPAC http://en.wikipedia.org/wiki/DPAC
Very early on in the preparation of the Gaia data reduction the issue of the programming language to use to develop the system was raised. The decision process involved scientists and software engineers; it was focused on the needs of a long-term project, with stringent requirements regarding the software validation and quality and large CPU and data handling needs (1021flops, 1PB).
FORTRAN was somewhat favoured by the scientific community but was quickly discarded; the type of system to develop would have been unmaintainable, and even not feasible in some cases. For this purpose the choice of an object-oriented approach was deemed advisable. The choice was narrowed to C++ and Java.
The C++ versus Java debate lasted longer. “Orthodox”thinking stated that C++ should be used for High Performance Computing for performance reasons. “Heterodox”thinking suggested that the disadvantage of Java in performance was outweighted by faster development and higher code reliability.
However, when JIT Java VMs were released we did some benchmarks to compare C++ vs Java performances (linear algebra, FFTs, etc.) . The results showed that the Java performance had become quite reasonable, even comparable to C++ code (and likely to improve!). Additionally, Java offered 100% portability and I/O was likely to be the main limiting factor rather than raw computation performance.
Java was finally chosen as the development language for DPAC. Since then hundreds of thousands of code lines have been written for the reduction system We are happy with the decision made and haven’t (yet) faced any major drawback due to the choice of language.
A key piece of the Gaia astrometry is the calculation of the relativity effects on the apparent position of the objects in the sky: aberration, light bending, etc. This is a complex calculation taking into account the ephemeris of the major solar system bodies and requiring, for a μas accuracy, to reach the limit of the numerical precision of double variables.
An initial (legacy) implementation was available from S. Klionerin C. Used in the simulator code until 2008 through JNI calls. The same author recently developed for DPAC a new implementation using Java. Both implementations have been thoroughly compared and results agree at sub-μas level.
However, computation times differ substantially … In Mare Nostrum the Java version runs about four times faster than the C version
(and it’s not due to the JNI overhead).
Obviously, an optimisation of the C code should make it much more efficient, to at least the level of the Java code. However, this shows how the same developer did a quicker and better job in Java (a language that, unlike C, he was unfamiliar with).
The Gaia Simulator code amounts today to more than 100.000 lines of code and has produced several terabytes of simulated data in the last years that have been used for mission design and development and testing of the initial versions of some reduction algorithms. First fully functional system of DPAC, in production since 2006.
The simulator is run at the Mare Nostrum supercomputer http://en.wikipedia.org/wiki/MareNostrum
using the Grid Superscalar framework
(Latest run: 600,000 CPU hours 12TB of simulated data)
We routinely deploy it with very small overheads in several environments: e.g. developers desktop computers, small
department cluster for testing and validation and Mare Nostrum for production. Also in all OS flavours: Linux/Unix, Windows, Mac.
- We have no numerical libraries of the quality and sophistication of those available in C or Fortran (but this seems to be improving)
- Other types of libraries seem also more limited (e.g. MPI libraries)
- Support for Java development in HPC platforms is scarce. Experience and advice also. We are breaking the ice.
- Occasionally, we find some subtle but annoying differences between JVMs(but not often and never critical for the moment).
- We might not be able to take advantage of future advanced processors, like Cell.
- We do not have much control of garbage collection, and sometimes this may be a problem (but not having to worry about memory leaks is a bless).http://www.spscicomp.org/ScicomP15/slides/astro/torra.pdf