Benchmark Algorythmus

[theomega]

Hallo Leute,
ich suche eine Berechnung die extrem CPU lastig ist, aber nicht stark auf den RAM geht. Je simpler der Algorythmus desto besser, es soll nacher ein Benchmark für bestimmte Prozessoren werden, also fertige Programme bringen mir nichts. Ob delphi oder anderes ist mir egal, wird nacher eher nicht in Delphi gemacht werden können.
Also, wer kann was bieten? Was ist mit Primzahlentests? Sieb des Archimedes z.b. geht extrem auf den Ram, also nichts für mich!

Danke für ein Paar hilfen!
TO

[Dax]

Das hier müsste extrem auf die CPU, aber kaum aufs RAM gehen:

Delphi-Quellcode:

var i: Integer;
begin
  i := 10;
  Randomize;
  while SomeCondition do
    i := (i + Random(i) * Random(i)) mod High(Integer);
end;

[theomega]

oki, ich muß noch folgendes sagen: es sollten auf Zeit reproduzierbare ergebnisse sein, so dass ich sagen kann, CPU 1 bekommt das in x sekunden hin und CPU 2 in y sekunden. Ich geh doch recht in der Annahme, dass sobald Zufall ins Spiel kommt die Sache und damit auch die Ergebnisse recht zufällig werden und meinen Anforderungen nicht entsprechen?

[Dax]

Der Zufallsanteil darin ist nur gut, um die CPU auszulasten, sie braucht trotzdem ungefähr gleich lange für N Iterationen dieser Schleife. Für Benchmarks, die Zeit messen, nimmst du eben eine for-Schleife mit z.B. 10.000.000 Iterationen und misst die Zeit- ;-)

[MisterNiceGuy]

Damm probiers mal mit Fibonacci ;) Müsste irgendwo inner Math.pas drinstehen, das geht auch ganzschön auf die CPU!

[theomega]

fibonacci ist nicht geeignet, weil die zahlen zu schnell zu groß werden, mir stehen auf den zu verwendeten Prozessoren nur max. 32bit Interger zur verfügung. Trotzdem danke, aber hat noch jemand noch gute Vorschläge?

[theomega]

*Push* niemand ne Idee, also eine ohne Random und wo man mit 32 bit auskommt?

[Alexander]

Was mir gerade so einfällt ist der BubbleSort. Aber so Rechenlastig ist der nun auch wieder nicht...

[tommie-lie]

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.

[ibp]

Zitat:

Zitat von theomega

*Push* niemand ne Idee, also eine ohne Random und wo man mit 32 bit auskommt?

schreib dir doch eine eigene berechnungsmethode!

oder

ping doch mal hagen [negaH] an vielleicht hat der eine Idee!