QQQQQQQ SSSSS OOOOO RRRRRRR TTTTTTTTTT QQQQQQQQQ SSSSSS OOOOOOO RR RR TTTTTTTTTT QQ QQ SS OO OO RR RR TT QQ QQ SSS OO OO RRRRRRR TT QQ QQ QQ SS OO OO RR RR TT QQQQQQQQ SSSSSS OOOOOOO RR RR TT QQQQQ QQ SSSSS OOOOO RR RR TT BENCH 2.0 (c) ALFWARE Bernd Schubert ========= Version 2.06 Februar 2016 1. Einleitende Übersicht ======================== Mit der vorliegenden Sammlung von 20 kleinen Benchmarks kann man seinen Computer mal so richtig beschäftigen, damit ihm auch "warm" wird. Das Ganze ist entstanden, um mein geniales QSORT-Programm zu testen, welches ich von 16bit auf 32bit umgeschrieben und erweitert hatte. Die Benchmarks testen die reine Rechenleistung und die Schreib-/Leseleistung auf der Festplatte. Und sie sind von ansteigendem Schwierigkeitsgrad: während die ersten noch lächerlich einfach erscheinen, beißt sich an den größeren so ab 17 schon mancher Computer die Zähne aus. Was passiert? Es wird eine bestimmte Anzahl Zeilen "zufälligen" Inhalts und Länge (maximal 133) in eine Datei geschrieben und diese anschließend zeilenweise sortiert. Es wird die Zeit gemessen, wie lange dies dauert und es werden sogenannte MD5 Checksummen bestimmt. Damit sind die Tests wiederholbar und vergleichbar (die "zufälligen Inhalte" sind reproduzierbar, immer wieder gleich auf jedem Computer). Wie lange kann das dauern? Nun ja. Die größeren Tests können sich schon ein wenig hinziehen, aber es ist ja auch Sinn und Zweck der Sache, sich hier mal zu freuen, daß dies dann zukünftige Computer schaffen werden... Test01 ist mit 761 Bytes zufrieden, Test20 sortiert dagegen schon eine 68 GB große Datei. Man sollte immer rund die 7-fache Größe an freien Speicherplatz auf der Platte bereithalten. Und etwas Geduld! Test20 hat meinen "großen" PC (8GB RAM und 4 Kernel) schon mal ein paar Stunden im Griff gehabt. Einzelne Sorts (es sind je 4 pro Test) können auch schon mal abbrechen (es kommmt eine Meldung in die entsprechende Ergebnisdatei), das heißt aber nur, daß der Speicher zuende war und Windows nichts neues mehr swappen mochte), ist also nicht schlimm und erwischt letztlich jeden mal. Test19/20 schaffen nur noch max.2 der 4 Sorts, und brauchen auch ganz schön lange dafür (Test 3 bricht zusätzlich automatisch nach 2 Stunden ab) Warum gibt es so große Unterschiede zwischen den 4 einzelnen Sorts? Mein Sort-Programm wird in 4 verschiedenen Varianten benutzt: - mit 15 Zwischenspeichern - mit bis zu 999 Zwischenspeichern (je max 1 Mio Zeilen) - mit x Zwischenspeichern als binärer Baum - ganz ohne Zwischenspeicher Wenn man sich nun die Zeilenanzahlen der Test01 bis Test20 ansieht (10 bis 1 Millarde), so wird schon klar, daß jede der 4 Varianten für einen bestimmten Bereich optimal ist. Und daß manche Aufgaben sogar richtig gemein gestellt sind (wie soll man 10 Sätze noch in 15?, 1000? Zwischendateien teilen). Aber die fiesen Aufgaben sollen so sein und der gute Computer kommt mit allem klar. Spannend finde ich persönlich die Tests, wo es auch bei großer Datei noch ohne Zwischenspeicher (also nur mit RAM ggf. geswappt von Windows) schneller geht als mit! Nur hat man eben wenig Einfluß darauf, was Windows z.B. bei 8GB RAM und 68GB Daten für eine Strategie beschließt, während das sture Zusammenmischen der 1000 Zwischenspeicher noch einfach erscheint (leider aber manchmal am längsten dauert). Was kommt nun dabei raus? Pro Test 5 Dateien mit den Daten und 3 mit den Kontroll-Informationen. Letztere können auf Knopfdruck in ein Archiv mit dem Namen BENCH32.ZIP gepackt werden. Da ich alle Tests bereits ausgeführt habe, weiß ich was rauskommen müßte und man kann das vergleichen (auch die benötigten Zeiten). Ich freue mich also, wenn mir jemand seine BENCH32.ZIP (im Zweifelsfall auch BENCH16, BENCH64 siehe unten) einfach per Email schickt. Es gibt die Tests auch für 16bit-Systeme und ich habe mal 4 Tests parallel organisiert (in der Hoffnung, mehrere Kernels würden auch parallel rechnen und das Ganze in der Summe weniger Zeit benötigen) - dazu im Detail: 2. Zu den Einzelfunktionen ========================== Man kann die TEST01 bis TEST20 einzeln nacheinander(!) ausführen - bzw. TEST01BIS20 (TEST01BIS17 für Weicheier :-) ) und dann Kaffee trinken gehen. Bitte nicht parallel nebeneinander, sie würden sich behaken, siehe dazu aber Punkt BENCH64. Jeder TEST ruft die BENCH mit einer gewissen Zeilenanzahl auf: +-------+---------------+-----------------+-------------+---------------------+ ! Test ! Zeilen ! Byte ! Dauer h:min ! ! +-------+---------------+-----------------+-------------+---------------------+ ! 1 ! 10 ! 761 ! unter 0:01 ! ! ! 2 ! 100 ! 6.326 ! unter 0:01 ! ! ! 3 ! 1.000 ! 66.619 ! unter 0:01 ! ! ! 4 ! 5.000 ! 340.732 ! unter 0:01 ! ! ! 5 ! 10.000 ! 679.201 ! unter 0:01 ! ! ! 6 ! 20.000 ! 1.361.474 ! unter 0:01 ! ! ! 7 ! 50.000 ! 3.398.953 ! unter 0:01 ! ! ! 8 ! 100.000 ! 6.806.998 ! unter 0:01 ! ! ! 9 ! 200.000 ! 13.607.915 ! unter 0:01 ! ! ! 10 ! 500.000 ! 34.011.403 ! unter 0:01 ! ! ! 11 ! 1.000.000 ! 68.040.362 ! unter 0:01 ! ! ! 12 ! 2.000.000 ! 136.017.739 ! ca. 0:01 ! ! ! 13 ! 5.000.000 ! 340.027.832 ! ca. 0:04 ! ! ! 14 ! 10.000.000 ! 680.034.938 ! ca. 0:10 ! ! ! 15 ! 20.000.000 ! 1.359.965.496 ! ca. 0:30 ! ! ! 16 ! 50.000.000 ! 3.400.075.358 ! ca. 1:00 ! SORT 4 bricht ab ! ! 17 ! 100.000.000 ! 6.800.024.510 ! ca. 2:00 ! SORT 4 bricht ab ! ! 18 ! 200.000.000 ! 13.600.194.417 ! über 4:00 ! SORT 4 bricht ab ! ! 19 ! 500.000.000 ! 34.001.147.812 ! über 6:00 ! SORT 1,4 brechen ab ! ! 20 ! 1.000.000.000 ! 68.001.748.365 ! über 10:00 ! SORT 1,4 brechen ab ! +-----------------------------------------------------------------------------+ ! Summe ! 1.888.886.110 ! 128.447.557.211 ! ! ! +-------+---------------+-----------------+-------------+---------------------+ Die BENCH erstellt (mittels des Programmes NEUDATEI) eine Datei mit so vielen (maximal) 133 Zeichen langen Zeilen zufälligen Inhalts. Diese wird dann sortiert und zwar auf 4 verschiedene Arten mittels des (nicht immer fair aufgerufenen) Programmes QSORT. Vor und nach jedem Schritt protokolliert das Programm LOGBUCH (und LOG) die Start-/ bzw. Endezeit und errechnet daraus die verbrauchte Zeit. Es werden noch die MD5-Summen berechnet (mittels des genialen FSUM*) und ein DIR Kommando ausgeführt. So daß letztlich diese Dateien entstehen BERND01.TXT unsortiert BERND01.001 sortiert BERND01.002 sortiert BERND01.003 sortiert BERND01.004 sortiert sowie ERGEBN01.MD5 ERGDIR01.TXT ERGLOG01.TXT Beispielhaft für den TEST01 - bei den TEST02 bis TEST20 steht eben 02 bis 20. Die Dateien BERND01.001 bis 004 sollten (sofern der QSORT nicht abbricht) alle gleich sein und auch die gleiche MD5-Summe haben: ERGEBN01.MD5 ------------ ; SlavaSoft Optimizing Checksum Utility - fsum 2.52.00337 ; ; Generated on 04/05/11 at 10:02:49 ; 70601bbd7daaebfe293a3d6e94da48d1 *bernd01.001 70601bbd7daaebfe293a3d6e94da48d1 *bernd01.002 70601bbd7daaebfe293a3d6e94da48d1 *bernd01.003 70601bbd7daaebfe293a3d6e94da48d1 *bernd01.004 f8af86733131a094fb616afae4cfc700 *bernd01.txt a98b4b20c96ac3a34fcbcef4aacb3eda *erglog01.txt In der ERGDIR.TXT stehen die Größen ---------- Datenträger in Laufwerk C: ist TAIPAN Volumeseriennummer: 9496-766C Verzeichnis von c:\temp\bench20 04.04.2011 10:02 761 bernd01.001 04.04.2011 10:02 761 bernd01.002 04.04.2011 10:02 761 bernd01.003 04.04.2011 10:02 761 bernd01.004 04.04.2011 10:02 761 bernd01.txt 5 Datei(en) 3.805 Bytes 0 Verzeichnis(se), 38.713.065.472 Bytes frei In der ERGLOG.TXT stehen die Zeiten: ---------- fsum 04.04.2011 10:02:49,78 bis 04.04.2011 10:02:49,92 Dauer=00:00:00,14 qsort-4 04.04.2011 10:02:49,73 bis 04.04.2011 10:02:49,74 Dauer=00:00:00,01 qsort-3 04.04.2011 10:02:49,63 bis 04.04.2011 10:02:49,70 Dauer=00:00:00,07 qsort-2 04.04.2011 10:02:49,53 bis 04.04.2011 10:02:49,59 Dauer=00:00:00,06 qsort-1 04.04.2011 10:02:49,40 bis 04.04.2011 10:02:49,49 Dauer=00:00:00,09 neudatei 04.04.2011 10:02:49,18 bis 04.04.2011 10:02:49,37 Dauer=00:00:00,19 Vergleichbarkeit ---------------- Im Ordner VERSION\EXCEL gibt es eine BENCH32.XLS, wo ich mal einige Laufzeiten zusammengetragen habe. Im Ordner VERSION\VORGABE habe ich die "Normwerte" abgelegt, d.h. die eigentlich zu erreichenden MD5-Summen und meine Kontroll-/ Ergebnisdateien. So eine BENCH32.ZIP kann jeder auf seinem Computer selbst erstellen, mittels des SAUBER Programms. Dieses packt automatisch per 7ZA* das ZIP-Archiv. Dabei werden gleich noch mit die Dateien BERNDnn.* und ggf. vorhandene temporäre Zwischendateien (siehe auch Punkt 3) mit gelöscht. So hat man das Verzeichnis wieder schön sauber und eine nette BENCH32.ZIP, die man mir schicken kann. Ebenfalls kann man die Excel-Arbeitsblätter selber erstellen. Alles, was man dazu braucht, steht im Ordner VERSION\BEN2XLS, die dortige README.TXT erklärt, wie aus den o.a. Textdateien das Excel-Arbeitsblatt wird. Wiederholbarkeit ---------------- Alle Tests sind wiederholbar! Egal, ob man nun per SAUBER aufgeräumt/ eingepackt hatte oder nicht, funktioniert jeder Aufruf eines TESTnn immer wieder neu. Eventuell bereits vorhandene Dateien (seien es die BERNDnn.* oder temporäre Dateien aus einem Sort-Abbruch) werden überschrieben. Auch der SAUBER Befehl aktualiert das BENCH32.ZIP eben sofern schon vorhanden. BENCH16 und BENCH64 ------------------- Für kleinere Computer, auf denen 32bit-Programme nicht laufen, habe ich eine 16bit Lösung gestrickt, die sich aber leider aus technischen Gründen etwas unterscheidet von der normalen 32bit Variante (siehe dazu auch unter Punkt 3) Die Daten (MD5-Summen usw.) sind nicht vergleichbar! Ich habe in den Ordnern VERSION\16bit und VERSION\VORGABE sowie der Exceltabelle BENCH16.XLS die entsprechenden Programme und Vergleichsdaten abgelegt. Auf großen, schnellen, mutigen, starken Computern kann man auch mal mein BENCH64 ausprobieren. Grundidee und Hoffnung war hier, durch Parallelisierung auf Mehr-Kernel-Systemen das Gesamtpaket schneller "durch zu kriegen". Nein, es sind keine echten Parallelprogramme - dafür fehlen mir Wissen und Compiler. Aber man kann ja Windows 7 und Co. mal was managen lassen :-) Dazu gibt es die Umgebung TEST64, die sich durch einmaligen Aufruf des INST64 aufbaut! -> VERSION\64bit Hier ist nun (fast) alles 4x vorhanden und es sind 4 Unterverzeichnisse, damit sich auch temporär nichts behaken kann. Die START1 bis START4 können (und sollen!) nun parallel aufgerufen werden. Während START1 die TEST01 bis TEST13 durch jodelt, ist es noch immer schneller als START2, START3 bzw. START4, welche sich an den dickeren Brocken TEST14, TEST15 bzw. TEST16 versuchen. Am Ende kann man wieder SAUBER64 aufrufen, und es wird wie gehabt aufgeräumt und ein Päckchen BENCH64.ZIP für mich gepackt. Bemerkung: Meine Versuche in der letzten Version auch mit TEST17 bis TEST20 parallel, haben ergeben, daß außer Computer-Quälerei nicht viel dabei herauskommt, keine neuen Erkenntnisse. Die Kerne 1 bis 4 verhaken sich so untereinander und mit Windows, daß es am Ende sogar länger dauert, als wenn man alles nacheinander laufen läßt. DIe Paralellisierung hat scheinbar Grenzen, wenn Windows anfängt massiv zu swappen. 3. Technische Hinweise ====================== Der Aufruf der Batch-Abläufe erfolgt sinnvollerweise von der Kommandozeile (COMMAND bzw. CMD Fenster oder Befehlszeile vom z.B. Total Commander oder alt Norton Commander), weil nur dann kann man ja Namen/Parameter eingeben. Der Aufruf von anderen als unter Punkt 2 beschriebenen Abläufen/Programmen (insbesondere direkt BENCH, LOG oder die EXEn LOGBUCH, NEUDATEI, QSORT und FSUM* und 7ZA*) hat keinen Sinn und macht nur Ärger :-) 16bit: ------ siehe im Verzeichnis VERSION\16bit. Die meisten werden, denke ich, mit den Programmen und Abläufen im Hauptordner zufrieden sein. Ich habe meine 32bit EXEn sowie die Fremd-Programme FSUM* und 7ZA* problemlos unter Win7, Vista, XP und Win98SE getestet. Wo jedoch die 32bit-Version nicht läuft (ich habe z.B. noch so einen alten MSDOS Computer, der feierte gerade seinen 23.Geburtstag :-) kann man die 16bit- Version benutzen. Man müßte dazu --> den Inhalt des Version\16bit\XP16bit.ZIP in den Hauptordner bringen! Alles komplett ersetzen! (nur diese README aufheben :-) Dann gibt es auch TEST01 bis TEST20 und SAUBER usw. Die aufgerufenen EXEn sind 16bit-Versionen meiner Programme. Leider mußte ich die beiden Fremdprogramme FSUM* und 7ZA* ersetzen, da sie unter realen 16bit Umgebungen keine Chance haben. Ich habe die Abläufe etwas umgebaut und setze stattdessen VALIDATE(NA)* und PKZIP* ein. Somit gibt es kein MD5 sondern eine andere Checksumme. Auch sind die durch NEUDATEI 16bit und 32bit erzeugten Daten leider nicht vergleichbar (der Zufallszahlengenerator beider verwendeter Compiler hat jeweils eine andere Meinung). Ich habe jedoch auch BENCH16 vollständig durchgerechnet, auf einem XP-Rechner (der ja 16bit emulieren kann). Teilweise noch durch Ersatz des 16bit QSORT durch seinen 32bit Bruder (weil das kleinere natürlich eher Speicherprobleme hat und abbricht). Eine noch weitere Emulation der 16bit-Variante z.B. über das MSDOSBOX* Programm sollte gehen, ist jedoch nicht sinnvoll, da wie angedeutet, QSORT in der 16bit-Version viel früher über fehlenden RAM mault, während die 32bit-Version auch noch 2 Gigabyte klaglos in den Speicher nimmt. Das Gleiche gilt für virtuelle Maschinen Urspüngliches Ziel der 16bit Programm-Varianten sind ja aber auch 16bit-Rechner. Win98: ------ Auch das noch! Eine 3.Variante, was soll das, wird vielleicht jemand schimpfen. Nunja, ich habe leider feststellen müssen, daß die COMMAND.COM für Win98 (und 95?) nicht das hält, was sie verspricht. Zwar laufen die 32bit EXEn (wahlweise auch die 16bit EXEn), nicht jedoch die Batch-Skripte. Nach dem Schimpfen habe ich Ersatz geschaffen. Man müßte dazu nur zusätzlich(!) --> den Inhalt des Version\32bit\Win98.ZIP in den Hauptordner bringen! Alles überschreiben lassen (die entsprechende Frage mit JA beantworten). Die Unterschiede in BENCH, LOG und SAUBER sind nicht so wahnsinnig groß, aber immerhin vorhanden und da die CMD.EXE in diesem Fall logischer arbeitet und über Win XP, Vista und Win7 viel verbreiteter ist, habe ich in diesem Fall Win98 als Sonderfall gelassen. MD5: ---- siehe Bench20.MD5 Historie - Version 2011: ------------------------ Meine alte Variante des BENCH20 V 1.85 von 2011 ist ziemlich populär geworden, manche haben ihre Computer damit geprüft, auch ich. Damit das statistische Material nicht verloren geht (das ist bei Männern nun mal wichtig, wer hat den schnellsten, größten, am längsten durchhaltenden PC), habe ich diese Version hier noch komplett unter VERSION\Historie eingefügt. Generell gilt, daß das Programm heute natürlich noch genauso rechnet wie damals, die MD5 und CRC Checksummen sind die gleichen. Was sich geändert hat, sind die Laufzeiten. Das ist einerseits einer Verbesserung meines QSORT-Programmes zu verdanken, aber auch einer veränderten Aufrufweise (Art und Anzahl der Zwischenspeicher). Die Zeiten von Version 2011 und 2013 sind also nur bedingt vergleichbar pro Computer (sie sollten 2013 besser sein). Was gleich bleibt, ist die Rangfolge der Computer untereinander: wer also vor 2 Jahren schnell war, wird es auch jetzt sein. Ihr seid herzlich und ausdrücklich aufgefordert, mir erneut Eure BENCH32.ZIP und falls möglich auch die BENCH16.ZIP bzw. die BENCH64.ZIP zuzusenden. Keine Angst, die 64bit-Version läuft nun nicht mehr Tage und Wochen... Hier im Einzelnen der Inhalt der Ordner BENCH20 KLIENTEN DINO1 ... BENCH32-DINO1.ZIP meine Vergleichswerte Vista-Rechner BENCH64-DINO1.ZIP DINO2 ... BENCH32-DINO2.ZIP meine Vergleichswerte WIN7-Rechner BENCH64-DINO2.ZIP BENCH16-DINO2.ZIP SACHSE ... BENCH32-SACHSE.ZIP meine Vergleichswerte Laptop BENCH64-SACHSE.ZIP TEST64 KERN1 bis KERN4 Systeme für den Parallel-Test START1.BAT bis START4.BAT parallel aufzurufende Abläufe SAUBER64.BAT erzeugt die BENCH64.ZIP VERSION 16bit ... 16bit.ZIP komplettes System auf 16bit-Rechnern 32bit ... 32bit.ZIP komplettes System auf 32bit-Rechnern win98.ZIP ERSATZ unter Win98 (über 16/32bit) 64bit Install64.BAT erstellt einmalig den Ordner TEST64 BEN2XLS erstellt EXLs aus den TXT EXCEL BENCH16.XLS Zeiten/Vergleich von BENCH16.ZIP BENCH32.XLS Zeiten/Vergleich von BENCH32.ZIP BENCH64.XLS Zeiten/Vergleich von BENCH64.ZIP VORGABE BENCH16.ZIP Vergleichswerte (das soll herauskommen) BENCH32.ZIP Vergleichswerte (das soll herauskommen) BENCH64.ZIP Vergleichswerte (das soll herauskommen) HISTORIE 16bit 16bit-v2011.ZIP Programme von 2011, 16bit Version 16bit 16bit-v2012.ZIP Programme von 2012, 16bit Version 32bit 32bit-v2011.ZIP Programme von 2011, 32bit Version 32bit 32bit-v2012.ZIP Programme von 2012, 32bit Version win98-v2011.ZIP Programme von 2011, Win98 64bit Inst64-v2011.BAT Programme von 2011, 64bit Version doku Readme-v2011.TXT Excel bench32-v2011.XLS und diverse andere Laufzeit-Übersichten Klienten DINO2-v2011 BENCH32.ZIP, BENCH64.ZIP usw. Eberhard-v2011 Frank-v2011 Otto-v2011 Robert-v201 Vorgabe BENCH32-V2011 Vergleichswerte Programm 2011 & Co. Mein QSORT ---------- Das in diesem Paket enthaltene Sortierprogramm QSORT habe ich mal vor ca.20 Jahren begonnen. Es übertraf auch schon damals sein Vorbild von Microsoft* bei weitem vor allem durch die bis zu 999 Zwischenspeicher. Nun ja, aus 16bit wurde 32bit und aus 1 Gigabyte zu sortieren mit 999 temporären Beständen wurde 1 Gigabyte ohne Zwischenspeicher nur so im RAM. Die 68GB Datei vom TEST20 sind auch für moderne Computer und Festplatten schon eine anständige Aufgabe (zumal die Menge ja auch bis zu 7x gebraucht wird, 1x unsortiert, 4x sortiert, als _TEMP_ Bestände sowie versteckt in Windows Swapping). Die Zeit zum Sortieren (mehrere Stunden) reicht, um auch den letzten Kernel aus dem Sleep Modus zu wecken. Die große Stärke des neuen Baum-Algorithmus ist seine praktisch unbegrenzte Sortier-Größe für heutige Festplatten und Erdumlauftage bzw. Jahre. Nach allem, was ich von Konkurrenz-Produkten gesehen habe, ist QSORT auch bezüglich Sortiergeschwindigkeit anständig schnell, im Mittelfeld. Die Programmiersprache Pascal überrascht hier durch Eleganz (natürlich :-) und Schnelligkeit. Ich habe zwar keinen Gegenentwurf in C oder so, jedoch deuten einfache Benchmarks darauf hin, daß hier C keine Vorteile bringe. Exemplarisch seien hier 3 Versionen meines Programmes vorgestellt - Version 2002 (die letzte reine 16bit Version, leider würde sie unter WIN7/Vista 64bit nicht laufen) - Version 2011 (die erste vollständige Umsetzung nach 32bit FreePascal) - Version 2012 (optimiert und umgebaut) Zwischen den letzten beiden Versionen liegen jede Menge graue Haare, viel Trial-and-Error und ein paar richtig gute Ideen, um das Ganze schneller und effektiver zu machen. Veränderungen des QSORT von Version 4.30(2011) zur Version 5.11(2012) - neuer Listenquicksort (ca.50% schneller) mit 2 Ankern (Anfang und Ende) - Eingabe für 2 Anker angepaßt - MERGE optimiert (besseres Berücksichtigen nur offener Dateien), ca.20% schneller - bin.Baum als Alternative zum 9-99-999 MERGE-Algorithmus - bis zu 999.999 Blätter möglich, MERGE immer nur 2 Dateien (weniger komplex!) - teilweise leider etwas langsamer, da sehr viele MERGE-Vergleiche - Versuche mit iterativem Baum-Algorithmus sowie fixen/variablen Feldgrößen (Ergebnis: rekursiv und variable Felder sind optimal) - Dateioperationen durch SetTextBuf optimiert, leider bleiben ReadLN und WriteLN noch der Flaschenhals, ca.10% schneller - neue Befehle: /- (Sortiere BIS) /G case-(in)sensitive /B bin.Baum-Verfahren - bricht der Algorithmus bei /I und /P000 ab wegen Speicher (selten aber irgendwann mal sind die 2GB voll...), wird vor dem Absturz lieber erst der /B Algoritmus versucht (automatisch) - Eingabedatei und Ausgabedatei über /I und /O (5% schneller), Umleitung bleibt aber möglich (Input/Output) - Befehlsumbenennung /B (alt) wird /P (neu) Pufferanzahl /P (alt) wird /V (neu) temp.Verzeichnis - CARDINAL/LONGINT statt INTEGER (wg.Überlauf) - Hilfe erweitert+Beispiele - Programm kommentiert alle Zwischen-Schritte und Statistik - 16bit-Variante nicht mehr mit dem vollen Funktionsumfang (sprachbedingt) Letztendlich erweist sich jedoch, daß die aus der Not und sprachlichen Begrenzungen geborenen Kompromisse (15 Zwischendateien bzw. das dreistufige Mischen über 10-100-1000 Zwischenpuffer) eigentlich schon so eine Art Optimum waren, die das Programm auch vor 15 Jahren schon beherrschte. Falls jemand an dem Progamm noch etwas verbessern kann - Vorschläge sind gern willkommen (irgendeine Lazarus-Bibliothek aufrufen zählt hier aber nicht). Für dieses BENCH20 Paket ist diese QSORT-Version 5.22** nun optimiert, auch wenn es möglich ist, daß jemand in einem anderen Projekt von mir (z.B. GNOMI) eine andere, ältere oder neuere Version finden kann. c:\projekt\bench20>qsort -? QSORT Sortierprogramm V 5.22 11/2012 (c) ALFWARE B.Schubert QSORT [/Dn] [/Bn] [/R] [/+n] [/Ln] [/Pn] /Ieinfile /Oausfile /R ... reverse Sortierreihenfolge: ABSTEIGEND (Standard: AUFSTEIGEND) /+n ... Sortieren nur ab(+) bzw. bis(-) Spalte n (Standard: 1) /Ln ... max.Länge der zu sortierenden Sätze (Standard: 133) /Pn ... Anzahl Puffer (auf Festplatte) 1..[15]..999 (Standard: 0) /Dn ... dynamische Pufferanzahl (überschreibt /P) (Standard: AUS) n = Zeilen pro Puffer bei /D und /B (Standard: 1.000.000) /B ... neues Verfahren (bin.Baum) (Standard: AUS) über /Pn sind bis 999.999 Puffer zuweisbar (Standard: 99.999) oder /Dn möglichst nicht zu kleines n (Maximal: 20.000.000) /Mn ... Benutze n KB Speicher (Standard: ALLES) /Fn ... Funktionen: 0=ZÄHLE 1=TEILE 2=SORT 4=MERGE (Standard: 7 = alle) /Idn... Eingabedatei (ohne wäre < Umleitung möglich, Standard: INPUT) /Odn... Ausgabedatei (ohne wäre > Umleitung möglich, Standard: OUTPUT) /Zn ... Sortiere nur max. n Zeilen der Eingabe (Standard: ALLE) /G ... Unterscheide Groß/Kleinbuchstaben NICHT (Standard: UNTERSCH.) Weiter mit Taste /Uf ... Name der temporären Bestände (Standard: _TEMP_) /En ... Index des ersten temporären Bestands (Standard: 1) /V ... Nutze das TEMP-Verzeichnis (nur bis /P15) (Standard: NICHT) /W ... temporäre Bestände nicht löschen (Standard: LÖSCHEN) /Xn ... Zeilen am Anfang überlesen (Standard: KEINE) /Nn:mR Teil-Key Numerisch n-m, ABsteigend (Standard: GESAMT-KEY) /Sn:mG Teil-Key String n-m, AUFsteigend, NICHT G/k (Standard: GESAMT-KEY) /Kfn... Keine Duplicate Keys (schreibe in Datei) (Standard: AUS) /Q[F/A] Fortschrittsanzeige [Nichts/nur File/Alles] (Standard: Sorts) /A ... verhindert Wiederanlaufversuch (Standard: AUS) /Tn ... Time Out nach n Minuten 1..999 (Standard: AUS) Weiter mit Taste Die besten Ergebnisse werden erreicht: 1.ohne Parameter/Pufferspeicher -> nur im Hauptspeicher 2.mit Parameter /D ohne n für Verfahren 2 mit bis zu 999 Puffern 3.mit Parameter /B ohne n für Verfahren 3 mit bis zu 99.999 Puffern (bin.Baum) eventuell etwas langsamer Vorsicht!!! bei zu kleinem /Dn... sowie bei der Kombination /D /B Läuft das Programm im Verfahren 1 oder 2 (keine Puffer oder /D ohne n), UND ist über /I eine Eingabedatei angegeben, so wird vor einem eventuellen Abbruch wegen zu wenig Speicher erst noch das /B Verfahren (3) probiert! Verhindert werden kann dies allerdings durch Setzen des /A Paramters. Weiter mit Taste Beispiele: QSORT /IEingabepfad /OAusgabepfad -> sortiert im Hauptspeicher ohne Puffer von Eingabe nach Ausgabe bei Abbruch wird noch der bin.Baum probiert (geht dann meistens). QSORT /P15 /Q < Eingabe > Ausgabe -> sortiert von Eingabe nach Ausgabe (Datei-Umleitung!). Es werden genau! 15 Puffer benutzt, Verfahren 1. (Achtung, es werden vorher die Zeilen gezählt, geringfügig länger) Keine Fortschrittsanzeige. QSORT /D /QA < Eingabe /OAusgabepfad /R /-10 -> sortiert die (umgeleitete) Eingabe nach Ausgabe. Verfahren 1 mit bis zu 999 Puffern (je 1 Mio Zeilen). Umgekehrte Sortierfolge und Key nur Zeichen 1-10. Fortschrittsanzeige vollständig, Files+Sort-Operationen. Weiter mit Taste Hinweis: Parameter /Y hat keine spezielle Funktion, wird aber gebraucht, wenn man NUR die < und/oder > umgeleitete Ein-/Ausgabe sortieren möchte, ohne weitere Parameter (man vermeidet die Hilfe-Seite :-) ** Ein kleines Problem mit dem Free Pascal 2.6 und mehrere Änderungen an einer Zeitberechnungs-Bibliothek haben dem Projekt mittlerweile QSORT Version 5.33 eingebracht. Da ich aber speziell an dem dort eingeführten /C Schalter noch knoble, sollte dieser noch vorsichtig behandelt werden. 4. Rechtliche Hinweise* ====================== Die von mir verwendeten Fremdprogramme FSUM (SlavaSoft) 7ZA (I.Pavlov, 7Zip) VALIDATE (Network Assosiates) PKZIP (PKWARE) sind Eigentum Ihrer Entwickler. Ich nutze sie hier mit großer Dankbarkeit. Die anderen Programme (QSORT, NEUDATEI, LOGBUCH) habe ich selbst entwickelt. Quellen gern auf Anfrage. Das Compile erledigten Borlands Turbo Pascal 7.0 für 16bit und FreePascal 2.6.4 für 32bit - auch hier besten Dank an die Hersteller. Auch die Batches habe ich selbst entwickelt - alles kann frei benutzt und weitergegeben werden, solange es nicht verändert oder von jemandem adoptiert und kommerziell ausgebeutet wird. ENDE der Dokumentation ---------------------- Kontakt: programm@alfware.de oder www.alfware.de