In jüngster Zeit wurde viel über die neue Sprache Julia diskutiert, die sich als Werkzeug für Technisches Computing anbietet. Ihre Schöpfer rechtfertigen die Sprache so:
"Wir wollten eine Sprache auf Open-Source-Grundlage mit einer liberalen Lizenz. Wir wollten die Geschwindigkeit von C mit der Dynamik von Ruby. Wir wollten eine Sprache, die homoiconic sein sollte (also Code und Daten in derselben Weise repräsentiert), mit echten Makros wie in Lisp, aber mit einer eingängigen, vertrauten mathematischen Schreibweise wie in MATLAB. Wir wollten etwas, das für allgemeine Programmieraufgaben so nützlich sein sollte wie Python, so leicht mit Statistik umgehen kann wie R, für das Zeichenkettenverarbeitung so selbstverständlich ist wie für Perl, das in linearer Algebra so stark sein sollte wie MATLAB und das sich so gut zum Zusammenfügen von Programmen eignen sollte wie die Shell. Etwas, das man kinderleicht lernen kann und das doch die ernsthaftesten Hacker glücklich macht. Wir wollten das interaktiv und kompilierend. Wir wollten einfache skalare Schleifen schreiben können, die sich direkt in Maschinencode übersetzen und die CPU-Register nutzen. Gleichzeitig wollten wir
»A * B
«
schreiben können und damit Tausende Berechnungen anstoßen, die das Matrixprodukt bilden."
[2]
Die Julia-Webseite [1] hat noch mehr Informationen über die Zielsetzung, aber schon der zitierte Absatz klingt, als gehe für HPC-Nutzer ein Traum in Erfüllung. Insbesondere, weil einige der Ziele seit Jahren auf der Wunschliste standen und unerreichbar scheinen, bis man einen Blick auf die Benchmarks in Tabelle 1 wirft. Da das "P" in HPC ja für Performance steht, sollten die Ergebnisse dazu einladen, sich weiter mit Julia zu beschäftigen. Vielen High-Level-Sprachen wird unterstellt, weniger effizient als C oder Fortran zu sein. Die Tabelle beweist, dass das nicht so sein muss. Schon die Annäherung an die Geschwindigkeit der herkömmlichen, kompilierenden Sprachen kann man als Durchbruch für ein High-Level-HPC-Tool ansehen.
Tabelle 1
Benchmark-Ergebnisse
|
Julia v3f670da0 |
Python v2.7.1 |
MATLAB vR2011a |
Octave v3.4 |
R v2.14.2 |
JavaScript v8 3.6.6.11 |
---|---|---|---|---|---|---|
» |
1.97 |
31.47 |
1,336.37 |
2,383.80 |
225.23 |
1.55 |
» |
1.44 |
16.50 |
815.19 |
6,454.50 |
337.52 |
2.17 |
» |
1.49 |
55.84 |
132.71 |
3,127.50 |
713.77 |
4.11 |
» |
5.55 |
31.15 |
65.44 |
824.68 |
156.68 |
5.67 |
» |
0.74 |
18.03 |
1.08 |
328.33 |
164.69 |
0.75 |
» |
3.37 |
39.34 |
11.64 |
54.54 |
22.07 |
8.12 |
» |
1.00 |
1.18 |
0.70 |
1.65 |
8.64 |
41.79 |
* Tests sind relativ zu C++ und liefen auf einem MacBook Pro mit 2.53GHz Intel Core 2 Duo CPU und 8GByte 1,066MHz DDR3 RAM (Quelle: Julia-Webseite). |
Neben der Geschwindigkeit sollten weitere Julia-Features den Fachexperten gelegen sein.Die folgende kurze Liste ist eine Aufstellung der wichtigsten Vorzüge von Julia (eine vollständige Liste findet sich hier [3] ):
Eine Fähigkeit, die alle Hochsprachen benötigen, ist die, existierende Bibliotheken aus anderen Quellen zusammenzufügen. Es existiert zu viel guter Code, als dass man ihn ignorieren oder neu erfinden sollte. Dank der Nutzung eines LLVM-Compilers kann Julia ohne Weiteres existierende Shared Libraries verwenden, die mit GCC oder Clang-Tools kompiliert wurden. Im Ergebnis verfügt Julia über eine sehr performante Methode mit geringem Overhead, um bestehende Bibliotheken auszunutzen.
Eine weiteres wichtiges Feature von Julia ist die native Parallelverarbeitung auf der Basis von zwei Primitiven: Remote References und Remote Calls. Hinter den Kulissen benutzt Julia Message Passing, zwingt den Benutzer aber im Unterschied zu MPI nicht dazu, die Umgebung explizit zu kontrollieren. Überhaupt ist Kommunikation in Julia immer einseitig, was heißt, dass der Programmierer sich in einer zweiseitigen Operation nur um eine Seite zu kümmern braucht. Julia unterstützt außerdem verteilte Arrays.