Also um hier mal ein wenig mit dem Halbwissen aufzuräumen, die Aussagen von 
LightningBrothers mal auch von Entwicklerseite zu ergänzen 
und vor allem die ganz unterschiedlichen Einflüsse und Einflussbereiche aufzuzeigen: Hier ein etwas längerer Post, denn es ist kompliziert 
Erst einmal allgemein: DMXControl 3.3.0 ist nicht ein Programm sondern im Grunde 3 Programme (genauer 4, wenn man den Launcher mitzählt, aber der hat an dieser Stelle keinen Einfluss). Wie Stefan schon ausgeführt hat, haben Kernel und GUI unterschiedliche Anforderungen, was die Ressourcen angeht. Nur der Umbra ist da etwas genügsamer bzw. braucht eigentlich eine möglichst schnelle Verarbeitung des Netzwerk-Verkehrs. Aber lassen wir diesen erst einmal außen vor. So sind also wirklich vor allem der Kernel und die GUI in der Betrachtung relevant. Allerdings kommt es nun darauf an, was du machen möchtest. Und da rede ich jetzt nicht von der Größe des Projekts wie Stefan, sondern wirklich welche Bereiche du in DMXControl 3 genau berührst und wie du diese nutzt. Beispiel Matrix: DMXControl 3 berechnet Matrizen rein auf der CPU (hier ist bisher keinerlei GPU-Code entwickelt worden). Das hat zur Folge, dass bei sehr großen Matrizen die Updaterate in die Knie geht. Allerdings gibt es hier auch eine optimierte Variante. Wenn man mal in den DDFs genau darauf achtet, fällt bei der Definition von Matrizen auf, dass man dann nur ein eingeschränktes Funktionsset hat, was die einzelnen Pixel einer Matrix können. Das liegt daran, dass dafür ein optimierter und deutlich beschleunigter Rechenpfad eingebaut wurde, der zwar auch noch auf der CPU läuft, aber einige der HAL-Teile umgeht und so selbst bei großen Matrizen halbwegs vernünftige Updateraten bietet.
Nun zur CPU: DMXControl 3 besteht an sich aus mehreren Multi-Core-Applikationen, sie können also mehrere Kerne einer CPU nutzen. Das ist anders als z.B. DMXControl 2, was eine reine Single-Core-Applikation war. So machen wir an vielen Stellen von der Nebenläufigkeit Gebrauch, vor allem in der GUI. Wenn wir z.B. wissen, dass wir auf etwas kurz warten müssen (z.B. auf eine Antwort des Kernels), dann machen wir diese Aufrufe asynchron oder starten für gewisse Dinge eigene Threads, die dann prinzipiell auch auf anderen Kernen laufen können (so eben, wie das heute bei GUI-Programmierung üblich ist). Allerdings ist der Einsatz von mehreren Kernen nicht an allen Stellen sinnvoll. Und da kommen wir jetzt zum Kernel. Beispielsweise ist es bei einem gewissen Teil des HAL nicht sinnvoll, ihn zu parallelisieren. Das liegt daran, dass man sich dann andere Probleme einhandelt (aufwändiges Zusammenführen der Daten, nötige Wartepausen und möglicherweise auch sog. Race-Conditions). Da könnte eine Parallelisierung auch kontraproduktiv sein. Hier kommt es also auf die reine Single-Core-Performance der CPU an. je höher diese ist, desto besser. Und da können manchmal die "fetten" CPUs mit vielen Kernen schlechter als manch kleinere CPU mit wenigen Kernen sein da die "Kleinen" CPUs manchmal mehr Single-Core-Leistung haben als "die Großen". Außerdem ist hier zumindest bisher meist Intel besser als AMD, wobei letztere bei der Single-Core-Performance stark aufgeholt haben.
Kommen wir zur GPU: Diese wird immer wichtiger werden, denn anders als von showtechniker vermutet, läuft in DMXControl 3 doch schon ein bisschen was auf der GPU und das wird in Zukunft immer mehr werden. Erst einmal zum Status Quo. In der GUI von DMXControl 3.3.0 laufen insgesamt 3 Grafik-Frameworks / -Engins: Windows Forms (kurz WinForms), WPF und XNA. Zu letzterem hat Stefan ja schon ein bisschen war gesagt aber hier noch einmal die genauere Ausführung: Bei XNA handelt es sich tatsächlich um eine Game-Engine, ähnlich wie die heute durchaus bekannten Game-Engines Unity und Unreal Engine 5. XNA ist dabei aber auch für 2D Grafiken optimiert, was wir ja bei uns brauchen. Allerdings besteht eben die Problematik, die Stefan schon angerissen hat: XNA ist abgekündigt und wir wollen davon weg. Was Stefan aber nicht angesprochen hat sind WinForms und WPF. Ersteres ist das Fenster-Framework, welches wir bisher nutzen und welches die Steuerelemente anbietet, die man für Windows-Applikationen mit GUI braucht. Allerdings ist WinForms nicht wirklich auf hohe Grafik-Performance optimiert und das war auch der Grund, warum wir damals überhaupt angefangen haben, XNA in DMXControl 3 zu nutzen. Wäre nämlich die Stage View mit WinForms geschrieben, so hätten wir Updateraten von so einem Bild alle 1 bis 3 Sekunden. Hier kommt nun WPF ins Spiel. Dieses bietet ähnlich wie WinForms auch die ganzen Windows-Steuerelemente wie Buttons, Dropdowns etc. an, ist aber auf Grafikperformance optimiert, sprich ein Großteil der Anzeige wird aktiv auf der Grafikkarte gerechnet. Das ist der Grund, warum wir nun überhaupt aufwändigere Fenster wie z.B. die Executoren mit einem recht modernen Design bauen können, ohne uns zu hart zu verbiegen (wie das in XNA nötig ist). Mittel bis langfristig wollen wir daher komplett auf WPF umsteigen. Dadurch versprechen wir uns an manchen Stellen neben vielen anderen Dingen auch Performance-Verbesserungen. Alle neuen Fenster in DMXControl 3.3.0 sind daher bereits in WPF gebaut (u.a. Executoren, der Timecode-Player, die Master, die Projekt Administration und ein paar mehr) und wir werden jetzt Schritt für Schritt alte Fenster in WPF neu schrieben. Alles geht mit WPF aber auch nicht, weshalb Qasi da beim Timecode-Player noch einige Dinge selbst auf der Grafikkarte rechnen muss (und deshalb für den TCP noch einen Teil Shader-Code für die Grafikkartenberechnung geschrieben hat). Das heißt aber eben auch, dass die Grafikkarte für DMXControl 3 (zumindest für die GUI) in Zukunft immer wichtiger werden wird.
Kommen wir zum Arbeitsspeicher: DMXControl 3 ist aktuell größtenteils eine 32bit-Anwendung (nur der Umbra ist schon eine 64bit Anwendung). Das liegt daran, dass in der GUI wie im GPU-Abschnitt schon geschrieben eben XNA werkelt, was leider nur 32bit unterstützt. Im Kernel sind wir auf 32bit beschränkt, weil es eben einige Ausgabeplugins gibt, die 32bit benötigen und welche sich nicht in 64bit laden lassen. All das hat zur Folge, dass DMXControl 3 nur eine beschränkte Menge an Arbeitsspeicher nutzen kann. Das sind zwar theoretisch im Maximum etwa 4GB an RAM, die mit 32bit addressierbar sind. Aber praktisch ist das deutlich weniger und so ist meist schon bei so 1,6 - 1,8GB bei DMXControl 3 Schluss. Dann passt nichts mehr in den nutzbaren Speicher und DMXControl 3 (vor allem der Kernel) wirft OutOfMemory Exceptions und muss neu gestartet werden, obwohl der Arbeitsspeicher vor allem bei den heutigen Größen noch recht leer ist. Mittelfristig werden wir hier komplett auf 64bit umsteigen. So gehören dann auf einmal diese Arbeitsspeicher-Probleme bei größeren Projekten der Vergangenheit an.
Ich hoffe, dieser doch etwas längere Post hat etwas zur Klarheit bei den Zusammenhängen beigetragen 
Viele Grüße
JP
