Spiele-Engine fertig, aber lahm!

Es gibt 45 Antworten in diesem Thema, welches 6.720 mal aufgerufen wurde. Der letzte Beitrag (10. Februar 2012 um 02:30) ist von Vernunftmensch.

  • Fast sicher, daß man es nicht mehr vereinfachen kann im Anhang hier eine Routine aus meiner Engine.

    Mich würde wundern, wenn man die noch erheblich vereinfachen kann.

    Wer überrascht mich?

  • Würde es dadurch, das alles ins ASM zu übertragen, automatisch schneller?

    Das ist jetzt nicht wirklich eine Frage, oder?

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Das ist jetzt nicht wirklich eine Frage, oder?

    C ist schon sher maschinensprachenah. Ich gucke mir gleich ´mal die *.s-Datei an, ob ich das mit eigenem ASM übertreffen kann.

    Was habt ihr so für Erfahrungen?

  • Was habt ihr so für Erfahrungen?

    Übersetzter Code ist (mit an Wahrscheinlichkeit grenzender Sicherheit) immer langsamer als nativer Code.

    Vorausgesetzt. man weiss, was man tut.

    Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.- Bitte melde dich an, um diesen Link zu sehen.
    -
    User ignorieren? AdBlock!www.forum64.de##ARTICLE[data-user-id="xxxxx"]

  • Da fällt man doch vom Glauben ab!
    cc65 rechnet erst -1 und dann nochmal -25, statt einmal -26?


  • Da fällt man doch vom Glauben ab!
    cc65 rechnet erst -1 und dann nochmal -25, statt einmal -26?


    Hast du doch im Code auch so geschrieben.

  • Ich gucke noch nach, aber wenn der bei festen Multiplikationen in etwa beispielsweise 5*40+3 daraus eine Multiplikation macht?


    Da der cc65 anscheinend keine Operationen mit Konstanten wegoptimiert, wird wohl auch die Multiplikation erhalten bleiben.

  • Wirklich gut optimierende Compiler zu machen, ist eine Wissenschaft für sich, und eine Lebensaufgabe.


    Das dies bei einem nicht kommerziellen Projekt normalerweise ein Manko ist, sollte jedem klar sein. Es gibt nur wenige non Profit Compiler, die wirklich sehr gut optimieren: GCC (Gnu), LCC (Uni Projekt)

    Viele freie Compiler basieren auf den oben genannten oder auf aufgelassene kommerzielle Compiler.

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Zumindest für 680x0 produziert der GCC nicht gerade besonders tollen Code.

  • Jeder Compiler hat seine Stärken und Schwächen. Deshalb kann man auch die Leistungstests sehr leicht manipulieren, mit speziell getunten Beispielcode.


    Aber im Großen und Ganzen schneidet der GCC immer sehr gut ab, bei objektiv geführten Tests, und kann sich leicht gegen kommerzielle Produkte behaupten. Es steckt ja auch eine ziemlich beeindruckende Manpower drin in dem Produkt. Zudem gibt es wohl kaum einen Compiler, der Code für so viele verschiednen Zielplattformen ausgeben kann.


    Und der GCC leistet schon Erstaunliches, wenn man sich den entstandenen Code genauer ansieht. Es muss einer schon sehr gute Assemblerkenntnisse haben, und darüber hinaus die CPU internas sehr gut kennen, dass er besseren Code schreibt wie der GCC.

    Das gilt insbesondere für komplexere CPU's. Wenn eine CPU so einfach ist wie ein 6502, dann ist es für einen Menschen leichter gegen einen Compiler zu gewinnen. Bei komplexeren Prozessoren kann man die Vielzahl an speziellen Eigenschaften nicht mehr so gut erfassen.

    Im Übrigen ist eine CPU wie die 6502 nicht gerade für C predistiniert. Insofern sollte man da bei Assembler bleiben, wenn etwas zeitkritisch ist. Aber trotzdem ist der CC65 schon ein geniales Stück Software!!

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Fast sicher, daß man es nicht mehr vereinfachen kann im Anhang hier eine Routine aus meiner Engine.


    Evtl. habe ich was nicht verstanden, aber man könnte doch z.B.

    Code
    if (byte_insg==3 || ausrichtung==0) 
    	{
    		if (!bool_oben_stein) return 3;
    		if (!bool_unten_stein) return 1;
    		if (!bool_links_stein) return 2;
    		return 4;
    	};
    
    
    }


    schreiben. Die zweite if Abfrage danach fällt dann weg, ist ja doppelt.

  • Die zweite if Abfrage danach fällt dann weg, ist ja doppelt.


    Nicht ganz:
    Bei dieser Änderung würde der gesamte Rest der Funktion nach der if-Abfrage nie ausgeführt, falls byte_insg==3 oder ausrichtung==0. Dies ist im ursprünglichen Beispiel nicht der Fall, da u.U. alle bool-Werte true sein könnten.

    Gruß Dirk

  • Es gibt nur wenige non Profit Compiler, die wirklich sehr gut optimieren: GCC (Gnu), LCC (Uni Projekt)


    LLVM/clang ist dir nicht gut genug? ;)

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Zumindest für 680x0 produziert der GCC nicht gerade besonders tollen Code.


    Der Status vom GCC auf 680x0 ist ja auch mehr oder weniger "abgekündigt" ...
    Da sind viele aktuelle Entwicklungen, die auf moderneren Prozesssoren eingeflossen sind, warrscheinlich nicht drin.


  • Nicht ganz:
    Bei dieser Änderung würde der gesamte Rest der Funktion nach der if-Abfrage nie ausgeführt, falls byte_insg==3 oder ausrichtung==0. Dies ist im ursprünglichen Beispiel nicht der Fall, da u.U. alle bool-Werte true sein könnten.

    Gruß Dirk


    versteh ich nicht. Die if Abfrage wird jetzt auch nie ausgeführt falls einer der beiden Fälle auftritt. Man müßte nur "if (!bool_rechts_stein) return 4;" noch berücksichtigen.