Laufzeitoptimierung eines Consolen-Programms

[stpolster]

Hallo,
auf dem Forum "Matheplanet" läuft gerade eine Art Wettbewerb, bei dem es um möglichst schnelle Berechnung von langen Zahlen geht. Die Berechnung hat eigentlich wenig Sinn, es geht nur um Geschwindigkeit.
25 Millionen mal werden zwei lange Zahlen multipliziert, dann unter eine Grenze reduziert und das Ergebnis mit 2^128 div und mod geteilt.
Nachdem ich mit Delphi 5 im Vergleich zu anderen Programmiersprachen nicht ganz so gut war, habe ich es jetzt auf Console umgestellt und es wurde etwas schneller. Es nutzt die Langzahlroutinen von Wolfgang Ehrhardt.

Delphi-Quellcode:

program matheplanet_projekt2;
{$APPTYPE CONSOLE}
uses SysUtils,
  mp_base, mp_types;

var
  a, b, soll, sub, produkt, filter: mp_int;
  Time1: TDateTime;
  nn, nad, nsu: integer;

begin
  Writeln('hyperG-Problem');
  Writeln;
  mp_init6(a, b, soll, sub, produkt, filter);
  nad:=0;
  nsu:=0;
  mp_read_decimal_astr(a,'170141183460469231731687303715884105757');
  mp_read_decimal_astr(b,'170141183460469231731687303715884105703');
  mp_read_decimal_astr(soll,'57896044618658097711785492504343953926634992332820282019728792003956564819968');
  mp_read_decimal_astr(sub,'11111111111111111111111111111111111111111111111111111111111111111111111111111');
  mp_read_decimal_astr(filter,'340282366920938463463374607431768211455');
  time1 := now;
  for nn:=1 to 25000000 do begin
     mp_mul(a,b,produkt);
     while mp_cmp_mag(produkt,soll)<0 do begin
      mp_add(produkt,sub,produkt);
      inc(nad);
     end;
     repeat
      mp_sub(produkt,sub,produkt);
      inc(nsu);
     until mp_cmp_mag(soll,produkt)>0;
     mp_shr(produkt,128,a);
     mp_and(produkt,filter,b);
    end;
  Writeln(FormatDateTime('SS:ZZZ', now - Time1));
  Writeln(mp_adecimal(produkt));
  Writeln(nad);
  Writeln(nsu);
  Writeln;
  Writeln('Programmende mit ENTER');
  mp_clear6(a, b, soll, sub, produkt, filter);
  readln;
end.

Das Ergebnis ist

13:325
47306219819553867530681020915755484915944251665601 642944764215683054098939729
83884810
25000000

Da ich gern die "Ehre von Delphi" verteidigen würde, suche ich noch nach Ideen zur Beschleunigung. Bei mir läuft die Routine in etwa 13,3 Sekunden durch.
In der ZIP-Datei sind auch die nötigen Quelltexte von Wolfgang Erhardts Routinen.

Danke für evtl. Ideen
Steffen

[himitsu]

Schau auch mal nach dem DEC Math vom Delphi Encryption Compendium.

Im Forum und inzwischen auf GitHub sollte sich das finden lassen.


[ADD]
Ich glaub das war im Part II drin, oder einzeln.
Beim Michael lag nur Part I rum. http://backups.geheimniswelten.de/ww.../DEC/index.htm

[stpolster]

Danke.
Sehe ich mir an.

[Andreas13]

Hallo Steffen,
wenn ich Deinen Code mit XE5 kompiliere, dann brauche ich auf meinem PC knapp 7,4 Sekunden, während Dein Original matheplanet_projekt_console.exe von https://matheplanet.de/index.php etwa 9,4 Sekunden benötigt. Das ist leider nur ca. 21 % schneller.

Die Benutzung der neuesten (= letzten) Dateien von Wolfgang Ehrhardt vom November 2018 und das Hinzufügen der Zeile

Delphi-Quellcode:

Winapi.MMSystem.timeBeginPeriod(1);

bringen lediglich noch eine weitere 1/10 Sekunde. Mein bestes Ergebnis war 7,28 Sekunden. Weitere Optimierungsmöglichkeiten in Deinem Code habe ich noch nicht entdeckt.
In den extrem konzentrierten Code von Wolfgang Ehrhardt reinzupfuschen halte ich für ziemlich gefährlich... :duck:

Summa summarum: Ein noch neuerer Compiler könnte eventuell einen weiteren Geschwindigkeitsvorteil bringen. :gruebel:

[Andreas13]

Mit Lazarus (FreePascal 3.2.2) kompiliert braucht es knapp 16 Sekunden...:oops: :(

[stpolster]

Vielen Dank für den Test und die deutlich kleineren Zeiten.
Ich hatte es mit dem vor Jahren freien RAD Studio 10 versucht. Da kamen zumindest bei mir schlechtere Zeiten heraus.
In Wolfgang Ehrhardts Code etwas zu ändern, würde mir nicht in den Sinn kommen.

Ist es möglich, mir die EXE zu senden ?

Danke Steffen

[Andreas13]

Hallo Steffen,
die gezipte EXE ist im Anhang!

[stpolster]

Zitat:

Zitat von Andreas13 (Beitrag 1526385)

Hallo Steffen,
die gezipte EXE ist im Anhang!

Vielen Dank.

[Andreas13]

Sorry, es war die falsche Version, die zwar sehr schnell war, aber falsch gerechnet hat... :oops:

Hier ist die korrekte Fassung :-D

[stpolster]

Nochmals Danke.
Ich sehe es mir sofort an.

[Olli73]

Da du "nn" in der Schleife nicht nutzt, sollte sie rückwärts laufen (wegen Optimierung; prüfen auf 0 ist schneller). Wenn dem nicht so ist, kannst du selber "downto" verwenden.

[stpolster]

Danke. Probiere ich aus.

[Olli73]

Also ich habe mal von Debug auf Release umgestellt und die E/A-Prüfung abgeschaltet. Die Bereichsüberprüfung und Überlaufprüfung waren dann bereits abgeschaltet. Dies hat bei mir die Laufzeit von 20,x auf 11,x Sekunden verkürzt.

Ein

Delphi-Quellcode:

for nn:= 24999999 downto 0 do begin

hat dann nochmals eine Sekunde gebracht.

[Olli73]

64 bit bringt dann nochmals 2,5 Sekunden.

[Andreas13]

Zitat:

Zitat von Olli73 (Beitrag 1526391)

Also ich habe mal von Debug auf Release umgestellt und die E/A-Prüfung abgeschaltet. Die Bereichsüberprüfung und Überlaufprüfung waren dann bereits abgeschaltet. Dies hat bei mir die Laufzeit von 20,x auf 11,x Sekunden verkürzt.
Ein

Delphi-Quellcode:

for nn:= 24999999 downto 0 do begin

hat dann nochmals eine Sekunde gebracht.

Welche Delphi-Version benutzt Du Olli?
Denn bei XE5 haben Deine Vorschläge bei mir keinen meßbaren Zeitgewinn gebracht. Anscheinend optimiert XE5 bereits nach Deinen Empfehlungen. Allerdings läuft das 64-Bit-Prgramm bei mir 1 Sekunde schneller und braucht nur noch 6,23 Sekunden.

[Olli73]

Habe mit XE3 getestet.

Habe einen Core i7-4770, 16 GB RAM und SATA-SSD.

[Andreas13]

Danke, Olli.:-D
Ich verwende einen PC mit:
AMD Ryzen 7 PRO 4750G with Radeon Graphics
8 Cores, 3.580 MHz, 64 GM RAM,
Windows 10 auf WD - SATA-SSD, 1 TB
Eigene Anwendungen: Samsung SSD 980 PRO, 1 TB

[himitsu]

PS: CUDA, OpenCL und Co, aber ob es dann noch Delphi/Pascal wäre?

[Renate Schaaf]

Das größte Problem ist m.E., dass das Programm im Wesentlichen auf nur einem Prozessor läuft. Mit threads könnte man da sicher was rausholen.

[stpolster]

Danke für alle Hinweise.
Multithreading ist in den Bedingungen des Tests ausdrücklich "verboten", wobei ich auch nicht wüsste, wie man bei diesem Problem etwas parallel laufen lassen könnte.

Im Moment ist ein Rust-Programm mit 0,4 s Laufzeit das Schnellste.

Code:

// needs:
// cargo add ethnum;
use ethnum::U256;
use std::time::Instant;
fn main() {
    let ten = &U256::new(10);
    let two = &U256::new(2);

    let soll = two.pow(255);
    let z = two.pow(128) - 1;
    let sub = ten.pow(77) / 9;

    let mut a = two.pow(127) + 29;
    let mut b = two.pow(127) - 25;
    let mut c = U256::new(0);

    let mut nad = 0u64;
    let mut nsu = 0u64;

    let watch = Instant::now();

    for _nn in 0..25_000_000 {
        c = &a * &b;
        while &c < &soll {
            c += &#8834;
            nad += 1;
        }
        while &c > &soll {
            c -= &#8834;
            nsu += 1;
        }
        a = &c >> 128;
        b = &c & &z;
    }
    let duration = watch.elapsed();
    println!("c {:?}", c);
    println!("ad={:?} su={:?} in {} s", nad, nsu, duration.as_secs_f64());
}

Wie das möglich ist? Ich weiß es nicht. Zumal ich nicht einmal wusste, dass es ein "Rust" gibt. :(

[Andreas13]

Rust kenne ich zwar auch nicht, aber aus dem Quellcode geht hervor, daß es für die Berechnung einen "eingebauten" Datentype U256 verwendet, also einen vorzeichenlosen 256-Bit-Integer, der für die Hardware optimiert zu sein scheint.

Wolfgang Ehrhardt's mp_int hat dagegen eine variable Länge und daher einen größeren Overhead.

Ich habe versucht lebenswichtige Überprüfungen wie mp_not_init(..), mp_error<>MP_OKAY und MPC_ArgCheck zu deaktivieren: Es hat bei 64-Bit lediglich 0,3 Sekunden gebracht. :cry:

[Andreas13]

Ich finde, daß die Aufgabenstellung & der Geschwindigkeitswettbewerb von https://matheplanet.de/index.php etwas unfair ist, denn der Wertebereich von U256 umfaßt genau 77 Stellen. Und der Sollwert

Delphi-Quellcode:

mp_read_decimal_astr(soll,'57896044618658097711785492504343953926634992332820282019728792003956564819968');

hat genau 77 Ziffern.

Würde man die Zahlen lediglich um einige Stellen verlängern, wären solche Programmiersprachen, die maximal U256 bieten, von vornherein aus dem Rennen. Hingegen kann Wolfgang Ehrhardt's mp_int bis mehrere Millionen Stellen & mehr mithalten. :-D :thumb:

[himitsu]

Die MatheLib von Hagen war hochoptimiert, zwar in mehr Bezug auf Kryptographie.
Für das Projekt eines Einzelnen, waren seine Funktionen in vielen Belangen auf einem hohen Niveau, verglichen mit anderen Produkten großer Anbieter weltweit.
Und da dort auch mit festen Größen gerechnet wird ....



Ich glaube mich zu erinnern, dass entweder DEC-Math und/oder eine andere Mathe-Lib, die mal hier in der DP genannt wurde, auch einen festen Integer-Typen dieser Größe hatte, neben dem dynamischen Typen.

In dem Rust, sind die Constanten sub und damit auch ten doch auch irgendwie nutzlos?



Wisst ihr, was pervers total bescheuert wäre?
Diese Aufgabe auf die wohl unoptimierteste MatheLib loszulassen. :lol:
https://www.delphipraxis.net/135569-...athelib-_.html

Erstmal hatte sich SmartScreen bei der Demo geweigert, aber dann
2 ^ 255 = 57.896.044.618.658.097.711.785.492.504.343.953.926 .634.992.332.820.282.019.728.792.003.956.564.819.9 68
die ersten 77 Stellen nach nur 4,5 Millisekunden





Es gibt/gab doch auch Sprachen, welche speziell für mathematische Berechnungen optimiert wurden?
Die müssten hier doch enorm im Vorteil sein.

Delphi TurboPascal Pascal wurde ja ursprünglich mehr als Lehrsprache entwickelt und seit Delphi/Borland mehr in Richtung Datenbanken und GUI.

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1526404)

Es gibt/gab doch auch Sprachen, welche speziell für mathematische Berechnungen optimiert wurden?

FORTRAN

Zitat:

Zitat von himitsu (Beitrag 1526404)

Delphi TurboPascal wurde ja ursprünglich mehr als Leersprache entwickelt und seit Delphi/Borland mehr in Richtung Datenbanken und GUI.

Delphi TurboPascal :-D

[himitsu]

Zum Glück hattest'e das doppelte ee nicht auch noch entdeckt. :oops:


Also irgendwie rechnet das Rust doch was total Anderes?

Code:

while &c < &soll {
  c += &#8834;

Delphi-Quellcode:

while c < soll do begin
  c := c + sub;  // c := c + Power(ten, 77) div 9;

[Uwe Raabe]

Zitat:

Zitat von Andreas13 (Beitrag 1526400)

Wolfgang Ehrhardt's mp_int hat dagegen eine variable Länge und daher einen größeren Overhead.

Dazu sagt Wikipedia:

Zitat:

Arbitrary precision is used in applications where the speed of arithmetic is not a limiting factor, or where precise results with very large numbers are required.

Zitat:

Zitat von Andreas13 (Beitrag 1526401)

Würde man die Zahlen lediglich um einige Stellen verlängern, wären solche Programmiersprachen, die maximal U256 bieten, von vornherein aus dem Rennen. Hingegen kann Wolfgang Ehrhardt's mp_int bis mehrere Millionen Stellen & mehr mithalten.

Bei Benchmarks ist es aber allgemein so, dass Performance vor Flexibilität geht - ansonsten bräuchte man keinen Benchmark. Da geht es insbesondere auch nicht um schönen oder wartbaren Code, wobei ich persönlich den Code in einer Lösung mit Rudy's BigNumbers auch schöner finde - ist halt auch wieder langsamer.

Delphi-Quellcode:

program matheplanet_projekt3;
{$APPTYPE CONSOLE}
uses
  System.SysUtils,
  Velthuis.BigIntegers;

var
  a, b, soll, sub, produkt, filter: BigInteger;
  Time1: TDateTime;
  nn, nad, nsu: integer;

begin
  Writeln('hyperG-Problem');
  Writeln;
  nad:=0;
  nsu:=0;
  a := BigInteger.Parse('170141183460469231731687303715884105757');
  b := BigInteger.Parse('170141183460469231731687303715884105703');
  soll := BigInteger.Parse('57896044618658097711785492504343953926634992332820282019728792003956564819968');
  sub := BigInteger.Parse('11111111111111111111111111111111111111111111111111111111111111111111111111111');
  filter := BigInteger.Parse('340282366920938463463374607431768211455');
  time1 := now;
  for nn:=1 to 25000000 do begin
    produkt := a*b;
    while produkt < soll do begin
      produkt := produkt + sub;
      inc(nad);
    end;
    repeat
      produkt := produkt - sub;
      inc(nsu);
    until produkt < soll;
    a := produkt shr 128;
    b := produkt and filter;
  end;
  Writeln(FormatDateTime('SS:ZZZ', now - Time1));
  Writeln(produkt.ToString);
  Writeln(nad);
  Writeln(nsu);
  Writeln;
  Writeln('Programmende mit ENTER');
  readln;
end.

[himitsu]

Hier geht es auch ausschließlich um + , - , shr , and und Größer-/Kleinervergleiche, also um das Einfachste, was geht und wo man praktisch algorithmisch nichts optimieren kann.

Leider kann meine Lib kein binäres AND und SHR, bzw. nicht direkt, da sie durchweg dezimal arbeitet, hat sie Probleme mit 2er-Potenzen, die in ein 10er System nicht rein passen.
Es wäre alles besser, hätten wir 4 Finger, inkl. Daumen.

SHR kann ich ja noch durch eine extrem unoptimale Division ersetzen, aber beim AND müsste ich dann auch in jedem Durchlauf das dreifach umrechnen.

Delphi-Quellcode:

uses
  System.SysUtils, Winapi.Windows, System.Diagnostics,
  StringMatheLib in 'stringmathelib_131\StringMatheLib.pas',
  StringMatheRec in 'stringmathelib_131\StringMatheRec.pas';

begin
  try
    {const}var ten: MatheString := 10;
    {const}var two: MatheString := 2;

    var soll := Power(two, 255);
    var z := Power(two, 128) - 1;
    var sub := Power(ten, 77) div 9;

    var a := Power(two, 127) + 29;
    var b := Power(two, 127) - 25;
    var c := MatheString(0);

    var nad := 64;
    var nsu := 64;

    var watch := TStopwatch.StartNew;

    for var nn := 0 to 25000000 do begin
      c := a * b;
      while c < soll do begin
        c := c + sub;
        Inc(nad);
      end;
      while c > soll do begin
        c := c - sub;
        Inc(nsu);
      end;
      a := c div '340282366920938463463374607431768211456'; //a := c shr 128;
      b := c and z;
    end;
    var duration := watch.Elapsed.TotalSeconds;
    WriteLn('c0', string(c));
    WriteLn('ad=', nad, ' su=', nsu, ' in ', duration:1:8, ' sec');
  except
    on E: Exception do
      WriteLn(E.ClassName, ': ', E.Message);
  end;
end.

[Andreas13]

Zitat:

Zitat von Uwe Raabe (Beitrag 1526414)

Zitat:

Zitat von Andreas13 (Beitrag 1526400)

Wolfgang Ehrhardt's mp_int hat dagegen eine variable Länge und daher einen größeren Overhead.

Dazu sagt Wikipedia:

Zitat:

Arbitrary precision is used in applications where the speed of arithmetic is not a limiting factor, or where precise results with very large numbers are required.

Bei Benchmarks ist es aber allgemein so, dass Performance vor Flexibilität geht - ansonsten bräuchte man keinen Benchmark.[/DELPHI]

Ja, das ist korrekt, Uwe. Die Ausschreibung auf https://matheplanet.de/index.php habe ich erst jetzt gelesen:

Zitat:

...Mich interessierte nun, wie sich der 256 Bit Bereich schlägt.(YMP Code?)
...
Randbedingungen
...
b) Nutzung des gesamten 256 Bit Bereiches bei mul, add & sub, damit nicht abgekürzt werden kann (wenn Zwischenergebnis in den 128 oder 64 Bit Bereich sinkt)...
...

Damit hätte man mit einer MPA-Lösung erst gar nicht antreten sollen: Der Wettbewerb war für Motorräder und nicht für Fahrradfahrer vorgesehen.:-D :zwinker:

[stpolster]

Zitat:

Zitat von Andreas13 (Beitrag 1526421)

Damit hätte man mit einer MPA-Lösung erst gar nicht antreten sollen: Der Wettbewerb war für Motorräder und nicht für Fahrradfahrer vorgesehen.:-D :zwinker:

Aber das Fahrrad ist ein High-Tech-Rad mit einem sehr leistungsstarken Zusatzmotor. :lol:
Delphi + Wolfgang Erhardts Routinen schlagen sich so schlecht nicht.

Da ich nur wenig Ahnung habe, habe ich die Anfangsbedingungen natürlich nicht richtig verstanden. Ist nun mal so.

[Andreas13]

Nein, ganz im Gegenteil: Wolfgang Erhardts Routinen schlagen sich sehr gut! :thumb:
Wir haben eine erneute Bestätigung, daß die MPA-Routinen & Delphi korrekt rechnen (wir sind im "Ziel angekommen" und wurden "nicht disqualifiziert"). Aber wir sind nicht in unserer Gewichtsklasse, sondern weit darüber angetreten, und haben trotzdem gut abgeschnitten: Das erzielte Ergebnis läßt sich also sehen!:thumb: :-D

[Uwe Raabe]

Zitat:

Zitat von Andreas13 (Beitrag 1526424)

Nein, ganz im Gegenteil: Wolfgang Erhardts Routinen schlagen sich sehr gut! :thumb:

Das war auch eigentlich worauf ich hinaus wollte: Obwohl der Ansatz in punkto Performance eher ungünstig ist, kann sich das Ergebnis durchaus sehen lassen.

[himitsu]

MPInt = 4.7 Sekunden auf einem kleinen Schlepptop mit Delphi 11.3 in 64 Bit.

Code:

##### StrMath ####################
c056376183596999899117308588625209953108464105926767074623063990238734463292307
ad=84031 su=25065 in 9.61070060*1000 sec

##### Int256 ####################
c0-5735511060232939254446901397460932042972491126387202754970036519831719797026
ad=3973389 su=5290133 in 7.98520350*10 sec

##### MPInt ####################
c057505664344760038530679973515630121094664952824482015253584348948195539615650
ad=83884813 su=25000001 in 4.84421430 sec

Also dafür, dass ich beim StrMath das AND und SHR durch zwei eine brutal schlimme Division ersetzen mußte (DIV/MOD aus ganz ganz ganz vielen ADD/SUB)
und nicht nur billig einmal ADD/SUB/SHR/AND je Durchgang nutzen konnte, ist es doch fast erstaunlich, dass es damit bloß 9000 Sekunden dauert (knapp 6 Tage).

Schade irgendwie.
Mein MatheString konnte früher mal mit bis 2.14 Milliarden Dezimalstellen rechnen ... jetzt sind es nur noch 1.07 Milliarden (außer man entfernt das böse Unicode)




Ich dachte es wollte AUCH jemand mal die Quellcodes veröffentlichen, nachdem es aufgeräumt wurde, oder so.

https://github.com/MHumm/DelphiEncryptionCompendium
Das sieht immernoch nur nach Part I aus.

Bei mir hab ich nur bei den alten 5.1c und 5.2 den Part II.
und dort leider nur mit den vorkompilierten DCUs für Delphi 5 bis 7 plus deren PAS-Header als Doku (ohne die Implementation).

[himitsu]

DEC Math in aktuellerem Delphi. (es gibt vom DEC Part II bisher ja leider nur die DCU für Delphi 5, 6 und 7 und dazu den Interface-Teil der PAS, als Doku)

DEC Part III .... weiß nur, dass es das geben dürfte, aber was es ist ... keine Ahnung.
DEC Part I kennen ja alle ... das mit den Verschlüsselungen. (inzwischen auch als DEC Lite im GetIt, bzw. voll im GitHub)
Lite, weil es verboten ist gewisse Verschlüsselungstechnologien aus den USA zu exportieren, auch wenn das GetIt-Packet eigentlich aus Deutschland kommt.

Mal wieder ein Delphi 7 installiert
und als erstes versucht, ob sich aus den DCU ein paar OBJ zu erzeugen lassen, welche sich dann in neueren Delphis linken ließen.
Leider klappt das nur aus PAS (sowie auch aus C).



OK, dann leider nun der Weg über eine DLL.


Mir war so, als hätte Hagen den Quellcode an jemand weitergegeben, welcher das noch bissl aufräumen wollte,
weil "so wie es ist" wollte es Hagen nie rausgeben.




siehe https://www.delphipraxis.net/12974-u...stellen-3.html
usw.

[himitsu]

Zitat:

c0= 57 50566 43447 60038 53067 99735 15630 12109 46649 52824 48201 52535 84348 94819 55396 15650
ad=83884813 su=25000001 in 11.24300002 sec

Programmende mit ENTER

* OK, in einem Delphi 7
* mit Codes, die für eine 17 Jahre alte CPU optimiert wurden
* auf einem, 12th Gen Intel Core i7-1260P 2.10 GHz
* und außerdem wurde es nicht direkt für so "einfache" Berechnungen ausgelegt, sondern auf Cryptography und hochkompliziertes Zeugs, wie 'ne Million Stellen von Pi zu berechnen

Delphi-Quellcode:

program DECMathTest;

{$APPTYPE CONSOLE}

uses
  SysUtils,
  {ASN1, Console, ConsoleForm, CPU, CRC,
  DECCipher, DECData, DECFmt, DECHash, DECRandom, DECUtil,
  IDPrimes, IsPrimeHRUnit, LHSZ, NCombi, NGFPBld, NGFPs, NGFPTab,
  NIntM,} NInts {NInt_1, NMath, NPolys, NRats, Prime};

{$R *.res}

var
  a, b, c, soll, z, sub: IInteger;
  start: TDateTime;
  duration: Double;
  nad, nsu: Int64;
  nn: Integer;

begin
  NSet(a, '170141183460469231731687303715884105757');
  NSet(b, '170141183460469231731687303715884105703');
  NSet(soll, '57896044618658097711785492504343953926634992332820282019728792003956564819968');
  NSet(z, '340282366920938463463374607431768211455');
  NSet(sub, '11111111111111111111111111111111111111111111111111111111111111111111111111111');

  nad := 0;
  nsu := 0;
  start := Now;
  for nn := 0 to 25000000 do begin
    NMul(c, a, b);
    while NCmp(c, soll) < 0 do begin
      NAdd(c, c, sub);
      Inc(nad);
    end;
    while NCmp(c, soll) > 0 do begin
      NSub(c, c, sub);
      Inc(nsu);
    end;
    NShr(a, c, 128);
    NAnd(b, c, z);
  end;
  duration := (Now - start) * SecsPerDay;

  WriteLn('c0=', NStr(c));
  WriteLn('ad=', nad, ' su=', nsu, ' in ', duration:1:8, ' sec');
  WriteLn;
  WriteLn('Programmende mit ENTER');
  ReadLn;
end.

Delphi-Quellcode:

  for var nn := 25000000 downto 0 do begin
    c := a * b;
    while c < soll do begin
      c := c + sub;
      Inc(nad);
    end;
    while c > soll do begin
      c := c - sub;
      Inc(nsu);
    end;
    //a := c div d;  //a := c shr 128;
    //b := c mod d;  //b := c and z;
    //MatheString.MatheObj.QuotientModulo(c, d, PString(@a)^, PString(@b)^);
    var i := Length(c) - 38;
    a := Copy(c, 1, i);
    b := Copy(c, i + 1);
  end;

Komisch, hätte gedacht, dass das SHR/AND ... ähhh, ich meinte der DIV/MOD-Ersatz, das Tempo enorm runterzieht,
aber ein halbwegs equivalentes DezimalShift senkt die Zeit in meinem StringMath von 9610 auf nur 3355 Sekunden. :shock:

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1526681)

DEC Part I kennen ja alle ...

*räusper* Stimmt nicht. Es gibt mindestens eine Person die das nicht kennt. Ich. Also nicht "alle". qed.
Von DEC kenne ich nur PDP 11. :P

[itsChris]

So eine Besserwisserei...:roll:. Auch wenn es nicht jeder kennt, muss man nicht alles kommentieren und verbessern.

Zitat:

Zitat von freimatz (Beitrag 1526733)

Zitat:

Zitat von himitsu (Beitrag 1526681)

DEC Part I kennen ja alle ...

... Es gibt mindestens eine Person die das nicht kennt. Ich. Also nicht "alle". qed.... :P

Komma vergessen. Richtig wäre: Es gibt mindestens eine Person, die das nicht kennt.

[peterbelow]

Zitat:

Zitat von freimatz (Beitrag 1526733)

Von DEC kenne ich nur PDP 11. :P

Ach, das weckt Erinnerungen. :wink: Auf 'ner PDP11 haben wir in der Mittagspause öfter Dungeons gespielt. War so Anfang der 1980-er...

[Uwe Raabe]

Zitat:

Zitat von peterbelow (Beitrag 1526735)

Auf 'ner PDP11 haben wir in der Mittagspause öfter Dungeons gespielt. War so Anfang der 1980-er...

Das kommt mir irgendwie bekannt vor: CodeRage Deutschland 2016 - Session 09 - Delphi Adventure