Öh, schon vorbei? Mist, ich war ne Weile im Stress. Ich fand's bisher sehr interessant. Aber sollte das nicht ein Workshop zum sehr interessanten Thema Optimierung werden?

Gerade dazu wäre aber doch noch so viel zu sagen. Wer hat den schnellsten Core geschrieben, und warum war das der schnellste? Ist der Algorithmus schon am Ende (Mariani-Silver-Rekursion etc.)? Hat jemand mal Shark bemüht? Hat jemand mal die Pipeline-Stalls gezählt? Und was kann man dagegen machen? Und wie viel bringt sowas in der Regel? Warum nicht mal über Multiprocessing für die Dual-Maschinen nachgedacht? Gerade das wäre mit wenigen Zeilen Code zu machen. Was ist mit AltiVec (falls einem single-precision genügt)? Gerade ein Mandelbrotalgorithmus ist ein geeignetes Beispiel. Nur ein geringer Teil des Programms müsste hier vektorisiert werden, um die Performance beachtlich zu steigern.

Da ist doch noch locker ein Faktor 10 drin. Echtzeitzoom-Kamerafahrt wär doch mal was Neues. Ich sach: Warum jetzt schon resümieren?

edit: Ach, was red ich. Faktor 15 oder mehr würd mich auch nicht wundern. Auf zu Workshop I/b!

Tja, hier ist der Thread von den Workshop Ergebnissen:
Auf geht's, Ihr feigen Hunde!

3 oder 4 Leute von - ich weis nicht wieviele was machen wollten - haben Ihre Ergebnisse vorgestellt.
Das ist nun mittlerweile schon fast zwei Wochen her.
Wir haben alle noch auf eine OpenGL Version gehofft, kam aber nix...
Naja, vieleicht geht ja noch was...

Ansonsten fand ich den Wotkshop interessant, weil mein erster Kontakt mit Mac und Grafik. War mein zweites Cocoa Programm ueberhaupt, von daher sehr informativ.
Ich wuerde bei einem weiteren mitmachen.

so long

Also ich fands doch ziemlich interessant und sehe den Workshop auch noch nicht als beendet an. Wir müssten dann vielleicht mal in so eine Art Review einsteigen. Welches Coding wurde verwendet etc. Wie kann man es optimieren und so. Wir sollten im neuen Jahre damit einsteigen. Ich denke für einige ging es doch zu schnell, daß die Cracks (Danke nochmal!!!!) gleich mit Ihren Lösung vorgesprescht sind. Beim nächsten Mal würde ich eher ein stückweises Herangehen bevorzugen. Das "Erste Mal" sehe ich eher so als Generalprobe und man muss nun weiter dranbleiben und mehr auf die Vorgehensweise achten. Natürlich soll das auch alles im Rahmen bleiben, da wir ja alle anderweitig sehr angespannt sind. Leider!!! Ich würde mir wünschen, daß man beim nächsten Mal mehr auf modulares Programmieren eingeht. Also wie füge ich am sinnvollsten meiner App neue Funktionen hinzu, ohne jedesmal gleich die App komplett umproggen zu müssen. Sowas.

Also nochmal danke an alle!!!


UPDATE: Was mir noch aufgefallen ist. Der Ansatz, daß gleich eine App rauskommen muss ist doch eher fraglich, da man sich zu sehr im Ergebnis einengt. Was meint Ihr?

Original von kay
UPDATE: Was mir noch aufgefallen ist. Der Ansatz, daß gleich eine App rauskommen muss ist doch eher fraglich, da man sich zu sehr im Ergebnis einengt. Was meint Ihr?

Das kommt eben drauf an, was das Ergebnis sein sollte. Ich hatte das so verstanden, dass möglichst viele Forumsteilnehmer etwas über Softwareoptimierung lernen. Und das ist eine wichtige Aufgabenstellung in der Softwareentwicklung: Die App steht in etwa, es fehlt jedoch die optimale Performance. Und es ist ja nicht so, dass die App selbst das Ziel ist, sondern der Kenntnisgewinn durch die Teilnahme am Fortschritt des Projekts, und sei es nur durch Lesen der Beiträge.

In diesem Fall wäre es vielleicht effizienter gewesen, sogar eine simple Basisimplementation für alle vorzugeben, an der dann weitergearbeitet und rumgespielt werden kann bezüglich Optimierung. Dass jeder sich erstmal eine solche Anwendung schreiben musste, hat sicher einige abgeschreckt -- aber war für einige Fortgeschrittene sicher auch sehr aufschlussreich.

Wichtig wäre auf jeden Fall, mehr über die Änderungen zu kommunizieren, Schritt für Schritt. Das ist beim Erstellen des Grundgerüsts der Cocoa-Anwendung vielleicht nicht so spannend gewesen. Aber ab dem Punkt der Optimierungsmaßnahmen ist es das vielleicht schon. Jeder, der eine wesentliche Verbesserung am gemeinsamen Code vorschlägt, sollte gut erklären, warum er was vorhat. Dann kann man das diskutieren und schließlich übernehmen oder überdenken.

Auf jeden Fall muss mehr durch das Forum kommuniziert werden, und es wäre vorteilhaft, wenn der Workshopleiter immer im Besitz des aktuellen, den Konsens darstellenden Codes ist -- des Hauptzweiges, sozusagen. Den kann sich jeder herunterladen.

Natürlich ist das eine Einschränkung, das Ergebnis (App/Funktionsumfang) ist "vorgegeben", wenn auch nicht im Vorhinein. Aber ich denke, dass man dann gemeinsam mehr davon hat. Viele gute Workshops im Netz (und kommerzielle Schulungen auch) laufen ja in der Art "du fängst hiermit an, dann machst du das und dann das deswegen und dann dies deshalb und dann kommt das raus". Und trotzdem lernt man was, weil man es selbst eingebaut hat. Und bei diesem Workshop hier kann man ja sogar mitdiskutieren. Und es hält einen ja niemand davon ab, zu experimentieren und vom Pfad abzuweichen, so weit man will.

Ich finde, wenn man sich aus den drei oder vier vorliegenden Implementationen auf eine Referenz einigt oder eine zusammenstellt, hat man eine hervorragende Ausgangsbasis für den 2. Teil des Workshops.

dass möglichst viele Forumsteilnehmer etwas über Softwareoptimierung lernen

Was bedeutet Softwareoptimierung? Fuer mich bedeutet es nicht, dass die App so schnell wie moeglich laeuft. Fuer mich muss das ein Komprimiss aus Schnelligkeit des codes, Lesbarkeit und Struktur sein.

Die App steht in etwa, es fehlt jedoch die optimale Performance

Darum alleine kann es jedoch nicht gehen. Wenn ich optimale Perfromance haben will, dann muss ich in Assembler coden. Es muss eher auch um darum gehen, zu verstehen, wie der Compiler arbeitet, was er wie optimieren kann, wie Funktionen und Klassen-Methoden in umgesetzt werden, usw.


so long

Original von asrael

dass möglichst viele Forumsteilnehmer etwas über Softwareoptimierung lernen

Was bedeutet Softwareoptimierung? Fuer mich bedeutet es nicht, dass die App so schnell wie moeglich laeuft. Fuer mich muss das ein Komprimiss aus Schnelligkeit des codes, Lesbarkeit und Struktur sein.

Einverstanden. Den Begriff Optimierung kann man weit fassen. Ich hatte den Workshop so verstanden, dass es um Performanceoptimierung geht. Die Kunst besteht hier darin, nicht nur die Geschwindigkeit im Auge zu behalten, sondern auch den Optimierungsaufwand in Grenzen zu halten und das Design der Software nicht zu verhunzen. Die Frage ist: Wie viel Optimierung bringt wie viel, wann hört man auf, wodurch wird der Code hässlich? Dafür muss man ein Gefühl bekommen. Es bringt nichts, alles auseinanderzufrickeln, wenn man am Ende nur 20% Geschwindigkeit rausholt. Aber wir reden hier von ganz anderen Potentialen.

Original von asrael

Die App steht in etwa, es fehlt jedoch die optimale Performance

Darum alleine kann es jedoch nicht gehen. Wenn ich optimale Perfromance haben will, dann muss ich in Assembler coden.

Nee, man muss nicht in Assembler coden, um zu optimieren. Wie gesagt, halte ich es für durchaus möglich, ein Vielfaches an Performance aus den bisherigen Implementationen rauszuholen, und das völlig ohne sich die Finger schmutzig zu machen. Sprich: Der iMac von meinem Papi mit der optimierten Implementation rechnet die neuesten Dual-G5s mit der bisherigen Implementation locker in die Ecke. Damit kann man sich doch nicht zufrieden geben, wenn das Ziel des Workshops Optimierung ist.

Original von asrael
Es muss eher auch um darum gehen, zu verstehen, wie der Compiler arbeitet, was er wie optimieren kann, wie Funktionen und Klassen-Methoden in umgesetzt werden, usw.

Absolut richtig. Aber nichtmal das kam bisher zur Sprache. Wenn man sich den Assembler-Output (z.B. von M.A.X) mal anschaut, dann sieht man, dass die Prozessor-Pipelines total leer sind. Der Prozessor muss für jeden Takt, den er rechnet, erstmal drei Takte Däumchen drehen, bis er das Ergebnis weiterverarbeiten kann (Latenzzeiten). Ganz offensichtlich muss man ihm mehr parallel zu rechnen geben, und das geht auch ohne Assembler. [edit: Hier kann der Compiler endlich zeigen, was er kann, ob man schon früh einen Register-Überlauf hat oder nicht und wie windschnittig das Scheduling ist.] Bringt sicher Faktor 2, mindestens. Multiprocessing: leicht zu machen, das Design der Anwendung leidet so gut wie nicht: Nahezu Faktor 2. AltiVec: Wahrscheinlich nochmal fast Faktor 4. Hier leidet das Design auf unterer Ebene vielleicht ein wenig. Aber es ist doch interessant zu sehen, wie viel eigentlich. Dafür muss man ein Gefühl bekommen. Dazu kommen vielleicht noch algorithmische Änderungen, die auch nicht so schwer einzubauen sind, und nochmal beachtliche Steigerung bringen können. Das schöne ist: all diese Faktoren multiplizieren sich. Und plötzlich sind ganz andere Anwendungen möglich, oder man "spart" durch zwei Tage Arbeit tausende Euro an Hardwarekosten.

Original von blutfink
Absolut richtig. Aber nichtmal das kam bisher zur Sprache. Wenn man sich den Assembler-Output (z.B. von M.A.X) mal anschaut, dann sieht man, dass die Prozessor-Pipelines total leer sind. Der Prozessor muss für jeden Takt, den er rechnet, erstmal drei Takte Däumchen drehen, bis er das Ergebnis weiterverarbeiten kann (Latenzzeiten).

Um ehrlich zu sein hatte ich mir sowas schon gedacht.

Vielleicht wollen wir uns jetzt wenn wir viele Vorschläge haben, auf eine App festlegen und diese dann gemeinsam optimieren. Wenn man jetzt (so ala Projekt2003) wieder ein Sourceforge Projekt undter dme hut der Forums und des Wikis aufmacht, dann könnte man hier auch richtig gut gemainsam dran pfeilen. Vielleicht sollte man auch die option der wahl des berechnungs-cores geben, der dann halt gezielt angesprochen werden kann. Sowas würde mich sehr ansprechen udn wich würde da auch aktiv mitmischen.

Sagt ma was....