design-frage "ergebniss-cache"

[Treb]

folgendenes problem :

ich habe eine klasse

class FFT
{

Vector<double> calc(const Vector<double>& in);
}

und dazu ein paar Merkmalsextraktoren

class FeatureExtractor
{
virtual Vector<double> calc_feature(const Vector<double>& in) = 0;
}

bisher hat nur einer der Merkmalsextraktoren die FFT berechnet,
und ich habe die FFT als Komposition in diesen Merkmalsextraktor eingefügt

doch nun wird wohl ein weiterer die FFT berechnen, und zwar
"vom selben input-vector!!!"

ich wollte nun FFT als singleton nach sowas wie FFT_Server umbauen,
und die ergebnisse dann cachen, hat jemand schonmal sowas programmiert?

Also man stellt dann anfragen an den Server für die Berechnung, und die FFT klasse schaut im internen cache nach, ob das Ergebniss schon vorliegt,
und berechnet gegebenenfalls neu ...

[Jester]

Prinzipiell ist sowas kein Problem. Die Frage ist nur, ob es sich lohnt. Berechnest Du denn wirklich sooo oft vom gleichen Vektor die FFT, dass es sich lohnt das zu cachen?

[Treb]

die sache ist, das es einfacher ist,
die berechnung der FFT innerhalb der benutzenden klassen zu ändern,
als das ganze Interface abzuändern und die FFT Werte als Parameter
mitzugeben,
was dann noch dazu führen würde, das das interface hässlich wird,
weil einige feature-extractors die fft nicht brauchen ...

[hustbaer]

Ich denke es wäre hier evtl. hilfreich etwas mehr über die eigentliche Anwendung zu erfahren.

Ansonsten, also ganze allgemein... würde ich einen Cache eher als eine Notlösung ansehen. Wenns anders auch geht (ohne zu langsam zu werden), dann würde ich es anders machen.

Bei den meisten Anwendungen sollte es nicht schwer sein einmal berechnete Daten zur späteren Wiederverwendung aufzubehalten.

[Treb]

problembeschreibung :

von der sound-recorder-klasse kommt ein konstanter strom von ton-samples,
dieser wird dann in den sound-pre-processor geleitet, welcher den
stream in stücke hackt (und netterweise auch die lösung für mein problem liefert)

diese stücke werden dann an den feature-extractor geleitet, welcher
auf ihnen merkmale berechnet (die anzahl und art der merkmale ist erst zur
laufzeit bekannt)

manche merkmale brauchen zur berechnung nun die fourier-transformierte des ausschnitts, und manche nicht ...

zB.
MFCC braucht fft,
LPC nicht,
entropie braucht fft,
zero-crossing-rate nicht
...

lösung war :

meine preprocessor-klasse liefert netterweise den time-stamp des sound-stücks mit, ich cache nun in der fft nur eine einzige transformatierte, und überprüfe ob die timestamps der anforderung und dem cache übereinstimmen

für interessierte, es geht um dieses projekt :

www.trebnet.de

alles sehr zeitkritisch, weil in echtzeit berechnet

[hustbaer]

Ich würde das Puffern der FFT Daten entweder im "sound pre prozessor" machen oder im "stream stück".
Es in der FFT Klasse zu machen halte ich für ziemlich unsauber.