Matroids Matheplanet Forum Index
Moderiert von Wauzi
Mathematik » Zahlentheorie » smallest n-digit prime k-tuple - for several k - results on page 1
Thema eröffnet 2017-12-04 10:32 von pzktupel
Seite 7   [1 2 3 4 5 6 7 8 9 10 11]   11 Seiten
Autor
Kein bestimmter Bereich smallest n-digit prime k-tuple - for several k - results on page 1
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.240, eingetragen 2018-01-16

Bitte nicht E: {bei mir schon vergeben!} besser N: {wie Netzwerk}. Da könnte man 2 PCs besser vernetzen (1 Parameter.txt) Ich überlege, ob ich den 18 Ordner-PC auf 19 vergrößere und auch mit sleep arbeite. Könnte in Summe noch besser werden... Eine 64 Bit CPU arbeitet mit 64 Bit Variablen am schnellsten. Außerdem kommen ja 17stellige Zahlen am Ende raus -> ständige Wandlung entfällt damit.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.241, vom Themenstarter, eingetragen 2018-01-16

Das kann man ja dann einstellen wie man will. Soll ich das noch für P2 machen ? Jo könnte gehen. Mit subst N: LW:\ hätten dann alle eine Quelle und eine Parameter.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.242, eingetragen 2018-01-16

Aber nur die Parameterdatei global. Die pfgw und die log müssen in der schnellen RAM-Disk bleiben, da Netzwerk 100 mal langsamer ist!


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.243, eingetragen 2018-01-16

Frage: wie oft wird die pfgw pro 10 min aufgerufen, wenn: Exponent=94 Offsetgeschw.=400 Bio/10 min Ordneranzahl:18 Habe mal test-weise beim i9 die 32BIT Weiterleitungs-EXE durch eine 64 Bit exe mit 300 ms Sleep ausgetauscht. Man müsste doch denken, dass alles langsamer wird, weil sich die vielen 0,3 Sekunden gewaltig aufaddieren, ABER das GEGENTEIL ist der Fall: 409 Bio/10 min Nicht nur bessere Gleichverteilung, sondern auch weniger Warten aufeinander (BUS-Kollisionen). Da könnte ich ja morgen von 26 auf 19+9=28 Ordner hochgehen, mal sehen was das bringt. Es kommen nur noch 17stellige Offsets -> die Optimierung schreit immer lauter...


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.244, vom Themenstarter, eingetragen 2018-01-17

Heute um 01:45 Uhr bin ich aus dem Bett gefallen http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/rotate.gif !!!!!!!!!!!!!!!!!!!!!! new world record prime septuplet found !!!!!!!!!!!!!!!!!! Das 515-stellige (!) Primzahl-7-Tupel ist nun endlich nach 6 Monaten gefunden. http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/zzzdrink.gif Es sind geprüfte Primzahlen. Ausgeschrieben lautet es: \sourceon nameDerSprache 26426196885896173321399488692933254288512743825045473372906503218027316821156722518691075517842049625726732034841571838847608247390600294860738664976986639858207743059581038659058539555524025156322271706834607397841798315016140763387008829951229152327774556185373513707333938673759228834942147386939610095377499753743429591614832825269142302782725018442897836941700185290683481276367405060600962666864324123122270022047434027849290108893882798251000654711364037006812048497491570679454484905544494166790894879218371 + d,d=0,2,6,8,12,18,20 Die Kurzform ist: 115828580393941 * 1200# + 5132201 + d ,d=0,2,6,8,12,18,20 \sourceoff


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.245, vom Themenstarter, eingetragen 2018-01-17

@ HyperG Wie oft die aufgerufen wird ? Exakt alle 50*94*0.223 Mrd * 18 Tasks = 18,8 Bio. Wenn der 400 Bio in 10min schafft, währen das 21mal...alle 28s. Bei mir nimmt der PRP-Test hier beim 8-Tupel ca. 20% ein. Ich dachte , es lief sowieso die 64bit PFGW :-? Ist ja egal , wie der den PRP Test macht. 92_16782382282966723 93_06729362313069073


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.246, eingetragen 2018-01-17

Gratulation zum new world record prime septuplet !!! http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/icon14.gif Nach 6 Monaten endlich eine Anerkennung! http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/zzzdrink.gif Nun zu meinen Ordnern mit der neuen Sleep-Technik: durch die zwischengeschaltete 64-Bit-Weiterleitungs-EXE konnte ich die Last besser verteilen. Statt mit 18+8=26 Ordnern 400 Bio./ 10 min nun 19+9=28 Ordner 432 Bio./10 min Zur Erinnerung: das 2-Kern Notebook schaffte bei Exponent 85 25,7 Bio./10min (hier etwa 19 Bio./10 min) Also fast 2 Notebooks mehr Rechenleistung! Exponent 94 schon wieder weit in den 17stelligen Bereich. Vom Rechenaufwand schon jetzt das Doppelte von Deinem Exponent 93.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.247, vom Themenstarter, eingetragen 2018-01-17

Dank Dir! 94_19235798372973253


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.248, eingetragen 2018-01-17

Endlich: 094_021032705059027027 mein Offsetrekord 21 Brd.


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1342
Wohnort: Deutschland
  Beitrag No.249, eingetragen 2018-01-17

\quoteon(2018-01-17 01:52 - pzktupel in Beitrag No. 244) !!!!!!!!!!!!!!!!!!!!!! new world record prime septuplet found !!!!!!!!!!!!!!!!!! Das 515-stellige (!) Primzahl-7-Tupel ist nun endlich nach 6 Monaten gefunden. http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/zzzdrink.gif \quoteoff Herzlichen Glückwunsch auch von meiner Seite! Nach so langer Wartezeit freut man sich natürlich riesig auf das Ergebnis. Gute Arbeit! LG Primentus


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.250, vom Themenstarter, eingetragen 2018-01-17

Danke Primentus ! Hab heute, da das Projekt beendet ist, über das alte 14-Tupel mit mehr als 50 Stellen nachgedacht. Kann ich wahrscheinlich vergessen... :-( oder hab was übersehen.


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1342
Wohnort: Deutschland
  Beitrag No.251, eingetragen 2018-01-17

@pzktupel: Gern geschehen! Schon krass, dass bei 14-Tupeln bereits bei 50 Stellen mehr oder weniger Schluss ist. Warum steigt eigentlich der Rechenaufwand für wachsende k so enorm an? Ich hätte jetzt halt gedacht, wenn ein 7-Tupel mit 515 Stellen in 6 Monaten ermittelbar ist, müsste doch ein 14-Tupel (sprich doppelt so großes Tupel) mit 515 Stellen in etwa in 12 Monaten ermittelbar sein (mal angenommen es tritt ungefähr gleich früh auf wie das erste 7-Tupel). Aber anscheinend ist es nicht so simpel. Wird da der Vorsiebeprozess immer aufwendiger oder die PRP-Prüfung oder woran liegt das genau? Oder liegt das einfach nur daran, dass die 14-Tupel viel viel seltener und damit erst deutlich später auftreten als z. B. ein 7-Tupel, man also länger suchen muss? LG Primentus


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1342
Wohnort: Deutschland
  Beitrag No.252, eingetragen 2018-01-17

Edit: Dieser Beitrag kann gelöscht werden - versehentlich vorhergehenden Beitrag doppelt angelegt.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.253, vom Themenstarter, eingetragen 2018-01-17

Das Problem ist, wenn eine Bedingung mehr gefordert wird, fällt schonmal beim Sieben vielleicht 60% nochmal raus. Wenn man 7 Bedingungen mehr hat, verbleiben vielleicht 1/10000 Kandidaten im Vergleich zu 7. Diese 10.000 müssen schonmal mehr gesiebt als Interval..und dann muss nochmal viele tausend fach mehr gesiebt werden, weil ja die anderen 7 auch noch passen müssen. Der PRP-Test ist eig. Null Zeitanteil. Hier kann ein Core 2000 Zahlen pro Sekunde PRP testen (55 stellig). Beim sieben aller Teiler bis 250000 verbleiben auf 4 Mrd nur noch 2200 Kandidaten. Von denen erfüllt jede 5.5 eine Bedingung. Man muss mit 5.5^14 Kandidaten rechnen um 1 Treffer zu haben. 5.5^14/2200*4Mrd=42 BILLIARDEN k's für k * 100#+....+d,d=0,...,50 Das dauert zu lange. 1-2 Jahre etwa. Ein klassisches Offset wie hier, könnte sich bei 10^27 aufhalten. Ich war von 4 Brd ausgegangen..ca. 3 Monate, das wäre ja machbar. Aber so. Muss das nochmal überdenken....immerhin hatte ich 2007 nen 46 stelligen


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1342
Wohnort: Deutschland
  Beitrag No.254, eingetragen 2018-01-17

@pzktupel: Ok, danke für die Erklärung. Also hat man in erster Linie einfach wahnsinnig viele Kandidaten, bis man mal einen Treffer landet. Und wenn da ein ^14 in der Formel drin ist, dann leuchtet mir natürlich schon ein, dass das wesentlich länger dauert als wenn man da "nur" ein ^7 drin hätte. Dann erklärt sich für mich der enorme Anstieg mit wachsendem k. LG Primentus


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.255, vom Themenstarter, eingetragen 2018-01-18

\quoteon(2018-01-17 20:40 - Primentus in Beitrag No. 254) @pzktupel: Ok, danke für die Erklärung. Also hat man in erster Linie einfach wahnsinnig viele Kandidaten, bis man mal einen Treffer landet. Und wenn da ein ^14 in der Formel drin ist, dann leuchtet mir natürlich schon ein, dass das wesentlich länger dauert als wenn man da "nur" ein ^7 drin hätte. Dann erklärt sich für mich der enorme Anstieg mit wachsendem k. LG Primentus \quoteoff Genauso ist es. Wenn auf 1 Milliarde k's 550 Kandidaten übrig bleiben und man braucht 23 Milliarden Kandidaten, weiß man was Sache ist :-) Würde man das Offset einer solchen suchen , bekäme man dank der Daten von Seite 1 respektive 1 Brd * (515/200)^7 ~ 1e18


   Profil
Primentus
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 18.02.2016
Mitteilungen: 1342
Wohnort: Deutschland
  Beitrag No.256, eingetragen 2018-01-18

\quoteon(2018-01-18 00:25 - pzktupel in Beitrag No. 255) Genauso ist es. Wenn auf 1 Milliarde k's 550 Kandidaten übrig bleiben und man braucht 23 Milliarden Kandidaten, weiß man was Sache ist :-) \quoteoff Ok, das ist schon heftig. Das dauert dann natürlich sehr lange. LG Primentus


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.257, vom Themenstarter, eingetragen 2018-01-18

Der Sturm ist überhaupt nicht meins :-o Bäume sind schon abgeknickt.... 95_>30 Brd


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.258, eingetragen 2018-01-18

Wenn ich immer erst gegen 15:00 Uhr mit den Berechnungen anfange, hast Du mich bald eingeholt... Rechnest Du die ganze Nacht durch? Mein 95_ ist auch wieder über 16 Brd. und schon 18 7er dabei. Auf dem Brocken gerade 203 km/h (Fallgeschwindigkeit, wenn man sich breit macht)!!! Da kann keiner mehr stehen! Ich komm auch nicht mehr weg hier in Sachsen viele Straßen gesperrt! Auch schon kurze Stromausfälle -> Rechnung lief weiter -> zum Glück.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.259, vom Themenstarter, eingetragen 2018-01-18

Ja, der rechnet 365 Tage 100%. bin bei >35 Brd Sind ja nicht mehr viele bis 100.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.260, eingetragen 2018-01-18

095_019266906756122467 Ordner 5 und 26 von 28 Also wieder mindestens 1 Ordner umsonst gerechnet, da ich 18 Ordner mit "Ruhezustand" (also Startwert 0) und 9 Ordner mit Startwert 10000 berechnete. Sag jetzt bitte nicht, dass ich die 18 Ordner nochmals mit Statwert 10000 Bio nachrechnen muss :-(


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.261, vom Themenstarter, eingetragen 2018-01-18

\quoteon(2018-01-18 18:26 - hyperG in Beitrag No. 260) 095_019266906756122467 Ordner 5 und 26 von 28 Also wieder mindestens 1 Ordner umsonst gerechnet, da ich 18 Ordner mit "Ruhezustand" (also Startwert 0) und 9 Ordner mit Startwert 10000 berechnete. Sag jetzt bitte nicht, dass ich die 18 Ordner nochmals mit Statwert 10000 Bio nachrechnen muss :-( \quoteoff Wie ? 2 Ordner das gleiche geliefert ? 28 Tasks gesamt und alle 1..28 nur 1mal in task.txt eingetragen ? Wüsste nicht warum ... :-? Das geht so nicht. Alle 28 Tasks brauchen den gleichen Startwert, weil alle ab dieser Position ihre eigene Start-Position zugeteilt bekommen. -- 9 Ordner mit Startwert 10000 berechnete. Eher diese 9 mit derselben Tasknummer nur ab 0 bis 19 Brd Es muss immer der identische Startwert sein. Das Verfahren geht nicht anders. Bsp: Beginne mit 0 und 6 Tasks Verschiebeblock ist 6x normal 1. startet mit 0-1xnormal 2. startet mit 0-2xnormal 3. startet mit 0-3xnormal 4. startet mit 0-4xnormal 5. startet mit 0-5xnormal 6. startet mit 0-6xnormal


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.262, eingetragen 2018-01-18

Ja, die Task.txt ist OK -> mache ich ja schon länger. Aber statt beide PCs bei Startwert 10000 Bio neu zu starten, habe ich beim neuen PC den Ruhezustand genutzt und heute weiterlaufen lassen, was Startwert 0 entspricht -> also den Fehler, den ich schon mal hatte, wo Du eine Spezial-Exe gebastelt hattest. (meine Bequemlichkeit) Ich hätte beide PCs entweder: a) durchlaufen lassen müssen (Startweert 0) b) bis Offset 10009 laufen, dann alles beenden & löschen & dann alle 28 Ordner neu bei 10000 laufen lassen. Kann man nicht aus den log-Dateien sehen, welche Ordner der ersten 18 nicht nochmals durchlaufen müssen (mit Startwert 10000)?


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.263, vom Themenstarter, eingetragen 2018-01-18

95_78943815942310123 96_98311616999720023 , nichts mit 18 Stellen,lol 97_12092524371229423 (Triplet 0,2,6 bis 600 Stellen fertig) Generell erhebliche Speedanhebung passiert in v4. +25% definitiv mehr bzgl. Zeitpunkt 8er-Start http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/rotate.gif


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.264, vom Themenstarter, eingetragen 2018-01-24

98_111027901477071463 , erster mit 18 Stellen 99_033592004675597353 Yo, da ist er, der kleinste Googol seiner Art 100_17011398426864913 ----------------------- 51_00012430663709581 Beginne mit n=100 Pattern 1 Die 64bit Version hier: https://www.sendspace.com/file/24genf Damit alles nach Plan läuft, muss unter C:\TUPEL sein: parameter.txt PFGW64.exe Q8_1.txt fund.??? wird hier abgelegt.


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.265, eingetragen 2018-01-26

GMP.DLL V6 ohne pfgw noch schneller! Datei nur noch die Q8_02.txt im globalen Ordner, der per Übergabeparameter angegeben wird & wo fund.95 hinkommen soll. Pro Task 1 Ordner. Zusammenfassung der Messung Pattern 2 ; 2 Ordner, Start bei 19260 Bio Exponent 95: \sourceon Optimierungsschritte 5. Normans 8t_2v6.exe 181 s 22,9 Bio /10 min = 137,39 Bio./h 4 . 8t_02.exe vom 11.01. 19:53 112 s 37 Bio / 10 min = 222,0 Bio/h 3 . cpp_V4.exe 50,9 s 81,4 Bio/ 10 min = 488,25 Bio/h 2. cpp_V4.exe Reziproke dbl 44.7 s 1. cpp_V4.exe Rezipr+GMP 33.3 s 124,2 Bio/ 10 min = 745,4 Bio/h {beim i9 39 s} \sourceoff Norman & Horst habe ich die EXE bereits zugeschickt. Wer möchte, kann sich gern melden. Da ich jetzt 5,4 mal schneller bin, sollte die Suche, die über 5 h dauerte, nicht mal mehr 1 h dauern :-)


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.266, vom Themenstarter, eingetragen 2018-01-27

Pattern 1 56_001168984795216051 57_001060223800937761 Horst 57_000268590523020811 meins 55_000861870362926021 Horst 55_000243079049877721 meins


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.267, vom Themenstarter, eingetragen 2018-01-28

100_70764256923738301 58_000519634899946981 ,unter 10min


   Profil
Horst_h
Ehemals Aktiv Letzter Besuch: vor mehr als 3 Monaten
Dabei seit: 22.08.2017
Mitteilungen: 54
Wohnort: Deutschland
  Beitrag No.268, eingetragen 2018-01-29

Hallo, jau, da ist wohl was schief gelaufen :schaem: Jetzt habe ich auch 57_000268590523020811 und 055_000243079049877721 \sourceon nameDerSprache > Linux freebasic gcc 4.8.3 etwa 1050e12/h 055_000243079049877721 Time spent in secs 828.6281728744507 Startoffset -1186215065 057_000268590523020811 Time spent in secs 883.6773710250854 Startoffset -1720840145 > Windows freebasic gcc 5.2.1 720e12/h 057_000268590523020811 Time spent in secs 1339.691922999998 Startoffset -1720840145 \sourceoff Gute Güte, hätte ich doch einfach mal vorher mit n= 50 getestet, dass ging auch schon nicht. Ich nutze bei meinem Programm, dass ja nur ein minimal geändertes von pkztupel ist, nur einen Ordner und gut ist. Ich erstelle einen Beispieleordner mit Task.txt Parameter.Txt Link auf das Programm sowie Q8_01.txt und pfgw64 als echte Kopie, sonst bleiben die Programme hängen und kopiere diesen unter verschiedenen Ordnernamen. Leider schleicht die Version von Gerd mit 41e12/10min aka 250 e12/h unter wine64 vor sich hin \sourceon nameDerSprache # wine64 GMP_PrimeOctuplets4.exe 1 1 50 0 Gerd Lamprecht 8er Pattern2 TaskAll=1, MyTask=1, 10^50 + 0 Bio Startoffset=-304774595 Offset=31 Bio. v=41.803 Bio/10 min 446.363 s fertig: 31114624500817 Offset=31114624500817 \sourceoff Die "Verbesserungen" am Kernel wegen spectre führen ab und an zu Neustarts des Rechners.Zum Glück gibt es ja Stand.log Unter Win 10 das selbe Spiel, aber es gab ein "update" Gruß Horst


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.269, vom Themenstarter, eingetragen 2018-01-29

@Horst Bei Gerds Programm schleicht nichts. Das liegt an der Struktur, weil bei Pattern 2, 2 Pattern zu eins zusammenfallen. Vorne wie Hinten, selben Abstände...wie bei 0,2,6,8 3mal mehr Kandidaten auf gleichem Raum, d.h. Offset fällt kleiner aus als Pattern 1 und 3 -------------- Merk gerade, das Stand.log falsche werte hat..muss ich mal nach 99 schauen. ....weiß warum ( ist nur bei mir und nicht schlimm ) ....gibt ja noch die aktuelle output.txt .................... 99_153435283668088231 98 in Arbeit ............. von Horst: --- 12 Billion Exponent 75 --- 97 Billion Exponent 84 --- 3 Billion Exponent 85 --- 6186 Billion Exponent 87 --- 3465 Billion Exponent 88 --- 5395 Billion Exponent 91 --- 3 Billion Exponent 93


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.270, eingetragen 2018-01-30

@Horst: Dass Linux schneller sein soll, mag am Compiler liegen. Die AVX-Programme vom Pi-Weltmeister sind jedoch alle unter Win64 schneller. Deine neuen Pattern 1 mit meinen alten Pattern 2 zu vergleichen ist ja schon sehr provokativ... Alle meine cpp.exe sind auf dem i7 bisher immer schneller als Normans schnellste BAS: immer 1 1 95 19260 C:\TUPEL\8Tupel also Exponent 95 (fast doppelte von 50): \sourceon Pattern2 Exponent 95 STOP = wenn Fundstelle - 8T_2V9.exe (zu schnelle Anzeige 255...287 Bio/h) gestoppte 135 s 6907447322142*60*10/1e12/135= 30,7 Bio/ 10 min = 184 Bio/h - GMP_PrimeOctuplets4pfgwRezoAVX.exe (noch mit pfgw) Gerd Lamprecht 8er Pattern2 TaskAll=1, MyTask=1, 10^95 + 19260 Bio Offset=19268 Bio. v=43...52.718 Bio/10 min 96.486 s -> reale 43 Bio/ 10 min - GMP_PrimeOctuplets9GMPreziSSE2.exe (ab hier mit GMP's IsPrime) TaskAll=1, MyTask=1, Exponent=95, i64Start=19260 Offset=19266 Bio. v=43.273 Bio/10 min 94.053 s - GMP_PrimeOctuplets4ReziprokAVX.exe vor Gerd Lamprecht 8er Pattern2 TaskAll=1, MyTask=1, 10^95 + 19260 Bio Startoffset=19259999531893195 Offset=19266 Bio. v=59.823 Bio/10 min 69.084 s -> 60 Bio/ 10 min = 360,4 Bio/h \sourceoff Die Version 4 ist wegen der kleineren Arrays bei mir schneller. Normans AMD ohne AVX Befehle ist er angeblich minimal schneller mit seiner Version, da ja AMD bei Mul-Mod-DIV per Integer schneller ist als Intel-CPUs, die sich auf AVX spezialisiert haben. Du kannst mir gern Deine Version schicken, damit ich objektiv Zeit stoppen und selbst vergleichen kann.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.271, vom Themenstarter, eingetragen 2018-01-30

Hinweis: 8 Tupel hat durch Optimierungen Fehler bei Pattern 2 und 3 erhalten...wahrscheinlich 1-2% ------------- 99_067905918474430951 , statt 153, 67 Brd --------- Pattern 3 fertig...keine Änderung War wieder ein Schock http://matheplanet.com/matheplanet/nuke/html/images/forum/subject/shocked.gif Pattern 1 nur eine Änderung (99) Pattern 2 keine Änderung Hat nur einen erwischt...geht also normal weiter. ----------- Für 9T P1 35_000008331429424833 36_000136216406185473 37_000029871811331613 38_000128004431637663 39_000189164642750163


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.272, eingetragen 2018-02-01

\quoteon(2018-01-29 18:23 - Horst_h in Beitrag No. 268) Hallo, jau, da ist wohl was schief gelaufen :schaem: Jetzt habe ich auch 57_000268590523020811 und 055_000243079049877721 \sourceon nameDerSprache > Linux freebasic gcc 4.8.3 etwa 1050e12/h 055_000243079049877721 ... \sourceoff ... Leider schleicht die Version von Gerd mit 41e12/10min aka 250 e12/h unter wine64 vor sich hin Gruß Horst \quoteoff Dank Norman habe ich nun auch die korrigierte Pattern 1 Version bekommen und nach cpp umgeschrieben. Referenz war ja Exponent 57. \sourceon cpp Zunächst VC2012 Compiler: GMP_PrimeOctuplets10P1GMP32ReziAVX.exe 1 1 57 260 C:\TUPEL\8Tupel Win7 i7 TaskAll=1, MyTask=1, Exponent=57, i64Start=260 Offset=268 Bio. v=150.291 Bio/10 min 34.021 s 900 Bio /h fertig: 268590523020811 Offset=268590523020811 GMP_PrimeOctuplets10P1GMP32ReziAVX109.exe da IsPrime sehr viel schneller als Vorfilter TaskAll=1, MyTask=1, Exponent=57, i64Start=260 Offset=268 Bio. v=154.927 Bio/10 min 33.003 s Ab hier VC2017 Compiler: TaskAll=1, MyTask=1, Exponent=57, i64Start=260 Win7 i7 Offset=268 Bio. v=153.985 Bio/10 min 33.205 s 924 Bio /h fertig: 268590523020811 Offset=268590523020811 GMP_PrimeOctuplets10P1_2017.exe 1 1 57 260 C:\TUPEL\8Tupel Win10 i9 TaskAll=1, MyTask=1, Exponent=57, i64Start=260 Offset=268 Bio. v=179.658 Bio/10 min 28.460 s 1078 Bio/h fertig: 268590523020811 Offset=268590523020811 \sourceoff Alle finden auch 10^99+ 67905918474430951, die ab korrigierte V9 erst gefunden wurde. Weiter geht's mit Optimierungen wie AVX & Multithreading...


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.273, vom Themenstarter, eingetragen 2018-02-02

Starte 100 Pattern 2


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.274, vom Themenstarter, eingetragen 2018-02-02

100_gefunden 99_03057541923099787 98_07892285643678097 starte 97:


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.275, eingetragen 2018-02-02

Ja Norman, ich komme Dir bei Pattern 2 Exponent 95 entgegen. (rechne ja sicherheitshalber die Lücke nach) Bei AVX habe ich gerade lange nach einem Fehler gesucht: Der Befehl \sourceon nameDerSprache __m128 _mm_mul_ps (__m128 a, __m128 b) intern FOR j := 0 to 3 i := j*32 dst[i+31:i] := a[i+31:i] * b[i+31:i] \sourceoff Also 4 Multiplikationen parallel! Es gab aber Array-Überläufe und falsche Ergebnisse. Erst nach langem Suchen fand ich, dass er bei \sourceon AVX _mm_mul_ps 409519.000*41.000= 16790280.0000 FALSCH !!!??? \sourceoff statt der richtigen 16790279 berechnete!!!!????? Mit so einer Ungenauigkeit hätte ich nicht gerechnet!! Das hält zeitlich auf...


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.276, eingetragen 2018-02-02

Habe 8er Pattern 2 nochmals durchgerechnet, da es da ja Unterbrechung und Fehler gab: 10^95+ 19266906756122467 ist bestätigt. 4 Ordner lassen sich gut parallelisieren: fast vierfache Geschwindigkeit. Achtung: Das QC-Array, welches Norman mit Größe 2000 angab, ist zu klein! U läuft bis um die 3699 hoch, was natürlich den Speicherbereich danach überschreibt und Folgefehler produziert! 10^96 morgen...


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.277, vom Themenstarter, eingetragen 2018-02-03

97_12792145679304127 85_13999308233476441 Pattern 1 ------------ 9 Tupel Pattern 1 läuft...0,4,6,10,16,18,24,28,30 40_001153140766579083 41_000230848771310193 42_000393544278072573


   Profil
hyperG
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 03.02.2017
Mitteilungen: 1511
  Beitrag No.278, eingetragen 2018-02-03

Neues Konzept - Alles langsamer Pattern 2 Exponent 96: Bis 4 Ordner ist die Parallelisierung sehr gut. Ab 8 Ordner geht sie stark runter. Laut Norman liegt es am schlechten Hyperthreading. Also hab ich den Gegentest gemacht und die 8 Ordner mal anders angeordnet: Je 4 Ordner aber jeder im anderen Suchbereich völlig unabhängig voneinander: die ersten 4, also 4 1 0... 4 2 0 ... suchen parallel ab 0 Bio Die 2. 4 Ordner suchen ab 8000 Bio 4 1 8000 ... 4 2 8000 ... Und siehe da: kein Einbruch beim 4er Ordner Vorteil: -> d.h. ich habe so bei Verdopplung der Ordner auch eine Verdopplung der Geschwindigkeit! (ich hatte mich ja so geärgert, dass alles mit 28 Ordnern nur 2,5 mal statt 14 mal schneller war) \sourceon 8er Pattern 2 fertig: 10^96+4574726459861437 erste Fundstelle \sourceoff (wegen des neuen Konzepts auch noch bei 10^96+8250593315511307 eine weitere) Nachteil: a) Wenn der erste untere 4er Ordnerblock was findet, haben alle darüberliegenden Ordner mit höheren Offsets umsonst gerechnet. b ) man muss manuell einen unteren 4er Block stoppen, wenn er den Startoffset des darüberliegenden Ordners deutlich überschritten hat.


   Profil
pzktupel
Aktiv Letzter Besuch: in der letzten Woche
Dabei seit: 02.09.2017
Mitteilungen: 2055
Wohnort: Thüringen
  Beitrag No.279, vom Themenstarter, eingetragen 2018-02-03

Pattern 1 9-Tupel https://www.sendspace.com/file/8w2c0l Angedacht max. 80 Stellen, wenn überhaupt. Einzelprojekt n=100 für kleinstes Googol 9-Tupel seiner Art steht im Raum. Achtung, Programmcodeänderung F() ist invertiert, wegen wenigeren Vergleichen. Im Hauptsieb dann Abfrage F()=0 , dann erfüllt ---------- bis 55 komplett ---------------------------- 79_>98000 Billionen


   Profil
-->> Fortsetzung auf der nächsten Seite -->>
Seite 7Gehe zur Seite: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11  

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-2021 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]