Seite 2 von 3

Verfasst: Montag 21. Juli 2008, 10:07
von BlackJack
@epsilon: Kannst Du Deinen Benchmark vielleicht noch einmal Verfügbar machen? Der Paste ist anscheinend nach der Umstellung von ubuntuusers weg.

@BastiL: Wie sieht's mit der Zeit aus, wenn Du auch wirklich die Daten extrahierst und in eine Datei schreibst?

Verfasst: Montag 21. Juli 2008, 10:31
von BastiL
Das mit der Zeit für extrahieren und Schreiben müsste ich mir ansehen. Das ist allerdings im benchmark von Epsilon auch nicht dabei, das ist auch die reine Suchzeit. Das Schreiben geht gefühlt auf jeden Fall schneller als das Suchen, die gesamte Programmlaufzeit liegt für meinen Code unter 30 Sekunden.

Verfasst: Montag 21. Juli 2008, 10:47
von epsilon
Über den Cache von Google ist das Skript noch verfügbar (Hier mit Formatierung)

Das Skript hatte noch einen bug, wodurch in byteweise() immer die Selbe Anzahl an Bytes eingelesen wurde. Der Unterschied ist allerdings gering (falls es überhaupt einen Unterschied gibt):

mem: 6.33056998253 Sekunden
mmap: 6.20173692703 Sekunden
104857 Byte: 6.86206698418 Sekunden
10485760 Byte: 6.63443303108 Sekunden
104857600 Byte: 6.43973302841 Sekunden

Verfasst: Montag 21. Juli 2008, 19:14
von BastiL
Irgendwie hat mir das bisher nicht so ganz weitergeholfen. Was ich im Moment v.a. nicht verstehe ist der große Performenceunterschied zwischen meinem Skript und der "mem" Variante im Benchmark von epsilon. Das Einlesen ist ja genau gleich, anscheinend liegt das im Matchen es re? Ich muss da mal ein paar Tests fahren... Habt Ihr noch Ideen?

Verfasst: Dienstag 22. Juli 2008, 02:59
von epsilon
BastiL hat geschrieben:[...] Was ich im Moment v.a. nicht verstehe ist der große Performenceunterschied zwischen meinem Skript und der "mem" Variante im Benchmark von epsilon. Das Einlesen ist ja genau gleich, anscheinend liegt das im Matchen es re? Ich muss da mal ein paar Tests fahren... Habt Ihr noch Ideen?
Das kann ich mir ehrlich gesagt auch nicht erklären. Das Einzige, was ich mir denken könnte, ist dass du nicht den selben Regulären Ausdruck verwendet hast (hast du auch die Flags ausgetauscht? Also dein 're.I' gegen mein 're.S | re.U' ? Wenn nicht, teste das mal.).

Dann frage ich mich noch, wie du in 10 Sekunden 2 GB einlesen und den RE drüber laufen lassen willst? (Ich brauche alleine für das einlesen von 1 GB 30 Sekunden, und das ist das reine einlesen. Vielleicht hast du aber auch nur 'ne besser Festplatte als ich ;))

Dann frage ich mich noch: Hast auch (wie ich) für jeden Test eine andere file verwendet, bzw. vor jedem Test den Cache gelöscht? Benen' doch mal deine Testfile um und teste mit ihr dein Testskript, nachdem du meine 'mem' Funktion verwend hast.

BastiL hat geschrieben:Irgendwie hat mir das bisher nicht so ganz weitergeholfen.
Hast du überhaupt getestet, ob man mit mmap auf einem 64-Bit System größere Dateien als 2 bis 3 GB adressieren kann? Vom speed her darf ja mmap eigentlich gar nicht langsamer sein als das direkte, komplette Einlesen in den Speicher (wenn man auf jede Stelle in der file sowieso nur einmal mit dem RE zugreift). In meinen Tests war mmap sogar ein wenig schneller als das Einlesen in den Speicher.

Verfasst: Dienstag 22. Juli 2008, 21:45
von BastiL
epsilon hat geschrieben: Das Einzige, was ich mir denken könnte, ist dass du nicht den selben Regulären Ausdruck verwendet hast (hast du auch die Flags ausgetauscht? Also dein 're.I' gegen mein 're.S | re.U' ? Wenn nicht, teste das mal.).
Das habe ich nicht. Mein Programm hat nach wie vor den Flag re.I, das Benchmark von Dir re.S | re.U. Das macht wohl den Unterschied und das muss ich mir jetzt ansehen.
epsilon hat geschrieben:Dann frage ich mich noch, wie du in 10 Sekunden 2 GB einlesen und den RE drüber laufen lassen willst? (Ich brauche alleine für das einlesen von 1 GB 30 Sekunden, und das ist das reine einlesen. Vielleicht hast du aber auch nur 'ne besser Festplatte als ich ;))
Um ehrlich zu sein macht das mein Rechner nicht ich ;) Ich kann nicht so schnell lesen....
Dann frage ich mich noch: Hast auch (wie ich) für jeden Test eine andere file verwendet, bzw. vor jedem Test den Cache gelöscht? Benen' doch mal deine Testfile um und teste mit ihr dein Testskript, nachdem du meine 'mem' Funktion verwend hast.
Nein ich verwende dasselbe File. Dein Pfad zeigt doch auch immer auf die gleiche Datei?? Bei meinem Benchmark habe ich lediglich den Pfad geändert - zeige aber immer auf dieselbe Datei, genau wie Du....
Hast du überhaupt getestet, ob man mit mmap auf einem 64-Bit System größere Dateien als 2 bis 3 GB adressieren kann?
Noch nicht. Das muss ich machen, dazu gibt es im Netz durchaus widersprüchliche Infos...
Vom speed her darf ja mmap eigentlich gar nicht langsamer sein als das direkte, komplette Einlesen in den Speicher (wenn man auf jede Stelle in der file sowieso nur einmal mit dem RE zugreift). In meinen Tests war mmap sogar ein wenig schneller als das Einlesen in den Speicher.
Korrekt. Daher wäre das für mich der Weg wenn das mit Files > 2GB läuft...
Ich melde mich wieder wenn ich die Tests gefahren habe.

Verfasst: Mittwoch 23. Juli 2008, 04:43
von epsilon
BastiL hat geschrieben: Nein ich verwende dasselbe File. Dein Pfad zeigt doch auch immer auf die gleiche Datei?? Bei meinem Benchmark habe ich lediglich den Pfad geändert - zeige aber immer auf dieselbe Datei, genau wie Du....
Ne ich hab's immer mit 'ner anderen file getestet (siehe hier):
dewiktionary-20080617-pages-articles00.xml
dewiktionary-20080617-pages-articles01.xml
dewiktionary-20080617-pages-articles02.xml
dewiktionary-20080617-pages-articles03.xml
dewiktionary-20080617-pages-articles04.xml

Verfasst: Mittwoch 23. Juli 2008, 10:41
von BastiL
Also: wenn ich die Flags in meinem (schnellen) Skript tausche (re.S | re.U statt re.I) dann bleibt das Tempo gleich hoch, genauso wenn ich statt meinem re.search dein re.compile verwende.... Dein Skript bleibt deutlich langsamer.... Keine Ahnung warum...

Das Problem 2GB Grenze bleibt: wenn ich mmap verwende bekomme ich:

OverflowError: memory mapped size is too large (limited by C int)

Das scheint wohl auch ein Problem der Implementierung von Python 2.4.2 zu sein, selbst wenn ich die 64 Bit Version verwende (was ich gar nicht weiss - wie finde ich das heraus?)

Verfasst: Mittwoch 23. Juli 2008, 12:10
von Leonidas
Ich weiß grad nicht wie das bei Windows aussieht (müsste aber in sys.version stehen), aber eine Methode das herauszufinden ist:

Code: Alles auswählen

>>> sys.maxint == 2**(32-1)-1
False
>>> sys.maxint == 2**(64-1)-1
True

Verfasst: Mittwoch 23. Juli 2008, 13:14
von BastiL
Leonidas hat geschrieben:Ich weiß grad nicht wie das bei Windows aussieht (müsste aber in sys.version stehen), aber eine Methode das herauszufinden ist:

Code: Alles auswählen

>>> sys.maxint == 2**(32-1)-1
False
>>> sys.maxint == 2**(64-1)-1
True
So sieht das bei mir auch aus. Ist kein Win sondern 64Bit Linux. Die Binary ist auch 64-bittig...

Verfasst: Donnerstag 24. Juli 2008, 19:50
von BastiL
Tja ich weiss nicht mehr so richtig weiter. Meine Python-Version ist 2.4.2. Wenn man das Problem googelt dann bekommt man sehr unterschiedliches dazu... Allerdings scheint Python 2.5 damit generell weniger Probleme zu haben. Hat jemand Erfahrungen mit so großen Files?

Verfasst: Donnerstag 24. Juli 2008, 20:23
von Trundle
Zumindest bei der x86_64-Architektur (aka amd64) gilt sizeof(int) == 4 und (C)Python hat intern sehr oft ints benutzt, etwa beim Indizieren oder eben auch bei mmap-Objekten. Mit Python 2.5 wurden diese ints dann durch einen eigenen Datentyp (Py_ssize_t) ersetzt (siehe auch PEP-0353, um die Vorteile einer 64bit-Architektur nutzen zu können. Mit Python 2.5 sollte also mmap mit großen Dateien funktionieren.

Verfasst: Freitag 25. Juli 2008, 08:39
von BastiL
Kann dieses "sollte" jemand bestätigen? Ich habe eine x86_64 Architektur und überlege auf Python 2.5 upzudaten.
Trundle hat geschrieben:Zumindest bei der x86_64-Architektur (aka amd64) gilt sizeof(int) == 4 und (C)Python hat intern sehr oft ints benutzt, etwa beim Indizieren oder eben auch bei mmap-Objekten. Mit Python 2.5 wurden diese ints dann durch einen eigenen Datentyp (Py_ssize_t) ersetzt (siehe auch PEP-0353, um die Vorteile einer 64bit-Architektur nutzen zu können. Mit Python 2.5 sollte also mmap mit großen Dateien funktionieren.

Verfasst: Sonntag 27. Juli 2008, 22:12
von Trundle
BastiL hat geschrieben:Kann dieses "sollte" jemand bestätigen? Ich habe eine x86_64 Architektur und überlege auf Python 2.5 upzudaten.
Funktioniert (zumindest mit/unter/über/auf x86_64).

Verfasst: Montag 28. Juli 2008, 20:41
von BastiL
Ok, danke für die Info. Dann werde ich mal ein Update machen.

BastiL

Verfasst: Dienstag 29. Juli 2008, 20:40
von encbladexp
Was auch schön wäre: Ein der der Daten die die re durchwühlt...

Es sollte doch noch ein anderes, und vor allem schnelleres Verfahren für dein Problem geben.

mfg Betz Stefan

Verfasst: Mittwoch 30. Juli 2008, 07:58
von BastiL
encbladexp hat geschrieben:Was auch schön wäre: Ein der der Daten die die re durchwühlt...
Das verstehe ich nicht....? Was meinst Du damit?

Verfasst: Mittwoch 30. Juli 2008, 16:29
von epsilon
Das verstehe ich nicht....? Was meinst Du damit?
Ich denke, der Satz sollte eigentlich
Eine der Dateien die der re durchwühlt...
heißen ;)

Verfasst: Donnerstag 31. Juli 2008, 17:00
von BastiL
das geht leider nicht, da die Files riesig sind und vertrauliche Daten enthalten.

Verfasst: Donnerstag 31. Juli 2008, 17:17
von BastiL
Also ich bin inzwischen etwas weiter:

1. habe ich Python 2.5.2 verfügbar, damit läuft "mem" und "mmap" über Files größer als 2GB

2. scheint das Thempo mit Python 2.5.2 deutlich langsamer zu sein....

Ich muss mir das noch einmal anschauen und poste die Resultate dann.