Testprogramm zur prozessorspezifischen X86-Codeoptimierung

[mschnell]

@Horst_h: Nein, ich werde die Testbedingungen jetzt NICHT ändern, während täglich neue Ergebnisse hereinkommen! Punkt!

Dann macht es für mich (uns) wenig Sinn sich an der Durchführung der aufwändigen aber wenig aussagekräftigen Tests zu beteiligen.

-Michael

[ruewa]

... soll ich NICHT als genervt auffassen?

Doch, das siehst Du schon richtig.

Dann macht es für mich (uns) wenig Sinn sich an der Durchführung der aufwändigen aber wenig aussagekräftigen Tests zu beteiligen.

Einverstanden!

Ich wundere mich nur: Ihr bekrittelt eine angeblich furchtbar inhomogene Datenbasis (eine fundierte Begründung steht freilich noch aus) und schlagt zufallsgeneriert inhomogene Strings als Alternative vor? Ach ja, die werden ja statistisch geglättet! Das Lob der großen Zahl! Das gleiche gilt dann aber plötzlich nicht mehr für Strings aus ein paar tausend Quelltextdateien?

Leute, ich bin dieser ewigen Besserwisserei in Blaue hinein wirklich langsam überdrüssig und hab jetzt einfach mal nachgekuckt.
Hier also die empirische Basis Eurer vernichtenden Kritik:

Code: Alles auswählen

Strings           Matches      Charvergleiche / Call   Durchnittl. Match Result
 
2,373,103           29.50 %         37.88                 17.23
2,008,322           29,85 %         37,91                 17,37
  927,817           29.41 %         37.62                 16.86
1,001,044           29,67 %         37,56                 16,94
2,596,579           30,03 %         38,31                 17,55
2,068,872           30,03 %         38,26                 17,44
  928,631           29.41 %         37.62                 16.86
1,107,802           29.50 %         37.88                 17.08
2,165,024           30,14 %         38,25                 17,50
  928,630           29.41 %         37.62                 16.86
  928,630           29.41 %         37.62                 16.86
1,045,277           29.59 %         37.50                 16.92
2,068,872           30,03 %         38,26                 17,44
  979,116           29,70 %         37,61                 16,94

Bedenklich, bedenklich! Da muß man als Mathematiker glatt befürchten, daß bei Signalen zwischen 50 und 170% die zweite Nachkommastelle unrettbar verschmiert!

Das verstehe ich! Was ich nicht verstehe, ist, warum Ihr vollkommen ignoriert, daß es auf Datenhomogenität hier gar nicht ankommt, da hier überhaupt keine Absolutwerte (zwischen verschiedenen Computern) miteinander verglichen werden, sondern vielmehr Relativwerte, die aus jeweils bis aufs letzte Bit identischen Daten (auf dem jeweiligen Computer) gewonnen werden.

Oder um es mal anders auszudrücken: Eine Routine, die einen String nach einem Char durchsucht, und die doppelt so schnell ist wie eine zweite vergleichbare Funktion, wird in hinreichender Näherung sowohl dann doppelt so schnell sein, wenn beide den Treffer nach 60 Zeichen finden, wie auch dann, wenn sie ihn erst nach 120 Zeichen finden. Und erst recht dann, wenn der Treffer mal auf der 59 und mal auf der 61 liegt!

Ist es zuviel verlangt von einem Mathematiker, das zu verstehen? Ich meine, wir sind doch alle keine Dummköpfe!

Aber irgendwie ist man ja immer auch Mensch, gell, Michael...

Gruß Rüdiger


PS: Wie Ihr seht, sind die Rückmeldungen bisher leider immer noch viel zu dünn. Bitte beteiligt Euch, sofern Ihr das nicht schon getan habt. Es wäre wirklich schön, wenigstens 100 Datensätze zusammenzubekommen!

[Horst_h]

Hallo,

Hat doch keiner bezweifelt.

Aber es funktioniert ja.

Aber es ging Dir doch auch mal kurzzeitig darum, dass die Leute nicht solange auf das Einlesen der Dateien warten müssen.Da bot es sich doch an, direkt die Teststrings selbst zu erzeugen und dann am besten für jeden gleich.
Ich bin dennoch über die enorme Streuung der Werte erstaunt. Das bei einer CPU eine ASM-Abschnitt mit 150% läuft bei einer anderen mit 77%, was ja immer auf das Original Pos bezogen ist.
Core i5-3570K_CPU kommt mir auch seltsam vor.Der kommt nicht unter 80%, ist Lazarus 1.3, SVN revision 44761 soviel besser bei Pos?

Gruß Horst

[mschnell]

Da muß man als Mathematiker glatt befürchten, daß bei Signalen zwischen 50 und 170% die zweite Nachkommastelle unrettbar verschmiert!

Was Du zu weiter oben darüber geschrieben hast, wie die Ergebnisse für Vergleiche zwischen kleine Assembler-Schleifen teilweise unter Windows ganz anders ausfallen als unter Linux ist wirklich bedenklich, da ein Unterschied nach Betriebssystem theoretisch nicht auftreten dürfte. Betriebssystem-Latenzen sollten sich auf alle Schleifgen-Implementierungen proportional gleich auswirken, nach der Verhältnis-Bildung also nicht mehr existieren (bis auf die statistisch schwankende 2. Nachkomma-Stelle.)

Bei identischen Test-Voraussetzungen kann man tatsächlich leicht Signifikanzen ausrechnen und die Ergebnisse statistisch beurteilen.

-Michael

[Eb]

Hier mein Testergebnis.
Gruß Eb

[BeniBela]

Hier gibt es nur

Directory: /opt/lazarus
Filename Mask: *.pas;*.pp;*.inc;*.lpr;*.dpr
Files loaded: 0
Strings loaded: 0

[ruewa]

Was Du zu weiter oben darüber geschrieben hast, wie die Ergebnisse für Vergleiche zwischen kleine Assembler-Schleifen teilweise unter Windows ganz anders ausfallen als unter Linux...

Da hast Du was mißverstanden. Ich hatte das weder erwartet noch irgendwelche Anhaltspunkte dafür gefunden. Ich hatte Windows nur einmal dahingehend erwähnt, daß mir sporadische (und klar identifizierbare) Störspitzen bisher nur bei Windows-Daten aufgefallen waren. Also beim Thema "Streuung" von einzelnen Runs. Das wundert mich auch nicht wirklich, da ich denke, daß sich Linux disziplinierter verhält - ist aber vielleicht auch bloß ein Vorurteil. Das sind aber wirklich nur vereinzelte Beobachtungen, um etwas genaueres darüber sagen zu können, braucht es einfach mehr Daten.

Aber es ging Dir doch auch mal kurzzeitig darum, dass die Leute nicht solange auf das Einlesen der Dateien warten müssen.Da bot es sich doch an, direkt die Teststrings selbst zu erzeugen und dann am besten für jeden gleich.

Ja, das schon. Ich werde das dahingehend lösen, daß ich dem Programm noch eine NumEdit für die maximale Anzahl von Zeilen spendiere, auf 1.000.000 Strings voreingestellt. Dann bricht es einfach das weitere Einlesen von Dateien ab und gut ist's. Das sind 3 Zeilen Quelltext, darauf hätte ich ruhig schon früher kommen können...

Ich habe nicht prinzipiell etwas gegen Deine Generierung künstlicher Teststrings, ich messe dieser Frage nur keine große Bedeutung bei und scheue gravierendere Umbauten, solange der Test läuft. Das kann man meinetwegen beim nächsten Anlauf machen, falls es einen solchen geben wird.

Was natürlich gar nicht geht, ist, in diesem Stadium auch noch an den getesteten Funktionen rumzuschrauben - das würde alle bisherigen Beiträge komplett entwerten. Das kommt überhaupt nicht in Frage! Wundert Dich das?

Und was das abschätzige "es funktioniert ja" angeht: Hast Du eine leise Vorstellung davon, wieviel Arbeit (incl. Versuchen, Mißerfolgen, Design-Überlegungen, Recherche, Entwürfen, Vorläufertests) in diesem unscheinbaren Programm steckt? Da muß ich mir nicht vorhalten lassen, mich an einer aus meiner Sicht völlig unkritischen Stelle "nicht auseinandergesetzt" zu haben. Was, glaubst Du, steckt wohl hinter der Einschätzung, daß diese Datenstruktur Versuchs-unkritisch und hinreichend homogen sei? Pfeifen im Walde? Es ist vollkommen legitim, diese Einschätzung nicht zu teilen - wenn Du gute Gründe dafür findest. Aber denunziere sie bitte nicht leichtfertig als gedankenlos, solange Du die dahinterstehenden Überlegungen nicht kennst.

Gruß Rüdiger

PS: Danke, Eb & Horst!
@BeniBela: Weiß jetzt nicht, wie "/opt/lazarus" zustandekam. Normalerweise liegt Lazarus unter Linux in /usr/share/lazarus/, das ist auch die Voreinstellung von AlignTest.

[Patito]

Hier noch ein Ergebnis...

Bisher habe ich mich um das Alignment nur in ein paar Spezialfällen gekümmert.
Das systematisch zu untersuchen ist natürlich spannend.

[BeniBela]

@BeniBela: Weiß jetzt nicht, wie "/opt/lazarus" zustandekam. Normalerweise liegt Lazarus unter Linux in /usr/share/lazarus/, das ist auch die Voreinstellung von AlignTest.

Weil ich es in /opt installiert habe...

SVN checkout.

In /usr ist nichts

[ruewa]

@BeniBela: Ich kann das nicht reproduzieren. Auch wenn ich einen ungültigen (oder leeren) Pfad als Default setze, funktioniert bei mir alles so, wie es sollte. Und bei den Windows-Leuten, die Lazarus auf einer anderen Platte als C:\ haben, gab es bisher auch keine Probleme.

Die Pfadauswahl geschieht ja zwingend über den Dialog. Wenn dann das Verzeichnis im Memo angezeigt wird, beinhaltet das, daß der Pfad tatsächlich vorhanden ist (d.h. DirectoryExists(Pfad) = true). Das Laden der FileListe selbst ist dann simpelster Standard:

Code: Alles auswählen

  FileList := FindAllFiles(Path, FileMask, true);
  NumFiles := FileList.Count;

Irgendwie gehen mir da jetzt leider die Ideen aus...

Ich nehme an, Du hast schon via Filemanager überprüft, ob in dem Verzeichnis wirklich was drin ist? Vielleicht liegt eine neuere Installation von Lazarus woanders und hat die Inhalte des alten Verzeichnisses gelöscht (so war das bei mir mal, zurück blieb ein leeres Verzeichnis /usr/share/lazarus/1.2.2/). Was Du dann natürlich noch tun könntest, wäre, die Projekteinstellungen auf Optimierungstufe 1 und DebugInfo ON zu stellen und in ReadData (und veilleicht noch DirEditAcceptDirectory) nachzusehen, wo es klemmt.

Aber beim Test bitte wieder zurückstellen auf Optimization Level 2 und DebugInfo OFF. Die anderen Quelltextdateien können damit nichts zu tun haben, die bitte nicht editieren, sonst fliegen die Ergebnisse wegen falscher MD5-Summen aus der Auswertung.

Gruß Rüdiger

Edit: Eine Idee kommt mir gerade noch: FindAllFiles wurde erst kürzlich hier im Forum und im Bugtracker diskutiert und auch verändert. Wenn Du eine Trunc- oder RC-Version gezogen hast, könnte da ein Bug versteckt sein. Das kann ich aber von hier aus nicht überprüfen (bin noch auf 1.2.4).

[mschnell]

Das kann man meinetwegen beim nächsten Anlauf machen, falls es einen solchen geben wird.

Würde mich freuen, wenn der Test so implementiert wird, dass man ihn z.B. beliebig lange laufen lassen kann und dabei sieht, dass die Streuung immer kleiner wird. Und dass für alle Chips exakt derselbe Test gefahren wird. Und dass er einfach auf einer beliebigen Maschine gestartet werden kann (Windows und Linux executables, jeweils 32 und 64 Bit, keine Anforderungen an die System-Umgebung) möglichst vergleichbare Varianten der Assembler-Funktionen. Assembler-Funktionen, die möglichst nur einen genau umrissenen Aspekt testen (z.B. Suchschleife oder Call-Overhead). Ausgabe der Satistisch relevanten werte: Laufzeitvberhältnis zwischen den jeweils zu vergleichenden Code-Schipseln: Mittelwert und Varianz.

Die ganze au8fwändige Vorarbeit ist ja bereits gemacht.

-Michael

[Horst_h]

Hallo,

vielleicht will ja BeniBela meine abgewandelte Version ohne Datei einlesen mal versuchen.Für 32 Bit müsste die Random FUnktion funktionieren.
Da der EpikTimer unter Windows sehr hoch auflöst, muss man nicht soviele Runden drehen. In Zeile 91 von main.pas kann ma das ändern.

Natürlich passen die Daten nicht zu ruewas Auswertung.Aber den Effekt sieht man dennoch.
Function CharPos_Asm3c_InsideLoop_32 ist mehr als doppelt so langsam als _64
Bei 15 Runden steht immer noch 128.3% bei ...Loop_32, dauert nur 15 mal länger.

Code: Alles auswählen

all
    Run 4                                    Verified   12,10 ms ( 69,6 %)  =    25 ns / Call  =    22 ns Loop time / Call
 
Function CharPos_Asm3c_InsideLoop_32
    Run 1                                    Verified   22,06 ms (126,8 %)  =    45 ns / Call  =    43 ns Loop time / Call
    Run 2                                    Verified   22,07 ms (126,9 %)  =    45 ns / Call  =    43 ns Loop time / Call
    Run 3                                    Verified   22,14 ms (127,2 %)  =    45 ns / Call  =    43 ns Loop time / Call
    Run 4                                    Verified   22,06 ms (126,8 %)  =    45 ns / Call  =    43 ns Loop time / Call
 
Function CharPos_Asm3c_InsideLoop_64
    Run 1                                    Verified   8,962 ms ( 51,5 %)  =    18 ns / Call  =    16 ns Loop time / Call

Gruß Horst

[BeniBela]

Es hat die ; nicht gemocht

[magnetron]

Hallo,

anbei meine zwei Resultate, 32bit auf win 64bit und 64 bit auf Linux.
Ich bin gespannt auf die Auswertung und die weiteren Erkenntnisse.
Viele Grüße, Stefan

[Horst_h]

Hallo,

noch ein paar Linux-32 Varianten,
AMD MX 1500 aka Geode NX mit 1 Ghz: Total time elapsed: 01:04:37 ( 21 Watt ) AMD MX 1500 aka Geode NX mit Ghz
Processor LE-1100 : Total time elapsed: 00:36:39 ( 85 Watt )

Die Laufzeiten liegen nicht am einlesen der Dateien.

Gruß Horst