 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.02 Februar 2013

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 <www.slavasoft.com>
;
; 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 
          32bit    32bit-v2011.ZIP       Programme von 2011, 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 :-)


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.4.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: bernd.schubert22@alfware.de oder www.alfware.de