Parallelisierung

[Falko]

Hallo Zusammen!

Mich würde interessieren in wie fern man sich Seitens Dlubal mit parallelisierten Prozessoren beschäftigt? Ist es vorgesehen das der Solver von RFEM durch die Nutzung von Multicore-Prozessoren noch schneller wird? Oder kann das RFEM schon und ich weiß es bloß nicht?

[Frank Böhme]

AW: Parallelisierung

Hallo Zusammen!

Mich würde interessieren in wie fern man sich Seitens Dlubal mit parallelisierten Prozessoren beschäftigt? Ist es vorgesehen das der Solver von RFEM durch die Nutzung von Multicore-Prozessoren noch schneller wird? Oder kann das RFEM schon und ich weiß es bloß nicht?

Hallo Herr Dieringer,

ich kann Sie beruhigen, Sie nutzen RFEM nicht mit halber Kraft . Momentan werden Dualcore- bzw. Mehrkernprozessoren von RFEM noch nicht unterstützt.
Im Rahmen der Weiterentwicklung ist die Berücksichtigung von parallelisierten Prozessoren sowie die effiziente Nutzung der 64-Bit Technologie aber geplant.
Einen Zeithorizont kann ich Ihnen leider noch nicht nennen.

Viele Grüße
Frank Böhme

[sollner11]

AW: Parallelisierung

hallo,

da wir alle unsere rechner auch c2d umgestellt haben, haben wir natuerlich unbedingtes interesse an dieser entwicklung

gruss

[CaWo]

AW: Parallelisierung

Leider ist auch im August 2010 keine Nutzung von mehreren Kernen möglich.

Die Programme RSTAB und RFEM sind exorbitant langsam.

Siehe c't Heft 16/2010 Seite 171ff.

[Pitt]

AW: Parallelisierung

dann bin ich nicht der Einzige, bei dem es nicht schneller geht.

Auf meine Frage nach Unterstützung der 64 Bit-Technilogie mit Quad-Kern wurde mir mitgeteilt, dass RFEM4 diese Technologie unterstützt und dass geeignete Treiber im Extranet zu beziehen sind. Dort habe ich allerdings keine speziellen Treiber gefunden und schneller geht es mit meinem Quad-Core-Rechner auch nicht.

Daraufhin hieß es, dass "die Aufteilung auf mehrere Prozessoren nur für den direkten Solver aus mathematische Gründen möglich" ist.
Ich habe das so verstanden, dass bei iterativen Berechnungen eine Aufteilung auf mehrere Prozessoren nicht möglich ist.

Mein entsprechender Einwand (gerade solche Probleme sind rechenintensiv und sollten schneller ablaufen) wurde nicht beantwortet, ebenso wurde eine Berechnung meines Beispiels (ohne Iterationen) mit Zeitmessung nicht durchgeführt. Auch ohne diese Iterationen läuft das System bei mir nicht schneller.

Gruß Pitt

[Frank Faulstich]

AW: Parallelisierung

Hallo,

mit RFEM 4 ist durchaus eine Nutzung mehrere Prozessorkerne (Multithreading) und der 64Bit-Technologie möglich. Zuerst einmal möchte ich die Begriffe etwas auseinander nehmen.

Multithreading

Herkömmliche Programme führen immer einen Programmschritt nach dem anderen aus (Von-Neumann-Architektur). Seit Mitte der 1990er Jahre gibt es auch in der PC-Plattform immer mehr Computer, die über mehr als einen Prozessorkern verfügen. Heute ist das Standard. Wenn mehrere Programme (=Prozesse) gleichzeitig auf einer Maschine laufen, dann wird dadurch die Abarbeitung beschleunigt. Wenn nur ein einziges Programm auf dem Computer läuft, dann nutzt das zunächst einmal nur einen Prozessor und die anderen liegt brach und die Abarbeitung wird zunächst nicht beschleunigt. Abhilfe hierfür schafft das Multithreading. Das Programm wird in mehrere Threads (“Mini-Prozesse”) aufgeteilt, die parallel verarbeitet werden können. Das effektive Parallelisieren von Threads ist eine nicht ganz einfache Aufgabe. Beispiel: Die Ergebnisse einer Berechnung können erst dann ausgegeben werden, wenn alles vollständig berechnet ist. Das heißt, die Threads müssen untereinander kommunizieren und es entsteht ein gewisser Overhead. Wenn ein Programm mit Multithreading auf einer Einprozessormaschine ausgeführt wird, dann läuft es deswegen erst einmal langsamer.

Außerdem gibt es Programmschritte, die vom Ergebnis der vorherigen Schrittes abhängig sind. Es muss im RFEM-Rechenkern zunächst die Gesamtsteifigkeitsmatrix aufstellen, bevor das Gleichungssystem gelöst werden kann. Es lassen sich also nicht alle Abläufe parallel ausführen.

Diese Zusammenhänge können im Amdahlschen Gesetz dargestellt werden. Bei näherer Betrachtung zeigt das Gesetz, dann durch Multithreading durchaus erhebliche Geschwindigkeitssteigerungen erziehlen lassen, jedoch keine Wunder zu erwarten sind.

Ich habe vor einiger Zeit Tests an einem Computer mit 4 Prozessorkernen durchgeführt. Zum Testen wurde eine Struktur mit Volumenelementen benutzt. Ich habe die Struktur mit einem, mit zwei, drei und vier Kernen berechnet und die Zeit gestoppt. Die Zuschaltung des 2. Prozessors brachte eine Leistungssteigerung (Speedup) von 1,6, die des 3. von 2,0 und die des 4. vom 2,3 (immer verglichen mit einem Prozessor).

Interessant wird es, wenn man mit dem Amdahlschen es was weiter rechnet. Die maximale Beschleunigung würde in diesem Beispiel mit 9 Prozessoren erreicht, die Beschleunigung würde dann 2,7 (!) betragen. Mehr Kerne würden durch den Overhead die Berechnung verlangsamen.

Es hängt natürlich auch entscheidend von der Art der Struktur ab, wie die Berechnung von der Parallelisierung profitiert. Eine Stabstruktur, die lange rechnet, weil sehr viele Iterationen durchzuführen sind, wird sicherlich kaum beschleunigt. Große Strukturen mit Volumenelementen oder Schalenelementen profitieren deutlich.

Alles bisher gesagte gilt sowohl für 32Bit- als auch für 64Bit-Windows.

64Bit

In RFEM gibt es seit jeher zwei Solver, den direkten und den iterativen. In den Berechnungsparametern kann zwischen den Solvern umgeschaltet werden.

Der direkte Solver hat gegenüber dem iterativen den Vorteil, dass er wesentlich schneller ist. Jedoch braucht er mehr Speicher. Jetzt könnte man sagen, dann steck ich eben mehr RAM in den Rechner. Aber auch das hilft nur begrenzt. “Normales” 32Bit-Windows weißt jedem Prozess maximal 2GiByte Speicher zu, egal wie viel Speicher noch frei ist. Mehr Speicher kann ein Prozess bekommen, wenn der Computer mit einem 64Bit-Betriebssystem läuft. Es gibt von Windows XP, Windows Vista und Windows 7 jeweils ein 64Bit-Version.

Turbo Boost / Turbo Core

Der Artikel in der c’t [2] bezieht sich auf diese Technologie. Hierbei handelt es sich um eine Technik moderner Prozessoren von Intel und AMD, nicht multitheading-fähige Programme zu beschleunigen. Solche Programme profitieren am meisten von einer Erhöhung der Taktfrequenz. Wenn festgestellt wird, dass einige Kerne des Prozessors nichts zu tun haben, dann wird die Taktfrequenz der beschäftigten Kerne erhöht. Die Grenze für die Erhöhung der Taktfrequenz der Prozessoren ist ja die Wärmeentwicklung. Je höher die Taktfrequenz desto mehr Wärme wird frei. Wenn aber einige Kerne nicht zu tun haben und in den “Schlafmodus” geschaltet werden, dann können die Kerne, die Arbeit haben, etwas mehr Wärme produzieren, also kann deren Taktfrequenz gesteigert werden.

Ein Anwendungprogramm wie RSTAB/RFEM muss nicht speziell darauf vorbereitet werden, diese Technik zu nutzen. Das ist die Aufgabe des BIOS und teilweise des Betriebssystems. Sollte das nicht richtig funktionieren, dann sind in [1] auch ein paar Hinweise zur Fehlersuche zu finden.

Umsetzung in RFEM/RSTAB

Den Einbau des Multithreadings in das Programm ist nicht ganz simpel. Es ist wichtig, Aufwand gegen Nutzen abzuwägen. Die Frage ist also, wo bringt die Parallelisierung dem Kunden am meisten Nutzen. Wir haben uns entschieden, beim Rechenkern von RFEM anzufangen. Seit RFEM 4 nutzt der direkte Solver mehrere Prozessorkerne. Die Programmoberfläche von RFEM und das Ausdruckprotokoll nutzen weiterhin nur ein Kern. Das wird sich in Zukunft ändern.

Es ist auch geplant, den interativen Solver auf Multitheading umzustellen. Allerdings kommt das in diesem Fall dem Neuschreiben des Solvers gleich und wird noch etwas dauern.

Derzeit in Arbeit ist die Parallelisierung der Berechnung der Schnittgrößen. Das ist der Schritt, der nach dem Lösen des Gleichungssystems durchgeführt wird.

Für die Nutzung der 64Bit-Technik sind keine speziellen Treiber notwendig. Es muss nur ein 64Bit-Windows verhanden sein. Erkennt RFEM das, dann wird in den Berechnungsparametern die Nutzung des 64Bit-Solvers angeboten und bei neuen Dateien auch voreingestellt.

Wenn mit RFEM große Strukturen berechnet werden sollen, dann sollte ein 64Bit-Betriebssystem verwendet werden, der Rechner sollte über ausreicht RAM verfügen und es sollte der direkte Solver verwendet werden. Wie viel RAM im konkreten Fall notwendig ist, kann nicht vorhergesagt werden. Im Taskmanager von Windows kann man aber mal schauen, wie viel Speicher der Rechenkern (Prozess Solver64.exe) braucht.

In RSTAB wird momentan weder Multithreading noch 64Bit-Technik verwendet, was sich aber in Zukunft ändern wird.

Wenn die Arbeit mit RSTAB/RFEM als “exorbitant langsam” empfunden wird, dann sollte mit der Hotline abgeklärt werden, ob man wirklich die Leistungsgrenze erreicht hat oder ob es eventuell andere Ursachen gibt, die die Arbeit ausbremsen.

Viele Grüße

Frank Faulstich

[1] Benjamin Benz, Nachbrenner, c’t 16/2010

[Pitt]

AW: Parallelisierung

Hallo,

eine so ausführliche Antwort hätte ich mir von der Hotline auch gewünscht.

Ich werde mich in den nächsten Tagen mit meinem Problem direkt an Sie wenden.



Pitt

[CaWo]

AW: Parallelisierung

Nur der Gleichungslöser von RFEM nutzt mehrere Kerne.

Kann z.B. mit T-Monitor von CPUID beobachtet werden.

Aber das Gleichungslösen benötigt nur einen kleinen Bruchteil der gesamten Bearbeitungszeit.
Das Ermitteln der Element- und Stabschnittgrößen, Spannungsnachweise, Ausdruckprotokolle erfolgt jedoch nur auf einem Kern.

Insgesamt laufen die Programme RSTAB und FREM auf heutigen Rechnern zu langsam.

[Frank Faulstich]

AW: Parallelisierung

Hallo,

Nur der Gleichungslöser von RFEM nutzt mehrere Kerne.

Kann z.B. mit T-Monitor von CPUID beobachtet werden.

Aber das Gleichungslösen benötigt nur einen kleinen Bruchteil der gesamten Bearbeitungszeit.

Einige unserer Kunden rechnen sehr große Strukturen, bei der die Zeit für das Gleichungslösen eine entscheidende Rolle spielt.
Wie gesagt, es kommt auf die Modelle an...

Das Ermitteln der Element- und Stabschnittgrößen, Spannungsnachweise, Ausdruckprotokolle erfolgt jedoch nur auf einem Kern.

Insgesamt laufen die Programme RSTAB und FREM auf heutigen Rechnern zu langsam.

Wenn der Eindruck besteht, dass RSTAB/RFEM zu langsam laufen, dann kann da eventuell die Hotline herausfinden, wie sich die Probleme lösen lassen.

Viele Grüße

Frank Faulstich

[CaWo]

AW: Parallelisierung

Nach dem Umstieg auf RSTAB7 hier mal ein paar Zeitvergleiche.

Reines Stabwerk:
1340 Knoten, 3005 Stäbe, 8040 Gleichungen
37 LFs, 13 LGs, 16 LKs

Rechner 1 : Win XP , Intel Core Duo E4700, 2GB
RSTAB 7 = 07:00 min
RFEM 4 *) = 02:15

*) Das Stabwerk wurde mit RFEM geöffnet. RFEM ist Faktor 3 !! schneller.

Rechner 2 : Win 7-64bit , Intel i5-750, 8GB
RSTAB 7 = 09:40 min
RFEM 4 = 00:55

RFEM ist Faktor 10,5 !!!! schneller.

Fazit:
1) Je schneller der Rechner, desto langsamer rechnet RSTAB

2) Offensichtlich wird RSTAB nicht weiterentwickelt. Nennenswerte Unterschiede zwischen RSTAB6 und RSTAB 7 konnten nicht festgestellt werden.
Am besten den Vertrieb einstellen und den Kunden kostenlos RFEM zur Verfügung stellen.

[Frank Faulstich]

AW: Parallelisierung

Hallo CaWo,

um der Sache mit den Rechenzeiten auf den Grund zu gehen wäre es gut, die Datei an die Hotline zu schicken. Alles Andere wäre nur Spekulation.

Viele Grüße

Frank Faulstich

[Frank Faulstich]

AW: Parallelisierung

Hallo,

uns wurde die betreffende Datei zur Verfügung gestellt und ich kommte sie näher analysieren.

Der Hauptgrund für die großen Unterschiede in der Rechenzeit war die Berechnung der Lastfallkombinationen (LK). Hier gehen RSTAB und RFEM grundsätzlich verschiedene Wege.

RSTAB: Beim Berechnen einer LK werden die darin enthaltenen Lastfälle (LF) gerechnet, die Ergebnisse überlagert und in der RSTAB-Datei abgespeichert.

RFEM: Es werden nur die enthaltenen LFs berechnet. Erst beim Anzeigen der Ergebnisse findet die Überlagerung statt. Es werden keine LK-Ergebnisse abgespeichert.

Beide Methoden haben ihre Vor- und Nachteile. Die RFEM-Methode ist beim Berechnen schneller. Der Hauptvorteil ist, dass die Datenmenge zum Abspeichern wesentlich geringer ist.

Der Vorteil der RSTAB-Methode ist, dass der Zugriff auf die Ergebnisse in der Grafik sehr viel schneller ist. Ebenso ist die Berechnung in den Modulen schneller, weil diese auf vorhandene Ergebnisse zurückgreifen können.

Viele Grüße

Frank Faulstich