Dienstag, 27. April 2010

Ist Java langsam?

Ein vielgehörtes Vorurteil gegenüber Java ist, Java ist langsam. Oft kommt diese Behauptung von Programmieranfängern oder C-Programmierern. Ich bin der Meinung, das sollte man erstmal nachweisen. Dafür mangelte es mir aber an zwei Dingen, einem guten C-Programmierer und einer passenden Aufgabe. Einen C-Programierer hätte ich gefunden aber das auswählen einer passende Aufgabe ist nicht trivial. Denn wie heisst es, wer misst misst Mist. Aber es gibt auch für dieses Problem eine passende Antwort im Netz. Auf der Seite http://www.shudo.net/jit/perf/ werden die Geschwindigkeiten verschiedner Java-VMs verglichen und es wird auch .Net und C einbezogen. Auch wenn die Resultate aus 10/2004 stammen, so dürften sie auch noch heute gültig sein. Eine neue Frage wirft sich bei den heutigen Mulit-Core-CPUs auf, wie gut skalieren die VMs, diese Frage wurde damals noch nicht beantwortet. Zu den Antworten, die Messergebnisse zeigen einige deutliche Ergebnisse, C und Java sind ähnlich schnell beim Linpack und SciMark, der Vorsprung für C liegt im Bereich von 6%. Die Interpreter (Java, C#) sind immer weit abgeschlagen. Die VMs von Sun liegen in der Regel vorn. Die Server-VM ist schneller als die Client-VM.
Aber kein Vorurteil ohne wahren Kern. Die früheren Java-Versionen waren langsamer, Sun hat viel Zeit und Ideen in die Optimierung des JIT gesteckt. Heute ist man mit Java nicht langsamer als mit C, wichtig ist vor allem, dass die Programmierer wissen, was sie programmieren und was dies aus Sicht der CPU bedeutet. Diese Überlegungen dürften in Regel mehr Performance-Schub bringen als der Wechsel von Java zu C. Was bei den obigen Benchmarks auch nicht getestet wurde, war die Geschwindigkeit des graphischen Systems. Diese ist bei Java-Anwendungen in Architektur-bedingt niedriger. Aber auch hier hat Sun viel getan um die Geschwindigkeit zu steigern. Ich hoffe das Oracle genauso viel Zeit investiert um Java weiter zu entwickeln.

Nachtrag:
Hier ist nach ein weiterer interessanter Beitrag zum Thema Java Performance im Vergleich, leider auch schon von 2004:
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
http://www.ibm.com/developerworks/java/library/j-jtp09275.html

Donnerstag, 8. April 2010

Der richtige Umgang des Programmierers mit Passwörter

Viele Anwendungen wie der Apache Webserver oder andere haben ein eigenes Passworthandling. Trotzdem ist man als Programmierer machmal gezwungen sich selbst um das Handling der Passwörter kümmern. Die meisten selbstentwickelten Lösungen der Programmierer sind oft mäßig bis unzureichend. Das liegt auch daran, dass es während des Informatikstudiums keine oder nur selten entsprechende Vorlesungen oder Seminare gibt. Hier jetzt ein paar Regeln Regeln zum besseren Umgang mit Passwörtern.
  • Akzeptiere nur ausreichend lange Passwörter um Brute Force Attacken zu erschweren. Zur Zeit gelten Passwörter mit 8 und mehr Zeichen als akzeptabel.
  • Passwörter sollten nicht mit dem Benutzernamen identisch sein. Das wäre zu leicht zu erraten.
  • Passwörter sollten nicht Personennamen sein und auch möglichst kein normales Wort sein, auch sollte man nicht nur die Jahreszahl an eine Personennamen hängen. Diese Passwörter können durch Wörterbuch-Attacken ermittelt werden. Sinnvoll wäre immer eine Etropieprüfung der Passwörter.
  • Das Passwort sollte kein Tastaturmuster ala QWERTZU sein. Diese Passwörter sind auch anfällig für Attacken.
  • Passwörter sollten vom Programmierer nie als Klartext gespeichert werden. Passwörter sollten immer mit einer sicheren Hash-Funktion verarbeitet werden. Anschliessend wird dann der Hash-Wert gespeichert. Z.B. gelten zur Zeit SHA2 und MD5 als sicher. Durch das hashen ist es einem Eindringling nicht möglich die Passwörter im Klartext zu ermitteln.
  • Zusätzlichen Schutz bietet der Einsatz eines Salt. Dieser Salt wird dann zusätzlich zum Hash-Wert des Passworts gespeichert. Der Salt verhindert den Angriff von Eindringlingen via Rainbow Table.
Prinzipiell sollte man beim Schutz von Daten immer mehrere Verteidigungslinien aufbauen und sich nicht allein auf eine Schutzmassnahme verlassen. Oft zieht ein Einbruch weitere Einbrüche nach sich, wie z.B. auch bei der Apache Foundation (http://www.golem.de/1004/74458.html).

7FHFWF5TMNZC

Mittwoch, 7. April 2010

Mixt it oder auch nicht - die 32 Bit Java Option

Ich habe auf meinem Mac ein aktuelles Eclipse, die Mac Cocoa 64 Bit Version. Jetzt versuchte ich ein eigenes Eclipse-Plugin zu entwickeln und erzeugte ein entsprechendes neues Projekt. Wow, ein seltsamer Fehler in der .log Datei: java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM.
Was nun, die Tipps wie der auf Seite SWT FAQ fruchten nicht oder waren zu kompliziert. Einfacher war es beim Start meines Plugins die 32 Bit Karte zu ziehen. Mit Hilfe der VM-Option -d32 weist man die JVM an das 32 Bit Datenmodell zu benutzen. Dies muss man in Eclipse bei Run Configurations ... / Arguments / VM Arguments eintragen.
Neben der VM-Option -d32 gibt es auch die 64 Bit Option -d64. Und wenn die Ergebnisse aus der Veröffentlichung von  Venstermans, Eeckhout und De Bosschereaus aus dem Jahr 2005 noch heute stimmen, sollte man in der Regel bei der 32 Bit Option bleiben. Das 64 Bit Java verbraucht mehr Heap (39%), führt zu mehr Cache Misses und ist auch noch langsamer (1,7%).

Update: Diese Informationen sind für Java 7 nicht mehr zutreffend. In Java 7 gibt es eine Option die den 64 Bit Overhead reduziert.