Dirks Logbuch

Bitte? Ich habe schon oft gelesen, dass es diverse Photoshop-Plugins gibt, welche mehrere Kerne unterstützen, dann würde auch bei Bildbearbeitung ein Mehrkernsystem die Arbeit beschleunigen - wenn das alles so stimmt und man entsprechnende Plugins intensiv nutzt.

Ich würde auch nicht behaupten, dass jeder erhältliche Computer heutzutage für alles "normale" schnell genug ist. Gerade bei Netbooks sind mitunter sehr schwache CPUs im Einsatz, die bei Flash-Videos im H264-Format hoffnungslos überfordert sind. Nichts ist ärgerlicher, wenn das nagelneue Teilchen nicht mal den eigentlich simplen Akt der Videodarstellung perfekt beherrscht.

Mein Desktop-System ist jetzt ich glaube 2 Jahre alt, ein AMD X2 3800. Der reicht für H264 in HD gerade so mit einem guten Player (mplayer), und wenn ich mal für jemanden eine DVD aus TV-Aufnahmen zusammenstelle, was ein Umkodieren von Divx in MPEG2 erfordert, dann dauert das schon mal 2 Stunden pro DVD. Ein zehnmal schnellerer Rechner wäre mir da schon recht, und so schnell ist glaub noch keiner

Natürlich, zum simplen Surfen reicht auch der Laptop mit 800MHz hier neben mir. Wobei, wenn intensiv Javascript benutzt wird, wird es schon wieder zäh ...

Wenn man lange genug Dinge ausklammert, passt natürlich irgendwann jedes Gerät. Wenn es und die reine Arbeit mit Texten geht, gebe ich Recht, aber da war schon vor 5 Jahren jedes Gerät schnell genug, eigentlich schon zu Zeiten von Windows 95 ... Aber es gibt noch jede Menge andere Arbeiten am PC, da sei z. B. das große Feld der Softwareentwickler genannt. Auch ein Beispiel, wo der Rechner nicht fett genug sein kann, weil darauf noch die Testdatenbank, der Testwebserver usw. läuft und immer ein Haufen Jobs da sind, die irgendwie laufen: Compilervorgänge, Unit-Tests etc.

Wenn man weiss was man tut braucht man als Entwickler auch nicht sonderlich viel. Speicher ist nett, geht aber auch ohne -- ich habe bis 2006 primaer an einem Notebook mit 600MHz-CPU und 128MB RAM gearbeitet.

Mein aktuelles Notebook mit cpufreq on-demand governor ist laut cpufreq-info zu ueber 95% mit 1GHz getaktet. Von den 3GB RAM nutzen Programme etwa 200-300MB, Cache pendelt sich meist bei etwa 900MB ein. Bleiben also noch etwa 1.5GB Reserve, bevor angefangen wird den Cache zu nutzen. Schoen waere noch dem Kernel verbieten zu koennen die fuer Sus2disk benoetigte Swappartition zum swappen zu nutzen.

Datenbank und Webserver kann man auf dem Notebook entsprechend konfigurieren -- ueblicherweise arbeitet man da mit maximal einem Benutzer dran, ich brauch also keine Dinge wie 100 Apache-Instanzen preforken zu lassen. Gleiches fuer die Datenbank.

Compilervorgaenge sind nur bei groesseren Sachen oder bei einem kompletten Rebuild ein Problem, das kann man dann aber auch so einbauen dass das in der Mittagspause laeuft. Wenn Dein Buildsystem zwischendrin meint alles neu compilieren zu muessen ist das Buildsystem kaputt.

Klar, wenn man nicht programmieren kann und komische hochgeruestete bunte `Entwicklungsumgebungen' verwendet die im Hintergrund JIT-Compilen und dann lustige Wellenlinien unter kaputten Code malen wird man mit langsamerer Hardware nicht gluecklich.

Das ist leider ein generelles Problem. Zum einen kam bei den meisten Entwicklern noch nicht an dass es nicht mehr wie frueher regelmaessig hoeher getaktete CPUs gibt die dann den gewuenschten Performance-Schub bringen. Sondern dass man sich beim Programmdesign eben richtig Gedanken machen muss welche Teile man parallelisieren kann um von aktuellen Prozessorarchitekturen zu profitieren.

Zum anderen gibt es fuer die Entwickler die das eingesehen haben keine geeigneten Werkzeuge. POSIX Threads sind eine riesen Katastrophe, das ist kein Wunder dass es nur wenig Software gibt die das verwenden will, und noch weniger die das richtig hinbekommt. Der Thread-Wrapper in Qt ist schon etwas angenehmer, aber leider mies dokumentiert. Auch bei anderen Loesungen die ich kenne geht ein Grossteil der verwendeten Zeit darauf zu schauen dass sich die Thread-Implementation korrekt verhaelt. Bevor da nicht was passiert werden Anwendungen mit sinnvoll genutztem Multithreading nicht im Mainstream ankommen.

Bei Serversoftware hast Du zu einem grossen Teil die gleichen Tasks, die nur fuer verschiedene Benutzer parallel ausgefuehrt werden muessen um das auf mehrere Cores zu verteilen.

Bei Endanwendungen musst Du dagegen schauen wie Du den Task selbst auf verschiedene Cores bekommst. Daraus ergibt sich dann auch deutlich komplexeres Locking wegen mehr geteilten Speicherbereichen und anderen Resourcen, komplexere Wartebedingungen, etc.

Klar, auch bei Serveranwendungen gibt es Teile bei denen ein Task auf mehrere Cores verteilt wird, aber ich bekomme meistens schon einen guten Performancegewinn wenn man nur die Teile die ganz klar parallelisierbar sind auch auf mehrere Cores wirft.

Fuer die komplexeren Teile hast Du dann -- genau wie z.B. Photoshop -- Entwickler die mehr Erfahrung haben als der durchschnittliche GUI-Bastler und die Thread-APIs halbwegs beherrscht bekommen.

Mich wuerde mal interessieren wieviel Prozent der Abstuerze bei Multithreadinganwendungen auf falsches Locking zurueckgehen -- ich wuerde wetten dass das nicht unerheblich ist. Stillstehende Anwendungen aufgrund konkurrierender mutexes seh ich oft genug.

Zu POSIX Threads hab ich 2005 mal eine Kleinigkeit geschrieben: http://bwachter.lart.info/blog/article,134/

Datenbanken hatte ich bei obiger Betrachtung ausgeklammert -- damit man das performant hinbekommt braucht man deutlich mehr als Threads zu beherrschen.

Aber mal davon abgesehen -- was hat man noch auf dem Server das wirklich komplexe Parallelisierung braucht? HTTP, IMAP, J2EE-Kram, -- alles hat relativ deutlich einzelne Teile die man recht einfach auf mehrere Cores werfen kann, ohne dass sich richtig Gedanken machen muss wie man das verteilt und man das mit dem Locking hinbekommt.

Eine komplexe GUI-Anwendung sauber zu parallelisieren ist da deutlich schwieriger.

Beispiel Bildbearbeitung (genauer: Bildbetrachter, da ich daran aktuell rumspiele): Beim Oeffnen eines Verzeichnisses macht es Sinn darinliegende Bilder vorzuskalieren und zu cachen, und Thumbnails zu generieren. Auf mehreren Cores. Ich muss jetzt die Skalierungsthreads loslaufen lassen, bei jedem Thumbnail der GUI signalisieren dass das fertig ist und angezeigt werden kann, wenn zu einem Bild gesprungen wird das noch nicht skaliert wird das mit hoher Prioritaet reinpacken, bei Veraenderung der Fenstergroesse die Bilder neu skalieren, darauf achten dass ich nicht zu viel Speicher brauche, etc.

Das ist jetzt noch ein ziemlich einfacher Fall, Groessenordnungen von den Problemen entfernt die man hat wenn man bei Photoshop Graphikoperationen parallelisieren will -- und mit heutigen Tools nicht ohne reichlich Planungsaufwand machbar. Bei der ersten Implementation duerfte man auch ziemlich sicher eine Handvoll Deadlocks einbauen.

Ein einfacher Graphikviewer laesst sich mit modernen Toolkits mal eben an einem Nachmittag bauen (http://bwachter.lart.info/projects/aardview/). Will man obiges hat man ein komplexes Projekt.

Damit das in Mainstreamanwendungen ankommt muessen die Toolkits fuer Multithreading das bieten was sie inzwischen fuer GUI-Abstraktion koennen. Der Programmierer muss z.B. nur noch kennzeichnen welche Daten zwischen Threads geshared werden, und das Toolkit macht dann transparentes Locking.

Mein Punkt hier war nicht dass das mit GUI nicht geht -- mein Punkt ist dass der Durchschnittsentwickler damit ueberfordert ist, bzw. zu wenig Erfahrung hat um das in vernuenftiger Zeit hinzubekommen. Genauso wie der Entwickler der einen performanten IMAP-Server baut vermutlich erstmal wenig Erfolg beim Bau einer performanten relationalen Datenbank hat wird der durchschnittliche GUI-Entwickler eine ordentliche multithreaded GUI-Anwendung nicht hinbekommen.

Die aktuellen Threading-APIs sind noch relativ nahe an den ersten groesseren Versuchen mit dem Thema, und relativ `low level' -- Windows Threads und POSIX Threads schenken sich da auch nicht viel. Die beiden sind sich aehnlich genug dass man mit wenigen ifdefs in einem Stueck Code beides unterstuetzen kann (Habe dafuer leider keinen Beispielcode, da nicht OpenSource). Solange die Hauptarbeit dann darauf liegt sich darum zu kuemmern dass die Threads das tun was man will wird das nichts. Ich muss als Programmierer so unterstuetzt werden dass ich in aehnlicher Zeit wie aktuell eine Anwendung bauen kann, und das Toolkit mit meinen Hinweisen fuer bestimmte Codeteile relativ transparent entscheidet ob das jetzt parallel ausgefuehrt werden kann, oder eben nicht.

Mir ist gerade eingefallen dass Kristian Koehntopp dazu auch mal was geschrieben hat: http://blog.koehntopp.de/archives/2285-Skalierung-in-die-Breite.html#extended

Ich kenne die GIMP-Entwickler nicht. Was genau meinst Du mit dieser Frage?

`GIMP has limited multi-threading support. All plug-ins run as separate processes, and I believe much of the preview rendering is a separate process (and GIMP spends a lot of time here). However, GTK (the graphics library GIMP uses) is not thread safe and therefore the display functions all have to be from within the same process.'

Ich behaupte mal wenn es einfacher waere Threads zu verwenden wuerde man das bei GIMP sicher spueren.

Dass man meistens nur einen Thread hat der GUI zeichnen darf ist btw. weit verbreitet, auch bei Qt ist das so. Das Anwendungsdesign wird dadurch nicht einfacher.

Ich habe mir das Plugininterface grob angeschaut, es spricht meines Erachtens nichts dagegen Plugins (IIRC sind Filter groesstenteils Plugins?) mit Threads zu bauen -- allerdings muss sich der Pluginauthor dann komplett um das Threadmanagement kuemmern. Wie toll das bei aktuellen Werkzeugen ist habe ich oben beschrieben. Das, in Verbindung damit dass die Komplexitaet des Moduls vervielfacht wird und jede Menge Code fuer jedes Modul dupliziert wird duerfte dazu fuehren dass die meisten Entwickler keine Lust haben die Zeit fuer den Unterschied zwischen `kann man gut nutzen' und `ist extrem performant und nutzt mehrere Cores' reinzustecken, wenn sie denn dazu ueberhaupt in der Lage sind. Ich habe zumindest schon Plugins von nicht sonderlich fitten Programmierern gesehen -- die Einstiegshuerde ist auch nicht sonderlich hoch.

Wenn die Leistungsfähigkeit des Rechners nicht mehr das wichtigste Kriterium ist, wie wäre es dann mit der Öko- und Sozialbilanz? Die Initiative pcglobal beschäftigt sich damit. Die haben auch, vor allem für Großeinkäufer, einen Einkaufsleitfaden erstellt.