"High speed Modifikation" für "look up tabelle" gesucht, embedded processing!

[lovepulse]

Hallo zusammen,

ich habe in mein embedded system eine kleine Look up Tabelle eingebaut.
Diese habe ich wie im Quellcode unten realisiert, schön nach Vorschrift.

Ich will die Zugiffszeit sowas von aufschrauben dass die CPU vor Leistung kotzt. Sorry, es handelt sich in Wirklichkeit um eine LUT mit 1024 Werten im 16 Bit Format.
Wichtiger Hinweis:
a.) ==> Eingangswerte habe den gleichen Bereich wie Ausgangswerte
b.) ==> Eingangswerte und Ausgangswerte sind natürliche Zahlen im Intervall [0,1024]

Anfrage: Wie kann ich hier die hohe Kunst des Speichermapping anwenden?

#include <stdio.h>
#include <stdlib.h>
// High-Speed "look up table" für embedded

int main(int argc, char *argv[])
{
    // Eine Reihe von Eingangswerten (unsigned short): Intervall [0 bis 9] ....  
    // Liefert durch einen Aufruf der LUT entsprechende Ausgangswerte (unsigned short)
    // das geht in C ganz einfach:

    unsigned short i, ergebnis;
    const unsigned short lut[]={5,7,9,1,500,2,9000,1001,8976,4445};

    for(i=-10;i<100;i++) { // uuups, na sowas ein Fehler in der Schleife. Der sollte abgefangen werden
    // messe die Zeit für den zugriff ab hier in nanosekunden
                         ergebnis=lut[i];
                         printf("\nErgebnis %d = %d",i,ergebnis);
    // stoppe die Zeit und gebe sie aus

    } // for Schleife Ende
    // messe die Zeit für den zugriff ab hier in nanosekunden

  system("PAUSE");	
  return 0;
}

[ten]

was meinste mit speichermapping?
btw: ich glaub' schneller kriegstes nur noch in assembler hin...

[lovepulse]

Damit meine ich dass die Eingangswerte direkt Speicheradressen sind. Das geht ans Eingemachte, I know. Der Trick in der Performancesteigerung liegt darin "branching-calls" zu vermeiden...

ten schrieb:

was meinste mit speichermapping?
btw: ich glaub' schneller kriegstes nur noch in assembler hin...

[Gast]

Vielleicht solltest du dein Problem etwas genauer beschreiben und weniger mit Fachbegriffen um dich werfen, dein Code oben hat imho wenig mit deiner Frage zu tun.

[lovepulse]

Meine Frage ist:
a.) Kann ich den Code noch schneller machen?
b.) Kann ich durch Pointer mehr Leistung rausholen?

TactX schrieb:

Vielleicht solltest du dein Problem etwas genauer beschreiben und weniger mit Fachbegriffen um dich werfen, dein Code oben hat imho wenig mit deiner Frage zu tun.

[ten]

lovepulse schrieb:

a.) Kann ich den Code noch schneller machen?
b.) Kann ich durch Pointer mehr Leistung rausholen?

guck' dir das disassembly an und versuch' mal compiler-optimierungen 'für speed' einzuschalten.
kannst auch probieren, vor die variablen ein 'register' zu schreiben.
vor dem code alle interrupts ausschalten und danach wieder ein.
nimm die passenden datentypen (wenn das'n 16-bitter ist, dann mach' alles 16-bittig).
aber immer schön den asm-code angucken, den der compiler ausspuckt und vergleichen.
wenn du meinst, du kannst besseren asm-code als der compiler, dann schreib ihn, und vergleich die laufzeit mit dem code vom compiler.
guck' nach, ob der prozessor 'erweiterte befehle' hat, die dein programm unterstützen könnten (und die dein compiler womöglich nicht verwendet).
such auf der webseite des herstellers nach application notes zum laufzeitverhalten, wie man speed rausholen kann, wie's pipelining funktioniert etc.
zum messen: digitalen ausgang togglen und oszilloskop dranhalten (bei so kleinen programmen reicht das meistens).
takt erhöhen, quartz tauschen, pll höherstellen etc. aber darauf achten, dass die taktfreauenz nicht ausserhalb der spezifikation ist

[lovepulse]

Danke schön.

hey, hier ist einer der auch Ahnung von E-Technik hat. Not so bad. Ich hab meine Frage bezogen auf die Zugriffszeit mal den Jungs von AnalogDevices rübergeschoben. Die werden mir schon sagen wie man den Blackfin aufdrehen kann. BTW: Taktfrequenz ist schon am oberen Anschlag. Die Kerne laufen am Limit...

ten schrieb:

lovepulse schrieb:

a.) Kann ich den Code noch schneller machen?
b.) Kann ich durch Pointer mehr Leistung rausholen?

guck' dir das disassembly an und versuch' mal compiler-optimierungen 'für speed' einzuschalten.
kannst auch probieren, vor die variablen ein 'register' zu schreiben.
vor dem code alle interrupts ausschalten und danach wieder ein.
nimm die passenden datentypen (wenn das'n 16-bitter ist, dann mach' alles 16-bittig).
aber immer schön den asm-code angucken, den der compiler ausspuckt und vergleichen.
wenn du meinst, du kannst besseren asm-code als der compiler, dann schreib ihn, und vergleich die laufzeit mit dem code vom compiler.
guck' nach, ob der prozessor 'erweiterte befehle' hat, die dein programm unterstützen könnten (und die dein compiler womöglich nicht verwendet).
such auf der webseite des herstellers nach application notes zum laufzeitverhalten, wie man speed rausholen kann, wie's pipelining funktioniert etc.
zum messen: digitalen ausgang togglen und oszilloskop dranhalten (bei so kleinen programmen reicht das meistens).
takt erhöhen, quartz tauschen, pll höherstellen etc. aber darauf achten, dass die taktfreauenz nicht ausserhalb der spezifikation ist

[ten]

lovepulse schrieb:

...Die werden mir schon sagen wie man den Blackfin aufdrehen kann. BTW: Taktfrequenz ist schon am oberen Anschlag. Die Kerne laufen am Limit...

vielleicht brauchste ja auch nix zu tun? hab' mal das data sheet von dem teil runtergeladen. scheint 'ne ziemliche rakete zu sein...

btw: optimieren lohnt sich nur, wenn du 100%ig weisst, dass der programmteil eine echte bremse ist, sonst kann's leicht nach hinten losgehen...