3. Performance erhöhen?

Performance erhöhen?

  • C

    @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

    0
  • ?

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

    0
  • V

    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.

    0
  • C

    Jo mit Sicherheit 😮 😮 😮 ...

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

    0
  • O

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

    0
  • M

    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. 🙂

    0
  • O

    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^^

    0
  • M

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

    0
  • ?

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

    0
  • O

    why not? 🙂

    0
  • ?

    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.

    0
  • M

    @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.

    0
  • O

    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.

    0
  • M

    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.

    0
  • ?

    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.

    0
  • O

    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...

    0
  • ?

    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.

    0
  • O

    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.

    0
  • C

    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

    0
  • M

    Theorie:
    Direkte Interpreter sind langsam.

    0
Anmelden zum Antworten