Hallo!
In letzter Zeit hatte ich öfter mit großen Programmen zu tun (10 Unterprogramme mit je 80-200 Programmelementen). Allerdings kam ROBOPro schnell an seine Grenzen: Besonders bei der Markierung von mehreren Elementen drohte es jedes Mal abzustürzen. Die Frage war nun, ob es einfach an einem Mangel an Rechenleistung lag (was unwahrscheinlich war) oder ob es an sonst etwas lag. Über den Taskmanager fand ich dann folgendes heraus: Obwohl ROBOPro sämtliche 8 CPU-Kerne zur Verfügung stehen, nutzt es nur einen einzigen. Dieser kommt dann tatsächlich schnell an seine Grenzen.
Einige Recherchen (über schlechte Multicorenutzung allgemein) ergaben, dass es in diesem Fall daran liegt, dass ROBOPro nicht auf Multicorenutzung ausgelegt ist.
Liege ich richtig, sprich das Problem müsste in einem Update behoben werden, oder gibt es noch eine andere Möglichkeit ROBOPro mehr Rechenleistung zur Verfügung zu stellen?
Ich nutze Windows 7 x64 Professional.
LG
Max Z.
Schlechte Multicorenutzung
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
-
steffalk
- ft:pedia-Herausgeber
- Beiträge: 1955
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Schlechte Multicorenutzung
Tach auch!
In RoboPro dürfte wohl weder die eigentliche "Rechen"-Arbeit und schon gar nicht die Benutzeroberfläche mehrere Prozessoren ausnutzen.
Unter Windows gibt es normalerweise in einem Programm immer nur einen "Thread" ("Ausführungsfaden"), der für die Benutzeroberfläche zuständig ist. Eventuell könnte RoboPro irgendwas nicht Oberflächenbezogenes auf mehrere Kerne verteilen. Das ist aber nicht nur Arbeit für den Entwickler, sondern mitunter richitg aufwändig. In dem Moment, wo ein Programm mehrere Sachen tatsächlich gleichzeitig machen will, muss man sich um Dinge die die Synchronisation von Zugriffen auf dieselben Ressourcen, um die Synchronisation der fertigen Ergebnisse der einzelnen Threads und auch noch um so Kleinigkeiten wie der korrekten Behandlung von Laufzeitfehlern in einem der Threads kümmern. Da steigt die Komplexität leicht schnell an, und ebenso leicht baut man unheimlich schwer zu findende Fehler ein - die nämlich nur ganz selten mal auftreten, wenn grade zufällig das Timing ungünstig ausfällt.
Unter anderen Betriegssystemen (für die es RoboPro ja eh nicht gibt), sind die grundsätzlichen Probleme genau dieselben. Ohne einer Antwort von RPE vorgreifen zu wollen, würde ich würde nicht damit rechnen, dass sich da in absehbarer Zeit etwas ändert. Schließlich tut RoboPro seine Arbeit ja sehr gut - da wird kein riesiges Fass für solche Ausnahmefälle aufgemacht werden, wie Du sie gerade hast.
Wenn Du wirklich rechenaufwändige und parallelisierbare Programme schreiben willst, die online aufs Interface zugreifen sollen, könntest Du den nächsten Schritt machen. Um nur ein paar Beispiele zu nennen: Das .net Framework hat ab Version 4 ganz wunderbare Mechanismen, um parallelisierbare Dinge relativ einfach und zuverlässig (sprich: ohne Berge von manuellem Aufwand) zu parallelisieren. Ebenso ist das Microsoft Robotics Studio von vornherei dafür ausgelegt, Arbeit nicht nur auf mehrere Prozessoren, sondern sogar auf mehrere Computer zu verteilen. Du könntest beides in C# oder Visual Basic oder einer beliebigen anderen Sprache mit einem .net-Compiler nutzen. Allerdings findet das in einer ganz anderen Liga statt, als das recht "kindersichere" Programmieren in RoboPro. Du wirst also mit einer entsprechend steilerern Lernkurve rechnen müssen.
Gruß,
Stefan
In RoboPro dürfte wohl weder die eigentliche "Rechen"-Arbeit und schon gar nicht die Benutzeroberfläche mehrere Prozessoren ausnutzen.
Unter Windows gibt es normalerweise in einem Programm immer nur einen "Thread" ("Ausführungsfaden"), der für die Benutzeroberfläche zuständig ist. Eventuell könnte RoboPro irgendwas nicht Oberflächenbezogenes auf mehrere Kerne verteilen. Das ist aber nicht nur Arbeit für den Entwickler, sondern mitunter richitg aufwändig. In dem Moment, wo ein Programm mehrere Sachen tatsächlich gleichzeitig machen will, muss man sich um Dinge die die Synchronisation von Zugriffen auf dieselben Ressourcen, um die Synchronisation der fertigen Ergebnisse der einzelnen Threads und auch noch um so Kleinigkeiten wie der korrekten Behandlung von Laufzeitfehlern in einem der Threads kümmern. Da steigt die Komplexität leicht schnell an, und ebenso leicht baut man unheimlich schwer zu findende Fehler ein - die nämlich nur ganz selten mal auftreten, wenn grade zufällig das Timing ungünstig ausfällt.
Unter anderen Betriegssystemen (für die es RoboPro ja eh nicht gibt), sind die grundsätzlichen Probleme genau dieselben. Ohne einer Antwort von RPE vorgreifen zu wollen, würde ich würde nicht damit rechnen, dass sich da in absehbarer Zeit etwas ändert. Schließlich tut RoboPro seine Arbeit ja sehr gut - da wird kein riesiges Fass für solche Ausnahmefälle aufgemacht werden, wie Du sie gerade hast.
Wenn Du wirklich rechenaufwändige und parallelisierbare Programme schreiben willst, die online aufs Interface zugreifen sollen, könntest Du den nächsten Schritt machen. Um nur ein paar Beispiele zu nennen: Das .net Framework hat ab Version 4 ganz wunderbare Mechanismen, um parallelisierbare Dinge relativ einfach und zuverlässig (sprich: ohne Berge von manuellem Aufwand) zu parallelisieren. Ebenso ist das Microsoft Robotics Studio von vornherei dafür ausgelegt, Arbeit nicht nur auf mehrere Prozessoren, sondern sogar auf mehrere Computer zu verteilen. Du könntest beides in C# oder Visual Basic oder einer beliebigen anderen Sprache mit einem .net-Compiler nutzen. Allerdings findet das in einer ganz anderen Liga statt, als das recht "kindersichere" Programmieren in RoboPro. Du wirst also mit einer entsprechend steilerern Lernkurve rechnen müssen.
Gruß,
Stefan
Re: Schlechte Multicorenutzung
Hallo!
Vielen Dank für die umfangreiche Antwort.
Ich dachte mir schon dass es in die Richtung gehe...
Es stimmt, dass die "Lernkurve" sehr steil ist. ROBOPro ist die einzige Programmiersprache ist, die ich ausreichend verstehe um solch komplexe Programme zu realisieren. In C++ habe ich mehrmals begonnen, bin aber trotz vielen guten Anleitungen nie sehr weit gekommen.
Meinst du mit "parallelisierbar", dass man mehrere Programmschleifen Parallel laufen lassen kann?
LG
Max Z.
Vielen Dank für die umfangreiche Antwort.
Ich dachte mir schon dass es in die Richtung gehe...
Es stimmt, dass die "Lernkurve" sehr steil ist. ROBOPro ist die einzige Programmiersprache ist, die ich ausreichend verstehe um solch komplexe Programme zu realisieren. In C++ habe ich mehrmals begonnen, bin aber trotz vielen guten Anleitungen nie sehr weit gekommen.
Meinst du mit "parallelisierbar", dass man mehrere Programmschleifen Parallel laufen lassen kann?
LG
Max Z.
-
steffalk
- ft:pedia-Herausgeber
- Beiträge: 1955
- Registriert: 01 Nov 2010, 16:41
- Wohnort: Karlsruhe
- Kontaktdaten:
Re: Schlechte Multicorenutzung
Tach auch!
Mit "parallelisierbar" meine ich die Möglichkeit, eine gegebene Aufgabe in mehrere gleichzeitig (parallel) ausführbare Teile zu zerlegen.
Beispiel: Wenn Du die Summe aus einer Liste von Zahlen berechnen kannst, und 4 Prozessoren hast, dann könntest Du 4 Threads starten, und jeder addiert 1/4 der Liste (parallel und also gleichzeitig mit den anderen). Dann musst Du warten, bis alle fertig sind, und schließlich die Teilsummen addieren. Damit brauchst Du bis auf den zusätzlichen Verwaltungsaufwand nur 1/4 der Zeit.
Nicht alle Aufgaben können aber parallelisiert werden. Und insbesondere die Benutzeroberfläche im Wesentlichen auch nicht, weil das eine Beschränkung der typischen Fenster-Software in grafischen Benutzeroberflächen ist.
Gruß,
Stefan
Mit "parallelisierbar" meine ich die Möglichkeit, eine gegebene Aufgabe in mehrere gleichzeitig (parallel) ausführbare Teile zu zerlegen.
Beispiel: Wenn Du die Summe aus einer Liste von Zahlen berechnen kannst, und 4 Prozessoren hast, dann könntest Du 4 Threads starten, und jeder addiert 1/4 der Liste (parallel und also gleichzeitig mit den anderen). Dann musst Du warten, bis alle fertig sind, und schließlich die Teilsummen addieren. Damit brauchst Du bis auf den zusätzlichen Verwaltungsaufwand nur 1/4 der Zeit.
Nicht alle Aufgaben können aber parallelisiert werden. Und insbesondere die Benutzeroberfläche im Wesentlichen auch nicht, weil das eine Beschränkung der typischen Fenster-Software in grafischen Benutzeroberflächen ist.
Gruß,
Stefan
Re: Schlechte Multicorenutzung
Ok. Vielen Dank!
LG
Max Z.
LG
Max Z.