Menü
Avatar von Wedder
  • Wedder

mehr als 1000 Beiträge seit 21.06.2015

Re: Danke: Flutter vor Qt sagt der erste Eindruck:

Ok, zu

"Web-Anwendungen und Cloud-Anwendungen"

, hatte es im Eifer vergessen zu unterschieden.

"Heutige Prozessoren sind sehr fix mit Fließkommaberechnungen,"

Yes, ich versuch's mal mit float basiertem Dart/Flutter, soll ja über opengl mit Grafik Acceleleratoren auf den Devices arbeiten. Notfalls (Pan B) cache ich die einmal gerenderten Kacheln, und schmeiße sie bei wiederholtem Aufruf als Pixelbild auf den Canvas.

"Qt bringt einige ... Ich würde C++ nur dann empfehlen, wenn sehr erfahrene Entwickler ...
C# und .Net ist mittlerweile performancemäßig ... "

Habe schon an 3 prof. c++ Projekten schwer mitprogrammiert. Keine Sprache geht mir derzeit fließend aus den Fingern, aber arbeiten kann ich langsam und sicher mit jeder. Ich verstehe die Hintergründe und finde mich zurecht, wenn ich erst einmal dran bin.

Damals (vor 7 Jahren) war .Net (egal was) doppelt so langsam wie native c++ . Habe für die Moba dort Testsoftware geschrieben. Allerdings habe ich damals nicht direct2D ausgelotet, hätte ich wohl auch mal ausprobieren sollen.

"Das ist ein interessanter Ansatz. Allerdings wage ich zu behaupten, dass man das effizienter lösen könnte als mit Threads...."

Richtig ist, das eine einfache Rekursion auf einem Thread bzw. CPU-Kern schneller und sparsamer abläuft, als eine (ggf. maasiv) parallele. Sobald man aber mehrere Cores (sch ab Dual-Core) zur Verfügung hat, unterliegt die einfachen Rekursion sehr schnell. Man sollte allerdings keine Datenkonstrukte in diesen Threads erzeugen. Beim Eisenbahn Algo greifen die Strahlen bzw. Threads ja nur auf feste im Hauptprogramm initiierte (Daten)Objekte zu. Bei Threadwechsel wird dann nur der Programmcounter der CPU umgebogen, und ein paar Processor Register gepusht und später wieder gepoppt. Aufwendig und teuer wird es erst, wen die Thread selbst Objekte initiierten (Speicher allokieren). Die existierende C# Software wurde mit mehr als tausend threads vor 7 Jahren daraufhin getestet, und hat die Theorie diesbzgl. am PC bestätigt.

Ich habe bei weitem nicht alle Anforderungen an das Stellen von Fahrstrassen erwähnt (Fahrweg auf Freiheit prüfen, Fahrweg freihalten, auch gegen seitlich einfallende Züge genannt "Schutzsuche", Fahrstrasse dicht hinterm Zug wieder freigeben). Wenn Du zudem berücksichtigst , das 1000de von Ingenieuren daran Jahre gearbeitet haben, zu einer Zeit als es praktische nur Relais,keine ICs , kaum Transistoren, geschweige denn µC oder Prozessoren gab, Du würdest mir Recht geben, das für die sichere Fahrwegsteuerung bei Eisenbahnen dies (~ parallele Rekursion von zwei Seite) der beste und effizienteste Algo ist.

I.D.R."Einfahrt nach Gleis 3" kommt der auch mit 3 Suchstrahlen (~threads) plus 1 Echo plus Schutzsuche, und dem Zug nachfolgender Auflösung aus. Die erwähnten 100 bis 1000 threads ergeben sich erst , wenn ich vorbildwidrig damit Fahrwege über die gesamte (Modellbahn-)Anlage stellen lasse. Beim Vorbild hatte jeder Bahnhof sein eigenes Gleisbildstellwerk ( ~Tablet ). Erst mal zum Wenden in den nächsten Bahnhof fahren war damit nicht möglich.

Hinzu kommt, dass die Fahrplantwicklung (Handelsreisen-Problem oder Wegsuche ala Google) gar nicht das Thema solche Gleisbildstellwerke war und noch ist. Fahrpläne wurden Anfangs offline auf Papier gemacht, und dann an die Bahnhöge und Lokführer in Papierform verschickt, mittlerweile werden sie in Zentralstellwerken (eine Ebene höher) entwickelt und online gewartet. Wobei die Zentralstellwerke die heute oft weiterhin existierenden Bahnhofs GB Stellwerke personalsparend fernsteuern.

Ich reduziere also jetzt meine Anforderung auf erst mal Lokomotiven Remote, Weichen und Signal Steuerung über Listen , über 2 seperate Apps. Das probier ich erst mal mit dart und Flutter, für die Moba Kommunikation werden die asynchronen Funktionen ausreichen. Ich vermute, hinter den asynchronen Funktionen verbirgt sich so ein begrenzter und von Android limitierter threadpool.

Danach muss ich nochmal planen, wie ich das mit dem Gleisbildstellwerken angehe: Vielleicht doch wieder ein Serverchen in C++ (getarnt als Interface) zwischen Devices und Moba mit Tablets als Terminal dazu.

Auf die Parallelität der Original Fahrstraßensteuerung und Sicherung mit Suchstrahlen und Echo würde ich nicht verzichten wollen. Ohne wäre es keine Moba-Steuerung, weil es wäre nicht vorbildgerecht genug.

Wenn es vorbildgerecht ist, kann ich es sogar ohne Handbuch/Help weitergeben, und einfach auf das alte Vorbild Handbuch verweisen O:-).

Also vielen Dank :-) für Info und Grüße

Das Posting wurde vom Benutzer editiert (22.03.2019 21:23).

Bewerten
- +
Anzeige