 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 1.85 Mai 2011

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 
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. Test20 schafft nur noch den Sort mit 999 Zwischenspeichern.

Warum gibt es so große Unterschiede zwischen den 4 einzelnen Sorts?
Mein Sort-Programm wird in 4 verschiedenen Varianten benutzt:
- mit 999 Zwischenspeichern
- mit gar keinem
- mit 15 Zwischendateien 
- mit x Zwischenspeichern fester Größe (2000 Zeilen)
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 16?, 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 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 ! ca.    0:01 !                       !
!  11   !     1.000.000	!      68.040.362 ! ca.    0:02 !                       !
!  12   !     2.000.000	!     136.017.739 ! ca.    0:04 !                       !
!  13   !     5.000.000	!     340.027.832 ! ca.    0:10 !                       !
!  14   !    10.000.000	!     680.034.938 ! ca.    0:30 !                       !
!  15   !    20.000.000	!   1.359.965.496 ! über   2:00 !                       !
!  16   !    50.000.000	!   3.400.075.358 ! über   1:00 ! SORT 2+4 brechen ab   ! 
!  17   !   100.000.000	!   6.800.024.510 ! über   2:00 ! SORT 2+4 brechen ab   !
!  18   !   200.000.000	!  13.600.194.417 ! über   5:00 ! SORT 2+4 brechen ab   !
!  19   !   500.000.000	!  34.001.147.812 ! über   5:00 ! SORT 2,3,4 brechen ab ! 
!  20   ! 1.000.000.000	!  68.001.748.365 ! über   5:00 ! SORT 2,3,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 
Ergebnisse zusammengetragen habe.

Im Ordner VERSION\BENCH32 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.

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 16-bit Lösung gestrickt, die sich aber leider aus technischen
Gründen etwas unterscheidet von der normalen 32-bit Variante 
(siehe dazu auch unter Punkt 3) 
Die Daten (MD5-Summen usw.) sind nicht vergleichbar! Ich habe in den
Ordnern VERSION\16bit und VERSION\BENCH16 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 VERTEILE, 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.

Im Ordner VERSION\BENCH64 findet man logisch die Daten, die rauskommen sollen.
Hier fällt noch ein BIGBEN64.ZIP auf, welches von (den größeren Brüdern der START)
BIG1, BIG2, BIG3 und BIG4 stammt. Diese rufen auch noch TEST17 bis TEST20 mit auf.
Der Befehl zum Einpacken heißt dann eben SAUBIG64.
Meine Versuche haben jedoch ergeben, daß außer Computer-Quälerei nicht viel dabei
herauskommt. 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 20.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.

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\16bit\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


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 Hilfe nur so im RAM.
Vielleicht könnte man es noch schneller machen oder größere Bestände
in Angriff nehmen, jedoch finde ich 
a) die 68 GB aus TEST20 schon nicht ganz ohne auch für moderne Computer
   und Festplatten (zumal die Menge ja auch bis zu 7x gebraucht wird,
   1x unsortiert, 4x sortiert, als _TEMP_ Bestände sowie versteckt in
   Windows Swapping)
b) momentan keinen trivialen Ansatz, um ein paar technische Grenzen
   zu sprengen, als da wären
   - die 999 als Anzahl der Zwischenpuffer (mein Problem bzw. der Algorithmus)
   - die 2 GB im Heap (Pascal als Programmiersprache)
   - der Algorithmus beim Einmischen der 999 Zwischenpuffer
     (ich verwende ein dreistufiges Mischen über 10, 100 bzw. 1000)
     Verbesserungen sehe ich hier 
     - nach manchem mißratenem Versuch in die falsche Richtung (einstufig)
     - ein paar grauen Haaren und grauenhaften Laufzeiten,
     nur noch in einem binären Mischbaum. 
     Wenn da jemand eine Idee hätte, ob sich der Aufwand lohnen würde
     oder ob gar schon der damalige aus der Not geborene Kompromiß
     (Pascal nur 15 Dateien gleichzeitig) mit den 10, 100, 1000 das
     Optimum sein könnte.
     
Für dieses BENCH20 Paket ist diese QSORT-Version 4.30 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:\temp\bench20>qsort /?

 QSORT   Sortierprogramm   V 4.30   03/2011             (c) ALFWARE B.Schubert

 QSORT [/R] [/+n] [/Ln] [/Bn] < einfile > ausfile

   /R  ... reverse Sortierreihenfolge: ABSTEIGEND       (Standard: AUFSTEIGEND)
   /+n ... Sortieren erst ab Spalte n                   (Standard: 1)
   /Ln ... max.Länge der zu sortierenden Sätze          (Standard: 133)
   /Bn ... Anzahl Puffer (auf Festplatte) 1..[15]..999  (Standard: 0)
   /Dn ... dynamische Pufferanzahl (überschreibt /B)    (Standard: AUS)
           n = Zeilen pro Puffer bei /D                 (Standard: 2000)
   /Nf ... Name der temporären Bestände                 (Standard: _TEMP_)
   /P  ... Nutze das TEMP-Verzeichnis (nur bis /B15)    (Standard: NICHT)
   /T  ... temporäre Bestände nicht löschen             (Standard: LÖSCHEN)
   /En ... Index des ersten temporären Bestands         (Standard: 1)
   /Fn ... Funktionsumfang: 1=TEILE 2=SORT 4=MERGE      (Standard: 7 = alle)
                            0=ZÄHLE
   /Idn... Eingabedatei, dann keine < Umleitung möglich (Standard: INPUT)
   /Zn ... Sortiere nur max. n Zeilen der Eingabe       (Standard: ALLE)


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.2 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