Performance erhöhen?

[Gast]

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

[otze]

why not?

[Gast]

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.

[Gast]

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.

[otze]

Optimizer schrieb:

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.

ähm ich benutze keine register...

[Gast]

Ah ich les jetzt erst, wie du das Interpretieren bewerkstelligst. Ich hatte grad so nen JIT-Compilier im Hinterkopf. Gut, Typinformationen in deinem Bytecode brauchst du wohl trotzdem.

[otze]

bisher brauchte ich sie nicht. bzw ich verschlüssel sie in der funktionsnummer.

was ich damit meine?

push 5
push 5.0
push "Hallo"

die erste funktion bekommt die nr 0x04, die 2. 0x05 und die 3. 0x06.
0x04 erwartet nur int
0x05 nur float
0x06 nur strings(dh einen längenint und dann ein paar chars ;))

im ersten moment klingt das nach viel arbeit, aber wenn man bedenkt, dass ausser push eigentlich alle funktionen mit stackaddressen(der stack ist ein vector der die objekte polymorph speichert) arbeiten, ist das doch noch relativ einfach zu handhaben.

[code_pilot]

LOL hat sich ja ma ne Lustige Diskussion raus entwickelt ... naja mein Interpreter ist kein ByteCode-Interpreter sondern sowas wie VBScript, halt ein direkter Interpreter für darin geschrieben Scripts.

Aber schneller geworden isser immer noch nicht
ich glaube das Problem liegt ganz einfach daran, dass das Ding sehr lahm wird sobald man ein Script laufen lässt, das wirklich alle Funktionen braucht ... also Lesen, Interpretieren, Variablen holen, Variablen schreiben, bla, blub... kann man halt nicht "mal eben" dahin erklären.

Gruss,
~code_pilot

[Mr. N]

Theorie:
Direkte Interpreter sind langsam.

[otze]

THeorie: die Theorie ist richtig.
strings sind LAAAAHM ;)*

*im gegensatz zu anderen techniken die hier angewand werden könnten.

[Shade Of Mine]

code_pilot schrieb:

ich glaube das Problem liegt ganz einfach daran, dass das Ding sehr lahm wird sobald man ein Script laufen lässt, das wirklich alle Funktionen braucht ... also Lesen, Interpretieren, Variablen holen, Variablen schreiben, bla, blub... kann man halt nicht "mal eben" dahin erklären.

Und was spricht gegen kompilieren? kannst es ja ala PHP beim starten kompilieren - und hast im endeffekt einen interpreter und hast dennoch eine annehmbare geschwindigkeit. ein jitter wäre natürlich das beste - allerdings auch das komplexeste.

[otze]

wie funktioniert denn ein jiter mal kurz umrissen? *zu müde zum googlen*

[Shade Of Mine]

otze schrieb:

wie funktioniert denn ein jiter mal kurz umrissen? *zu müde zum googlen*

er kompiliert während der ausführung des programmes - kann dadurch natürlich geniale optimierungen machen, weil er ja genau die input daten kennt.

[otze]

aber dauert kompilieren bei groß projekten nicht teilweise schon 4 stunden?(bei normalen compilern)
wie kriegt man das in echtzeit hin?

[Gast]

Er compiliert ja nicht mehr direkt von der Hochsprache, sondern von einer Assembler-ähnlichen Zwischensprache aus.
Der Gag ist, dass diese Sprache aber noch prozessorunabhängig ist und der JIT-Compiler je nach gerade vorhandenem Prozessortyp entsprechende Optimierungen einbauen kann. Trotzdem fehlt ihm natürlich die praktisch unbegrenzte Zeit statischer Compiler ein bisschen.
Da diese Technologie aber noch in Entwicklung ist (insbesondere von Sun's HotSpot Optimierung kann man noch einiges erwarten), hat sie ihr volles Potenzial noch nicht entfaltet, für die statischen Compiler gilt natürlich das selbe, auch wenn man da schon mehr Erfahrung hat.

[Gast]

Ach, und bei .Net wird das Problem recht elegant umgangen, indem Native Images abgelegt werden, die auch nach dem Shutdown des Systems noch vorhanden sind. Somit wird das Programm nur beim ersten Aufruf wirklich compiliert, allerdings ist es trotzdem noch möglich, dynamisch Klassen hinzuzuladen.