Sind Lua-Funktionen begrenzt

!!! Please ensure, that your contribution or question is placed into the relevant section !!!
Questions about rolling stock, for example, do not belong in "Questions about the Forum". Following is perhaps the right area where your question will be better looked after:
General questions to EEP , Splines, rolling stock, Structures in EEP, landscape elements, Signalling system and controlling, designers, Europe-wide EEP meetings , Gossip
Your cooperation to keep the forum clear is appreciated.
  • An UF1 -- Parallelisieren bedeutet nicht nur rechenaufgaben verteilen; es geht auch um bessere Nutzung des RAM I/O und vom Cache im Prozessor, während core 1 eine Rehnung durchführt, kann core 1, Daten im innersten Cache für die nächste "Berechnung" schieben, und Core 3 Daten aus den RAM in den äußeren Cache für die übernächste Rechnung holen; wenn man die Intel Libraries studieert, erkennt man auch, dass man bei geeigneten Memory-allozierung in Programm eine erhöhte Effizien der Cache-Nutzung erreichen kann.

    SNE



    Desktop: CPU 2 Xeon E5-2640 (a 4 Kerne), 32 GB RAM 1,333 GHz; 512 GB HDD, Grafikkarte: GeForce GTX 650 Ti, 1 GB RAM

    Notebook: i7-3630 (4 Core) 2.4 GHz, 16 GB RAM, 512 GB SSD; Grafikkarte: Radeon HD 7600M

    Windows 10; EEP 14.1, Plug-in 1

  • Aber das müsste ja alles in EEP programmiert werden.:av_1:

    Deshalb bleibts (wahrscheinlich) ein schöner Traum.:at_1:


    :aq_1:

    Intel i3-540 3,2GHz 8GB, RAID10, HD 6570 1GB, W7/64 Prof., EEP 6-6.1, 10-14, HN13, MK, TM, "Schiefe Ebene 6 + 8", "Bahn2000"

  • Holznagel


    Hier eine Version für deine Textausgabe:



    Etwas kompakter kann man es auch in einer Schleife erledigen:


    LUA Source Code
    1. AusgabeText = ""
    2. for i = 1, 18 do
    3. AusgabeText = AusgabeText..string.format("Zeit %d ist:....%d\n", i, Zb[i])
    4. end
    5. print(AusgabeText)

    Das erspart viel Schreibarbeit, ist aber nicht schneller als die Version darüber.

    you don't believe we're on the eve of destruction

    - Barry McGuire -

    The post was edited 5 times, last by Goetz: Schreib- und Formatfehler im Code korrigiert! ().

  • an eep_gogo;


    ich glaube nicht, dass alles in EEP programmiert werden müsste. Wenn die mit EEP gelieferte und installierte LUA version, die multithread module hätte, könnte man in EEP Main die Threads starten, selbstgeschriebene Funktionen.

    SNE



    Desktop: CPU 2 Xeon E5-2640 (a 4 Kerne), 32 GB RAM 1,333 GHz; 512 GB HDD, Grafikkarte: GeForce GTX 650 Ti, 1 GB RAM

    Notebook: i7-3630 (4 Core) 2.4 GHz, 16 GB RAM, 512 GB SSD; Grafikkarte: Radeon HD 7600M

    Windows 10; EEP 14.1, Plug-in 1

  • Hallo Goetz,

    Danke für die Hinweise, aber wie schon gesagt ich brauche die print-Anweisungen nur beim programmieren oder zur Kontrolle wenn ich andere functionen erstelle. Da ist es egal. Werde aber Deine vorgeschlagenen Textausgaben bei der nächsten Anwendung ausprobieren.

    Eine function z.B. entlastet LUA enorm. wenn man am Anfang von LUA einen Zähler einbaut der nur alle 5 X 200 milli Sek. eine function aufruft, also nur jede Sekunde. Bei 90% reicht die Abfrage alle Sekunden.

    Noch eins, im Forum werden immer wieder von dem eine oder anderen von euch Schaltungen vorgestellt. Die beobachte ich immer und manche baue ich auch nach. Es sind z.T. sehr gute Ideen. Wenn man aber die eine oder andere Idee bei sich in einer eigenen Anlage einbauen will kommen auch viele Problem zu Tage die andere nicht haben. Trotzdem vielen Dank an alle die hier etwas vorstellen.... und es weiter machen...


    LG

    PC MS Windows 10 64 Bit 16 GB Ram, Nvidia GeForce GTX1070

    Laptop MS Windows 8.1 64 Bit, I7 - 4700 HQ CPU @ 2,40 GHz 16 GB Ram, Nvidia GeForce GTX780M

    EEP Versionen 5 bis 15 in Kompl. Ausführung.

    Virenschutz G-Data

  • Auch auf die Gefahr hin, hier off-topic zu werden (wenn dies eine eigenständige Diskussion wird, können wir sie ja abtrennen). Im Moment nur so viel:

    Ich bin nicht sicher, ob sich die bei EEP anfallenden Berechnungen überhaupt zur Parallelisierung eignen.

    Wenn die Framerate nicht mehr die gewöhnlichen 60fps schafft, beobachte ich auf meinem Rechner eine hohe CPU-Last auf wenigen Cores, und bin auf der Graphikkarte noch deutlich von möglichen Anschägen entfernt.

    Wenn ich ein größeres GBS einblende, sehe ich mehr CPU-Last ohne Änderung in der Framerate. Meine Interpretation: Die fortlaufende Aktualisierung des GBS läuft in einem eigenen Thread und auf einem freien Core.


    Was macht EEP eigentlich so CPU-hungrig? Ich vermute alles, was nicht direkt mit dem Zusammenstellen des nächsten Bilds für den Monitor zusammenhängt. Darunter erwarte ich:

    • Bewegung der Vegetation im Wind
    • Berechnung der nächsten Position aller Rollmateralien
    • Auslösen und Verarbeiten von Kontaktpunkten
    • Bewegen von Achsen (wie Türen, Stromabnehmern, Schranken, Mühlrädern, Drehscheiben, etc.)
    • Partikelsysteme (Rauch, Staub, Wasser)
    • ... und sicher noch mehr

    Die meisten dieser Berechnungen müssen getan werden – ganz egal, ob sie im sichtbaren Bereich stattfinden oder nicht. Aber viele dieser Berechnungen erscheinen mir völlig unabhängig von anderen Berechnungen. Und hier sehe ich noch deutliches Potenzial für mehr Parallelisierung, und damit für eine höhere Framerate auf Kosten eines höheren CPU-Bedarfs (anderer Cores).


    Gruß

    Christopher

    PC: Intel i7-7700K; 64bit; 4,2 GHz; 16GB RAM; GeForce GTX 1080 (8 GB); Win 10; EEP 6, 13.2 Plugins 1+2, 14.1 (Dev), 15 (Dev); HomeNOS 14 (Dev)
    Laptop: Intel i5 3230M; 64bit; 2,6 GHz; 8GB RAM; GeForce GT740M (1 GB); Win 8.1; EEP 6, 13.2 Plugins 1+2; HomeNOS 13 (User)

  • Noch eins, im Forum werden immer wieder von dem eine oder anderen von euch Schaltungen vorgestellt. Die beobachte ich immer und manche baue ich auch nach. Es sind z.T. sehr gute Ideen. Wenn man aber die eine oder andere Idee bei sich in einer eigenen Anlage einbauen will kommen auch viele Problem zu Tage die andere nicht haben.

    Ohne ein spezifisches Beispiel ist das schwer nachzuvollziehen.

    Ich sehe da 2 mögliche Gründe.

    1. Anlagenspezifische Scripts können sich auf Eigenheiten einer bestimmten Anlage beziehen. Da müssten dann jeweils SignalIDs etc. angepasst werden, was nicht immer ganz einfach ist.

    2. Du weisst gar nicht, ob andere User wirklich keine Probleme bekommen, solange sie diese nicht hier bekanntgeben.

    2a. Ebensowenig weisst Du, wieviele Leute diese Scripts tatsächlich verwenden. Die Downloadzahlen (falls überhaupt ersichtlich) sagen darüber nichts aus.


    :aq_1:Gruss Jürg

    Samsung Series 9 Laptop / Lenovo Z50 - 70 Laptop
    Intel i5 1.7 Ghz / Intel i7 2.0 Ghz
    4 Gb Speicher / 8 Gb Speicher
    Intel HD Graphics 4000 / NVIDIA Geforce 840M
    Windows 10 64 /Windows 10 64
    EEP15 / EEP14, EEP15
    AnlagenBau / AnlagenLaufLass

    ________________________________________________________________________

    Wer den Schaden hat braucht für den Schrott nicht zu sorgen (Alte Autofahrerregel)

  • an eep_gogo;


    ich glaube nicht, dass alles in EEP programmiert werden müsste. Wenn die mit EEP gelieferte und installierte LUA version, die multithread module hätte, könnte man in EEP Main die Threads starten, selbstgeschriebene Funktionen.


    Hat sich jemand mit folgendem befasst? http://web.archive.org/web/*/h…/professional/luathread/*

    SNE



    Desktop: CPU 2 Xeon E5-2640 (a 4 Kerne), 32 GB RAM 1,333 GHz; 512 GB HDD, Grafikkarte: GeForce GTX 650 Ti, 1 GB RAM

    Notebook: i7-3630 (4 Core) 2.4 GHz, 16 GB RAM, 512 GB SSD; Grafikkarte: Radeon HD 7600M

    Windows 10; EEP 14.1, Plug-in 1

  • Sorry, der Link ist nicht mehr verfügbar; muss zuerst suchen

    SNE



    Desktop: CPU 2 Xeon E5-2640 (a 4 Kerne), 32 GB RAM 1,333 GHz; 512 GB HDD, Grafikkarte: GeForce GTX 650 Ti, 1 GB RAM

    Notebook: i7-3630 (4 Core) 2.4 GHz, 16 GB RAM, 512 GB SSD; Grafikkarte: Radeon HD 7600M

    Windows 10; EEP 14.1, Plug-in 1

  • Zur allgemeinen Performance von LUA Scripten in EEP habe ich eine Frage.

    Was für eine Ausführungszeit hat der Befehl EEPSetSignal oder EEPSetSwitch.


    Wenn ich also z.B. 50 x EEPSetSwitch in einem Rutsch in einer Funktion aufrufe, blockiere ich dann EEP in dieser Zeit, und wenn wie lange. Darf ich so etwas überhaupt machen.

    Grund: Ich lasse in 20 sek. Intervallen alle Strassen-Weichen einfach umschalten, damit die Fahrzeuge, zufällig abbiegen oder geradeaus weiterfahren. Zusätzlich werden auch die Ampeln mit solchen Intervallen geschaltet. Das Ergebnis dabei ist das alle Fahrzeuge sich völlig frei und zufällig auf der Anlage bewegen, was ein schönes lebhaftes Treiben auf den Strassen bewirkt.

    Ich habe etwa 50 Kreuzungen und Abfahrten auf meiner aktuellen Anlage, also etwa 150 Weichenobjekte für die Strassen.

    Es ist für mich wichtig das zu wissen, sonst muss ich mir evtl. ein anderes Konzept überlegen.

    Betriebssystem: Windows 7 Ultimate N 64 Bit

    Arbeitsspeicher: 8GB RAM

    Prozessor: Intel(R) Core(TM) I5-2320 CPU 3GHz

    ASUS GTX750TI-PH-2GD5 - Grafikkarte - GF GTX 750 Ti - 2GB GDDR5

    Motherboard: GIGABYTE Typ 7 Series

    EEP 13.2, EEP 14.1

  • Schöne Idee, die Du da hast.


    Peter

    Betriebsystemname: Microsoft Windows 10 Pro Education

    Prozessor: AMD Ryzen 5 1600 Six-Core Processor, 3200 MHz, 6 Kern(e), 12 logische(r) Prozessor(en)

    PC:RAM 16 GB

    Grafik Karte: Name NVIDIA GeForce GTX 1060 6GB


    EEP6 mit allen Plugins und Patches
    EEP7 bis13 mit allen Patches und Plugins

    EEP 14 und EEP 15
    Modelkonverter
    PlanEx 3.1
    Home-Nostruktor 13.0
    Modellkatalog
    Bodentextur Tool



  • Wenn ich also z.B. 50 x EEPSetSwitch in einem Rutsch in einer Funktion aufrufe

    dann schadet das nicht der Performance.

    Du darfst sogar zusätzlich noch für jede Weiche einen Zufallswert würfeln und wirst keine Veränderung der Framerate sehen.


    Aber wenn du zu jeder Weiche auch noch eine print() Ausgabe schreibst, dann wirst du sehen, dass dieses print() viel Zeit braucht.

  • Aber wenn du zu jeder Weiche auch noch eine print() Ausgabe schreibst, dann wirst du sehen, dass dieses print() viel Zeit braucht.

    OK, das verstehe ich.

    Aber wie sieht es dann mit dem Ereignisfenster aus? Alle Operationen werden ja im Ereignisfenster protokolliert, und da wird dann auch Text generiert, der möglicherweise über Events verschickt wird.

    Gibt es denn da keine Ausbremsung? Ich könnte mir vorstellen das das Verhalten mit oder ohne angezeigtem Ereignisfenster unterschiedlich ist. So ist es in unseren entwickelten Applikationen ebenfalls.

    Betriebssystem: Windows 7 Ultimate N 64 Bit

    Arbeitsspeicher: 8GB RAM

    Prozessor: Intel(R) Core(TM) I5-2320 CPU 3GHz

    ASUS GTX750TI-PH-2GD5 - Grafikkarte - GF GTX 750 Ti - 2GB GDDR5

    Motherboard: GIGABYTE Typ 7 Series

    EEP 13.2, EEP 14.1

  • Alle Operationen werden ja im Ereignisfenster protokolliert

    Nicht zwingend,

    sondern nur, wenn du im Lua Editor unten links die entsprechenden Checkboxen aktivierst.

    Oder eben Ereignisse mit entsprechenden print() Befehlen ausstattest.


    Ein print() pro Zyklus stellt außerdem überhaupt kein Problem dar.

    Du kannst also den Text von 50 Ereignissen in einem String zusammenfassen und dann mit einem print() den kompletten String ausgeben. Die Zeilenumbrüche "\n" musst du in diesem Fall mit in den String einbauen.


    Und genau das passiert auch bei den Ereignisanzeigen, die du unten im Editfenster aktivieren kannst.

    Alle Ereignisse, die in einem Zyklus stattfinden (wie z.B. das Umschalten deiner 50 Weichen) werden zusammengefasst und mit einem print() ausgegeben.



    Beispiel für das Umschalten von 50 Weichen, deren Nummern in einer Tabelle stehen.

    Mit zufälliger Stellung und kompletter Textausgabe. Ohne Performanceeinbuße.

    you don't believe we're on the eve of destruction

    - Barry McGuire -

    The post was edited 4 times, last by Goetz ().

  • Alle Ereignisse, die in einem Zyklus stattfinden (wie z.B. das Umschalten deiner 50 Weichen) werden zusammengefasst und mit einem print() ausgegeben.

    Das ist natürlich eine sehr wichtige Erkenntnis.

    Danke Goetz, für Deine Info.

    Ja, Man arbeitet sich so langsam in die Tiefen des EEP Universums vor.

    Betriebssystem: Windows 7 Ultimate N 64 Bit

    Arbeitsspeicher: 8GB RAM

    Prozessor: Intel(R) Core(TM) I5-2320 CPU 3GHz

    ASUS GTX750TI-PH-2GD5 - Grafikkarte - GF GTX 750 Ti - 2GB GDDR5

    Motherboard: GIGABYTE Typ 7 Series

    EEP 13.2, EEP 14.1

  • Ich schicke noch etwas hinterher.


    Wenn du die EEPMain() entlasten willst (was in diesem Fall nicht nötig ist), dann ist es nicht hilfreich alle Aktionen nur bei jedem fünften Durchlauf auszuführen. Weil dieser fünfte Durchlauf dann trotzdem die volle Last hat.


    Besser ist es, die Aktionen auf fünf Durchläufe zu verteilen:

  • Besser ist es, die Aktionen auf fünf Durchläufe zu verteilen:

    Danke, Ja, Ich weiß das habe ich schon berücksichtigt und angewendet. Ich habe es nur in der Anfangsfrage nicht erwähnt. Es war erstmal eine generelle Frage bzgl. der Performance Last.


    Ich schalte nicht alle Straßenkreuzungen auf einmal und auch nicht alle Ampeln, sondern habe das auf mehrere Funktionen mit Bereichen verteilt. Allein schon deswegen, um noch mehr den Zufallseffekt zu erreichen. Denn was nützt es wenn die Abfahrt auf rechts steht, aber die Ampel dann immer auf rot ist. Das muss also asynchron auseinander laufen. Und das mache ich unter den Strassen Kreuzungen genauso. Insgesamt habe ich jetzt fünf Funktionen die abwechselt die Straßenkreuzungen schalten und drei Funktionen die für die Ampeln zuständig sind. Wenn ich heute noch Zeit habe setze ich mal meine aktuellen Bilder der Anlage rein, dann seht ihr was für ein Straßennetz ich da im Einsatz habe.

    Betriebssystem: Windows 7 Ultimate N 64 Bit

    Arbeitsspeicher: 8GB RAM

    Prozessor: Intel(R) Core(TM) I5-2320 CPU 3GHz

    ASUS GTX750TI-PH-2GD5 - Grafikkarte - GF GTX 750 Ti - 2GB GDDR5

    Motherboard: GIGABYTE Typ 7 Series

    EEP 13.2, EEP 14.1