Performance erhöhen?

otze

performance ist stark projektabhängig.
wie sollen wir dir sagen, wo dein programm rumlahmt, oder wo man optimieren kann, wenn wir nichtmal wissen, _was_ dein programm macht. Eins kann ich dir bisher sagen: and er gemappten datei liegts sicher nicht, das mappen ist sehr schnell.
aber schon bei deiner funktion die einzelne zeichen auslesen soll, weis ich nichtmehr, ob da ein flaschenhals ist:liest du einfach zeichen für zeichen aus? oder suchst du erst in der gemappten datei nach dem zeichen?

dazu muss man sagen, dass die optimierung zu einer schlanken datei jedes inlinen für den compiler unmöglich macht, da ein inline eine automatische vergrößerung der datei mit sich bringt.

ps:der bcb 4.0 taugt heutzutage nichts mehr, als vergleich: der bcb 6 ist auch schon mehrere Jahre alt! such dir lieber einen moderneren compiler wie VC++7.1, gcc(enthalten im MinGW/Dev-C++ ,beide kostenlos),Comeau,und einige andere

Der vorteil an den modernen compilern ist, dass sie unheimlich gute optimierungsalgorithmen haben, die aus deinem programm noch einiges rausholen können.

ansonsten,wenn du selber nicht mal ansatzweise weist, wie viel die einzelnen operationen verschlingen, such dir erstmal die hotspots raus, dh die funktionen/klassen, die viele male im verlauf des programms benutzt werden. Diese hotspots kannst du dann testen, wieviel zeit sie verbrauchen, und dann ma schaun, was da noch so geht

1. würde ich das inlining dem Compiler überlassen, der macht das in 99% der Fälle sicher besser.
Mit diesen Mikro-Optimierung wirst du nur in speziellen Fällen was erreichen.
2. wird der größte Teil der Laufzeit in relativ wenig Code-Abschnitten verbracht. Wenn du das Falsche optimierst und den Code dort 10mal so schnell machst, merkst du immer noch keinen Unterschied -> besorg dir nen Profiler.

PuppetMaster2k schrieb:

Für Performancesteigerung gibt es viele Möglichkeiten. Wie wärs wenn du das Konzept der Lazy Evaluation (späte Berechnung) implementierst, dann ist dein Programm evtl. nur noch bei der Berechnung etwas langsamer aber ansonsten performant.

Das kann man niemals so allgemein sagen. Vielleicht ist gerade für sein Programm, das etwas, was alles noch schlimmer macht.
So lange der Fragesteller keinen Überblick hat, kann ihm vermutlich auch keiner helfen.

code_pilot

hallo,

erstmal danke für eure antworten!
Also, bei meinem Projekt handelt es sich um eine Scriptsprache. Das Script, das ausgeführt werden soll, wird zuvor in den Speicher gemappt, und halt mit einer Funktion immer Zeichen für Zeichen ausgelsen - um die Frage von otze zu beantworten: Diese Funktion liest immer ein Zeichen, setzt einen offsett höher (sprich: Eine Variable, welche die aktuelle Position im gemappten file enthält, da das gemappte file ein dynamisches char-Array ist) und gibt dieses gelesene Zeichen zurück. Zudem erfolgt eine Prüfung, ob ein \r gelesen wurde, wenn dies der Fall ist setzt er den offsett noch einmal höher um das nachfolgende \n zu überspringen.

Hmm alles jetzt auf einen anderen Compiler umzustellen könnte Schwierig werden :(...

Grüsse,
code_pilot

Hör doch endlich auf, rumzuraten und wirf nen Profiler an.

otze

du gehst in einem script wirklich zeichen für zeichen weiter?
wär da nicht ein vorgeschalteter tokenizer(wenn nicht sogar ein lexer) etwas effektiver?

code_pilot

@optimizer: Jo mach ich mal ... ähm kannst du mir evtl einen empfehlen??? Habe die Sourcen grad nicht parat kann also erst zuhause testen...

@otze: Tjoa aber da hätte ich komplett "from-the-base" das so machen sollen, das ist jetzt leider nicht mehr der Fall, und bei 8000 Zeilen Source code hab ich da auch keine Lust mehr das noch zu ändern :p ... mach ich mal wenn ich wieder mehr zeit habe

Danke & Gruss,
code_pilot

Der CodeAnalyst von AMD ist zumindest kostenlos. Ob er so empfehlenswert ist, ich weiß es nicht.

volkard

code_pilot schrieb:

@otze: Tjoa aber da hätte ich komplett "from-the-base" das so machen sollen, das ist jetzt leider nicht mehr der Fall, und bei 8000 Zeilen Source code

tjoa. 8k zeilen sind viel für nen interpreter. beim umwerfen und reimplementieren kommen bestimmt 1k raus.

code_pilot

Jo mit Sicherheit ...

Das ist kein "mal eben" Prog, da steckt viel Arbeit drin...

otze

mein bytecode interpreter ist keine 100 zeilen lang ;). der passende compiler dazu ist aber ziemlich kopfschmerzen verdächtig

Mr. N

otze schrieb:

mein bytecode interpreter ist keine 100 zeilen lang ;). der passende compiler dazu ist aber ziemlich kopfschmerzen verdächtig

Von was compiliert der denn? Ach und JITs sind denke ich noch immer in Mode. Bau dir doch einen, dann ist die Komplexität besser verteilt.

otze

ist der absolut primitivste bytecode, den ich mir einfallen lassen konte
zb sähe die zeile

add 1 2

im code so aus:

0x03           0x01       0x02
befehlsnummer  parameter1 parameter2

das programm selber besteht aus ner map, die die passenden funktionen für die nummern bereithält,diesen dann den charstream übergib, und sagt mach mal
primitiv, aber schnell

hauptproblem der Kopfschmerzen ist, dass ich den compiler wegen eines fest eingeplanten befehls komplett umbauen muss,und zwar von einer ordendlichen form in eine ziemlich komplexe. der befehl lautet: jump. ich fange an, jumps zu hassen^^

Mr. N

Naja da brauchste wohl Backpatching. Und mach ja nich mehrere Längen von Jumps. Alle hassen x86. *G*

Dein Bytecode scheint mir nicht sehr portabel zu sein, ist das möglich?

otze

why not?

Wie berücksichtigst du jetzt z.B. bei add die Größe eines Datentyps? Wenn du immer die Wortbereite des gerade vorhandenen Prozessors zugrunde legst, ist es nicht portabel. Es kann nicht sein, dass auf ner x86 CPU dann ein Überlauf stattfindet und bei x64 nicht.
Mir sieht das so ein bisschen sehr low-level aus, nicht wesentlich höher als Assembler, da müsste irgendwie noch dabei stehen, wie groß so ne Zahl in Bits ist, damit der JIT-Compiler je nach Prozessor den richtigen Code generieren kann.

Allerdings hab ich jetzt auch vielleicht einfach nur zu wenig von deinem Bytecode gesehen.

Mr. N

@Optimizer:
Ich glaube, du wirfst da etwas zusammen. So weit ich das sehe, baut er einen Bytecode-Interpreter. Der _ist_ portabel, so er funktioniert und richtig gecodet ist.

otze

auf diese art von portabilität hab ich bisher nicht geachtet,es hat erstmal gereicht zu wissen, dass es funktioniert.
wenn der ansatz aber so wie ich ihn mir gedacht hab funktionieren sollte, werd ich das ganze dann aber wahrscheinlich mit festen datentypen, wie zb die, die es bei boost gibt portabel machen. Dann hat ein int halt die größe 4 und ein float die größe 8(in bytes).

und schon währe das problem gelöst

@Mr.N doch es gibt probleme:

beispiel: generieren des bytecodes auf maschiene A(32 Bit):
ofstream(...) out;
long i;
out<<i;

auslesen des codes auf maschiene B(64 bit)
ifstream(...) in;
long i;
in>>i;

na? wo steckt der fehler? long soll auf 64bit maschienen 64 bit groß sein, dh es wird doppelt soviel eingelesen,wie vorher geschrieben wurde.

Mr. N

otze schrieb:

na? wo steckt der fehler? long soll auf 64bit maschienen 64 bit groß sein, dh es wird doppelt soviel eingelesen,wie vorher geschrieben wurde.

von solchen fehlern geh ich nichtmal aus, weil sie offentsichtlich sind.