sehr schneller Rechner gesucht

[Phoenix]

Also, auf den ersten Blick sieht es so aus, als würdest Du das Array von integern NUR dazu verwenden, nullen und einsen zu speichern. Und das auch nur in den ersten 30 Feldern des 100-teiligen Arrays.

Ich würde daher empfehlen anstelle des arrays SN einen einzigen DOUBLE zu verwenden. Der kann mit seinen 4 byte = 32 bit genau die gleiche Datenmenge abbilden wie Du sie verwendest.

UNd dann würde ich die ganzen Operationen bitweise machen und auch die ganzen Vergleiche auf Bitmasken umstellen.
Das hat den *riesigen* Vorteil, dass ein Bitvergleich über 32 byte genau in einer Rechenoperation auf der CPU erledigt werden kann. Derzeit machst Du bei jedem Durchlauf 30 fakultät viele Indizierte Zugriffe auf das array (die jedesmal ein paar rechenoperationen verwenden), was mit 30 einzelnen Bitweisen operationen zu machen wäre.

Das spart Dir faktoren an Zeit.

[fkerber]

Von zeichnen sehe ich hier allerdings auch nichts, oder?

[Phoenix]

Der Canvas - pixel-teil da unter den 'bit' vergleichen und vor der langen zuweisungsreihe in der mitte versteckt

[Namenloser]

Double? Du meinst wohl longint. Double ist float.

[Assarbad]

Zitat von Phoenix:

Ich würde daher empfehlen anstelle des arrays SN einen einzigen DOUBLE zu verwenden. Der kann mit seinen 4 byte = 32 bit genau die gleiche Datenmenge abbilden wie Du sie verwendest.

Does not compute.

Double ist 64bit breit, Single ist 32bit.

ms-help://embarcadero.rs_xe/vcl/System.Double.html

Zitat:

Defines a double-precision floating-point number.

Double is a double-precision real type that is represented with floating-point notation. The range of the Double type is from 5.0 x 10^-324 through 1.7 x 10^308. The size of a Double value is 8 bytes.

NB: du hast allerdings dahingehend recht, daß ein Double verlustlos beliebige 32bit-Integerwerte darstellen kann (also ohne Rundungsverluste).

[divBy0]

Bin erst nächstes Wochenende wieder zu Hause, könnte deinen Code dann mal mit einem Intel Core i7-970 (3.2GHz, 6.4GT/s, 12MB) testen.

Allerdings läuft dein Code ja nur auf einem von sechs Kernen.

[mikeslash]

Oh, ich hätte gedacht, dass sich das automatisch auf alle Kerne verteilt. Kann man es denn auch so programmieren, dass alle Kerne genutzt werden?

Gruß, Mike

[Medium]

Pro Thread ein Kern --> Aufteilung auf mehrere parallel arbeitende Threads. Nicht jedes Problem ist allerdings parallelisierbar, und bei nicht jedem ist die Eignung offensichtlich, bzw. muss sie erst hergestellt werden. Ich hab jetzt leider nicht mehr die Wachheit das in diesem Fall zu überblicken . Sobald der Fall gegeben ist, dass Teilergebnisse nicht von der Gesamtheit voriger Ergebnisse abhängen, ist Parallelisierung in der Regel möglich. Automatisch passiert in diese Richtung aber nix.

[himitsu]

OK, selbst wenn Double keine 4 Byte ist ... Double und Bit-Operationen paßt ebensowenig.

Wenn schon, dann Integer/LongInt.


Also das Integer-Array auf einen Integer und Bit-Operationen runterkürzen,
und dann kann man bestimmt auch die ganzen Fließkomma-Operationen auf einen Int64 beschränken.
Zumindestens sollten sich so bestimmt locker mal über 90% des Codes und damit von der Laufzeit einsparen lassen.

[Assarbad]

Zitat von himitsu:

OK, selbst wenn Double keine 4 Byte ist ... Double und Bit-Operationen paßt ebensowenig.

Wenn schon, dann Integer/LongInt.

Stimmt.

Zitat von himitsu:

Also das Integer-Array auf einen Integer und Bit-Operationen runterkürzen,

Das wüßte ich gern genauer. Was soll das bringen? Die kleinste Einheit die der Prozessor modifizieren kann ist: ein Byte. Was soll es da also bringen (außer Platzeinsparung) das zu tun? Wir reden hier ja nicht von mehreren Megabyte mit einem Array von Einsen und Nullen und einer Beschränkung der verfügbaren RAM-Menge bei der uns das juckt (siehe "Programming Pearls" und mehrere der darin beschriebenen Probleme). Schneller ist es jedenfalls unter normalen Umständen schon deshalb nicht, weil eine 32bit-CPU schneller ist mit einem Befehl eine Null oder Eins an eine Speicherstelle zu schreiben als in mehreren Operationen genau das Bit zu modifizieren was man eben gerade modifizieren wollte (was auch an eine Speicherstelle schreibt aber zusätzlich AND, OR oder NOT braucht, je nach Fall ... von den bedingten Sprüngen nicht zu reden) ...

Wenn du jetzt mit einer revolutionären Methode aufwarten kannst mit der man Bits sehr einfach als Array benutzen kann, ohne Laufzeitverluste, dann interessiert das sicher nicht nur mich

Einfügung: Unbenommen der obigen Aussagen, scheint hier ein Fall gegeben zu sein wo man in der Tat mit Bitmasken arbeiten könnte. Und dann sollte der Laufzeitverlust sich in der Tat umkehren. Sorry, das hatte ich übersehen.

Zitat von himitsu:

und dann kann man bestimmt auch die ganzen Fließkomma-Operationen auf einen Int64 beschränken.
Zumindestens sollten sich so bestimmt locker mal über 90% des Codes und damit von der Laufzeit einsparen lassen.

Daß Gleitkommaoperationen langsamer sind - und nichts anderes sagst du - ist seit einigen Jahren nur noch ein schönes Märchen. Das war in der Tat so, bspw. als FPU und CPU noch in verschiedenen Sockeln steckten usw. - inzwischen aber nicht mehr. Es hängt zwar vom Einzelfall und benutzten Operationen ab, aber eine verallgemeinernde Aussage wie die, daß Gleitkommaoperationen generell langsamer seien, ist nicht haltbar.