Donnerstag, 14. Oktober 2010

Verbreitung der Programmiersprache Java

Wenn ein Softwareprojekt ansteht, steht auch immer die Frage mit welcher Programmiersprache soll es umgesetzt werden. Oft wird die Programmiersprache dafür gewählt, für die es im Haus verfügbare Programmierer gibt. Und trotz dieser pragmatischen Antwort bleibt diese Frage. Wenn dies aber eine offene Frage ist, kann man anfangen das Problem mit allen Programmiersprachen zu vergleichen, um die beste Programmiersprache zu finden. Auch wenn man sich einschränkt ist dies eine sehr Zeitaufwendige Untersuchung. Unklar ist auch ob man alle Aspekte des Problems kennt um objektiv die richtige Programmiersprache zu wählen. Ich behaupte, das es nicht möglich ist alle Aspekte und Informationen vor der Beendigung des Projektes zu kennen. Daher bin ich ein Verfechter der Agilen Softwareentwicklung, die flexibel mit wechselnden Anforderungen umgehen kann. Mit dieser Erkenntnis kann man andere Kriterien für die Auswahl einer Programmiersprache heranziehen. Wenn man davon ausgeht das alle Programmiersprachen ähnlich leistungsfähig sind, kann man sich an dem Verbreitungsgrad einer Programmiersprache orientieren. Zu behaupten alle Programmiersprachen sind gleich leistungsfähig ist eine sehr grobe Vereinfachung, die aber aber für die wichtigsten Programmiersprachen ein zulässige Annahme ist. So lassen sich Java, C++ oder C# im Allgemeinen als äquivalent betrachten. Dazu kommt, dass der Verbreitungsgrad von Programmiersprachen sich gut ermitteln lässt. Bei Heise Jobs 2010 (http://www.heise.de/jobs/artikel/Wer-verdient-wie-viel-981845.html?artikelseite=8) liegt Java bei 17,3% auf Platz 1 und C++ bei 7,4%. Bei Tiobe ist die Nummer 1 Java mit 18% vor C mit 17% gefolgt von C++ mit 9,8% (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html). Bei Gulp liegt Java derzeit (09/2010) bei ca. 16%, C bei 9% und C++ bei nur 4%. Der Trend bei Gulp und Tiobe ist ähnlich, die Differenz lässt sich zu Teil dadurch erklären, dass bei Gulp nacht Skills gefiltert wird, d.h. SQL hat dort eine Wert von 13%, wohingegen SQL bei Tiobe nicht separat aufgeführt wird. Trends bei den Programmiersprachen werden bei Tiobe direkt angegeben, auch bei Gulp kann man Trendanalysen durchführen. Bei Gulp fällt auf, dass die Angaben zu einer Programmiersprache stark zeitlich schwanke, für genaue Aussagen, müsste man die Gulp-Daten statistisch bearbeiten. In diesem Zusammenhang interessant sind die Nutzungswerte der Usenet Gruppe Java (siehe Bild).

Danach erreichte Java seinen Höhepunkt im Jahr 2002 und ist bis 2010 deutlich geschrumpft. Bei Gulp erreichte Java seine grösste Popularität im Jahr 2000. Dies betrifft nicht nur Java sondern auch andere etablierte Programmiersprachen wie C. C erreicht bei Gulp im Jahr 1999 seine maximale Beliebtheit. 1999 ist dabei das erste verfügbare Jahr in Gulp. Ob diese Rückgänge real oder nur Prozentual auf Grund sich neu etablierender Programmiersprachen ist, ist nicht zu ermitteln. Aber die zunehmende Diversität der Programmiersprachen ist sicher ein Grund für die prozentualen Rückgänge bei Gulp und die realen Rückgänge im Usenet. Bei den dramatisch erscheinenden Java Usenet Zahlen kommt hinzu, dass es auch bei den Hilfepunkten zu einer staken der Diversität z.B. durch Webforen kam. Bei Tiobe sind auch allgemein abnehmende Verbreitungsgrade festzustellen, aber entgegen dem Trend bei Gulp kann sich dort C im Langzeittrend (10 Jahre) besser behaupten und sogar Boden gut machen.
Abschliessend kann man sagen, dass es in den letzten 10 Jahren zu einer stark zunehmenden Diversität der Programmiersprachen kam. Trotzdem behaupten sich die wichtigen Sprachen wie Java oder C weiterhin. Diese neue Vielfalt der Programmiersprachen lädt dazu ein beim nächsten Projekt mal über alternative Programmiersprachen nachzudenken. Ein einfaches Auswahlkriterium könnte die Verbreitung der Sprache sein.

Mittwoch, 6. Oktober 2010

Freies R Lehrbuch


Wikipedia ist jedem Bekannt und ist heute so etwas wie ein kollektives Gedächtnis oder für viele eine Art dritte Gehirnhälfte. Neben dem Wikipedia-Projekt gibt es weitere Projekte, z.B. Wikibooks. Wikibooks sind Lehrbücher zu speziellen Themen. Zur Zeit helfe ich bei der Erstellung eines Buchs über die Statistik-Software und Sprache R. Helfer sind gern willkommen. Ein allgemeines Problem bei den Wikibooks ist, dass viel Experten zwar tiefgreifendes Expertenwissen haben aber nicht in der Lage sind, leicht verständliche Texte zu schreiben. Ein Grund dafür ist, dass die Experten meist ein Uni-Karriere hinter sich haben und dem entsprechend sozialisiert sind. Ihr Schreibstiel ist eher kompliziert und akademisch und weniger erklärend. Aus diesem Grund ist es wichtig, dass nicht nur Fachexperten bei Wikibooks helfen, sondern auch normale Anwender. Bitte helft mit, nicht nur Experten sind wichtig um gute Bücher zu schreiben.

Dienstag, 5. Oktober 2010

Wie gut skaliert Illumina OLB?

Illumina ist zur Zeit einer der Hersteller von Next Generation Sequencing (NGS) Maschinen. Beim NGS fallen im Vergleich zu den bis hierhin üblichen Methoden der Genetik eine riesige Menge an Daten an. NGS ermöglicht Genom-weite Untersuchungen. Teil der Illumina Auswertungspipeline sind die Softwarebausteine Casva und der Off Line Base Caller (OLB). Weil sie risige Datenmanegen verarbeiten müssen, tun sie das möglichst parallel. Deshalb mach ich hier eine Test, wie gut der OLB skaliert. Beim betrachten der Testergebnisse ist zu beachten, dass die Illumina Software  sich gerade in Phase der rapiden Weiterentwicklung befindet.
Für diesen Test setze ich das Testdatenset von Illumina ein, ein Dell R815 Server mit 4 Magny Cours (insgesamt 48 Cores, 64GB RAM, RAID 0, Centos 5.5). Ich variiere den Parameter j des OLB, der für eine Aufteilung des Jobs in mehrere Prozesse dient. Ich erhalte folgende Messergebnisse:

Und diese Daten jetzt mal als Diagramm:
Positiv ist, dass OLB über mehrere Cores skaliert. Es wird mehr als der Faktor 4 erreicht. Negativ ist, dass OLB mit mehr als 7 Prozessen keinen Geschwindigkeitszuwachs mehr hat. Damit drängt sich die nächste Frage auf, warum ist 7 das Optimum und warum scheint es ein Plateau bei 4-6 zu geben?

Aus meiner Sicht enthält OLB ca. 23..24% nicht skalierenden Code. Zusammenfassend kann man sagen, OLB profitiert sehr gut von mehreren CPU-Cores, aber nur begrenzt bis 7, d.h. die Taktfrequenz spielt weiterhin, wenn auch untergeordnete Rolle.

Off-Line Base Caller 1.8

Nach der Restrukturierung von Illuminas Software gibt es jetzt den Off-Line Base Caller. Dieser kann wie folgt installiert werden. Für diese Beschreibung wird vorausgesetzt, das Casava wie hier beschrieben auf dem Computer installiert wurde.

Installation FFT Bibliothek.
  • tar xfz fftw-3.1.2.tar.gz 
  • cd fftw-3.1.2
  • ./configure --enable-single
  • make
  • su
    • make install
    • exit
Installation von OLB.
  • tar xfz OLB-1.8.0.tar.gz
  • cd ../../OLB-1.8.0
  • make
  • su
    • make install
    • exit
Testen von OLB mit Testdaten.
  • tar xfjv Illumina_Genome_Analyzer_Validation_Dataset_v_1_8_0.tar.bz2
  • cd Illumina_Genome_Analyzer_Validation_Dataset_v_1_8_0
  • su
    •  ./validate.sh /home/mirkoebert/illumina/olb/OLB-1.8.0