Performance erhöhen?

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.

Ich meinte nicht direkt sowas. Du wirst doch auch im Bytecode so ne Art Variable haben, wie du beim Assembler halt mit Registern arbeitest, wirst du hier auch mit Variablen hantieren.
Die darfst du aber nicht einfach 1:1 auf Register von der Maschine dann abbilden, weil sich bei unterschiedlich breiten Registern der Code unterschiedlich verhalten kann. Du musst also im Bytecode auf jeden Fall Typinformationen festhalten.