Java Urban Legend: "Java kann kein Multi-Core"

Es ist immer wieder erstaunlich, welche Urban Legends sich über Java halten.

"Java ist langsam, zu langsam" ist davon noch der absolute Klassiker. Aktuelles Beispiel sind die Kommentare in "TWiT 126" vor ein paar Wochen.

So langsam sollte sich diese Legende doch wirklich in Luft aufgelöst haben, oder? Naja, wenn nicht, dann sollte man schnell Brian Goetz Kolumne "Java theory and practice" lesen. Insbesondere Urban performance legends und Urban performance legends, revisted. Dort heisst es zum Beispiel:

You don't have to search through too many blogs or Slashdot postings to find confidently worded statements like "Garbage collection will never be as efficient as direct memory management." And, in a way, those statements are right -- dynamic memory management is not as fast -- it's often considerably faster. The malloc/free approach deals with blocks of memory one at a time, whereas the garbage collection approach tends to deal with memory management in large batches, yielding more opportunities for optimization (at the cost of some loss in predictability).

Eine andere Legende ist, dass Java keine Multi-Prozessoren ausnutzen kann, weil es nur User-Level-Threads hat. Mir war bis heute nicht klar, dass diese Legende wirklich jemand glaubt. Aber dann hat mich ein Kommolitone, der eigentlich weiß was er tut, eines besseren belehrt.

Vermittelt wird diese Legende offenbar durch eigentlich gute Autoren wie Tanenbaum. Wenn man nach "Java User-Level" bei Google sucht, dann findet man Dutzende von Betriebssystem-Kursen, in denen genau dies gelehrt wird z.B. Uni Dortmund, Uni Mannheim und selbst, Oh Schreck, Uni Paderborn. Da muß ich wohl in KMS mal geschlafen haben. Selbst in der Wikipedia ist dies nicht eindeutig beantwortet.

Offenbar ist der Hintergrund für die Legende, dass viele immer noch bei Java 1.1. hängengeblieben sind. Dort gab es (nur) so genannte Green Threads, dies waren Javas User-Level-Threads.
Aber diese Beschränkung wurde schon mit 1.2 aufgehoben. Also vor mehr als 10 Jahren!

In "Programmieren mit Java" heisst es:

Derzeit werden Java-Threads folgendermaßen unter Windows, Solaris und Linux implementiert:

• Unter Windows NT/2000/XP werden Java-Threads auf Threads im Betriebssystems abgebildet, die innerhalb des Virtual-Machine-Prozesses ablaufen. Die Anzahl der gestarteten Prozesse und Threads kann auf dieser Plattform gut im Task-Manager beobachtet werden. Beim Starten eines Java-Programms sieht man, dass sich die Anzahl der Prozesse um Eins erhöht, die Anzahl der Threads nimmt dagegen stärker zu. Dies ist auch dann der Fall, wenn das Programm selbst keine eigenen Threads erzeugt, weil die Virtual Machine eigene System-Threads für Aufgaben wie Garbage Collection startet.
• Bei Solaris werden seit JDK-Version 1.2 die nativen Threads eingesetzt. In den Vorversionen machte die Solaris-Virtual Machine von Green Threads Gebrauch.
• Unter Linux werden Threads seit JDK-Version 1.3 mit abgespalteten Tochterprozessen realisiert. Zuvor wurden auch hier Green Threads verwendet. Dadurch, dass für Java-Threads komplette Prozesse erzeugt werden, kann die Erzeugung einer großen Anzahl neuer Threads länger dauern als bei Betriebssystemen, auf denen native Threads eingesetzt werden.

Ein Blick in die Aktivitätsanzeige oder "top" hätte die Behauptung also widerlegen können.

Ans Extrem treibt es zum Beispiel die Firma "Azul Systems", die Werbung macht mit "World's Most Powerful Platform for Java Computing: Massive Capacity: 768 Processors and 768 GB of Memory".

Also: Ich hoffe, ich kann zumindest bei den Lesern dieses Blogs diese Legende aus der Welt schaffen.

Bei Autoren/Forschern aus dem Systemsoftware-Bereich bin ich schon lange sehr vorsichtig, wenn diese sich zu Software-Engineering-Themen äußern. So sehr die Autoren ihren eigenen Kram in- und auswendig kennen, so viel Mist über SE ist manchmal auch enthalten. Bestes Beispiel: "Reliable Distributed Systems". Teilweise recht grausam. Ein Paper, dass schön Distributed Computing und Software Engineering verbindet ist z.B. dieses hier.

VKrit: Architektur paralleler Rechnersysteme

Diese Veranstaltung "Architektur paralleler Rechnersysteme" von dem PC^2-Mitarbeiter Jens Simon sorgt dafür, dass (große) parallele und verteilte Systeme nach dem Weggang von Professor Kao an der Uni Paderborn nicht total untergehen. Die Veranstaltung ist weitgehend unbekannt, weil die Webseite dazu nicht über die Seite "Lehrangebot" erreichbar ist.
Im Modulhandbuch wird sie auch nicht explizit erwähnt. Dort heisst es aber:

Die Veranstaltungen über Cluster Computing, Architektur paralleler Rechnersysteme und Performance-optimierte Programmierung führen in die Welt des Hochleistungsrechnens. Dabei werden sowohl der prinzipielle Aufbau als auch Fall Beispiele von Hochleistungsrechnern vorgestellt. Ferner wird auf die entsprechende Systemsoftware, auf die Netzwerkstrukturen und insbesondere auf die Programmiermodelle für Parallelrechner eingegangen.

Das Thema finde ich sehr interessant und eines der empfohlenen Bücher "Hennessy/Patterson: Computer Architecture - A Quantitative Approach" ist eines der besten Bücher, die ich bisher im Studium gelesen habe.

Ein Plus-Punkt bekommt die Veranstaltungen wegen den Übungsaufgaben, die auch praktische Entwicklung auf dem PC^2-Cluster beinhalteten.

Negativ ist anzumerken, dass in der Vorlesung und in dem Folienskript teilweise der rote Faden fehlt. Einzelne Themen werden mehrmals besprochen und dabei teilweise unterschiedlich definiert. Insgesamt brauchen die Folien nochmals eine gründliche Durchsicht.
Auch wirkt die Motivation mit dem Zitat von Luiz Andre Barroso über die Google Architektur in Anbetracht der Ausrichtung der gesamten Veranstaltung auf wissenschaftliches Rechnen (was auch genau dem Fokus des PC^2 entspricht)sehr merkwürdig.

Das Google Konzept z.B. hier widerspricht in meingen Augen genau dem Fokus und den Inhalten der Vorlesungen (Sehr deutlich z.B. auf Folie 23 der Vorlesung zu Clustern). Eine Motivation, die eher auf wissenschaftliches Rechnen mit Aufgaben wie Barnes Hut (Galaxiesimulation) u.a. eingeht, würde der Vorlesung besser entsprechen.

Bis auf die verbesserungsbedürftigen Folien und der Motivation, die nicht zur Vorlesung passt, auch eine gute Veranstaltung, die ich empfehlen kann.

VKrit: Semantik von Programmiersprachen

Meine kurze Reihe von persönlichen Veranstaltungskritiken setze ich mit zwei Wochen Verspätung zur Prüfung fort: Semantik von Programmiersprachen

Im Modulhandbuch steht zu Semantik von Programmiersprachen nicht viel. Dort heisst es nur:

Semantik von Programmiersprachen
1 Operationale Semantik
2 Mathematische Semantik
3 Axiomatische Semantik
4 Induktives Definieren und Beweisen
5 Semantische Bereiche und Fixpunkttheorie
6 Rekursionsgleichungen
7 Semantik nebenläufiger Systeme

Klingt sehr theoretisch. Ist es auch.

Und dies ist gleichzeitig der größte Vor- und der größte Nachteil der Veranstaltung.

Ein Vorteil weil in keiner anderen Veranstaltung in der Softwaretechnik so formal mit den Themen der Softwaretechnik umgegangen wird.

Ein Nachteil, weil mir (außer dem Training des formellen Umganges mit SWT-Themen an sich) kaum eine Anwendung für das Wissen und die Methoden bewusst ist. Auch der Motivationsabschnitt des Skriptes gibt nicht viel her.

Teilweise gibt es Zusammenhänge mit Model Checking (z.B. Fixed Point Theory), natürlich auch mit Programmverifikation (z.B. Axiomatische Semantik), aber darauf wird nicht eingegangen.

Die Veranstaltung kann höchstens dazu dienen, dass Handwerkszeug für andere Veranstaltungen bereitzustellen.

Deshalb: Wenn man diese Veranstaltung belegt, sollte man dies auf jeden Fall als erste Veranstaltung in einem Modul machen. Wie ich es gemacht habe: Erst "Model Checking" dann "Semantik" ist nicht wirklich sinnvoll.

VKrit: English for Computer Science Students

Das Semester geht zu Ende, seit für meine ganz private VKrik.
Im Grund will ich zu jeder Veranstaltung einen kurzen Kommentar veröffentlichen.
Fangen wir deshalb mit etwas einfachen an. Meine Englisch-Veranstaltungen im Studium Generale: Im letzten Semester "Reading, writing about und discussing technical texts" von Professor Warren und in diesem Semester "English for Computer Science Students" (je 2 ECTS-Punkte). Beide bewerte ich sehr positiv und sind definitiv empfehlenswert.

Die Grundlagen von wissenschaftlichen Schreiben an der Universität kaum vermittelt. Ohne den Kurs bei Professor Warren im letzten Semester wäre meine Bachelorarbeit sowohl inhaltlich als auch sprachlich deutlich schlechter gewesen. Ich habe dort etwas über Englisch gelernt, aber wesentlich mehr zum wissenschaftlichen Schreiben mitgenommen.

Eine andere Ausrichtung hatte die Veranstaltung in diesem Semester. Die Veranstaltung besteht aus mehreren Teilen, u.a. muss man englische Texte lesen und verstehen Zusammenfassungen und Bewerbungsschreiben erstellen und eine kurze Präsentation über ein beliebiges Thema auf Englisch halten.. Es gibt Hörverstehensübungen, Grammatikübungen.
Insgeamt wirkt es entfernt wie eine Vorbereitung auf den TOEFL-Tests.

Daneben hatten beide Veranstaltungen auch eine Komponente, die über die Lehre der Sprache hinausgeht. Insbesondere in "English for Computer Science Students" wurde auch über kulturelle Eigenheiten der USA gesprochen. Beim Reading-Kurs bestand diese zusätzliche Komponente mehr aus wissenschaftliche Eigenheiten und dem Universitätssystem in den USA.

Wer sich mehr für diese Komponente interessiert, der sei auch auf diesen Artikel über die Seite "USA Erklärt" verwiesen.

Diese Komponente bringt nichts für die Vorbereitung für auf Englisch gehaltene Kurse im Master, aber ich fand dies fast noch interessanter als die eigentlichen Kurse.

Wer noch mehr Englisch hören möchte, den verweise ich auf den kostenlosen Podcast "English as a second language".

ZFS

Das ZFS-Dateisystem von Sun Microsofts wird im Solaris 10 Betriebssystem eingesetzt und wurde vor einiger Zeit auch als Open Source veröffentlicht.

Interessant (besonders wenn man diese Vorlesung gerade hört) ist ZFS vor allem deshalb, weil es alte Annahmen, die vor 15 Jahren ihre Berechtigung hatten, über Bord wirft.

Die Liste der Features wäre zu lang um sie hier aufzuzählen, aber u.a. bietet ZFS

• Ende-zu-Ende-Datenintegrität durch Transaktionen und Checksums
• Pooled Storage, dass Ende der festen Größenteilung von Dateisystemen (Dateisystem wächst und schrumpft je nach Bedarf)

Mehr Informationen zu ZFS allgemein gibt es in dieser Präsentation von Sun", die ganz unbescheiden ZFS als "The Last Word in File Systems" bezeichnet.
Einen kleinen Einblick in die Entwicklungsarbeiten an ZFS bietet dieser Bericht auf den Forschungsseiten von SUN.
Eine Anleitung wie man ZFS als "Filesystem in Userspace" betreibt findet sich im node-0-Blog.

High-Performance-Computing on Mac OS X

Die Webseite "High-Performance-Computing on Mac OS X" bietet eine gute Übersicht über verschiedene Mac OS X-bezogene Tools für HPC.

Dies umfasst Themen von OpenMP-GCC-Compiler für Mac, Open-Source-MPI-Bibliotheken bis zu Informationen zu Apples XGrid-Software.

Aber es gibt auch Informationen zur AltiVec-Technologie in den G4- und G5-Prozessoren. Stark vereinfacht: Eine Art PowerPC-Version der SEE (Streaming SIMD Extensions).

Die Informationen kann ich im Moment gut gebrauchen, da der PC^2-Cluster gewartet wird und ich so meine Hausaufgaben (Jacobi-Folge per MPI) nicht machen kann.
Die MPI-Implementierung LAM kam mir dann genau richtig.

Skript zu Computergrafik von Prof. Domik

Auf der Homepage des Forschungsgruppe von Prof. Domik ist ein Skript für Computergrafik verfügbar (Copyright 1994 - 1997).

Dort sind dann alle Informationen verfügbar und nicht wie in den Folien der Veranstaltung zu teilen herausgelassen. Die offiziellen Materialien der Vorlesung kann man ja nur als verstümmelt bezeichnen. Die wichtigen Informationen (Algorithmen, etc) sind jeweils nicht vorhanden.

Klausur Nr 2: Sozialphilosophie

Heute habe die zweite Klausur in diesem Semester geschrieben. Sie war für die Vorlesung "Soziale Realität - Philosophische Ansätze von der Antike bis heute" aber die Kurzfassung "Sozialphilosophie" passt genau so gut.

Wer sich immer noch fragt, ob sich Naturwissenschaften und Gesellschaftswissenschaften unterscheiden sollte einfach mal als Informatikstudent diese Vorlesung besuchen. Diese Leute denken ganz anders als ich. Nach Sätzen wie

Das Für-sich-Sein ist die Negation des Für-andere-Sein, die Synthesis von An-sich-Sein und Für-andere-Sein. Das An-sich-Sein hat sich im Für-andere-Sein bewahrt: In diesem Moment kehrt das entäußerte Wesen wieder zu sich selbst zurück. Im überwundenen Für-andere-Sein ist es an den anderen gereift. Das Wissen im An-sich-Sein ist im Außer-sich-treten des Für-andere-Sein ein Wissen von sich selbst geworden, das Subjekt konnte sich selbst zum Gegenstand nehmen, heißt, es hat sich selbst im anderen erkannt als das, was es ist: ein wissendes Subjekt. Nach Hegel: Die einfache Gewissheit seiner selbst ist ihm geworden.

(aus wikipedia.de, die Professorin hat nicht direkt diesen Satz gesagt, aber durchaus vergleichbar verwirrende) und der Bemerkung der Professorin jetzt sei ja klar, was Hegel meint, hat sich bei mir nur noch der Kopf gedreht.

Schon sehr seltsame Wissenschaft. Aber man muss schon sagen, dass ich einiges neues gelernt habe. Kein Wunder, wenn man vorher wenig über Themen wie Staatsphilosophie weiß. Wir haben under anderem Platon, Aristoteles, Hobbes, Locke, Rousseau, Hegel, Marx, Max Weber und in Ansätzen Kant, Popper und Arendt sowie Dilthey behandelt. Also eine ganze Menge Stoff.

Die Klausur bestand aus 10 Fragen von denen man in einer Stunde sechs beantworten muss. Die Fragen waren zum Beispiel "Weshalb ist Erziehung ein wichtiger Bestandteil der Sozialphilosophie? Argumentieren Sie im Rückgriff auf Autoren aus der Geschichte der Philosophie" oder "Erläutern Sie die Hauptpunkte der Staatsphilosophie nach Hobbes und erklären Sie seine bahnbrechende Bedeutung für die Staatsphilosophie".

Als Nächstes ist "Methoden des Algorithmenentwurfes" am nächsten Montag dran.

Build-Automatisierung mit Cruisecontrol

Im Softwaretechnikpraktikum meines Studienganges habe ich als Software-Qualitätsbeauftragter die Build-Management-Software Cruisecontrol eingesetzt.
Hier will ich von einen Erfahrungen mit Cruisecontrol berichten:

Die Software arbeitet im Grunde wie folgt:
Sie überprüft die Quellcodeverwaltung eines Software in regelmäßigen Abständen (im SoPra-Projekt zweimal am Tag) und erstellt einen neuen Build der Software.
Dabei können dann System wie ant oder maven zum Einsatz kommen, um den Ablauf des Build-Vorganges zu steuern (im Projekt "ant").
Die Ergebnisse jedes Build-Vorganges werden dann auf einer Webseite veröffentlicht und per Email an die Entwickler verschickt. Es gibt sogar eine Erweiterung von Cruisecontrol zum Ansteuern eines Blicklichtes, dass als Alarmzeichen in einem Projektbüro dient.

Zusätzlich zu dem reinen Compilieren haben wir auch jedesmal die javadoc-Dokumentation aktuallisiert, die Einhaltung der Codekonventionen mit Checkstyle überprüft und natürlich die JUnit-Testfälle ausgeführt. Gleichzeitig wurde auch die Codeabdeckung der Testfälle mit emma ermittelt.

Die Automatisierung der Builds und der Tests hat sich meiner Meinung nach Bewährung.
Cruisecontrol spielt die zentrale Rolle und ist (bis auf die kleinen Macken) mittlerweile wirklich gut gelungen.
Der Server wurde durch Checkstyle und Emma erweitert und Cruisecontrol arbeitet auch gut mit diesen Tools zusammen.

Aber Cruisecontrol hat kleine Macken.
- Für jede Änderung an der Konfiguration muss der Server gestoppt und neugestartet werden.
- Ich habe nicht vorausgefunden, wie man Cruisecontrol so einstellt, dass zu bestimmten Tageszeiten also z.B. jedes Mal um acht Uhr, eine Build gestartet wird.
- Auch scheint es nicht so gut möglich zu sein die Software so einzustellen, dass zum Beispiel einmal am Tag ein volles Build (z.B. mit Codeüberdeckung und javadoc) erstellt wird und sonst (alle 10 Minuten) nur ein kleines Build. Dafür scheinen zwei seperate Cruisecontrol Projekte notwendig zu sein. Schade, diese Funktion hätte ich gut gebrauchen können.
- Es werden bei jedem Build (zumindest so wie wir es eingestellt hatten) unheimliche Mengen an Daten erstellt. Jeder Build belegte mehr als 10 Megabyte auf der Festplatte. Man sollte also eine Menge Festplattenplatz freihalten.
- Die Emails, die an die Entwicklern verschickt werden, werden sehr schnell sehr groß. Die Mails waren im Projekt im Schnitt ca. 500 Kilobyte groß. Die Entwicklern, die nur ein Modem-Anschluss haben, waren davon nicht begeistert.

Mein Fazit ist: Trotz einiger Macken ist Cruisecontrol in Projekten auch kurzfristig einsetzbar und kann helfen die Codequalität zu erhöhen. Insbesondere dadurch das Entwickler, die fehlerhaften Code einchecken auffallen und per Mail angeprangert werden. Im Softwaretechnikpraktikum ist es aber so gewesen, dass die Sanktionsmöglichkeiten fehlen, um guten Code auch von allen einzufordern.
Gerade aber die Möglichkeit den gesamten Buildprozess auf einem Server integieren, hilft dem Team einen Überblick über den aktuellen Stand der Software zu geben.
Schon vor mehr als zwei Jahren habe ich einmal einen Bericht über Cruisecontrol im Java Magazin gelesen, damals habe ich es aber nicht eingesetzt, da die Dokumentation noch sehr schlecht gewesen ist. Dies hat sich geändert mit User Guides und dem Cruisecontrol Wiki werden viele Fragen beantwortet.