Matroids Matheplanet Forum Index
Moderiert von matroid
Mathematik » Numerik & Optimierung » Verschiedene Programmiersprachen zu Modulo im Geschwindigkeitsvergleich
Seite 1   [1 2]   2 Seiten
Autor
Universität/Hochschule Verschiedene Programmiersprachen zu Modulo im Geschwindigkeitsvergleich
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Themenstart: 2022-11-06

Da hier im Forum Fragen zur Optimierung der Modulo-Funktion (Divisionsrest) kamen, wollte ich mal verschiedene Sprachen und "Unterbefehle" miteinander vergleichen. Bei rosettacode.org habe ich jedoch keine passenden Beispiele gefunden. Also hier meine Vorschläge in verschiedenen Sprachen. Python bietet z.B. mindestens 3 verschiedene Befehle an (Einbindung fremder Bib...). Bevor ich jedoch kein einfaches Beispiel mit unoptimierten 08/15 Python-Befehlen habe, mache ich zunächst mit anderen Sprachen weiter. Zunächst einfachster Code ohne jegliche Optimierung. Ich gebe zu, dass die Multiplikation mit 13 auch bremst und noch etwas zu großen Einfluss auf die Gesamtzeit hat, aber über 100000 stark unterschiedliche Zahlen mit 1000 bis 200000 Stellen im RAM zu halten, gefällt mir auch nicht. Wichtig: die Berechnungszeit darf erst nach der Berechnung des Startwertes 11^1004 erfolgen, damit die Pow-Funktion nicht zu großen Einfluß hat! \sourceon Mathematica start=11^1004; ta=AbsoluteTime[];sum=0; For[k=3,k<195536,k++,mo=Mod[start,k];sum+=mo;start=start*13] Print[Mod[sum,10^7]," in ",AbsoluteTime[]-ta," s"] Ergebnis: 791831 in 7.201 s \sourceoff SAGE online: https://sagecell.sagemath.org/ \sourceon SAGE start=pow(11, 1004) t1=cputime() su=0 for k in IntegerRange(3,195536): mo=start % k su+=mo start*=13 print(su % 10^7) print(cputime(t1)) Ergebnis: 791831 in 7.532 s {erstaunlich schnell für einen entfernten Server mit Interpreter!} \sourceoff Jeder kann gern weitere Beispiele für andere Sprachen hinzufügen. Maple würde mich sehr interessieren, da ich das hier nicht testen kann. 3 weitere Sprachen habe ich bereits im Kopf, die noch folgen...


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.1, vom Themenstarter, eingetragen 2022-11-06

Beispiel 3 PARI/GP: \sourceon PARI/GP start=11^1004 wt=getwalltime() su=0; for (k = 3, 195535, mo=start % k; su+=mo; start*=13) printf(su % 10^7) printf("%11.3f s",(getwalltime()-wt)*1.0/1000.0) ergibt 791831 5.389 s \sourceoff Schnellste bisher.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.2, vom Themenstarter, eingetragen 2022-11-07

JAVA ohne Optimierung mit BigInteger: \sourceon JAVA int n = Integer.parseInt(args[0]);// 195536 wird übergeben BigInteger bi_start= new BigInteger("11"); BigInteger bi_13= new BigInteger("13"); bi_start=bi_start.pow(1004); BigInteger bi_su=new BigInteger("0"); BigInteger bi_10Mio=new BigInteger("10000000"); BigInteger bi_k=new BigInteger("3"); BigInteger bi_1=new BigInteger("1"); long start = System.nanoTime(); for (int k = 3;k < n;k++) { bi_su=bi_su.add(bi_start.mod(bi_k)); bi_k=bi_k.add(bi_1); bi_start=bi_start.multiply(bi_13); } System.out.println(bi_su.mod(bi_10Mio)); long finish = System.nanoTime(); double dDiffms=(finish - start) / 1000000; System.out.println((dDiffms/1000.0) + " s"); Ausgabe: 791831 in 36.98 s \sourceoff Langsamer Interpreter bisher...


   Profil
tactac
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 15.10.2014
Mitteilungen: 2663
  Beitrag No.3, eingetragen 2022-11-07

\(\begingroup\)\(\newcommand{\sem}[1]{[\![#1]\!]} \newcommand{\name}[1]{\ulcorner#1\urcorner} \newcommand{\upamp}{\mathbin {⅋}} \newcommand{\monus}{\mathbin {∸}}\) Zum Vergleich: mit dem Java-Code aus #2: \sourceon bash tactac@ubuntu:~/stuff$ javac ModTest.java && time java ModTest 195536 791831 32.77 s real 0m32,834s user 0m32,932s sys 0m0,124s \sourceoff Mit \sourceon Haskell main = print $ (\(_,su,_)->su`mod`10^7) $ iterate(\(!start,!su,!k) -> (start*13,su+start`mod`k,k+1))(11^1004,0,3)!!195533 \sourceoff \sourceon bash tactac@ubuntu:~/stuff$ ghc --make -O2 ModTest.hs && time ./ModTest 791831 real 0m2,854s user 0m2,573s sys 0m0,280s \sourceoff Btw., 11^1004 auszurechnen ist ja eigentlich egal und muss von der Messung nicht unbedingt ausgeschlossen werden. Das geht in ungefähr nullkommanix Sekunden.\(\endgroup\)


   Profil
zippy
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 24.10.2018
Mitteilungen: 4229
  Beitrag No.4, eingetragen 2022-11-07

Das Java-Beispiel zeigt, dass mein 13 Jahre alter Rechner etwa halb so schnell wie eure ist... \sourceon bash $ java X 195536 791831 60.729 s \sourceoff ... aber auch hier ist Java deutlich langsamer als andere Sprachen. \sourceon Common Lisp (SBCL) CL-USER> (time (mod (loop for k from 3 to 195535 as start = (expt 11 1004) then (* start 13) sum (mod start k)) (expt 10 7))) Evaluation took: 35.067 seconds of real time 35.022577 seconds of total run time (34.742483 user, 0.280094 system) [ Run times consist of 0.640 seconds GC time, and 34.383 seconds non-GC time. ] 99.87% CPU 105,202,933,695 processor cycles 17,842,256,928 bytes consed 791831 \sourceoff [ Linux Kernel 6.0, Prozessor Intel E8400 ] --zippy


   Profil
MontyPythagoras
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 13.05.2014
Mitteilungen: 3169
Wohnort: Werne
  Beitrag No.5, eingetragen 2022-11-07

Hallo zusammen, heute Abend werde ich gerne mal Python mit ein paar Just-In-Time-Compilern (numba, pypy) testen. Es wäre aber zur Einordnung der Ergebnisse eventuell auch wichtig, jeweils zu erwähnen, auf welchem Prozessor die Berechnung durchgeführt wurde, sonst ergibt das ein schiefes Bild. Ciao, Thomas


   Profil
Finn0
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 30.06.2021
Mitteilungen: 54
  Beitrag No.6, eingetragen 2022-11-07

\sourceon [dependencies] rug = "1.17.0" \sourceoff \sourceon Rust use rug::{Assign, Integer}; fn main() { let mut start = Integer::new(); start.assign(Integer::i_pow_u(11, 1004)); let mut su = Integer::from(0); let mut mo = Integer::new(); for k in 3..195536 { mo.assign((&start) % k); su += &mo; start *= 13; } println!("{}", su % 10u32.pow(7)); } \sourceoff Benötigte 11.24 Sekunden. Lief mit Linux Kernel 5.4 auf Core i3-2350M, der hat 4 Kerne mit 2.30 GHz. Das Crate rug bietet eine Schnittstelle zur GNU Multiple Precision Arithmetic Library.


   Profil
thureduehrsen
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 13.11.2007
Mitteilungen: 1273
Wohnort: Kiel, Deutschland
  Beitrag No.7, eingetragen 2022-11-07

Hier eine C-Version mit GNU Multiple Precision Arithmetic Library (GMP): \showon \sourceon C /* Verschiedene Programmiersprachen zu Modulo im Geschwindigkeitsvergleich (Matheplanet-Thread von hyperG, 2022-11-06 22:42) C-Code mit GNU Multiprecision library Thure Dührsen, 2022-11-07 Lizenz: WTFPL Debian: apt install libgmp-dev gcc -std=c99 -Wall -Wextra -Wunused -Wuninitialized -Wfatal-errors\ -Wconversion M.c -lgmp -lrt */ #define _POSIX_C_SOURCE 199309L /* man 2 clock_getres */ #include #include #include /* GNU Multiprecision library */ #include #define READCLOCK(i) \ \ r = clock_gettime(CLOCK_MONOTONIC, &t##i); \ \ if (r != 0) { \ fprintf(stderr, "%s\n", "Cannot read clock"); \ exit(1); \ } /************************************************************/ int main(void) { /* setup */ struct timespec t1, t2; int r; /* Rückgabewert von clock_gettime */ long int d; /* Differenz zweier Zeitstempel */ double df; /* wie oben, aber Millisekunden */ /* start = 11^1004; */ mpz_t start; mpz_t base; mpz_init_set_ui(start, 1); mpz_init_set_ui(base, 11); mpz_pow_ui(start, base, 1004); /* Zeitstempel 1 */ READCLOCK(1); /* sum = 0 */ mpz_t sum; mpz_init_set_ui(sum, 0); /* for k = 3 to 195536 ... */ mpz_t k; mpz_t mo; mpz_init(mo); for (mpz_init_set_ui(k, 3); mpz_cmp_ui(k, 195536) < 0; mpz_add_ui(k, k, 1)) { /* mo = start % k */ mpz_fdiv_r(mo, start, k); /* sum += mo */ mpz_add(sum, sum, mo); /* start *= 13 */ mpz_mul_ui(start, start, 13); } /* print sum % 10^7 */ printf("\nErgebnis: %lu", mpz_fdiv_r_ui(mo, sum, 10000000)); /* Zeitstempel 2 */ READCLOCK(2); /* Bilde Differenz der Zeitstempel */ d = ((t2.tv_sec - t1.tv_sec) * 1000000000L + t2.tv_nsec) - t1.tv_nsec; df = d / 1000000.0; /* Millisekunden */ printf(" in %.3f s\n", df / 1000); return EXIT_SUCCESS; } \sourceoff \showoff Kompilieren: \showon \sourceon bash gcc -std=c99 -Wall -Wextra -Wunused -Wuninitialized -Wfatal-errors -Wconversion M.c -lgmp -lrt \sourceoff \showoff Ausgabe: \sourceon plaintext ./a.out; echo; uname -s -v -r; grep -m 2 -E '(model name|MHz)' /proc/cpuinfo Ergebnis: 791831 in 5.790 s Linux 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21) model name : Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz cpu MHz : 2906.395 \sourceoff Wie werden wir die Prozessorabhängigkeit elegant los? Das hier sieht mir fragil und nicht sonderlich portabel aus. mfg thureduehrsen


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.8, vom Themenstarter, eingetragen 2022-11-07

Vielen Dank an ALLE Beispiele hier! \quoteon(2022-11-07 00:44 - tactac in Beitrag No. 3) ... \sourceon bash tactac@ubuntu:~/stuff$ ghc --make -O2 ModTest.hs && time ./ModTest 791831 real 0m2,854s user 0m2,573s sys 0m0,280s \sourceoff ... \quoteoff Mal ist real schneller und mal user? Analog Mathematica misstraue ich solchen "internen Messungen", da gern nur Teilberechnungen einbezogen werden. Unter 3 s mit nur 1 Kern, oder wird da bereits per Multitasking optimiert? https://matheplanet.com/matheplanet/nuke/html/images/forum/subject/shocked.gif (müsste man im Task-Manager sehen, wie hoch die CPU-Auslastung ist) Es geht hier auch nicht um das Ausspielen der CPUs gegeneinander, sondern um Vergleich der Sprachen: mal 1 Thread & mal ALLE Kerne. Damit die CPU irrelevant wird, zeige ich im nächsten Beitrag ein GMP-Beispiel (winzig kleine exe) die jeder bei seinem PC unter Win7...Win11 selbst testen kann. [Die Antwort wurde nach Beitrag No.6 begonnen.]


   Profil
Finn0
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 30.06.2021
Mitteilungen: 54
  Beitrag No.9, eingetragen 2022-11-07

Dezente Optimierung unter Anwendung von Grundwissen über Kongruenzenrechnung. Parallelisierung vermittels rayon. \sourceon [dependencies] rug = "1.17.0" rayon = "1.5.3" \sourceoff \sourceon Rust use rug::{Assign, Integer}; use std::time::Instant; use rayon::prelude::*; fn pow_mod(mut x: u64, mut n: u64, m: u64) -> u64 { let mut y: u64 = 1; while n > 1 { if n%2 == 1 {y = (y*x)%m;} n /= 2; x = (x*x)%m; } if n == 1 {y = (y*x)%m;} y } fn main() { let mut start = Integer::new(); start.assign(Integer::i_pow_u(11, 1004)); let time_start = Instant::now(); let su: Integer = (3..195536).into_par_iter().map(|k| { let mut r0 = Integer::new(); let mut r1 = Integer::new(); let mut r2 = Integer::new(); r0.assign((&start) % k); r1.assign(&r0 * pow_mod(13, k - 3, k)); r2.assign(&r1 % k); r2.clone() }).sum(); println!("{}", su % 10u32.pow(7)); println!("{:?}", time_start.elapsed()); } \sourceoff Benötigte im Mittel 76 Millisekunden. [Die Antwort wurde nach Beitrag No.6 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.10, vom Themenstarter, eingetragen 2022-11-07

Ha, thureduehrsen, ich habe gerade das GLEICHE per VC probiert mit externer DLL dynamisch eingebunden: \sourceon c++ ... int lmaxSchleifen = atoi(argv[1]); mpz_t mpzStart, mpzMo , mpzSu; mpz_init_set_str(mpzStart, "11", 10); mpz_init_set_ui(mpzMo, 0); mpz_init_set_ui(mpzSu, 0); mpz_pow_ui(mpzStart, mpzStart, 1004); unsigned long ulRet, ulSu=0; double beginS=cputimeS(); for (int k = 3; k < lmaxSchleifen; k++) { mpz_mod_ui(mpzMo, mpzStart, k); mpz_add(mpzSu, mpzSu, mpzMo); mpz_mul_ui(mpzStart, mpzStart, 13); } ulRet=mpz_mod_ui(mpzMo, mpzSu, 10000000); gmp_printf("%ld = %Zd ", ulRet, mpzMo); gmp_printf(" in %7.3f s\n",cputimeS()-beginS); ergibt:791831 = 791831 in 6.781 s \sourceoff Da ich gerade die CPU-Taktfrequenz aus Energiekostengründen reduzierte, kommt etwa die gleiche Zeit heraus. Unter GMP_Mod_Bench.zip kann man sich die exe herunterladen und selbst testen. (Antivir getestet; von mir ist nur die winzige exe; die bat zeigt nur, wie man den Übergabeparameter übergibt; alles 64 Bit Win7...Win11) Die DLL ist aus dem Internet und bindet nur die GMP-Befehle in die kleine exe ein. Mit jeder Neuerung braucht man nur die DLL austauschen und hat sofort ein Vergleich. [Die Antwort wurde nach Beitrag No.8 begonnen.]


   Profil
tactac
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 15.10.2014
Mitteilungen: 2663
  Beitrag No.11, eingetragen 2022-11-07

\quoteon(2022-11-07 20:41 - hyperG in Beitrag No. 8) Unter 3 s mit nur 1 Kern, oder wird da bereits per Multitasking optimiert? https://matheplanet.com/matheplanet/nuke/html/images/forum/subject/shocked.gif (müsste man im Task-Manager sehen, wie hoch die CPU-Auslastung ist) \quoteoff Nur 1 Kern. [Die Antwort wurde nach Beitrag No.9 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.12, vom Themenstarter, eingetragen 2022-11-07

\quoteon(2022-11-07 20:45 - Finn0 in Beitrag No. 9) Dezente Optimierung unter Anwendung von Grundwissen über Kongruenzenrechnung. ... \quoteoff Genau, wie im Startbeitrag bereits geschrieben, gefällt mir die Mul mit 13 auch nicht! Statt konstante mul mit 13 wäre unregelmäßige Addition mit nicht vorhersehbarer Variable besser! Hauptberechnungszeit soll ja auf MOD(x, m) liegen, wobei m < 200000. Ich überlege mir mal was...


   Profil
MontyPythagoras
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 13.05.2014
Mitteilungen: 3169
Wohnort: Werne
  Beitrag No.13, eingetragen 2022-11-07

Hallo zusammen, Prozessor: i7-8650U, 4.2GHz, 1 Kern Ohne JIT-Compiler \sourceon Python \numberson from time import process_time as cpu def modtest(n): s = 0 for k in range(3, 195536): s += n % k n *= 13 return s def tara(n): s = 0 for k in range(3, 195536): n *= 13 return s n0 = 11**1004 t0 = cpu() n = tara(n0) t1 = cpu() n = modtest(n0) t2 = cpu() n %= 10**7 print("Result {} in {:.3f}s total time, {:.3f}s net time".format( n, t2 - t1, t2 - 2 * t1 + t0)) \sourceoff \sourceon Ausgabe Result 791831 in 26.062s total time, 23.812s net time \sourceoff Die 23,8 Sekunden sind also die Zeit für die modulo-Berechnung, etwas über 2 Sekunden gehen für die Multiplikation drauf. Mit pypy ist das ganze sogar noch langsamer: \sourceon Ausgabe Result 791831 in 29.656s total time, 27.312s net time \sourceoff Das ist seltsam, denn eine Addition von 100 Millionen Zahlen wird in pypy um den Faktor 100 schneller. Gut, das war hier natürlich nicht zu erwarten, aber 2 bis 3 mal so schnell hätte ich schon erwartet. numba will noch gar nicht und meckert mit irgendeiner Fehlermeldung herum. Ciao, Thomas [Die Antwort wurde nach Beitrag No.11 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.14, vom Themenstarter, eingetragen 2022-11-07

Folgender Vorschlag zur Verbesserung der Hervorhebung der Mod-Geschwindigkeit: Per Pseudo-Zufallsgenerator wird mit Variable b (64 Bit) ein unvorhersehbarer Offset hinzuaddiert. Somit sollte keine Abkürzung möglich sein. \sourceon Mathematica start=11^199007; ta=AbsoluteTime[];sum=0;b=283620147; For[k=3,k<199999,k++,mo=Mod[start,k];sum+=mo;b=Mod[b*630360016,2147483647];start=start+Mod[b,200000]] ; Print[sum," in ",AbsoluteTime[]-ta," s"] 9993967179 in 12.7243716 s \sourceoff [Die Antwort wurde nach Beitrag No.12 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.15, vom Themenstarter, eingetragen 2022-11-07

\quoteon(2022-11-07 21:32 - MontyPythagoras in Beitrag No. 13) ... \sourceon nameDerSprache def modtest(n): s = 0 for k in range(3, 195536): s += n % k n *= 13 return s ... \sourceoff ... \quoteoff Super, danke. Hiermit kann ich mit ein und der selben CPU und dem selben Python die Zeile s += n % k gegen die Funktion GMP_MOD austauschen und vergleichen. Natürlich ohne das verschleiernde "mul 13" und mit dem Pseudo-Zufallsgenerator aus Beitrag 14.


   Profil
tactac
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 15.10.2014
Mitteilungen: 2663
  Beitrag No.16, eingetragen 2022-11-07

\(\begingroup\)\(\newcommand{\sem}[1]{[\![#1]\!]} \newcommand{\name}[1]{\ulcorner#1\urcorner} \newcommand{\upamp}{\mathbin {⅋}} \newcommand{\monus}{\mathbin {∸}}\) \sourceon Haskell main = print $ loop 3 0 283620147 (11^199007) where loop k sum b start | k < 199999 = loop (k+1)(sum + start`mod`k)b'(start + b'`mod`200000) | otherwise = sum where b' = b*630360016`mod`2147483647 \sourceoff \sourceon bash tactac@ubuntu:~/stuff$ ghc --make -O2 MPModTest.hs && time ./MPModTest && grep -m 2 -E '(model name|MHz)' /proc/cpuinfo [1 of 1] Compiling Main ( MPModTest.hs, MPModTest.o ) Linking MPModTest ... 9993967179 real 0m1,727s user 0m1,727s sys 0m0,000s model name : Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz cpu MHz : 2300.000 \sourceoff\(\endgroup\)


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.17, vom Themenstarter, eingetragen 2022-11-07

SAGE: \sourceon SAGE start=pow(11,199007) t1=cputime() su=0 b=283620147; for k in IntegerRange(3,199999): mo=start % k su+=mo b=(b*630360016)% 2147483647 start+=b % 200000 print(su) print(cputime(t1)) \sourceoff ergibt 9993967179 in 13.098417 s [Die Antwort wurde nach Beitrag No.15 begonnen.]


   Profil
MontyPythagoras
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 13.05.2014
Mitteilungen: 3169
Wohnort: Werne
  Beitrag No.18, eingetragen 2022-11-07

HallO Gerd, warum jetzt eine neue Funktion anfangen? Wenn Du die Multiplikation eliminieren willst, lass die Funktionen ein zweites Mal laufen ohne die Modulo-Berechnung (wie in meinem Beitrag #13, Funktion "tara"), und ziehe das ab. Ciao, Thomas


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1663
Wohnort: Deutschland
  Beitrag No.19, eingetragen 2022-11-07

Hallo hyperG, \sourceon Win10 Kommandozeile GMP_Mod_Bench.exe 195536 \sourceoff ergibt bei mir (AMD Ryzen 5 2600 Six-Core 3.40 GHz, 16 GB RAM, Windows 10 Home 64-Bit): \sourceon Win10 Kommandozeilenausgabe 791831 791831= 791831 in 5.460 s \sourceoff LG Primentus [Die Antwort wurde nach Beitrag No.17 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.20, vom Themenstarter, eingetragen 2022-11-07

@Primentus: danke! Da habe ich meine Taktfrequenz doch etwas zu sehr gesenkt, wenn der i9 schon vom Ryzen 5 überholt wird :-) @MontyPythagoras: Habe den Code absichtlich verkompliziert, damit solch mystischen Programme wie Haskell keine Abkürzung finden! Außerdem soll bunt und unvorhersehbar Mod gebildet werden. @tactac: Hast Du das mal Handgestoppt? Ich kann die "unter 2 s ohne Multitasking" nicht glauben. Hier c++ und GMP ohne Multitasking: \sourceon c++ int lmaxSchleifen = atoi(argv[1]); mpz_t mpzStart, mpzMo , mpzSu; mpz_init_set_str(mpzStart, "11", 10); mpz_init_set_ui(mpzMo, 0); mpz_init_set_ui(mpzSu, 0); mpz_pow_ui(mpzStart, mpzStart, 199007); unsigned long ulRet; unsigned __int64 b = 283620147;//muss wegen Überlauf echte 64 Bit sein double beginS=cputimeS(); for (int k = 3; k < lmaxSchleifen; k++) { mpz_mod_ui(mpzMo, mpzStart, k); mpz_add(mpzSu, mpzSu, mpzMo); b = (b * 630360016) % 2147483647; mpz_add_ui(mpzStart, mpzStart, b % 200000); } gmp_printf("9993967179 = %Zd ", mpzSu);gmp_printf(" in %7.3f s\n",cputimeS()-beginS); 9993967179 = 9993967179 in 11.434 s \sourceoff [Die Antwort wurde nach Beitrag No.17 begonnen.]


   Profil
tactac
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 15.10.2014
Mitteilungen: 2663
  Beitrag No.21, eingetragen 2022-11-07

\(\begingroup\)\(\newcommand{\sem}[1]{[\![#1]\!]} \newcommand{\name}[1]{\ulcorner#1\urcorner} \newcommand{\upamp}{\mathbin {⅋}} \newcommand{\monus}{\mathbin {∸}}\) \quoteon(2022-11-07 23:07 - hyperG in Beitrag No. 20) @tactac: Hast Du das mal Handgestoppt? Ich kann die "unter 2 s ohne Multitasking" nicht glauben. \quoteoff Was gibt's da groß zu stoppen? Man weiß doch, wie lang 2s ungefähr sind. Da das Programm nur so kurz läuft, habe ich es mal mit 1999999 statt 199999 laufen lassen (um dann auch besser zu sehen, ob wirklich nur ein Kern verwendet wird; und ja: isso). \sourceon bash tactac@ubuntu:~/stuff$ time ./MPModTest 999497117535 real 0m17,523s user 0m17,494s sys 0m0,028s \sourceoff Aber so schlau dürfte der Compiler eh nicht sein, dass er weiß, wie er das sinnvoll parallelisieren soll. \(\endgroup\)


   Profil
Finn0
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 30.06.2021
Mitteilungen: 54
  Beitrag No.22, eingetragen 2022-11-07

In einer gewissen Skriptsprache, die ich mal geschaffen habe, lässt sich die Iteration gleichartig wie in tactacs Haskell-Programm formulieren. Das sieht so aus: \sourceon f = |[s, k, n]| [s + n%k, k + 1, n*13] s = f.orbit([0, 3, 11^1004]).skip(195533)()[0] print(s % 10^7) \sourceoff Benötigte 9.3 Sekunden. Absurderweise schneller als das Rust-Programm, obwohl der Interpreter ebenfalls in Rust geschrieben ist und ebenfalls GMP nutzt, wobei da aber die Schnittstelle zu GMP von mir selbst geschrieben ist. Das C-Programm von Thure Dührsen benötigte auf meinem System 8.6 Sekunden. Sind keine Ausreißer, ich mittle da schon über ein paar Berechnungen. [Die Antwort wurde nach Beitrag No.15 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.23, vom Themenstarter, eingetragen 2022-11-08

Hier nun innerhalb von Python der Vergleich der beiden Modulo: a) mit x % m b) mit int(f_mod(mpz(x),mpz(m))) \sourceon Python from gmpy2 import mpz, gcd, lcm, is_prime, powmod, f_mod from functools import reduce from time import process_time as cpu def modtest(n): s = 0 b=283620147 for k in range(3, 199999): # s += n % k # Result 9993967179 in 59.594s total time s += int(f_mod(mpz(n),mpz(k))) # Result 9993967179 in 52.969s total time b=(b*630360016)% 2147483647 n+=b % 200000 return s # Main entry point if __name__ == '__main__': try: n0 = 11**199007 t0 = cpu() n = modtest(n0) t2 = cpu() print("Result {} in {:.3f}s total time".format(n, t2 - t0)) except e: print ("[-]", e) \sourceoff Result 9993967179 in 52.969s total time Nicht ganz 7 s schneller mit Austausch des 08/15 Modulo gegen das GMP Modulo. [Die Antwort wurde nach Beitrag No.20 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.24, vom Themenstarter, eingetragen 2022-11-08

\quoteon(2022-11-07 23:15 - tactac in Beitrag No. 21) \quoteon(2022-11-07 23:07 - hyperG in Beitrag No. 20) @tactac: Hast Du das mal Handgestoppt? Ich kann die "unter 2 s ohne Multitasking" nicht glauben. \quoteoff ... mal mit 1999999 statt 199999 laufen lassen (um dann auch besser zu sehen, ob wirklich nur ein Kern verwendet wird; und ja: isso). \sourceon bash tactac@ubuntu:~/stuff$ time ./MPModTest 999497117535 real 0m17,523s user 0m17,494s sys 0m0,028s \sourceoff \quoteoff Wow, unter 18 s, unglaublich. 1999999 statt 199999 braucht bei Mathematica 999497117535 in 127.275 s 1999999 statt 199999 VC c++ mit GMP 999497117535 in 114.325 s Die verschachtelte serielle Abarbeitung lässt sich wirklich schwer parallelisieren. Man könnte sich die Zwischenergebnisse in einem Array merken... @Finn0 , ja, die Zeit liegt etwa im GMP Bereich. Willst Du das auch mal mit der Logik ab Beitrag 14 testen? @All: würde noch jemand seine exe hochladen, um mit gleicher CPU zu testen? @Primentus: meine angepasste exe ohne Mul 13 aber mit Pseudozufall lade ich gleich hoch: hier GMP_Mod_BenchOhne13.zip (DLL & BAT hatte ich ja schon im Beitrag 10 hochgeladen) Dort kann man dann die beiden Übergabeparameter 199999 und 1999999 testen.


   Profil
tactac
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 15.10.2014
Mitteilungen: 2663
  Beitrag No.25, eingetragen 2022-11-08

\(\begingroup\)\(\newcommand{\sem}[1]{[\![#1]\!]} \newcommand{\name}[1]{\ulcorner#1\urcorner} \newcommand{\upamp}{\mathbin {⅋}} \newcommand{\monus}{\mathbin {∸}}\) Zum Vergleich Code aus #23 ausgeführt: \sourceon bash tactac@ubuntu:~/stuff$ time python3 MPModTest.py Result 9993967179 in 41.915s total time real 0m41,979s user 0m39,408s sys 0m2,569s \sourceoff \(\endgroup\)


   Profil
MontyPythagoras
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 13.05.2014
Mitteilungen: 3169
Wohnort: Werne
  Beitrag No.26, eingetragen 2022-11-08

Zu Python: offenbar unterstützen die Just-In-Time Compiler numba und pypy die großen Integer-Werte nicht. Evtl. könnte man noch cython probieren, oder eben gmpy2 einbinden, was hyperG und tactac in #23 und #25 schon erfolgreich getestet haben. Da cython aber im Grunde in C übersetzt bzw. die dort definierten Zahlentypen verwendet und C letztlich auch auf GMP zurückgreift für die Berechnung von großen Ganzzahlen, ist das wahrscheinlich nicht zielführend. Ciao, Thomas


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.27, vom Themenstarter, eingetragen 2022-11-08

Damit ich besser vergleichen kann, habe ich meine CPU-Frequenz etwas angehoben (3,3 GHz -> 4,3 GHz), um mit anderen etwa gleich zu sein: - minimal schneller als Primentus im Beitrag 19 (5.18 s statt 5.4 s) - minimal langsamer als tactac im Beitrag 25 (41.99 s statt 41.7 s; ohne int(..) sogar 41.58 s Dann noch JAVA mit dem neuen Code: \sourceon JAVA int n = Integer.parseInt(args[0]);// 199999 als Parameter übergeben BigInteger bi_start= new BigInteger("11"); bi_start=bi_start.pow(199007); BigInteger bi_su=new BigInteger("0"); BigInteger bi_200k=new BigInteger("200000"); //BigInteger bi_k=new BigInteger("3"); nicht nötig BigInteger bi_1=new BigInteger("1"); BigInteger bi_b=new BigInteger("283620147"); BigInteger bi_b1=new BigInteger("630360016"); BigInteger bi_b2=new BigInteger("2147483647"); long start = System.nanoTime(); for (int k = 3;k < n;k++) { bi_su=bi_su.add(bi_start.mod(BigInteger.valueOf(k)));//bi_k)) //bi_k=bi_k.add(bi_1); nicht nötig //l64_b=(l64_b*630360016L)% 2147483647L; Überlauf, da JAVA kein u64 kann - oder?!! bi_b=bi_b.multiply(bi_b1).mod(bi_b2); bi_start=bi_start.add(bi_b.mod(bi_200k)); } System.out.println(bi_su); long finish = System.nanoTime(); double dDiffms=(finish - start) / 1000000; System.out.println((dDiffms/1000.0) + " s"); ergibt 9993967179 in 53.088 s \sourceoff Zwar war die Zeile mit l64_b schneller, ABER falsch wegen internen Überlauf! Vielleicht kennt jemand einen Trick für vorzeichenlose u64 Typdefinition? @tactac: Da Dein letztes Haskell entgegen aller anderen Programme hier trotz größerer Zahlen und größerer Schleife schneller statt langsamer (zum zum alten Mul 13) wurde, vermute ich, dass der Compiler sich letzte Mod-Ergebnisse merkte und durch kleine Offsets sofort auf das nächste Ergebnis schlussfolgern konnte? Könnte man diese "vermutete Abkürzung" verhindern, und ihn mit z.B. "If k mod 3==0, dann start+=b else if k mod 3 ==1, dann start/=2 else if k mod 3 ==2, dann start*=2" durcheinander bringen? Mal sehen, ob ich https://www.haskell.org/ghc/download.html unter Win10 zum Laufen bekomme... neue Zwischenergebnisse zusammen in einer Übersicht: \sourceon 4,3 MHz ; Schleife bis 199999 JAVA |py % |py GMP|SAGE|c GMP |Mathematica| 53.088|45.48| 41.58|13.8|8.733 |9.732 \sourceoff Dann noch GP/Pari und YMP... Nachtrag: JAVA ist mit bi_su=bi_su.add(bi_start.mod(BigInteger.valueOf(k))); minimal schneller, da k nicht als BigInteger parallel behandelt werden muss: 53.088 s statt 53.136 s -> Code angepasst


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.28, vom Themenstarter, eingetragen 2022-11-08

PARI/GP \sourceon PARI start=11^199007 wt=getwalltime() su=0; b=283620147; for (k = 3, 199998, mo=start % k; su+=mo; b=(b*630360016)% 2147483647;start+=b % 200000) printf(su) printf("%11.3f s",(getwalltime()-wt)*1.0/1000.0) ergibt 9993967179 in 6.967 s \sourceoff Damit neue Tabelle \sourceon 4,3 MHz ; Schleife bis 199999; Werte in Sekunden JAVA |py % |py GMP|SAGE|Mathematica|c GMP |PARI/GP 53.088|45.48| 41.58|13.8| 9.732 |8.733 | 6.967 \sourceoff


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1663
Wohnort: Deutschland
  Beitrag No.29, eingetragen 2022-11-08

Hallo hyperG, ich habe Deine neue exe-Datei ohne Mul 13 mal eben ausgeführt. Auf meinem AMD Ryzen 5 2600 Six-Core 3.40 GHz, 16 GB RAM, Windows 10 Home 64-Bit ergibt sich: \sourceon Win10 Kommandozeile GMP_Mod_Bench.exe 199999 \sourceoff \sourceon Win10 Kommandozeilenausgabe 9993967179 = 9993967179 in 9.190 s \sourceoff sowie \sourceon Win10 Kommandozeile GMP_Mod_Bench.exe 1999999 \sourceoff \sourceon Win10 Kommandozeilenausgabe 9993967179 = 999497117535 in 92.164 s \sourceoff LG Primentus


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.30, vom Themenstarter, eingetragen 2022-11-09

Danke @Primentus -> wie gesagt etwas langsamer als mein PC. Hier mein 1. Haskell Programm! \sourceon nameDerSprache ghc-9.2.5-x86_64-unknown-mingw32\ghc-9.2\ghc-9.2.5-x86_64-unknown-mingw32\bin>TIMErstart= 0:19:03,95 ghc-9.2.5-x86_64-unknown-mingw32\ghc-9.2\ghc-9.2.5-x86_64-unknown-mingw32\bin>MPModTest.exe 9993967179 TIMErstop= 0:19:07,96 also 4 s \sourceoff Wow. Da gib's noch viele ghc.exe ... Kann ich meine i9 CPU besser nutzen? YMP hat leider keine optimierte MOD Funktion für kleine Mod :-( (nur für sehr große Argumente lohnt die Kehrwert-Iteration) Gute Nacht.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.31, vom Themenstarter, eingetragen 2022-11-09

Zusammenfassung der Ergebnisse der Mod-Berechnungen bei kleinem 2. Argument (selbe PC; ohne "mul 13"): \sourceon Berechnungszeiten in s JAVA |py % |py GMP|SAGE online|Mathematica|c GMP |PARI/GP|Haskell_Win9.2.|c GMP 1)|YMP 53.088|45.48| 41.58|13.8 | 9.732 |8.733 | 6.967 | 4.01 | 1.03 |unbrauchbar \sourceoff zu "unbrauchbar": Da YMP für den Mod-Befehl eine Kehrwertiteration verwendet, ist er leider für ein kleineres 2. Argument unbrauchbar: - Iteration stürzt bei bestimmten Werten ab (Schleife nur bis 2222 oder erst ab sehr großen Werten) - 34 mal langsamer als GMP Um die Mächtigkeit von YMP {(c) Pi-Weltmeister Alexander J. Yee } zu zeigen, nun sehr große Argumente (1. Argument größer 207000 Stellen ; 2. Argument > 133000 Stellen) \sourceon Mathematica start=11^199007;sum=0;b=283620147;modEnde=13^119395; ta=AbsoluteTime[]; For[k=modEnde,kMPModPow13.exe 630572916 TIMErstop=19:05:32,27 -> =23,72 s \sourceoff (tactac kann es gern noch optimieren und die schnellere Version von ubuntu zeigen) YMP: https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_199007_13Pow119395k.PNG Nun ergibt sich eine völlig andere Reihenfolge: \sourceon Berechnungszeit in s Haskell|Mathematica|YMP 23.72 | 20.74 |7.48 \sourceoff - GMP könnte man noch mit Multitasking... - bc könnte ich noch (ist meist langsamer) - c# könnte ich noch Schade, dass keine Beispiele in anderen Sprachen kamen wie: - maple - http://magma.maths.usyd.edu.au/calc/ - Basic ... Nachtrag zu 1): siehe Verbesserung bei GMP im Beitrag 33!! Nachtrag zum CAS "Julia": dort verwendet der Interpreter auch die GMP-DLL, weshalb sich da keine Verbesserung ergeben kann. Man könnte dort auch die DLL von H... dorthin kopieren -> und würde vermutlich auch Verbesserungen sehen... Grüße


   Profil
Scynja
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 23.02.2011
Mitteilungen: 562
Wohnort: Deutschland
  Beitrag No.32, eingetragen 2022-11-09

\quoteon(2022-11-09 19:54 - hyperG in Beitrag No. 31) Zusammenfassung der Ergebnisse der Mod-Berechnungen bei kleinem 2. Argument (selbe PC; ohne "mul 13"): \sourceon Berechnungszeiten in s JAVA |py % |py GMP|SAGE online|Mathematica|c GMP |PARI/GP|Haskell_Win9.2.|YMP 53.088|45.48| 41.58|13.8 | 9.732 |8.733 | 6.967 | 4.01 |unbrauchbar \sourceoff zu "unbrauchbar": Da YMP für den Mod-Befehl eine Kehrwertiteration verwendet, ist er leider für ein kleineres 2. Argument unbrauchbar: - Iteration stürzt bei bestimmten Werten ab (Schleife nur bis 2222 oder erst ab sehr großen Werten) - 34 mal langsamer als GMP Um die Mächtigkeit von YMP {(c) Pi-Weltmeister Alexander J. Yee } zu zeigen, nun sehr große Argumente (1. Argument größer 207000 Stellen ; 2. Argument > 133000 Stellen) \sourceon Mathematica start=11^199007;sum=0;b=283620147;modEnde=13^119395; ta=AbsoluteTime[]; For[k=modEnde,kMPModPow13.exe 630572916 TIMErstop=19:05:32,27 -> =23,72 s \sourceoff (tactac kann es gern noch optimieren und die schnellere Version von ubuntu zeigen) YMP: https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_199007_13Pow119395k.PNG Nun ergibt sich eine völlig andere Reihenfolge: \sourceon Berechnungszeit in s Haskell|Mathematica|YMP 23.72 | 20.74 |7.48 \sourceoff - GMP könnte man noch mit Multitasking... - bc könnte ich noch (ist meist langsamer) - c# könnte ich noch Schade, dass keine Beispiele in anderen Sprachen kamen wie: - maple - http://magma.maths.usyd.edu.au/calc/ - Basic ... Grüße \quoteoff Wenn du das maple-Programm schreibst, kann ich es gerne einmal durchlaufen lassen. Ich habe zwar eine Lizenz, aber nutze das Programm fast nicht, weshalb ich in dem Dialekt nicht fit bin. Ich weiß auch nicht, ob es sinnvoll ist noch eine .js-Version zu bauen. Die wird wahrscheinlich langsamer sein.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.33, vom Themenstarter, eingetragen 2022-11-09

Wie im Beitrag No. 10 beschrieben, habe ich die GMP-DLL ja dynamisch eingebunden. Nun fand ich doch tatsächlich diese libgmp-10.dll im Ordner der Haskell_Win9.2. Installation. Einfach in mein Bin-Ordner kopiert und die selbe EXE gestartet: https://matheplanet.com/matheplanet/nuke/html/uploads/b/47407_NeueDLL.png Wow, so einen Quantensprung von Faktor 8,51 habe ich ja noch nie erlebt. https://matheplanet.com/matheplanet/nuke/html/images/forum/subject/shocked.gif Wie tactac im Beitrag 21 musste ich das mit 1999999 probieren, um die Kernbelastung besser zu erkennen: wirklich nur 1 Kern 999497117535 in 10.269 s Tabelle im Beitrag 31 wird erweitert... [Die Antwort wurde nach Beitrag No.31 begonnen.]


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.34, vom Themenstarter, eingetragen 2022-11-09

\quoteon(2022-11-09 21:02 - Scynja in Beitrag No. 32) ... Wenn du das maple-Programm schreibst, kann ich es gerne einmal durchlaufen lassen. Ich habe zwar eine Lizenz, aber nutze das Programm fast nicht, weshalb ich in dem Dialekt nicht fit bin. Ich weiß auch nicht, ob es sinnvoll ist noch eine .js-Version zu bauen. Die wird wahrscheinlich langsamer sein. \quoteoff Das wäre toll. Hier gibt es viele Mitglieder, die immer von maple sprachen, da wird sich doch bestimmt jemand finden. Laut der Seite hier kann man Mathematica-Code (siehe Beitrag 14) direkt übersetzen lassen! Oder wenn das nicht geht, kann ich Dir eine Mathematica-Code-Datei online stellen, und Du kannst diese mit: \sourceon maple convert("MyNotebook.nb",FromMmaNotebook) > FromMmaNotebook("MyNotebook.nb") \sourceoff in Deine Maple-Sprache übersetzen lassen... Grüße Gerd


   Profil
Scynja
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 23.02.2011
Mitteilungen: 562
Wohnort: Deutschland
  Beitrag No.35, eingetragen 2022-11-09

Servus, das Übersetzen war eine Katastrophe. Bzw. ich habe es nicht hinbekommen. Also selbst geschrieben: \sourceon maple restart; st := time(); _local(start); start := 11^1004; _local(sum); sum := 0; _local(k); k := 3; _local(movar); movar := 0; for k from 3 to 195536 do movar := start mod k; sum := sum + movar; start := 13*start; end do; print(sum mod 10^7); time() - st; 805988 27.766 \sourceoff Die Zeit vom Anfang kann man vernachlässigen. Das macht weniger als 10% der Gesamtzeit aus. In Java hatte ich mit 791831 27.554 s die gleiche Zeit. Meine Mapleversion ist allerdings glaube ich in Java geschrieben, sodass vermutlich die Java-Funktionen dafür verwendet werden. Was mir auffällt, ist, dass die Zahlen unterschiedlich sind?! wahrscheinlich ist ein Fehler in der Formel. Edit: Die for-Schleife darf nur bis 195535 gehen. Dann stimmt auch das Ergebnis.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.36, vom Themenstarter, eingetragen 2022-11-09

Danke Scynja, aber Du hast Beitrag 1 statt 14 genommen! Und ja, fehlerhaft -> deshalb wurde ja eine Mod-Prüfsumme zur Ausgabe gebracht. Die alte Version hatte zig Nachteile: - zu starker Einfluß von mul 13 - Abkürzung möglich, sodass der eigentlich zu untersuchende MOD Befehl irrelevant wird. Und die neue aktuelle JAVA Variante findet man bereits im Beitrag 27.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.37, vom Themenstarter, eingetragen 2022-11-09

Probiere mal: \sourceon maple start := 11^199007; sum := 0; b:=283620147; st := time(); for k from 3 to 199998 do sum := sum + (start mod k); b:=(b*630360016)mod 2147483647; start:=start+(b mod 200000) ; end do; print(sum); time() - st; \sourceoff Es könnte auch statt der 199998 eine 199999 sein, je nachdem, ob die Schleife bei <= oder < endet.


   Profil
Scynja
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 23.02.2011
Mitteilungen: 562
Wohnort: Deutschland
  Beitrag No.38, eingetragen 2022-11-09

\quoteon(2022-11-09 23:24 - hyperG in Beitrag No. 37) Probiere mal: \showon \sourceon maple start := 11^199007; sum := 0; b:=283620147; st := time(); for k from 3 to 199998 do sum := sum + (start mod k); b:=(b*630360016)mod 2147483647; start:=start+(b mod 200000) ; end do; print(sum); time() - st; \sourceoff \showoff Es könnte auch statt der 199998 eine 199999 sein, je nachdem, ob die Schleife bei <= oder < endet. \quoteoff \sourceon maple _local(start); start := 11^199007; _local(sum); sum := 0; _local(b); b := 283620147; _local(st); st := time(); for k from 3 to 199998 do sum := sum + (start mod k); b := (630360016*b) mod 2147483647; start := start + (b mod 200000); end do; print(sum); time() - st; 9993967179 53.375 \sourceoff


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1907
  Beitrag No.39, vom Themenstarter, eingetragen 2022-11-09

Super, danke Scynja. Scheint ja wirklich genau so schnell (langsam) wie JAVA zu sein.


   Profil
-->> Fortsetzung auf der nächsten Seite -->>
Seite 1Gehe zur Seite: 1 | 2  

Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2023 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]