Das deutsche QBasic- und FreeBASIC-Forum

[pzktupel]

Hallo, ich wollte gerne einmal nachfragen, wie hoch Eurer Datensatz / s ist.
Worum gehts....ich arbeite mit sehr großen Datein , die viele Zahlen enthalten.
Ich rede hier von 5GB Datein mit ca. 230 Mio Zeilen.
Der PC (Ryzen,Win10) schafft ca. 700000 Zeilen pro Sekunde. (~10 MB/s)
Die Zahl wird zeilenweise gelesen und gleich verarbeitet...nächste Zahl gelsen usw

Sprache: Freebasic, Platte: HDD

Kann man diese Rate steigern oder ist dies normal ?

Gruß

[dreael]

Einfache Antwort: Auf SSD wechseln, falls aktuell noch eine mechanische Festplatte dreht!

Primär beschleunigt eine SSD Lesezugriffe, speziell, wenn diese nicht sequenziell erfolgen, sondern viel Random Access. In FreeBasic: Wenn viel mit SEEK in grossen Dateien herumgesprungen wird, wo dann eine mechanische Festplatte nur noch viel am Rattern ist.

Natürlich auch wichtig: Grösse des RAM (Arbeitsspeicher); bei üppig ausgestattetem Rechner kann es passieren, dass es nur das erste Mal länger geht und beim zweiten Mal viel schneller, weil alles im RAM gecacht ist: Situation einer In-Memory-Datenbank.
_________________
Teste die PC-Sicherheit mit www.sec-check.net

[grindstone]

Das zeilenweise Nachladen von Daten kostet relativ viel Zeit. Schneller ist es, die Daten in größeren Blöcken von der Festpaltte zu holen. Das erfordert dann allerdings einen geeigneten Parser, der auch das rechtzeitige Nachladen übernimmt.

[St_W]

Ich hatte mal vor einigen Jahren eine kleine Filestream Klasse geschrieben für meine damaligen Bedürfnisse. Unterstützt aber wirklich nur das notwendigste, sprich einzelne/mehrere Bytes aus einer Datei zu lesen. Funktionen zum Lesen von Zeilen oder peek() Funktionalität ist da nicht dabei. Vielleicht dennoch ein guter Start oder zumindest ein Denkanstoß

[pzktupel]

Danke für die Antworten, werde mir das mit den blockweise einlesen mal anschauen.

SSD ist dasselbe bzl Speed

Problem was ich hier habe, dass ich die Zahlen zeilenweise verarbeiten muss und sofort wieder verworfen werden. Anstatt bei 8 Tasks gleichzeitig alles in den RAM zu laden, wird einmalig von der Platte gelesen.

Vielleicht liegt es an Freebasic ?

Mein Kumpel hat auf einem i9 auf Wunsch alle Zahlen bis 100Mio auf Platte geschrieben. Das zeilenweise Einlesen hat bei ihm 8s gedauert. Sprache: C++

[pzktupel]

Ich habe den Rat von grindstone befolgt.


Open "E:\TUPEL\3TEX777.bin" for Binary Access Read As #1

PRINT timer
WHILE NOT EOF(1)
S=Input(20000000, #1)
FOR v=1 TO 20000000 STEP 20
M1=VAL(MID(S,v,10))
M2=VAL(MID(S,v+10,10))
REM PRINT M1,M2:SLEEP
NEXT v
WEND

print timer
CLOSE #1

Keine Frage, für große Blöcke, liest er schnell die Datei aus, wenn ich aber
aus dem langen String die nummerischen Werte (auf 10 Stellen formatiert)
zurückgewinne, ist es wieder sehr langsam. ( 1mio/s )
Offenbar verliert Freebasic beim verarbeiten oder umrechnen in Integerwerte aus Strings viel Zeit oder gibt es noch andere Dinge ?

Ob aus einem 100 MB String die Zahlen zu gewinnen ist in etwa gleich , wie zeilenweise Integer gleich einzulesen.

[nemored]

MID ist nicht gerade das Schnellste (weil automatische Sicherheitsprüfungen durchgeführt werden, ob die Angaben im erlaubten Intervall liegen; und es ist sicher auch nicht so günstig, dass der Start der nächsten Zahl immer wieder neu berechnet werden muss. Ich könnte mir vorstellen, dass du Zeit gewinnst, wenn du den Speicherblock einmal von vorn bis hinten durchläufst und dabei immer 10 aufeinander folgende Zeichen zu einer Zahl zusammensetzt.

Ist das Format der Datei fest vorgegeben? Sonst fände ich es wesentlich geschickter, die Zahlen nicht als String zu speichern, sondern binär.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[grindstone]

@nemored: Auch für binäre Daten ziehe ich wenn irgend möglich einen String als Speicherort vor, weil ich mir dabei um die Speicherverwaltung keinen Kopf machen muß.

@pzktupel: Um den Zugriff auf den Datenstring zu beschleunigen, muß man ein weinig in die Trickkiste greifen:

[pzktupel]

Schön !

Ich habe heute den ganzen Tag beknobelt und ich konnte auch tatsächlich dank eurer Hilfe Speed x6 erreichen.
Was passierte ?
Diese Idee mit den blockweise einlesen klappte richtig gut. Ich formatierte alle Zahlen auf 10 Stellen konnte mit "VALUINT" die schnellste Konvertierung zu einer Integer erreichen. Mit VAL ist das langsamer !
Ins scharfe Sieb konnte ich das auch schon erfolgreich einbinden.
3 GB File mit 274 Mio Zahlen ist in 80s ausgelesen und verarbeitet, vorher 8min 20s.

Hier der Code:
Open "E:\TUPEL\3TEX1899.txt" for Binary Access Read As #1

PRINT timer
WHILE NOT EOF(1)
S=INPUT(1000000,#1)
i=1
WHILE i<1000000
M1=VALUINT(MID(S,i,10))
M2=VALUINT(MID(S,i+10,10))
i+=20
WEND
WEND
print timer
CLOSE #1
SLEEP


Dank Euche !

[nemored]

[pzktupel]

Das leuchtet ein ! Ihr seid die Profies

Etwas Eigenwerbung...

Man kann fragen, warum das ganze ?

Ich programmiere die schnellsten Primzahl-k-Tupel Siebe, nur kommt man an Grenzen, die immer wiedermal optimiert werden müssen.

Auf MP finden sich die Resulte:

https://matheplanet.de/matheplanet/nuke/html/viewtopic.php?topic=232720&start=0

Das größte Sahnebonbon waren die beiden Offset zu finden für das kleinste 100stellige Primzahl-10-Tupel beider Typen,unter Freebasic versteht sich.

Es ist:
10^99+84878086452295590307+d , d=0,2,6,12,14,20,24,26,30,32
10^99+707220670972957883551+d , d=0,2,6,8,12,18,20,26,30,32

Grüße

@nemored mit binär muss ich nochmal testen, ist eben ungünstig,weil ich
nur maschinencode so sehe...so wie es jetzt ist,ist auch gut.

[pzktupel]

Ich komm hier bei einer Unstimmigkeit nicht weiter....

Der code von @nemored klappt nur bedingt...bug ???

Abgesehen davon, habe ich aus *9 in *10 geändert

Type tTrick
Union
As String*20000000 S 'datenstring
As String*10 t(1 To 2000000) 'array von 10-byte-strings
End Union
End Type

ar.S=Input(20000000, #1)
k=1
For ii=1 TO 2000000 STEP 10
PRINT VAL(ar.t(k));:SLEEP
k+=1
NEXT ii

Wenn ich aus meiner Liste lese:
0 10 14 9 4 12 21 16 9 3 16 29 0 30 22 38 19 18 17 20 45 41 5 13 23 23 32 23 13 28 0 59 56 54 19 6 82 67 62 27 0 70 52 7 72 90 41 83 60 61 84 37 48 101 0 101 84 21 32 147...

Dann erhalte ich:
0 10 14 9 4 12 21 16 9 3 ?? 29 0 30 22 38 19 18 17 20 ???(5) 5 13 23 23 32 23 13 28 0 9 54 19 6 82 67 62 27 0 70 2 72 90 41 83...

Fällt was auf ? Da passen etliche nicht,wieso ?

16, (45 41),...
Keine Panik, die Zahlen haben eine Bedeutung !

0 spezifischer Einstiegspunkt zur 13
10 : 13 teilt 10*11#+1

14 spezifischer Einstiegspunkt zur 17
9 : 17 teilt 9*11#+1

4 spezifischer Einstiegspunkt zur 19
12 : 19 teilt 12*11#+1

Hoch komplex...

Allerding über die meinige Methode
WHILE NOT EOF(1)
S=INPUT(1000000,#1)
v1+=1
i=1
WHILE i<1000000
V=M1
M1=VALUINT(MID(S,i,10))
M2=VALUINT(MID(S,i+10,10))
PRINT M1;" ";M2;" ";:SLEEP
i+=20
WEND
WEND
erhalte ich:
0 10 14 9 4 12 21 16 9 3 16 29 0 30 22 38 19 18 17 20 45 41 5 13 23 23 32 23 13 28 0 59 56 54 19 6 82 67 62 27 0 70 52 7 72 90

[grindstone]