|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 12.12.2007, 07:28 Titel: Kann man beeinflußen wie stark FB optimiert? |
|
|
Ich hab mal ein paar Experimente in FB mit dem inline ASM gemacht um zu sehen wie ich ASM Fragmente optimieren kann. Zur Zeitmessung habe ich den TSC genutzt, sollte also halbwegs genau sein.
Um die Meßungenauigkeit zu ermitteln hab ich erstmal eine leere FOR-Schleife gebencht und dann, aus Langeweile eine ASM Schleife gebencht. Das ASM nur halb so viele Takte benötigt hat mich, bei so einer simplen Aufgabe, schon etwas gewundert. Also hab ich mir den von FB produzierten ASM Code mal angesehen. Da zählt FB die Schleifenvariable doch tatsächlich im Speicher herunter, anstatt in einem Register? Kann man das beeinflußen, ich habe weder eine Kompileroption noch einen entsprechenden FB Befehl gefunden. Btw, zum steuern der Optimierung hab ich gar nix gefunden, macht das FB komplett automatisch? Das wäre schlecht, da man normalerweise die Optimierung zum Debugging abschalten können sollte.
P.S. Standardoptimierungen wie var*2 -> shl var, 1 macht FB selbstverständlich. Aber kann man das nicht per Kompileroption steuern? |
|
Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005 Beiträge: 1875 Wohnort: D59192
|
Verfasst am: 12.12.2007, 10:04 Titel: |
|
|
nein diese Möglichkeit gibt es beim FBC nicht.
Wie du selbst schon festgestellt hast werden einige Integeroperationen durch Schiebebefehle ersetzt und Fließkommaoperationen direkt als FPU - ASManweisungen gesetzt, der ASM-Quelltext wird dann aber nicht weiter optimiert. _________________ Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
Nach oben |
|
|
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 12.12.2007, 10:36 Titel: |
|
|
Schade, ich hatte gehofft das man irgendwie zur Fehlersuche Optimierungen komplett abschalten und zum optimieren Variablen in Registern halten kann. Naja, vllt geht das ja später mal. Ist ja erstmal Version 0.18, da ist ja später noch Zeit für
Edit:
P.S. Hab gelesen das man per Switch Optionen an den Assembler übergeben kann. Beherrscht GAS optimierungen die man ein/ausschalten kann? Google bringt mir grad keine Switch Liste dafür |
|
Nach oben |
|
|
PMedia
Anmeldungsdatum: 14.08.2006 Beiträge: 2847
|
Verfasst am: 12.12.2007, 12:52 Titel: |
|
|
Du kannst dich ja am Sourceforge-Projekt anmelden und die FreeBasic-Runtimebibliothek entsprechend anpassen |
|
Nach oben |
|
|
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 12.12.2007, 13:03 Titel: |
|
|
Gib doch mal den Link ..... neeee, lieber nich. Hab keine Ahnung vom Kompilerbau
Mal ernsthaft, wird irgendwo an Optimierungen für FB gearbeitet? Ich meine jetzt nicht nur die Optimierung des Programmcodes durch den Kompiler, das sollen mal schön die Profis machen, ich meine die Arbeitsweise der internen Funktionen. z.B. Stringfunktionen.
Ich hatte da mal ne Webseite für VB gefunden, da wurden verschiedenste Funktionen von VB durch optimierte Varianten nachgebaut und getestet, das wäre doch für FB auch interessant, oder? Wenn die Ergebnisse dann direkt in die Runtime einfließen würde .....
Nur mal so als Idee auf deinen Kommentar |
|
Nach oben |
|
|
ytwinky
Anmeldungsdatum: 28.05.2005 Beiträge: 2624 Wohnort: Machteburch
|
Verfasst am: 12.12.2007, 21:49 Titel: |
|
|
hi,
wenn du dich an das Entwickler-Team wenden möchtest, solltest du vorher mal hier reinkucken..
..schon um zu sehen, wie gut deine Englischkenntnisse sind..
Bei Anfragen im Forum ist es nicht so schlimm, wenn dein Englisch nicht fließend ist(Beispiele dafür gibt es genug..)
Wenn du aber ernsthaft über eine Beteiligung nachdenkst, solltest du schon einigermaßen fließend sprechen
Kuck einfach mal rüber..
Gruß
ytwinky _________________
v1ctor hat Folgendes geschrieben: | Yeah, i like INPUT$(n) as much as PRINT USING.. | ..also ungefähr so, wie ich GOTO.. |
|
Nach oben |
|
|
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 13.12.2007, 08:45 Titel: |
|
|
Hmm, maybe I should give it a try But first I have to think about my vacation next week, otherwise my girlfriend will be very angry , so I have to shift this until next year
Btw, translating is easy in internet dict.cc or translate.google.com are helpful resources for difficult words |
|
Nach oben |
|
|
Bimi
Anmeldungsdatum: 03.12.2007 Beiträge: 66
|
Verfasst am: 13.12.2007, 12:33 Titel: |
|
|
Compileroptimierungen sind so ein Kapitel für sich...
Ein optimierender Compiler optimiert eine Leerschleife nicht, er haut sie komplett raus...
Nicht nur FreeBasis, sondern auch viele anderen Compiler wie z.B. die GNU Compiler Collection halten die Zählvariable im Speicher und nicht in einem Register. Das hat mehrere Gründe...
Irgendwie habe ich das Gefühl das das Wissen um Assembler irgendwo vor 15-20 Jahren stehen geblieben ist. Immer wieder trifft man auf folgende Aussagen:
* xor <r>,<r> ist schneller als mov <r>,0 zum löschen eines Registers
* use shl <r>,2 instead of imul 4
Ja, das galt einmal...vor vielen Jahren als die CPUs keine Caches hatten, nicht superskalar waren, über kein internes Code Optimizing verfügten und alleine im System waren und sich nicht mit anderen CPUs oder CPU-Kernen synchronisieren mussten.
Das ist heute etwas anders.
Heute arbeiten wir ausschließlich mit RISC-Prozessoren und ein Intel hat schon lange nicht mehr nur die paar Allzweckregister (eax,ebx,...), die noch nie welche waren. Intern arbeitet eine moderne x86 CPU mit einem translator, der den Assemblercode so wie du ihn gepostet hast in internen RISC-Code umwandelt und dann optimiert. Für moderne Prozessoren gilt:
* alle primitiven Instruktionen haben eine konstante Ausführungszeit. Ein shl läuft nicht schneller und nicht langsamer als ein mov oder ein xor
* Als verfügen über ein 1st LC der mit vollem Takt läuft - ein Zugriff auf diesen Cache ist kaum langsamer als ein Registerzugriff. Der scheinbare Speicherzugriff ist also in Wirklichkeit ein Cachezugriff weil die Zählvariable mit tödlicher Sicherheit im Cache steht
* Bei mehr als einem CPU Kern (egal ob dual core oder mehrere CPU's) besteht das Synchronisierungsproblem. Caches lassen sich synchronisieren, Register nicht.
* eine moderne CPU hat Registerbänke und entscheidet selbst welche Werte in Registern abgelegt werden und welche nicht.
Ein wenig Historie (falls es überhaupt jemanden interessiert):
Der Umschwung der Prozessoren begann etwa 1995. Damals gab es bei Intel den i486 und den Pentium. Doch schon damals erkannte man, das die Kombination aus RISC und CISC ind From von CRISC an ihre GRenzen stößt. CISC ist nicht für hohe Taktraten geeignet. Also entschloss sich Intel komplett von Vorne zu beginnen und entwickelte den Pentium Pro. Dieser war eine reine 32Bit RISC-CPU und die Basis aller heutigen bis einschl P4. Doch der Befehlssatz der x86 Architektur ist alles andere als RISC-tauglich. Damit jedoch die User ihre Programme weiterhin verwenden konnten, musste die CPU mit diesem Code umgehen können und deshalb erhielt der PP einen decoder, der die x86 in seine RISC Struktur überführte. Ab diesem Zeitpunkt stimmt der Assembler Code nur noch inhaltlich mit dem Ausführcode überein. Trotz dieses Zwischenschrittes war der PP bei gleicher Taktfrequenz erheblich schneller als ein gleich getakteter Pentium-S - aber nur bei 32Bit. Bei 16 Bit war er langsamer weil die 16 Bit x86 Architektur im PP emuliert wurde. Dies galt auch für alle folgenden (Pentium II, Pentium III) - nur dort fiel es nicht mehr auf, weil es keine vergleichbare CPU alter Bauart mehr gab.
Dann kam der Athlon von AMD und hängte den Pentium gnadenlos ab. Während nämlich Intel die Compilerhersteller mit Informationen versorgte wie man optimierten Code für die neuen CPU's produziert, verlagerte AMD die Codeoptimierung einfach in die CPU. Beim decoden der x86 Instruktionen wird der Code auch gleich optimiert und das war auch der Grund warum der Athlon die Intel CPU in Benchmarks manchmal weit hinter sich lies und manchmal eben nicht. Dies hieng davon ab ob das Testprogramm mit einem optimierenden Compiler entwickelt wurde oder nicht.
Die Optimierung in die CPU zu verlagern macht auch Intel beim großen
Redesign der Architektur, was als Ergebnis den Pentium 4 hervorbrachte.
AMD64 und die Core 2 Duo Reihe arbeiten nicht nur mit 64 Bit, sondern wieder mit völlig neuen Kerneln - die Assemblersprache mit der diese Programmiert werden, stammt noch vom 8086, die 32 Bit Befehle vom 80386 aus dem Jahre 1988...
Was bedeutet das für die Optimierung?
Die bestehenden und bekannten Techniken (xor eax,eax stat mov eax,0) machen heute keinen Sinn mehr. Man kann die Performance auch nicht an einer Leerschleife ausmachen, weil dieser gerade mal drei bis fünf Befehle aus dem Befehlssatz nutzt.
Datenabhängigkeiten Vermeinden:
Eine Datenabhängigkeit entsteht wenn die Operation n+1 auf das Ergebnis der Operation n angewiesen ist. Dies ist bei einer Leerschleife faktisch immer der Fall. Die Zählvariable wird gelesen, geprüft und geändert. Beim erneuten Lesen der Zählvariable muss gewartet werden bis der Wert vom vorherigen Durchlauf geschrieben wurde. Eine performante Schleife prüft nicht ob die Zählvariable den Zielwert erreicht hat...
Diese Code wurde mal von einem "Assembler-Freak" gepostet als schnelle Nichtstu-Zählschleife
Code: |
xor ecx,ecx
l1:
inc ecx
cmp ecx,1000
jne l1
|
inc schreibt ecx, cmp liest ecx -->Datenabhängigkeit
...und nun vergleicht mal mit der von Intel vorgeschlagenen Variante
Code: |
movl cx,1000
l1:
dec cx
jecxz l2
jmp l1
l2:
|
Kein lesen, jecxz springt wenn cx 0 ist und prüft dies im Gegensatz zu cmp anhand der Flags. Und vor allem die branch-prediction der CPU kommt damit besser klar....
...ich will hier nicht alles zumüllen - wer sich für die Optimierung interessiert -> PM _________________ Rechtbehelf:
Rechschreibverfehlungen, Vergehen an der Deutschen Sprache sowie Stabwechselverbuchselungen unterliegen dem Urheberrecht, sind voll beabsichtigt und fördern das aufmerksame Lesen. |
|
Nach oben |
|
|
marzec
Anmeldungsdatum: 13.10.2004 Beiträge: 267
|
Verfasst am: 13.12.2007, 20:28 Titel: |
|
|
keyhole optimierungen sind zwar net, bringen auch in in paar fällen performance sind aber architekturabhängig. fb tut da ein paar dinge damit diverse "benchmarks" chneller laufen. wirkliche optimierung wie mit data flow analysis auf ntermediate language leel wie es die gnu compiler suite macht gibts nicht. wird auch kaum möglich sein dss in fb einzupflegen, is ein gar grausiges flickwerk... _________________ Yagl - yet another gameprogramming library |
|
Nach oben |
|
|
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 14.12.2007, 18:23 Titel: |
|
|
Hi, nachdem mein angefangenes Posting dank eines Mausklicks grad ins Nirvana gegangen ist, hier nochmal die kurze Version
Erstmal danke an Bimi für die gute Erklärung Mein Wissen ist in etwa auf dem 486/Pentium Level stehengeblieben, später war es nicht mehr nötig und auch zu aufwendig umfangreiche Optimierungen auf Assembler Ebene zu machen. Die Sache mit U in V Pipeline gepaarten Befehlen und dem Risc Kern hab ich noch mitbekommen, daraufhin zu optimieren hab ich aber lieber dem Kompiler überlassen
Unabhängig von den neuen CPU Kernen sollte doch aber stimmen, wenn ich mit dem TSC eine doppelt so lange Ausführungszeit für einen Codeabschnitt messe, dann ist das entsprechende Programm halb so schnell? Und da sehe ich sehr wohl, das die FB Kompilervariante der FOR Schleife halb so schnell ist wie mein ASM Code, auch wenn der vllt nicht optimal ist
Code: |
mov ecx, 1000
L1:
...
dec ECX
jnz L1
|
Genauso läuft die Routine a = b*5 ca 25% langsamer als z.B. a = b*4 + b, was ich darauf schiebe, das b*4 durch ein Shift ersetzt wird, anstelle eines IMul. Vllt ist es bei modernen CPUs nicht mehr so einfach zu erklären, aber Optimierung bringt scheinbar auch hier etwas. Auch wenn die Gründe für die Beschleunigung vllt nicht die sind die ich vermutet hatte.
Zum handoptimieren sollte man Vtune bzw, ... mir fällt grad der Name von dem AMD Tool nicht ein, benutzen. Ist aber ziemlich kompliziert und braucht Zeit. Aber es ist schon nicht schlecht wenn der Kompiler so ein paar Sachen eingebaut hat.
Bin grad etwas unter Zeitdruck, aber ich hoffe wir können das Topic in den nächsten Wochen weiterführen.
So long ... |
|
Nach oben |
|
|
MisterD
Anmeldungsdatum: 10.09.2004 Beiträge: 3071 Wohnort: bei Darmstadt
|
Verfasst am: 14.12.2007, 23:05 Titel: |
|
|
mul ist ja auch ne multiplikation, das ist nicht mehr primitiv im gegensatz zu shift _________________ "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra |
|
Nach oben |
|
|
Bimi
Anmeldungsdatum: 03.12.2007 Beiträge: 66
|
Verfasst am: 19.12.2007, 10:04 Titel: |
|
|
MisterD hat Folgendes geschrieben: | mul ist ja auch ne multiplikation, das ist nicht mehr primitiv im gegensatz zu shift |
...gehört intern ab dem i486 zu den primiven Befehlen. _________________ Rechtbehelf:
Rechschreibverfehlungen, Vergehen an der Deutschen Sprache sowie Stabwechselverbuchselungen unterliegen dem Urheberrecht, sind voll beabsichtigt und fördern das aufmerksame Lesen. |
|
Nach oben |
|
|
vander
Anmeldungsdatum: 03.01.2007 Beiträge: 16
|
Verfasst am: 22.12.2007, 15:48 Titel: |
|
|
Zitat: | Ich hatte da mal ne Webseite für VB gefunden, ... | VBSpeed
Sicher kann man das nicht 1:1 in FB übernehmen, da die Vorraussetzungen die zur Entwicklung der Routinen geführt haben verschieden sind. Aber so etwas in der Art könnte ich mir für FB auch vorstellen. Dabei sollte die Zielstellung sein die vorhanden/eingebauten Funktionen zu optimieren, wenn nötig auch mit ASM. Bei FB ist das einfacher zu realisieren als in VB, durch den inline ASM. Aber FB Code soll auf verschiedenen Platformen laufen, was es wieder kompliziert macht.
Generell wäre es gut eine Codedatenbank mit Resourcenvgl. der Routinen(Speed/Speicher) zu haben. |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|