Seite 4: Ausblick auf Julia 1.0

Inhaltsverzeichnis

Julia 1.0 sollte eigentlich zur JuliaCon im Juni 2017 fertig sein. Leider konnten die Macher den Zeitplan nicht einhalten und haben stattdessen Julia 0.6 veröffentlicht. Ein Großteil der geplanten Features für Julia 1.0 sind jedoch in Version 0.6 enthalten. Das kommende 0.7-Release soll ohne Breaking Changes auskommen und Warnungen für Code ausgeben, der nicht 1.0-kompatibel ist. Programme, die mit Julia 0.7 ohne Warnungen laufen, sind im Umkehrschluss kompatibel zum 1.0-Release, das nach derzeitiger Planung im vierten Quartal diesen Jahres erscheinen soll.

Entschlackung und Effizienz

Viele Funktionen der Standardbibliothek sollen bis zum Release von Julia 1.0 in eigenständigen Paketen landen. Damit wird Julia im Kern schlanker, und die einzelnen Pakete können unterschiedliche Update-Zyklen haben. Damit Julia trotzdem benutzerfreundlich bleibt, will das Team verstärkt auf Metapakete setzen, die mehrere Pakete kombinieren und sicherstellen, dass das Zusammenspiel funktioniert.

Unter anderem um die oben beschriebenen Metapakete zu realisieren, wird es eine neue Version des Paketmanagers als Pkg 3 geben, dessen Alphaversion bereits zur JuliaCon 2017 erschienen ist. Er soll stabiler sein, besser Performance bieten und besser Lösungen für getrennte Namensbereiche bringen.

Pläne und Wünsche

Julia bietet noch kein Paket, das auf Augenhöhe mit dem beliebten DataFrame-Typ der Programmiersprache R ist. Aufgrund seiner großen Bedeutung für die statistische Arbeit hat die Weiterentwicklung der Infrastruktur eine hohe Priorität. Ein großes Problem bei statistischen Daten ist die häufige Arbeit mit fehlenden Werten – außerdem können Einträge mehrere Typen haben. Das lässt sich in Julia als Union-Typ darstellen, der in Version 0.6 noch schlechte Performance bietet. Die Entwickler arbeiten aktiv an der Lösung des Problems, die sie teilweise bereits im Master Branch umgesetzt haben.

Ein weiteres notwendiges Sprachkonstrukt sind effiziente Named Tuples, die unter anderem zum Einsatz kommen, um zeilenorientierte Datenbanken zu implementieren. Julia-Entwickler können mit ihnen zudem den schnellen Dispatch von Funktionen mit Keyword-Argumenten implementieren – deren mangelnde Performance führt immer wieder zu Klagen in der Entwickler-Community.

Wenn ein Objekt nie eine Funktion verlässt, muss der Garbage Collector sie nicht verfolgen und kann sie potenziell auf dem Stack allokieren. Die Optimierung ist unter anderem wichtig, um einen Array-View-Typ ohne Performanceverlust zu implementieren. Eine andere Anwendung ist das Verpacken von Immutables in mutierbaren Typen. Mit verbesserter Escape-Analyse kann der Compiler diesen Vorgang komplett eliminieren, sodass sich teilweise die Vorteile von Immutable- und Mutable-Typen kombinieren lassen.

Im Moment cached die Toolchain von Julia nur die ersten Teile der Compiler-Pipeline, speichert aber weder den LLVM-IR noch den kompilierten binären Code ohne weiteren Aufwand. Das führt dazu, dass Entwickler beim ersten Aufruf von Funktionen auf das Kompilieren warten müssen. Außerdem können sie keine Binary erstellen, die auf den JIT-Compiler verzichtet erstellen, was für eingebettete Geräte oder das Einbinden von Julia-Bibliotheken in andere Sprachen erstrebenswert wäre. Manuell ist das bereits seit geraumer Zeit möglich, und die Integration in die Compiler-Infrastruktur steht weit oben auf der Prioritätenliste.