Re: Benchmark Algorythmus
8. Jan 2005, 09:23
Was hast du denn gegen Dax' Vorschlag?
Wenn auf der Zielplattform ein Zufallsgenerator zur Verfügung steht, der die Zufallszahlen synchron erzeugen kann (also für jede Zahl die gleiche Zeit braucht, z.B. einen Takt, weil er sie aus einem Pool holt), dann ist gegen sowas eigentlich nichts einzuwenden. Du rechnest ja nur mit den Random-Werten, und eine Integer-Berechnung benötigt immer gleich viele Taktzyklen, egal ob von den 32bit nun sieben oder siebzehn auf 1 gesetzt sind.
Wo wir aber auch schon bei der nächsten Frage sind: Was für eine Architektur isses denn? Du fragst uns nach einem Rechenlastigen Benchmark für eine spezialisierte Architektur, verrätst aber nicht, welche es ist. Wenn die Architektur z.B. massiv viele Pipelines einsetzt, sollte man versuchen alle Pipelines um jeden Preis auszulasten und viele Sprünge zu vermeiden, damit nicht jedesmal die Pipelines neu befüttert werden müssen. Hat der Prozessor nur eine Pipeline, spielt das natürlich keine Rolle und man kann sich auch auf Schleifen konzentrieren, sofern die Architektur keine geisteskranke Sprungvorhersage hat. Hat sie eine, muss man sich nach ihr richten. Und wie schnell ist das Speicherinterface im Vergleich zum Prozessor? Darf man den Speicher ruhig für Daten benutzen, oder ist man auf die zahl der Register beschränkt? Wie sieht's mit synchronem Cache aus? Wie groß ist er? Gibt's überhaupt welchen, oder gibt's nur langsamer getakteten Cache? Wieviel langsamer getaktet ist der?
U.u. müsste man direkt Assembler-Beispiele nehmen, denn man weiß sonst nie, welche Variablen der Compiler auf den Stack legt, und wie groß der Stack sein darf, damit er in den schnelleren Cache ausgelagert werden kann.
|