Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Kann man beeinflußen wie stark FB optimiert?

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Profi-Forum
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 12.12.2007, 06:28    Titel: Kann man beeinflußen wie stark FB optimiert? Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
volta



Anmeldungsdatum: 04.05.2005
Beiträge: 1874
Wohnort: D59192

BeitragVerfasst am: 12.12.2007, 09:04    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 12.12.2007, 09:36    Titel: Antworten mit Zitat

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 zwinkern

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 traurig
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
PMedia



Anmeldungsdatum: 14.08.2006
Beiträge: 2847

BeitragVerfasst am: 12.12.2007, 11:52    Titel: Antworten mit Zitat

Du kannst dich ja am Sourceforge-Projekt anmelden und die FreeBasic-Runtimebibliothek entsprechend anpassen zwinkern
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 12.12.2007, 12:03    Titel: Antworten mit Zitat

Gib doch mal den Link ..... neeee, lieber nich. Hab keine Ahnung vom Kompilerbau Zunge rausstrecken
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 zwinkern
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ytwinky



Anmeldungsdatum: 28.05.2005
Beiträge: 2624
Wohnort: Machteburch

BeitragVerfasst am: 12.12.2007, 20:49    Titel: Antworten mit Zitat

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.. happy
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 zwinkern
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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 13.12.2007, 07:45    Titel: Antworten mit Zitat

Hmm, maybe I should give it a try lächeln But first I have to think about my vacation next week, otherwise my girlfriend will be very angry geschockt , so I have to shift this until next year cool

Btw, translating is easy in internet grinsen dict.cc or translate.google.com are helpful resources for difficult words zwinkern
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Bimi



Anmeldungsdatum: 03.12.2007
Beiträge: 66

BeitragVerfasst am: 13.12.2007, 11:33    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
marzec



Anmeldungsdatum: 13.10.2004
Beiträge: 267

BeitragVerfasst am: 13.12.2007, 19:28    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 14.12.2007, 17:23    Titel: Antworten mit Zitat

Hi, nachdem mein angefangenes Posting dank eines Mausklicks mit dem Kopf durch die Mauer wollen grad ins Nirvana gegangen ist, hier nochmal die kurze Version mit den Augen rollen

Erstmal danke an Bimi für die gute Erklärung lächeln 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 grinsen
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 zwinkern
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
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 14.12.2007, 22:05    Titel: Antworten mit Zitat

mul ist ja auch ne multiplikation, das ist nicht mehr primitiv im gegensatz zu shift zwinkern
_________________
"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
Benutzer-Profile anzeigen Private Nachricht senden
Bimi



Anmeldungsdatum: 03.12.2007
Beiträge: 66

BeitragVerfasst am: 19.12.2007, 09:04    Titel: Antworten mit Zitat

MisterD hat Folgendes geschrieben:
mul ist ja auch ne multiplikation, das ist nicht mehr primitiv im gegensatz zu shift zwinkern


...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
Benutzer-Profile anzeigen Private Nachricht senden
vander



Anmeldungsdatum: 03.01.2007
Beiträge: 16

BeitragVerfasst am: 22.12.2007, 14:48    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Profi-Forum Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
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.

 Impressum :: Datenschutz