Ich will eine Berechnung beschleunigen und wiederaufsetzbar machen, indem ich manche Daten auf Platte speichere. Die Dateien heißen sinnvollerweise 0000000002.txt bis 4294967296.txt, aber nicht alle 2^32-2 Dateien werden entstehen. Ich rechne mal mit nur 10Mio bis 100Mio Stück. Eine Datei hat 2k bis 3k.
Ich denke daran, daß ich 42950 Verzeichnisse mache und dann 00000/00002.txt bis 42949/67296.txt ablege.
Ich weiß, daß DOS und Win95 bei mehr als 10K Verzeichniseinträgen lächerlich langsam wurden. Ist das bei XP mit NTFS auch noch so? Oder kann ich ruhigen Gewissens zweistufig bleiben?

^^ich weiss zwar auch nicht ob win das packt, aber falls nicht, zerleg den dateinamen in unterverzeichnisse, wie: 1234\5678\9abc\defg.txt. das macht windoof die zugriffe vielleicht einfacher.

If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.

Link: http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx

MS meint dazu:

If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.

Link: http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx

Vielen Dank.

Wie wàre es anstelle Millionen von Dateien mit einer einzigen, als Hashtabelle?

Nö, besser nicht.
Wenn eine Datei gelesen wird, werden die drin stehenden Zahlen (zum Beispiel 600 Stück) nach aufsteigender Größe gelesen und verarbeitet. Wenn eine neue Zahl zu einer Datei hinzukommt, ist sie größer als alle bisherigen Zahlen der Datei, also kann einfach hinten drangehängt werden. Das macht Dateien schonmal recht praktisch.

Mit python und alchemy ist sowas in 5min gemacht. Oder besser in elixir

Wie waere es mit einer Datenbank? Muss ja nicht gleich mysql sein, nimmt halt sqlite.

Dateien sind für mich optimal, solange das Dateisystem nicht völlig überlastet ist. Es sieht nicht danach aus, daß NTFS schnell in die Knie ginge.

Dateien sind für mich optimal, solange das Dateisystem nicht völlig überlastet ist.

was hast du eigentlich vor, beschreib doch mal? es ist keine seltenheit, dass ein DBMS (wie schon DEvent vorgeschlagen hat), wesentlich effektiver mit grossen datenmengen umgehen kann, als wenn man alles selber in dateien schreiben würde. ich habe z.b. letztens erst recht positive erfahrungen mit HSQLDB (ein DBMS komplett in Java geschrieben, spottet jeder aussage, dass Java langsam sei) gemacht und früher auch schon (mit DB2, mySQL).

was hast du eigentlich vor, beschreib doch mal?

Ich mache das da (mußt Du nicht ganz lesen, ich fasse gleich zusammen)
http://www.gpgpgpu.com/gecco2009/6.pdf
Allerdings ohne GPU und ohne genetische Algorithmen. Darüberhinaus auf einem alten Rechner und single threaded.

Die Funktion isPrime(x) sagt, ob x eine Primzahl ist.
Die Funktion isSPRP(x,a) sagt, ob x eine stark wahrscheinliche Primzahl zur Basis a ist. http://en.wikipedia.org/wiki/Probable_prime
Die isSPRP() verbläst praktisch die gesamte Rechentzeit.
Sie verbläst für einmal isSPRP(x,a) leider log(x) Integer-Divisionen.
isSPRP(x,irgendwas) liefert sehr oft das gleiche wie isPrime(x). Leider nicht immer. Aber zum Beispiel liefert isSPRP(x,2) das gleiche wie isPrime(x), solange x<2047. Wenn man alle Basen bis 2^32 ausprobiert, kommt man zu der am weitesten tragenden Basis:
isSPRP(x,42162995) liefert das gleiche Ergebnis wie isPrime(x), solange x<97921.
Damit kann man eine isPrime() deutlich beschleunigen, indem man ein leckeres

//vorher ein wenig trial division durch 2,3,5,7
if(x<97921)
  return !isSPRP(x,42162995);
//nachher der test für große zahlen

baut.
Man braucht dann in diesem Bereich nur noch log(x) Divisionen statt der normalen sqrt(x) Divisionen. Das rockt die Bude.
Ist aber auch nicht neu http://www.groupsrv.com/science/post-3260091.html

Im Wesentlichen ist mein Programm nur ein

for a=2 to maxint (bin jetzt bei ca 70000)
  for b=3 to a-1 (bin dauernd zwischen 3 und ca 70000)
//also laufe über alle paare (a;b) mit a,b<=maxint
    for x=2 to inf (sehr oft bis ein paar milliönchen)
       if isSPRP(x,a) and isSPRP(x,b) and (not isPrime(x))
//also finde den ersten Aussetzer für dieses Basenpaar
          if x>bestesXBisher
             print a,b,x,teilerVon(x)
             break, also exit for, also beim nächsten b weitermachen

Aber das braucht EWIG. Und dann kommen halt die Optimierungen. Die allerstärkste Optimierung von mir ist die, daß ich "die üblichen Verdächtigen" in einem Move-To-Front-Cache halte und vor der x-Schleife erstmal "die üblichen Verdächtigen" gegen die beiden Basen prüfe. Ein x wird zum "üblichen Verdächtigen", wenn es den Vergleich x>bestesXBisher auslösen kann.

Wenn a so um 30k ist, sorgt diese Optimierung dafür, daß während b von 2 bis 30k läuft, alle b bis auf ungefähr eins bereits einen Treffer in "den üblichen Verdächtigen" haben und nicht die x-Schleife bis ein paar Milliönchen betreten muß.
Bei a=30k ist die Anzahl "der üblichen Verdächtigen" gerde mal 2042. Also Hammer-Beschleunigung. Mit Move-To-Front in "den üblichen Verdächtigen" habe ich sogar meistens nur weniger als 10 isSPRP() pro neuem b zu zahlen.

Manchmal aber muß die x-Schleife laufen. Und hier kommt die Optimierung mit den Dateien. Dann habe ich für a und für b, falls ich jemals a oder b in einer x-Schleife schon laufen ließ, die kleinen SPRPs für a und b schon auf der Platte und kann einfach die beiden Dateien laden und die erste Gleichheit suchen. Ist keine Gleichheit da, wird die x-Schleife genommen, die aber zusätzlich alle SPRPs, die anfallen, in die beiden Dateien ablegt für's nächste mal.

Für die Suche bis a=75k sind lustigerweise nur 3000 Dateien entstanden mit zusammen 5MB (weil die erste Optimierung so sagenhaft gut greift).
Die letzen beiden Dateien sind
0000074616.txt

217
451
793
899
2201
2407
2573
3097
4123
6533
6817
7471
8321
8911
16849
17767
18721
23653
25351
27511
28639
31609
34279
35371
41251
41431
45449
45551
68101
74615
74617
81631
83333
105163
113201
114211
134383
134413
145351
193999
194407
196093
226801
230323
252601
284581
302177
320131
328021
334729
340367
355577
398413
418801
463079
468541
497503
522319
533681
551953
597871
615421
627751
646601
651511
653251
671977
672049
689323
741751
833341
876961
910303
1024651
1053313
1092547
1109593
1212751
1219661
1266481
1278781
1297741
1346413
1386529
1407737
1480337
1562809
1585693
1602319
1641041
1718431
1722913
1746979
1773289
1836541
1907851
1963501
2125759
2146651
2259583
2346121
2428511
2484121
2527291
2636461
2746387
2907521
2948947
3126337
3273913
3337741
3363121
3458011
3464131
3522481
3539101
3542533
3654691
3700897
3828001
3855439
4157455
4224533
4335241
4499701
4564913
4800277
4863127
4932841

und
0000000659.txt

15
33
55
91
165
329
529
703
901
1045
2035
2413
2821
3439
4097
4699
5713
6643
6697
6985
9955
12403
12773
13333
15841
17161
19909
22987
24013
24727
27307
30857
32477
34455
38665
49051
49141
50293
52633
58969
68251
73841
80137
80477
89281
91001
97939
104833
119341
121153
124073
127243
128627
132715
133141
141373
145585
147187
153401
159031
188191
189145
190061
194221
197209
197633
208339
217141
234199
246061
258445
264773
317683
318551
336169
343001
360533
368335
396271
415351
434941
436753
438751
474631
479107
485357
490831
514447
533513
546535
610091
627203
677615
694153
701677
724087
736291
748661
765937
776383
787081
789319
810701
850519
853469
873181
919921
929633
935713
985249
1032533
1033853
1040299
1044199
1056331
1066781
1082401
1093471
1151809
1197373
1200601
1264285
1277371
1348327
1452811
1621777
1670257
1684621
1690501
1717223
1717903
1843873
1850971
1860841
1892323
1904033
1934227
2008007
2030341
2156883
2162473
2237017
2337301
2367307
2457577
2746279
2766115
3003589
3044587
3076481
3093697
3294187
3375487
3387781
3446071
3568661
3593863
3616273
3624209
3632581
3746041
3882139
3888165
4024297
4077151
4181815
4181921
4184041
4209461
4219129
4225453
4238191
4253971
4293181
4378769
4384693
4441501
4448221
4518457
4710763
4720927
4846337
4865911
4906441
4910455
4932841

Entsprechen war 4932841 das kleinste x, das zu den Basen 74616 und 659 ein Aussetzer war.
Meine 49Mio sind noch weit weg von den 177Mio von David McAllister.
Aber ich mache ja auch eine erschöpfende Suche und lasse keinen Kandidaten aus, um irgendwann ich wenigen hundert Prozessorjahren das optimale Paar zu haben.

Die Dateien-Optimierung soll dafür sorgen und sorgt dafür, daß die x-Schleife immer jene milliönchen SPRP-Tests nicht machen muß, die bereits auf einer der beiden Basen schon passiert sind. Ich muß also manchmal (ca einmal pro Sekunde) so zwei kleine Datein lesen und die werden dann auch sequentiell gelesen. Ich denke, Dateien sind da optimal.

Übrigens habe ich festgestellt, daß statt 543756235327412.txt eine 5437/5623/5327/412.txt nicht so schlau ist. Besser ist es, mit den Verzeichnissen nur einen Suchweg zu machen und zu zerlegen in 5437/5623/5327/543756235327412.txt. Da kann ich mit normalen tools oder mit freaktools und weniger Nachdenken leichter umstrukturieren. 5437/5623/5327/412.txt nur nehmen, wenn nur automatisch drauf zugegriffen wird wie in ccache oder so.

Die Dateien, die entstehen, sind als soche von Bestand und können unmittelbar für den komplett wahnwitzigen Versuch genommen werden, auch das perfekte Basentripel zu finden. Aber dazu brächte es bis zum Ende Milliarden von Rechnern, die hunderte von Jahren laufen. Mal schauen, eine (fremderfundene) vielleicht tausendstarke mathematische Optimierung gärt in mir. Vielleicht gilt Moore's Gesetz weiter und in 15 Jahren haben wir wider 1000-mal mehr Rechenpower als jetzt.

;fricky schrieb:

was hast du eigentlich vor, beschreib doch mal?

Ich mache das da (mußt Du nicht ganz lesen, ich fasse gleich zusammen)
http://www.gpgpgpu.com/gecco2009/6.pdf

ein primzahlen-sucher? vielleicht interessiert dich das: http://www.alpertron.com.ar/ECM.HTM
kann relativ schnell relativ grosse zahlen faktorisieren, source code ist auch auf der seite, der code sieht zwar furchtbar aus, aber vielleicht kannstes irgendwie für deine zwecke verwerten.

?

Ach, übrigens, ich benutze C++ mit Objektorientierung.
Die teure x-Schleife ist derzeit:

{
				sa.start(a);
				sb.start(b);
				while(sa.peek()!=sb.peek()){
					cout<<a<<' '<<b<<' '<<sa.peek()<<' '<<sb.peek()<<"           \r";
					if(sa.peek()<sb.peek()){
						sa.pop();
					}
					else{
						sb.pop();
					}
				}

sa und sb sind dabei vom Typ SPRPGenerator. Und der erledigt die ganzen Geschichten um Laden und Speichern und ums Dazuberechnen, wenn noch nicht genug Daten da sind.

volkard schrieb:

;fricky schrieb:

was hast du eigentlich vor, beschreib doch mal?

Ich mache das da (mußt Du nicht ganz lesen, ich fasse gleich zusammen)
http://www.gpgpgpu.com/gecco2009/6.pdf

ein primzahlen-sucher? vielleicht interessiert dich das: http://www.alpertron.com.ar/ECM.HTM
kann relativ schnell relativ grosse zahlen faktorisieren, source code ist auch auf der seite, der code sieht zwar furchtbar aus, aber vielleicht kannstes irgendwie für deine zwecke verwerten.

Denke nicht. Bis 2^64 nehme ich zum Faktorisieren Pollard's Rho mit Brent. Aber was treibt Dich dazu, so unpassende Links zu posten? Google-Größenwahn, daß Du meinst, mit zwei Minuten Googlen was Tolles beitragen zu können?

volkard schrieb:

;fricky schrieb:

was hast du eigentlich vor, beschreib doch mal?

Ich mache das da (mußt Du nicht ganz lesen, ich fasse gleich zusammen)
http://www.gpgpgpu.com/gecco2009/6.pdf

ein primzahlen-sucher?

Nee, ein Primzahlen-Sucher-Sucher.

Aber was treibt Dich dazu, so unpassende Links zu posten?

ich hatte das applet noch in erinnerung, finde es ganz schick.

volkard schrieb:

Google-Größenwahn, daß Du meinst, mit zwei Minuten Googlen was Tolles beitragen zu können

google ist einfach toll. kennste schon diese seite: http://primes.utm.edu/prove/index.html

volkard schrieb:

Aber was treibt Dich dazu, so unpassende Links zu posten?

ich hatte das applet noch in erinnerung, finde es ganz schick.

volkard schrieb:

Google-Größenwahn, daß Du meinst, mit zwei Minuten Googlen was Tolles beitragen zu können

google ist einfach toll. kennste schon diese seite: http://primes.utm.edu/prove/index.html

Vor 5 Jahren kannte ich sie noch, wie
http://www.c-plusplus.net/forum/viewtopic-var-t-is-67513-and-start-is-10.html
beweist.

Vor 5 Jahren kannte ich sie noch, wie
http://www.c-plusplus.net/forum/viewtopic-var-t-is-67513-and-start-is-10.html
beweist.

wow, du beschäftigst dich wohl schon ziemlich lange mit dem thema, bist wohl ein echter zahlentheorie-freak? schon mal dran gedacht, eine eigene webseite mit deinen forschungsergebnissen aufzumachen?

wow, du beschäftigst dich wohl schon ziemlich lange mit dem thema,

Ja. 1997 oder so spendierte ich ein halbes Jahr Freizeit darein und seitdem gelegentlich vielleicht mal eine Woche im Jahr. Heuer ein wenig mehr, und ursprünglich gar nicht dessentwegen, sondern weil ich eine Spielwiese für das Range-Konzept brauchte. Uih, das Konzept ist stark!

;fricky schrieb:

bist wohl ein echter zahlentheorie-freak?

Nur Hobby-Mathematiker. Mir fehlt der Unterbau.

;fricky schrieb:

schon mal dran gedacht, eine eigene webseite mit deinen forschungsergebnissen aufzumachen?

Ja, langsam wird es dringend. Inzwischen kriege ich ca. eine Milliarde mal mehr Tests pro Stunde unter als am Anfang. Immernoch ohne jeden mathematischen Trick. Im Endeffekt nur ein paar Beobachtungen, die erlauben, Rechenzeit zu sparen und C++-Code ohne abstraction overhead. Primzahlen sind kacke, die fliehen immer und jeder beobachtete Trick ist dann doch nur für ein paar Tausend oder Millionen gültig. Die Geschichte meines Suchers ist aber schreibenswert, weil da der Reihe nach hunderte von geilen Programmiertricks vorkommen, allein in den letzten Tagen eine move-to-front-list als intrusive ring, ein verzögertes bubble-sort, ein update-log und sentinel-ranges. Aber meine Klassen sind obzwar minimalistisch noch ziemlich hingekotzt. Und das alles zum Aufschreiben nachzuvollziehen wird voll lange dauern, in der Zeit könnte ich ja soo viel sinnvolles machen...