On Fri, Oct 13, 2006 at 10:58:53AM +0200, Frank Gerlach wrote:

Wieso fuegst Du nicht einfach ein paar gettimeofday() aufrufe an den kritischen Stellen ein ?

Habe ich schon gemacht (nur daher weiss ich, dass mir der Profiler zu kurze Zeiten angibtt).

Allerdings war die ursprüngliche Aufgabenstellung ja, den Profiler zu benutzten.

Es würde mich schon beruhigen (einfach fürs Weltbild ;) wenn ich wüsste, dass der Profiler und die händische Messung in etwas übereinstimmen.

Marcus

On Fri, Oct 13, 2006 at 04:55:23PM +0200, Tobias Koenig wrote:

Ich würde dir empfehlen valgrind mit dem cachegrind tool zu verwenden. Valgrind emuliert einen kompletten Prozessor, so daß jeder Register/Speicherzugriff mitprotokolliert wird und mittels kcachegrind sogar eine graphische Auswertung gemacht werden kann.

Danke! valgrind habe ich mir gerade mal angeschaut. Ganz nett, scheint im Gegensatz zu gprof keine Funktionen ,,zu vergessen''. Allerdings macht es durch die Emulation den ganzen Prozess extrem langsam.

Für meine ursprüngliche Aufgabe, mal eben schnell herauszufinden, welche Aufrufe innerhalbe einer Funktion die meiste Zeit verbrauchen, sieht es ganz brauchbar aus.

Das Problem, das ich sehe, ist, dass der Code, der mit Profiler/valgrind läuft, wahrscheinlich ziemlich wenig mit dem Code des finalen Binaries (mit eingeschalteter Optimierung) zu tun hat.

Aber damit muss man wohl leben...

Es ist allerdings von Vorteil die Qt4 Bibliothek auch mit Debug-Optionen zu kompilieren um aussagekräftige Diagramme zu bekommen.

Jo, habe ich schon da und werden auch benutzt.

Wie sieht denn dein Code aus? Evtl. kann man auf Ebene der Algorithmen schon bei der Optimierung anfangen?

Problem war, dass ich mir mit Hilfe zweier verschachtelter for-Schleifen alle Pixelwerte eins Bildes angeschaut habe und diese dann jeweils in einen anderen Farbraum transformiert habe.

Dabei habe ich nur QT-Bordmittel verwendet. Aber wie immer im Leben scheint es auch dort wichtig zu sein, zu wissen ,,was die Welt, im Innersten zusammenhält''. EINFACH ist eben nicht immer gleich SCHNELL!

Nochmal danke für deinen Tipp!

Marcus

On Fri, Oct 13, 2006 at 06:07:46PM +0200, Marcus Obst wrote:

On Fri, Oct 13, 2006 at 04:55:23PM +0200, Tobias Koenig wrote:

Hi Marcus,

...

Wie sieht denn dein Code aus? Evtl. kann man auf Ebene der Algorithmen schon bei der Optimierung anfangen?

Problem war, dass ich mir mit Hilfe zweier verschachtelter for-Schleifen alle Pixelwerte eins Bildes angeschaut habe und diese dann jeweils in einen anderen Farbraum transformiert habe.

Hmm, um das durchlaufen scheint man nicht drumherum zu kommen, man könnte aber evtl. einen Teil der Berechnung in Assembler auslagern. So wird in KDE z.B. der SSE Befehlssatz zur Manipulation von Icons verwendet sofern vorhanden. Der Code ist unter http://websvn.kde.org/trunk/KDE/kdelibs/kdefx/kimageeffect.cpp erreichbar.

Dabei habe ich nur QT-Bordmittel verwendet. Aber wie immer im Leben scheint es auch dort wichtig zu sein, zu wissen ,,was die Welt, im Innersten zusammenhält''. EINFACH ist eben nicht immer gleich SCHNELL!

Ich nehme an du hast QImage dafür benutzt... hast du QImage::pixel() oder QImage::scanLine()/bits() zum Zugriff auf die Pixel verwendet? Letzteres dürfte recht schnell sein.

Ciao, Tobias

On Fri, Oct 13, 2006 at 08:11:08PM +0200, Frank Gerlach wrote: Hi,

Hier koennte auch der Intel-Compiler helfen. Dieser kann automatisch SSEx-code erzeugen und automatisch vektorisieren. Bei einem einfachen benchmark mit einer verschachtelten Schleife habe ich hier Beschleunigungen um mehrere 100% gegenueber gcc erzielt. Es gibt eine Eval-Version des Intel-Compilers fuer 2 Wochen.

Klappt das auch auf einen AMD System? Sprich, benutzt der Compiler wirklich nur SSEx Aufrufe oder auch irgendwelche undokumentierten Intel Hacks?

Ciao, Tobias

Frank Gerlach schrieb:

Hier koennte auch der Intel-Compiler helfen. Dieser kann automatisch SSEx-code erzeugen und automatisch vektorisieren. Bei einem einfachen benchmark mit einer verschachtelten Schleife habe ich hier Beschleunigungen um mehrere 100% gegenueber gcc erzielt. Es gibt eine Eval-Version des Intel-Compilers fuer 2 Wochen.

Hast Du dem gcc auch gesagt, dass er SSE verwenden soll?

Hier hält sich der Geschwindigkeitsvorteil in Grenzen, zumal ich bei Intel Probleme mit dem Speichermanagement (Fortran) habe (gcc/gfortran 4.1).

Tobias

On Mon, 16 Oct 2006 09:43:50 +0200 "Frank Gerlach" frankgerlach@gmail.com wrote:

...

Hast Du dem gcc auch gesagt, dass er SSE verwenden soll?

weiss ich nicht mehr genau - aber waere sicher interessant es mal zu testen. Ich galube aber nicht, dass der gcc die gleiche Vektorisierung wie der icc implementiert.

Hier hat der GCC 4 dazu gelernt. Der GCC 3 nicht. Mit ICC compilierte Programme laufen auch auf AMD, nutzen auch dessen SSE2 usw., man muss es ihm nur ggf. sagen.

Im Linux-Mag gasb mal nen Artikel dazu. Fazit: der GCC 4 ist für typischen Code genau so schnell wie der icc (CPU-intensive Bencharmks wie etwa bladeenc)

mfg, Fabian