LUT für float
-
Das wolltest du vielleicht sagen, aber für mich war es nicht verständlich.
Für mich kam nur rüber "Speicher is langsam".
-
ProgChild schrieb:
hustbaer schrieb:
Das legt nahe dass du das "Speicherzugriff ist sehr sehr viel langsamer" auf das Lesen und Schreiben der zu konvertierenden Daten beziehst.
Und das ist genau kein Problem. Um dabei vom Speicher ausgebremst zu werden muss man sich schon ordentlich ins Zeug legen.Nö. Brauchst nur bei einem 2D-Array die falsche Reihenfolge der Indizes verwenden.
Ja, klar, mit ausreichend Dummheit kann man alles kaputt machen.
-
Danke für eure Kommentare.
Leider verstehe ich nicht alles was ihr schreibt, auch wird mir nicht klar, ob es einen Konsens gibt, ob ein LUT performanter wäre oder eben nicht.
Also grob überschlagen habe ich wohl mit mindestens 100 000 000 Multiplikationen der Art
(int32_t)(float (zwischen 0.0 und 1.0) * 0xffff)und ich suche eine möglichst effiziente Methode das möglichst systemunabhängig zu realisieren.
Viele Grüße mickey
-
Ich denke es gibt einen Konsens bezüglich LUT, und zwar dass es in deinem Fall keinen Sinn macht.
Etwas systemunabhängiges und gleichzeitig schnelles kann ich dir nicht anbieten, aber ich sehe kein Problem, wenn man eine systemunabhängige Lösung implementiert (die halt so schnell ist wie man sie hinbekommt), und dann für die wichtigsten Systeme eine spezifische, schnellere Variante. z.B. mit SSE.
-
Danke.
(Auch wenn mich das Ergebnis wundert, also, dass ein Lookup nicht schneller ist als eine Rechnung...)
Viele Grüße mickey
-
Wenn der LUT klein genug ist und/oder die Berechnung kompliziert genug ist, dann ist ein Table-Lookup ja auch schneller.
In deinem Fall ist der LUT aber gross und die Rechnung extrem einfach.
-
Danke.
