Mit Lazarus komp. Programm unter Suse langsamer als Windows??

Hinweis: In dem Thema Mit Lazarus komp. Programm unter Suse langsamer als Windows?? gibt es 9 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Guten Abend!


    Ich habe während der vergangenen Tage eine kleine Simulation (GUI) mit Lazarus (1.0) entwickelt.
    Kompiliert wurde mit fpc 2.6.0, alle Einstellungen den Compiler betreffend wurden belassen.


    So, jetzt hab' ich das Ganze unter Windows Vista kompiliert. Ebenfalls Aktuelle Lazarus Version.
    Identischer Quelltext. Läuft jetzt 100mal (gerechneter Wert!!) schneller. :)


    Da ich die Simulation gerne weiter unter Linux betreiben würde, interessiert mich jetzt ja doch, wie sowas zustande kommt. ;)


    Grüße,
    ancistrus

    Für den Inhalt des Beitrages 46786 haftet ausdrücklich der jeweilige Autor: ancistrus

  • Das Übliche:
    Guck mal was da vor dem Keyboard ist.
    Das wird das Problem sein.


    Zwar compiliert der irgendwelche Sachen in echt antiken Sprachen, aber was er wie auf welcher Platform macht, schreibt der nicht.


    Eine Simulation.
    Wenn man ein Altersheim simuliert wäre ja ein langsames Linux richtiger, als ein schnelles Windows.
    Was sollen wir dazu sagen, wenn wir nicht wissen, was da simuliert wird?


    Und ne Gui.
    In Linux. Hmm, welche? Welches Framework? GTK Qt? welche libs?
    Was sollen wir dazu sagen?
    Was sagt strace/ltrace?
    Welche Teile des Programms sind langsam?
    Debugger? Testframework?


    Eine erschöpfende Antwort aus dieser Informationsdürre auspressen zu wollen, muss scheitern.
    Ich leite dich also zu Wikipedia oder einer Enzyklopädie weiter...


    scnr.


    p.s. wie kommst du ausgerechnet auf Pascal? Und reden wir von Pascal, oder ObjectPascal?

    Für den Inhalt des Beitrages 46791 haftet ausdrücklich der jeweilige Autor: uhelp

  • Sehr charmant, dein Post :D



    Eigentlich wollte ich am Ende meines Posts noch schreiben, dass ich -falls die gegebenen Infos nicht ausreichen- gerne welche nachtrage; hab's dann aber weggelassen, weil ich dachte, es wäre eine Selbstverständlichkeit :D
    Nachdem du mir also so eindrucksvoll deutlich gemacht hast, dass die Informationen nicht ausreichen werden, hier also der Rest:


    1) Es handelt sich um die Simulation eines Zellularautomaten. Es soll der Zustand eines geschlossenen Systems nach n Generationen ausgerechnet werden; wobei jede Zelle genau zwei Zustände annehmen kann und nach festgelegten Regeln überführt wird.


    2) Geschrieben habe ich in ObjectPascal.


    3) GUI ist glaub' ich GTK, Units eingebunden habe ich:

    Code
    Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,  ComCtrls, ExtCtrls, Buttons, lclintf


    Die GUI sollte aber keine Rolle spielen, da der geschwindigkeitsbestimmende Schritt nichts mit der Visualisierung zu tun hat, sondern in der Berechnung der Zustände besteht. (Die wiederum nur elementare Kontrollstrukturen sowie die Canvas.Pixels Eigenschaft nutzt.)


    4) strace/ltrace kenne ich nicht, werde ich mal googlen :)



    Liebe Grüße,
    ancistrus



    Achso, btw: Ich höre immer nur (mehr oder weniger ;) ) unterschwellig abschätzige Kommentare zu Pascal;
    könntest du mir grob erklären, warum? Oder einen Link posten?

    Für den Inhalt des Beitrages 46805 haftet ausdrücklich der jeweilige Autor: ancistrus

  • ancistrus:
    Lass dir da nicht rein reden.
    Wenn dir Pascal/ObjectPascal gefällt, dann programmiere damit.
    Pascal ist eben nicht mehr die aktuellste Programmiersprache, einige Sprachkonstrukte werden evtl. gar nicht implementiert sein, bzw. eine sehr kryptische Syntax aufweise. (schätze ich mal)
    Aber wenn dir Pascal gefällt. kannst du damit ruhig weitermachen :)
    (Wobei es nicht schaden kann etwas über den Tellerrand heraus zuschauen)

    ___________________________________________________________________________________
    Zypper Befehlsreferenz

    Für den Inhalt des Beitrages 46811 haftet ausdrücklich der jeweilige Autor: lush

  • Danke für die Erklärung! Ich wollte mir da auch nicht "reinreden" lassen ;)
    Aber wenn so viele (Profis) jedes Mal, wenn ich "Pascal" sage, die Hände über'm Kopf zusammenschlagen,
    dachte ich, ich sollte micht vll. begründet überreden lassen. ;)


    Wenn es um einfache Dinge wie die besagte Simulation geht, werde ich auch erstmal bei Pascal bleiben.



    Grüße,
    ancistrus

    Für den Inhalt des Beitrages 46813 haftet ausdrücklich der jeweilige Autor: ancistrus

  • Naja ein Profi bin ich nicht wirklich :D
    Und wie gesagt, da hat jeder andere Meinungen.
    Das hängt eben auch stark davon ab, was man programmiert.


    uhelp mag zum Beispiel meine favorisierte Sprache auch nicht. (Java)
    Und seine erste Wahl (python) ist nicht mein Ding ^^

    ___________________________________________________________________________________
    Zypper Befehlsreferenz

    Für den Inhalt des Beitrages 46816 haftet ausdrücklich der jeweilige Autor: lush

  • Bloß keine falsche Bescheidenheit. ;)
    Naja, mal sehen. Die ein oder andere Sprache werde ich mir bestimmt mal ansehen.



    Ich will ja nicht ablenken, aber.... fällt dir vll. was zu meiner ursprünglichen Frage ein?



    Grüße,
    ancistrus

    Für den Inhalt des Beitrages 46817 haftet ausdrücklich der jeweilige Autor: ancistrus

  • Ist eventuell das Linuxsystem virtualisiert?
    Wie sieht die Auslastung der Prozessorkerne bei der Simulation aus?
    Wie sieht es mit Ausnutzung vom RAM aus und daraus folgend mit der Verwendung von swap (bei Windows heisst das glaub ich virtueller Arbeitsspeicher)?

  • Der Speicherbedarf liegt bei beiden Systemen bei etwa 4MB. Die CPU Auslastungen:


    Linux: etwa 20%
    Windows: fast 100%



    Grüße,
    ancistrus

    Für den Inhalt des Beitrages 46824 haftet ausdrücklich der jeweilige Autor: ancistrus

  • Zur Sache weiter kann ich nicht viel sagen.
    Weder hab ich Pascal drauf, noch GTK;
    und ob das nicht letztlich doch relevant ist, wissen wir so noch nicht.
    Sehr häufig kommen sich die event Schleife der GUI und die funcs -in diesem Fall deinem- Programm in die Quere.
    Ich schätze sogar, dass ist der häufigste Grund. ( Raceconditions in event-gesteuerten Systemen. )
    Wie verhält es sich ohne GUI? GIbbet eine cli Version?
    Tatsächliche Laufzeitmessungen?


    Zum Pascal.
    Ein Problem, auf das du früher oder später stoßen wirst, ist die Integrationsfähigkeit in moderne Umgebungen. Von einem modernen Programm erwartet man, dass die GUI nach Belieben auf beliebig vielen Frameworks läuft und insbesondere, dass HTML5 mit javascript direkt ausgegeben werden kann (und zwar für GUIs, die einem "Fullsize.GUI-Framework" das Wasser reichen.) Und damit ist das Zeugs auch schnell (wenn gut gemacht, sofort) auch auf allen maßgeblichen Smartphone Plattformen lauffähig.
    (Heute kann man nicht mehr programmieren, ohne primär Smartphones im Auge zu haben. Und NEIN, ich bin davon wahrlich kein Freund.)


    Du wirst also irgendwann anfangen, viele kleine "Nebeninterfaces" zu bauen, um auf dem ein- oder anderen System auch lauffähig zu werden, oder die ein- oder andere Funktionalität, die eben ohne Interaktion im Netz nicht darstellbar ist, doch einzubauen.
    Nach fünf solcher "Nebeninterfaces" bist du in der Pflegehölle (ich meine jetzt nicht bundesdeutsche Altersheime).
    Du wirst mehr nervtötende Codepflege betreiben, als wirklich freudig zu programmieren.


    Zwar hat Pascal kraft seines Alters noch die Gene in sich, die die damaligen Programmiersprachen ausmachten und heute eher hinderlich sind, doch gleicht solche Schwächen die Rechenpower und Speicherzuwachs locker aus.


    Aber, wie ein Vorredner schon sagte: Wenn es dir taugt, bleib dabei.


    Ich mag Pascal trotzdem nicht.
    Es hatte seine Hochzeit zu CP/M Zeiten und DOS.


    Ich selbst bevorzuge immer zuerst Python.
    Obwohl eine Scriptsprache, schlägt es C Programme in bestimmten Disziplinen selbst bei der Performance.
    Es lassen sich mit 10 Zeilen Code ein voll funktionsfähiger Echoserver samt Client schreiben.

    Für den Inhalt des Beitrages 46825 haftet ausdrücklich der jeweilige Autor: uhelp