LUT für float
-
hustbaer schrieb:
Und auch der L2 Cache ist nicht SO lahm wie du uns hier weismachen willst (AFAIK 10 cycles Latenz beim i7).
Ja. Er versucht eine einzelne Gleitkomma-Multiplikation wegzuoptimieren... Wie lange braucht die nochmal?
-
ProgChild schrieb:
hustbaer schrieb:
Und auch der L2 Cache ist nicht SO lahm wie du uns hier weismachen willst (AFAIK 10 cycles Latenz beim i7).
Ja. Er versucht eine einzelne Gleitkomma-Multiplikation wegzuoptimieren... Wie lange braucht die nochmal?
Ja. Und?
Wahrscheinlich hast du eh sehr viele Daten zu verarbeiten, was nahe legt, dass nicht der Prozessor, sondern der Speicher zu langsam ist.
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.Nichts anderes hab ich geschrieben.
Und selbst auf die LUT bezogen: Faktor 10 oder um was es sich da reissen wird ist für mich nicht "sehr sehr viel langsamer". Eher "viel langsamer". Aber das ist natürlich Ansichtssache.
-
Shade Of Mine schrieb:
hustbaer schrieb:
Der Speicher ist heutzutage eigentlich sehr sehr flott bei sequenziellen Zugriffen.
Bei so einer LUT hast du aber Random Access ueber Page-Grenzen hinweg.
Aber klar, sequentielle Zugriffe sind enorm schnell, was teuer ist sind aber die page faults...
Page-Grenzen sind vollkommen egal.
Page-Faults hast du auch nur beim 1. Durchlauf des Algorithmus', danach wird das OS die Seiten wohl hoffentlich nicht sofort auslagern.Aber mal davon abgesehen dass es darum geht was gerade im Cache ist und was nicht: dass Random-Access böse ist (weil langsam) ist mir schon klar. Nur dass ich die Darstellung von ProgChild einfach für übertrieben bzw. falsch halte.
Vielleicht hab' ich ihn auch nur falsch verstanden, aber sein Beitrag liest sich für mich so, als wolle er behaupten, dass der Algorithmus so-oder-so vom Speicherzugriff limitiert sein wird, ganz egal ob mit oder ohne LUT, weil der OP so viel Daten umwandeln will.
Und das ist nunmal Unfug^3.
-
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.
hustbaer schrieb:
Nur dass ich die Darstellung von ProgChild einfach für übertrieben bzw. falsch halte.
Vielleicht hab' ich ihn auch nur falsch verstanden, aber sein Beitrag liest sich für mich so, als wolle er behaupten, dass der Algorithmus so-oder-so vom Speicherzugriff limitiert sein wird, ganz egal ob mit oder ohne LUT, weil der OP so viel Daten umwandeln will.
Nein. Meine Aussage war, dass er mit eine Tabelle eine einzelne Gleitkomma-Operation nicht schneller bekommt.
-
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.
