Wie programmiere ich performant? Literaturtipps?

[....]

Pointer Zugriff auf Array sollte schneller sein, als mit Index.

Und wenns Hardware abhängig sein darf
http://de.wikipedia.org/wiki/SIMD (SSE Zeugs)

[hustbaer]

Wenn m_delayLine ein std::vector ist könntest du mal versuchen nen einfachen Pointer draus zu machen. Je nach STL Implementierung macht das durchaus nen Unterschied.

Und natürlich immer nur den Release Build profilen.
Source-Code beim Debuggen/Profilen bekommst du im Release-Build indem du einfach im Release-Build auch die Erzeugung von Debug-Infos einschaltest. Hat bei mir zumindest immer funktioniert.

[asm-freak]

soerenP schrieb:

Für etwa den selben Algorithmus (vom Syntheseprinzip her) schafft es ein anderes Plugin anstatt mit 30% CPU-Auslastung mit sowenig dass ich die Anzeige nicht lesen kann. (2-3%)

das könnte in assembler geschrieben worden sein. möglicherweise solltest du das mit deinem code auch tun (zumindest die flaschenhälse).

[Gast]

Ich bin jetzt nicht ganz durch den Code durchgestiegen, aber das memmove() hört sich nicht gerade optimal an. Wieviel bytes werden da immer verschoben? Vielleicht eine Ringpuffer-Struktur anwenden?

Edit: bzgl. dem anderen Plugin: "Optimiert" es vielleicht gar am Konzept? Also z.B. IIR statt FIR?

[hustbaer]

@soerenP: wie gross ist denn der verwendete LUT? Wenn der recht gross ist (> 1/2 1st Level Cache oder sogar > 2nd Level Cache) kann das schon gröber bremsen.

@Tim: er schreibt 5 bzw. 13 Samples, wobei ein Sample ein float ist. Wären also 20 bzw. 52 Bytes. Bei 52 bytes könnte IMO ein Ringpuffer etwas schneller sein, bei 20 eher nicht.

Allerdings würde ich den Puffer umdrehen und memcpy statt memmove verwenden.

p.S.: oder gleich ne for() Schleife - memcpy ist entweder intrinsic (=langsam weil "rep movsb") oder aber ein unnötiger function call + test auf quadword alignment etc. (=unnötiger overhead für so kleine blöcke).

[soerenP]

Tim schrieb:

Edit: bzgl. dem anderen Plugin: "Optimiert" es vielleicht gar am Konzept? Also z.B. IIR statt FIR?

Ich denke nicht. Ich habe es mal mit IIRs ausprobiert. Die verschieben die Phase in einer Weise, dass man starke verstimmungen erhält. (sowohl zwischen zwei Tönen, als auch im Ton selber (Inharmonizität)) Bei Firs kann man die Verzögerung des Kernels bis zu einem bestimmten Punkt im Delay ausgleichen und alles ist gestimmt und harmonisch.

hustbaer schrieb:

@soerenP: wie gross ist denn der verwendete LUT? Wenn der recht gross ist (> 1/2 1st Level Cache oder sogar > 2nd Level Cache) kann das schon gröber bremsen.

@Tim: er schreibt 5 bzw. 13 Samples, wobei ein Sample ein float ist. Wären also 20 bzw. 52 Bytes. Bei 52 bytes könnte IMO ein Ringpuffer etwas schneller sein, bei 20 eher nicht.

Allerdings würde ich den Puffer umdrehen und memcpy statt memmove verwenden.

p.S.: oder gleich ne for() Schleife - memcpy ist entweder intrinsic (=langsam weil "rep movsb") oder aber ein unnötiger function call + test auf quadword alignment etc. (=unnötiger overhead für so kleine blöcke).

Der LUT ist recht groß (20 "metrische" KiloByte), damit ich linear interpolieren kann. Lieber intelligenter interpolieren als großen LUT?
Den memmove/Ringpuffer teste ich nochmal...
Lädt der denn den ganzen Lut in den Cache? Ich sollte mich mal mit Computerarchitektur beschäftigen, glaub ich.
Vielen Dank für die zahlreichen Vorschläge!
Grüße
Sören

[Gast]

hustbaer schrieb:

@Tim: er schreibt 5 bzw. 13 Samples, wobei ein Sample ein float ist. Wären also 20 bzw. 52 Bytes. Bei 52 bytes könnte IMO ein Ringpuffer etwas schneller sein, bei 20 eher nicht.

Oh, den Kommentar in dem die 5/13 steht habe ich irgendwie... ignoriert

[soerenP]

ZU den LUTs:
Ich hab die mal auf 500 mal 4 Byte geschrumpft. Hat nicht wirklich was gebracht...
Grüße
Sören

[Ponto]

soerenP schrieb:

ZU den LUTs:
Ich hab die mal auf 500 mal 4 Byte geschrumpft. Hat nicht wirklich was gebracht...
Grüße
Sören

Hast du nicht mal eine vollständige Testimplementierung, die man mal laufen lassen kann? Alles ist mit Dummywerten gefüllt, nur der langsame Kernalgorithmus nicht?

[soerenP]

Ponto schrieb:

Hast du nicht mal eine vollständige Testimplementierung, die man mal laufen lassen kann? Alles ist mit Dummywerten gefüllt, nur der langsame Kernalgorithmus nicht?

???
Versteh ich nicht? Das Ding läuft komplett als VST-Instrument. Nur zu langsam um das einzubauen, was ich noch vor habe, oder um es auch für andere Leute interessant zu machen. Was lässt dich denn denken, dass da noch nichts läuft? Und was meinst du mit "Alles ist mit Dummywerten gefüllt, nur der langsame Kernalgorithmus nicht?"
Gruß
Sören

[Ponto]

soerenP schrieb:

Ponto schrieb:

Hast du nicht mal eine vollständige Testimplementierung, die man mal laufen lassen kann? Alles ist mit Dummywerten gefüllt, nur der langsame Kernalgorithmus nicht?

???
Versteh ich nicht? Das Ding läuft komplett als VST-Instrument. Nur zu langsam um das einzubauen, was ich noch vor habe, oder um es auch für andere Leute interessant zu machen. Was lässt dich denn denken, dass da noch nichts läuft? Und was meinst du mit "Alles ist mit Dummywerten gefüllt, nur der langsame Kernalgorithmus nicht?"
Gruß
Sören

Ich meine, dass ich nur vom Lesen deines Quellcodes keine Laufzeitprobleme sehen kann. Etwas, was man lokal laufen lassen kann, wäre besser. Und da will man nicht das ganze Plugin haben, sondern die langsame Routine auf irgendwelchen Dummydaten.

[soerenP]

Ahhhh, entschuldige. "Hast nicht mal?" kann man auf zwei Arten interpretieren, ich hab die falsche gewählt.
Ich mach morgen mal was fertig, vielen Dank für deine Hilfe!
Sören

[gcc fan]

Performant programmiert wird mit -O3.

[soerenP]

Hab aber nur 02, was mach ich jetzt?
Man könnte mal probieren, was der gcc dazu sagt, war aber immer ein bisschen zu blöd die Geschichte ans laufen zu bekommen. Ich denke aber nicht, dass da Wunder zu erwarten sind, oder?