Geschwindigkeit ...
Wir diskutieren gerade bei identi.ca über Rechnergeschwindigkeiten.
Wenn es nicht um das Spielen oder Videoschnitt geht, kann man meiner Meinung nach mit jedem aktuellen Betriebssystem seine Arbeit tun (siehe auch den Brief an einen Windowsnutzer).
Gleiches gilt für mich in besonderem Masse für die Geschwindigkeit aktueller Rechner. Auch dort kann man mit jedem heute handelsüblichen Rechner vermutlich auf Jahre hinaus seine Arbeit erledigen. Manchmal schlägt natürlich (wie auch bei Minimalismus) das Paretoprinzip zu. Da kauft man sich den schnellsten verfügbaren Rechner, um zwei oder drei Mal in der Lebenszeit des Gerätes in die Nähe der Leistungsgrenzen zu kommen.
Witzig ist, dass dieser Art des "Mehr-PS-habens" noch so willig gefrönt wird. Ich bin der festen Meinung, dass man richtig viel Speicher haben sollte, der ist wirklich durch nichts zu ersetzen, allerdings, kratzt die "Durchblutung" (der Refresh) von zu viel Speicher auch dazu, dass die Akkulaufzeit schlechter ist als mit weniger Speicher.
Es gibt also für alles ein "für und wieder".
Ich persönlich liebäugele gerade mit einem Gerät, dem ThinkPad Edge, das dann auch langsamer sein wird als mein jetziger Rechner. Aber, für das was ich tue - Web, E-Mail, Texte schreiben und Entwicklung - brauche ich nicht den schnellsten Rechner.
Wenn es nicht um das Spielen oder Videoschnitt geht, kann man meiner Meinung nach mit jedem aktuellen Betriebssystem seine Arbeit tun (siehe auch den Brief an einen Windowsnutzer).
Gleiches gilt für mich in besonderem Masse für die Geschwindigkeit aktueller Rechner. Auch dort kann man mit jedem heute handelsüblichen Rechner vermutlich auf Jahre hinaus seine Arbeit erledigen. Manchmal schlägt natürlich (wie auch bei Minimalismus) das Paretoprinzip zu. Da kauft man sich den schnellsten verfügbaren Rechner, um zwei oder drei Mal in der Lebenszeit des Gerätes in die Nähe der Leistungsgrenzen zu kommen.
Witzig ist, dass dieser Art des "Mehr-PS-habens" noch so willig gefrönt wird. Ich bin der festen Meinung, dass man richtig viel Speicher haben sollte, der ist wirklich durch nichts zu ersetzen, allerdings, kratzt die "Durchblutung" (der Refresh) von zu viel Speicher auch dazu, dass die Akkulaufzeit schlechter ist als mit weniger Speicher.
Es gibt also für alles ein "für und wieder".
Ich persönlich liebäugele gerade mit einem Gerät, dem ThinkPad Edge, das dann auch langsamer sein wird als mein jetziger Rechner. Aber, für das was ich tue - Web, E-Mail, Texte schreiben und Entwicklung - brauche ich nicht den schnellsten Rechner.
Trackbacks
. miradlo bloggt  am : Notebook, Laptop, Schläppi, Rechner…
Vorschau anzeigen
17″ Laptop an Utes Arbeitsplatz Aktuell ist mein Hauptrechner ein Fujitsu Siemens Amilo XI 1554, mehr zu den Daten schrieb ich ja schon mal. Die Leistung der Kiste ist teilweise noch immer nicht so schlecht, aber vieles wird doch allmählic...
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ute am :
Hmpf, ich bin unschlüssig, das Ding soll schon einige Zeit halten, wenn ich was Neues kaufe. Ich mag nicht, womöglich vor Lebenszeitende eines Notebooks wegen fehlender Leistung wechseln müssen.
Ich denke ein Lenovo ist aus Stabilitätsgründen schon mein Ziel und 17" ist einfach Muss, ich kann sonst nicht arbeiten.
Aber da gibt's je nach Händler immernoch zahllose Alternativen mit sehr unterschiedlichen Preisen.
Dirk Deimeke am :
Was Du wirklich brauchst, hängt ganz stark mit dem zusammen, was Du machst. Beispiel: Bei 99% Textverarbeitung, ist es schon wirklich völlig egal, was das restliche Prozent ausmacht, auch wenn das die HyperDuperVideobearbeitung ist.
Bei Lenovo musst Du mittlerweile auf die Grafikkarte aufpassen, es sollte Intel oder Nvidea sein.
Dirk Deimeke am :
Usul am :
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 ...
Dirk Deimeke am :
Usul am :
Dirk Deimeke am :
Aufgrund von optischen Gimmicks wird aber ein grosser Teil der Prozessor- und Grafikkartenleistung gar nicht zur Bewältigung der Aufgaben benutzt.
Ich kenne Entwickler, hallo Roland, die lassen eine komplette Entwicklungsumgebung auf ihrem EEE PC laufen, inklusive aller Abhängigkeiten, wie Datenbank und ähnlichem.
Wenn wir da etwas tiefer einsteigen, zeigt sich, dass Speicher wesentlich wichtiger ist als ein schneller Prozessor, da sowohl Datenbank als auch Webserver überwiegend im Leerlauf laufen und selbst im Betrieb mit einem Nutzer kaum Last verursachen. Auch hier lässt sich durch Tuning von Datenbank-Parametern und Webserver-Einstellungen eine Menge Spielraum erzeugen.
Wenn kein Build-Rechner vorhanden ist, macht ein stärker ausgestatter Prozessor bei compilierten Sprachen sicher Sinn, das stelle ich nicht in Frage, aber auch hier lässt sich durch eine hohe Modularisierung viel Zeit sparen. Es wird dann nicht immer das komplette Projekt durchcompiliert.
Leider ist es so, dass niemand mehr optimiert, wenn versucht wird alle Performance-Engpässe durch Hardware zu erschlagen. Viele Entwicklerrechner sind besser ausgestattet als die Server, auf denen die Anwendungen später laufen sollen, was sehr häufig zu sehr langen Optimierungsphasen führt.
Bernd Wachter am :
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.
Dirk Deimeke am :
Danke dafür!
Bernd Wachter am :
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.
Dirk Deimeke am :
Bernd Wachter am :
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/
Dirk Deimeke am :
Und gerade Bildbearbeitung bietet sich aufgrund der Datenfülle nun wirklich an, ebenfalls parallelisiert zu werden. Dass die Programmierung des ganzen einige Fallstricke birgt, ist mir klar. Aber, dass es deutlich komplexer als bei einer Serveranwendung ist, glaube ich nicht (aber "glauben" heisst nicht "wissen").
Danke für den Link auf den Artikel.
Bernd Wachter am :
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
Dirk Deimeke am :
Meiner Meinung nach wird GIMP nicht von Ottodurchschnittsentwicklern entwickelt, oder etwa doch.
Bernd Wachter am :
`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.
Dirk Deimeke am :
Die meiste Rechenzeit wird meiner Meinung nach nicht für die Darstellung, sondern für die Filter verbraten oder für Manipulationen, die das ganze Bild betreffen. Und das wäre Meinung nach sehr wohl parallelisierbar.
Bernd Wachter am :
Dirk Deimeke am :
Thomas Koch am :
Dirk Deimeke am :