Motorola zu Intel konvertieren ....
-
@tntnet okay, dass ein messen nicht viel sinn macht, wenn dauernd threadwechsel passieren und das einlesen nur sehr wenig zeit in anspruch nimmt ist klar. aber ich wollte hat darauf hinaus, dass die lut immer extra wieder in den cache gepackt wird...egal
@net warum darf denn der optimierer nicht eingreifen. verstehe ich irgendwie nicht. es geht ja schon um die endgeschwindigkeit. optmieren finde ich da sogar notwendig. gerade bei nichtoptimierten debugfähigem code wird ja die maskensache stark benachteiligt.
jenz
-
jenz schrieb:
@net warum darf denn der optimierer nicht eingreifen. verstehe ich irgendwie nicht. es geht ja schon um die endgeschwindigkeit.
weil wir dann unsere 3 verfahren (lut/mask/loopless) einfach nicht vergleichen können. mann sollte z.b. von einer einfachen von-neumann architektur ausgehen, bei der jeder befehl einzeln geholt und abgearbeitet wird. und alles nacheinander. jede optimierung o.ä. verfäscht das ergebnis. manche compiler z.b. erkennen gewisse codeteile (pattern mathing schimpft sich das, glaub' ich) und ersetzen die komplett gegen was schnelleres. das geht also so nicht...
-
net schrieb:
jenz schrieb:
@net warum darf denn der optimierer nicht eingreifen. verstehe ich irgendwie nicht. es geht ja schon um die endgeschwindigkeit.
weil wir dann unsere 3 verfahren (lut/mask/loopless) einfach nicht vergleichen können. mann sollte z.b. von einer einfachen von-neumann architektur ausgehen, bei der jeder befehl einzeln geholt und abgearbeitet wird. und alles nacheinander. jede optimierung o.ä. verfäscht das ergebnis. manche compiler z.b. erkennen gewisse codeteile (pattern mathing schimpft sich das, glaub' ich) und ersetzen die komplett gegen was schnelleres. das geht also so nicht...
um von einem verfälschten ergebnis sprechen zu können, muss erst einaml feststehen, was gemessen werden soll. die algorithmische komplexität aller vorgestellten verfahren ist gleich, es ist also keiner dieser algorithmen prinzipiell schneller als ein anderer, es kommt auf die konkrete anwendung an. und wenn es letzlich auf die performance einer konkreten anwendung in einer konkreten umgebung geht, hat es keinen sinn, den algorithmus unter bedingungen (sprich ohne optimierungen) zu testen, unter denen dieser am ende nicht eingesetzt werden wird. zudem ist die transformation von sourcecode in ausführbaren code ja kein eindeutiger prozess, jeder ausführbare code, der zum selben ergebnis führt, ist gleichermaßen gültig. dem code eines nicht optimierten builds größere signifikanz einzuräumen als dem eines optimieren builds erscheint mir recht sinnfrei.
-
camper schrieb:
dem code eines nicht optimierten builds größere signifikanz einzuräumen als dem eines optimieren builds erscheint mir recht sinnfrei.
du bist auch so ein spielverderber
man braucht doch gewisse rahmenbedingungen um solche vergleiche anstellen zu können (eine 'referenzplattform', die darf nix am ursprünglichen code ändern), sonst vergleicht man äpfel mit birnen. auch wenn alle algos von der komplexität gleich sind, das 'wie' macht den geschwindigkeitsunterschied aus...
-
apropos "recht sinnfrei":
for (s=0; s<32; s++) { if (read_bit() == 1) result |= table[s]; }mit
table[s]= (1<<s);