Das Thread-Mysterium

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	mpmxyz Betreff: Das Thread-Mysterium	Fr, Jul 02, 2010 19:39 Antworten mit Zitat
Da ich gerne meinen Mandelbrot-Renderer eine parallele Berechnung ermöglichen möchte, habe ich mich über die Thread-Implementierung von BlitzMax informiert. Dabei ist mir eines klar geworden: Im Threaded-Modus wird kein Referenzzählungs-GC verwendet, sondern einer, welcher auch Zyklen schafft: http://www.blitzbasic.com/Comm...opic=80344 (brachte mich auf die Annahme) Hinten ist ein Testcode, welcher einem unter anderem auch die Geschwindigkeit der Programme misst. Das Besondere: Im Threaded-Modus läuft der Code ohne Probleme. Im normalen Modus gibt es durch einen Zyklus ein dickes Speicherleck. (für einen Geschwindigkeitsvergleich ohne Speicherleck die markierte Zeile entfernen) Nun merke ich, dass ich schon ein paar mal Mist erzählt hatte, weil nirgendswo steht, dass nicht der einfache Standard-GC genutzt wird. Die Geschwindigkeitseinbußen von ca. 35% kommen wohl durch den veränderten Garbage Collector. So erscheint der Compiler/BlitzMax/brl.Threads selbst aber wieder in einem anderen Licht: Ist BlitzMax-Multithreading nicht so schlimm wie sein Ruf? Kennt ihr Probleme oder habt ihr nie welche gehabt? Bitte sagt es! mfG mpmxyz Anhang zum Testen: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] SuperStrict Framework brl.StandardIO Import brl.System Import brl.LinkedList Local mem1:Int=GCMemAlloced() Local time1:Int=MilliSecs() For Local i:Int=0 Until 10000 Local list:TList=New TList Local orgList:TList=list For Local j:Int=0 Until 1000 list.addLast(New TList) list=TList(list.last()) list.addLast(orgList) '<--- Next GCCollect() Next GCCollect() Local time2:Int=MilliSecs() Print "Zeit: "+(time2-time1) GCCollect() Delay 1000 GCCollect() Local mem2:Int=GCMemAlloced() Print "Speicher: "+(mem2-mem1) Input() End
Moin Moin! Projekte: DBPC CodeCruncher Mandelbrot-Renderer

mpmxyz

Betreff: Das Thread-Mysterium

Fr, Jul 02, 2010 19:39
Antworten mit Zitat

Da ich gerne meinen Mandelbrot-Renderer eine parallele Berechnung ermöglichen möchte, habe ich mich über die Thread-Implementierung von BlitzMax informiert.
Dabei ist mir eines klar geworden:
Im Threaded-Modus wird kein Referenzzählungs-GC verwendet, sondern einer, welcher auch Zyklen schafft:
http://www.blitzbasic.com/Comm...opic=80344 (brachte mich auf die Annahme)

Hinten ist ein Testcode, welcher einem unter anderem auch die Geschwindigkeit der Programme misst.
Das Besondere:
Im Threaded-Modus läuft der Code ohne Probleme.
Im normalen Modus gibt es durch einen Zyklus ein dickes Speicherleck. (für einen Geschwindigkeitsvergleich ohne Speicherleck die markierte Zeile entfernen)

Nun merke ich, dass ich schon ein paar mal Mist erzählt hatte, weil nirgendswo steht, dass nicht der einfache Standard-GC genutzt wird.
Die Geschwindigkeitseinbußen von ca. 35% kommen wohl durch den veränderten Garbage Collector.
So erscheint der Compiler/BlitzMax/brl.Threads selbst aber wieder in einem anderen Licht:
Ist BlitzMax-Multithreading nicht so schlimm wie sein Ruf?
Kennt ihr Probleme oder habt ihr nie welche gehabt?
Bitte sagt es!

mfG
mpmxyz

Anhang zum Testen:
BlitzMax: [AUSKLAPPEN]

SuperStrict
Framework brl.StandardIO
Import brl.System
Import brl.LinkedList

Local mem1:Int=GCMemAlloced()
Local time1:Int=MilliSecs()
For Local i:Int=0 Until 10000
	Local list:TList=New TList
	Local orgList:TList=list
	For Local j:Int=0 Until 1000
		list.addLast(New TList)
		list=TList(list.last())
		list.addLast(orgList) '<---
	Next
	GCCollect()
Next
GCCollect()
Local time2:Int=MilliSecs()
Print "Zeit: "+(time2-time1)
GCCollect()
Delay 1000
GCCollect()
Local mem2:Int=GCMemAlloced()
Print "Speicher: "+(mem2-mem1)
Input()
End

Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer

	Noobody Betreff: Re: Das Thread-Mysterium	Sa, Jul 03, 2010 9:06 Antworten mit Zitat
mpmxyz hat Folgendes geschrieben: Ist BlitzMax-Multithreading nicht so schlimm wie sein Ruf? Weil du plötzlich entdeckt hast, dass der Threaded-GC zyklische Datenstrukturen beherrscht? Das Hauptproblem im Multithreading sind die ganzen BRL-Module, die nicht darauf ausgelegt sind. Entweder fliegt einem das Programm um die Ohren, weil zwei Threads eine Ressource verwenden, die das Modul nicht ordnungsgemäss sperrt, oder es funktioniert nicht, weil von irgendeinem Thread Events abgefangen werden, auf die der andere wartet. Grosses Problem für mich war auch der grottenlahme GC im MT-Modus (ich versuchte, meinen Fraktalraytracer auf MT umzuschrauben). Alleine schon den MT-Build zu aktivieren machte das Rendern 7 Mal langsamer - mehr, als ich je durch Multithreading hätte herausholen können.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Betreff: Re: Das Thread-Mysterium

Sa, Jul 03, 2010 9:06
Antworten mit Zitat

mpmxyz hat Folgendes geschrieben:

Ist BlitzMax-Multithreading nicht so schlimm wie sein Ruf?

Weil du plötzlich entdeckt hast, dass der Threaded-GC zyklische Datenstrukturen beherrscht?

Das Hauptproblem im Multithreading sind die ganzen BRL-Module, die nicht darauf ausgelegt sind. Entweder fliegt einem das Programm um die Ohren, weil zwei Threads eine Ressource verwenden, die das Modul nicht ordnungsgemäss sperrt, oder es funktioniert nicht, weil von irgendeinem Thread Events abgefangen werden, auf die der andere wartet.

Grosses Problem für mich war auch der grottenlahme GC im MT-Modus (ich versuchte, meinen Fraktalraytracer auf MT umzuschrauben). Alleine schon den MT-Build zu aktivieren machte das Rendern 7 Mal langsamer - mehr, als ich je durch Multithreading hätte herausholen können.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	Firstdeathmaker	Sa, Jul 03, 2010 13:34 Antworten mit Zitat
Also ich hab bisher zwar nicht viel, aber dennoch sehr gute Erfahrung mit MT gemacht. Ganz am Anfang war es doch sehr buggy... Ich arbeite z.B. gerade an einer Physikengine, bei der ich die Physikberechnungen in Threads ausgelagert habe. Das tolle wie ich finde ist, dass man die komplette Logik seines Spiels auslagern kann, und dann nur noch die render-methoden im MainThread ausführen muss, beides also komplett unabhängig voneinander läuft. Und was die Koordination angeht: Es gibt doch Mutexe und Signals. Wenn BMax etwas nicht alleine schafft, kann man die entsprechenden Funktionen nicht durch Wrapper ersetzen wenn etwas mal nicht klappt? Bei meinem Rechner (Core I7 Q 720) mit 4 Kernen, bzw. 8 durch Hyperthreading, macht Multitasking eine Menge aus, wenn es auch wirklich genutzt wird. Beispiel: Anno 1403, teilt alle seine Berechnungen in extrem viele parallele Threads auf. Auch der neue Firefox hat hier zugelegt. Das nutzt dann meine CPU auch wirklich mal aus. Leider machen dass nicht alle Programme.
www.illusion-games.de Space War 3 \| Space Race \| Galaxy on Fire \| Razoon Gewinner des BCC #57 User posted image

Firstdeathmaker

Sa, Jul 03, 2010 13:34
Antworten mit Zitat

Also ich hab bisher zwar nicht viel, aber dennoch sehr gute Erfahrung mit MT gemacht. Ganz am Anfang war es doch sehr buggy...

Ich arbeite z.B. gerade an einer Physikengine, bei der ich die Physikberechnungen in Threads ausgelagert habe. Das tolle wie ich finde ist, dass man die komplette Logik seines Spiels auslagern kann, und dann nur noch die render-methoden im MainThread ausführen muss, beides also komplett unabhängig voneinander läuft.

Und was die Koordination angeht: Es gibt doch Mutexe und Signals. Wenn BMax etwas nicht alleine schafft, kann man die entsprechenden Funktionen nicht durch Wrapper ersetzen wenn etwas mal nicht klappt?

Bei meinem Rechner (Core I7 Q 720) mit 4 Kernen, bzw. 8 durch Hyperthreading, macht Multitasking eine Menge aus, wenn es auch wirklich genutzt wird. Beispiel: Anno 1403, teilt alle seine Berechnungen in extrem viele parallele Threads auf. Auch der neue Firefox hat hier zugelegt. Das nutzt dann meine CPU auch wirklich mal aus. Leider machen dass nicht alle Programme.

www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

	mpmxyz	Sa, Jul 03, 2010 14:45 Antworten mit Zitat
@Noobody In der Dokumentation steht nur, dass es einen GC mit Referenzzählung gibt. Zusätzlich zu den Gerüchten, dass es (fatale) Fehler in den Modulen gäbe, hatte diese Information für einen großen Irrtum meinerseits geführt. Woher sollte ich wissen, dass es anders ist? Aus der Dokumentation schon einmal nicht! Da ich nun nicht mehr sicher war, was stimmt und was nicht stimmt, wollte ich mit diesem Thread für mich und für andere ein wenig Klarheit schaffen. Was sollten die brl-Module denn deiner Meinung nach machen? Sollen sie alles absichern, auch wenn das bearbeitete Objekt nur in einem Thread gebraucht wird? Ich kenne auch aus anderen Sprachen einige Modul-Äquialente, welche genau die selben Probleme haben, da sie auf den Overhead verzichten wollen. Mit der Geschwindigkeit habe ich keine Probleme. Mein Mandelbrot-Renderer hat beim Umschalten auf den Threaded-Modus etwa die gleiche Rechengeschwindigkeit, wie im "Not Threaded"-Modus. Das einzige, was störend aber "behebbar" ist, ist die Tatsache, dass man Threads schwer debuggen kann. Den zum Debuggen nötigen eigenen Code muss man aber normalerweise nur ein einziges Mal schreiben. mfG mpmxyz
Moin Moin! Projekte: DBPC CodeCruncher Mandelbrot-Renderer

mpmxyz

Sa, Jul 03, 2010 14:45
Antworten mit Zitat

@Noobody
In der Dokumentation steht nur, dass es einen GC mit Referenzzählung gibt.
Zusätzlich zu den Gerüchten, dass es (fatale) Fehler in den Modulen gäbe, hatte diese Information für einen großen Irrtum meinerseits geführt. Woher sollte ich wissen, dass es anders ist?
Aus der Dokumentation schon einmal nicht!
Da ich nun nicht mehr sicher war, was stimmt und was nicht stimmt, wollte ich mit diesem Thread für mich und für andere ein wenig Klarheit schaffen.

Was sollten die brl-Module denn deiner Meinung nach machen?
Sollen sie alles absichern, auch wenn das bearbeitete Objekt nur in einem Thread gebraucht wird?
Ich kenne auch aus anderen Sprachen einige Modul-Äquialente, welche genau die selben Probleme haben, da sie auf den Overhead verzichten wollen.

Mit der Geschwindigkeit habe ich keine Probleme.
Mein Mandelbrot-Renderer hat beim Umschalten auf den Threaded-Modus etwa die gleiche Rechengeschwindigkeit, wie im "Not Threaded"-Modus.

Das einzige, was störend aber "behebbar" ist, ist die Tatsache, dass man Threads schwer debuggen kann.
Den zum Debuggen nötigen eigenen Code muss man aber normalerweise nur ein einziges Mal schreiben.
mfG
mpmxyz

Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer

	Noobody	Sa, Jul 03, 2010 15:08 Antworten mit Zitat
mpmxyz hat Folgendes geschrieben: In der Dokumentation steht nur, dass es einen GC mit Referenzzählung gibt. Zusätzlich zu den Gerüchten, dass es (fatale) Fehler in den Modulen gäbe, hatte diese Information für einen großen Irrtum meinerseits geführt. Woher sollte ich wissen, dass es anders ist? Macht der veränderte GC im Threaded-Modus für dich so einen grossen Unterschied? Und ja, das steht nicht in der Dokumentation. So vieles steht nicht in der Dokumentation - bei BRL hapert es da ein wenig. mpmxyz hat Folgendes geschrieben: Was sollten die brl-Module denn deiner Meinung nach machen? Sollen sie alles absichern, auch wenn das bearbeitete Objekt nur in einem Thread gebraucht wird? Wofür gibt es denn das ?Threaded-Flag, wenn es nicht genutzt wird? Das ist doch genau für solche Dinge gedacht. mpmxyz hat Folgendes geschrieben: Mein Mandelbrot-Renderer hat beim Umschalten auf den Threaded-Modus etwa die gleiche Rechengeschwindigkeit, wie im "Not Threaded"-Modus. Ist ja schön, dass du nur ein dutzend Objekte nutzt, aber bei mehr als tausend Stück sackt die Performance einfach furchtbar ein. Den Fraktal-Raytracer, den SPH-Simulator und den normalen Raytracer musste ich daher für Multithreading-Zwecke auf C++ portieren, da sie jeweils stark auf Quaternionen, Partikelobjekte oder Vektoren aufbauten. Eine kleine GUI-Applikation, die nebenbei noch eine Datei schreiben muss oder wie bei dir ein simpler Mandelbrot-Zeichner gehen noch ziemlich gut mit dem Threaded-GC, aber bei Projekten mit grosses Objektanzahl ist Threaded eher Last als Gewinn. Firstdeathmaker hat Folgendes geschrieben: Es gibt doch Mutexe und Signals. Wenn BMax etwas nicht alleine schafft, kann man die entsprechenden Funktionen nicht durch Wrapper ersetzen wenn etwas mal nicht klappt? Es lässt sich eben nicht alles mit Mutexes lösen Dass man Timer nicht in einem anderen Thread als dem Hauptthread verwenden kann, liegt schlicht an der drunterliegenden Struktur und nicht an gleichzeitigem Zugriff.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Sa, Jul 03, 2010 15:08
Antworten mit Zitat

mpmxyz hat Folgendes geschrieben:

In der Dokumentation steht nur, dass es einen GC mit Referenzzählung gibt.
Zusätzlich zu den Gerüchten, dass es (fatale) Fehler in den Modulen gäbe, hatte diese Information für einen großen Irrtum meinerseits geführt. Woher sollte ich wissen, dass es anders ist?

Macht der veränderte GC im Threaded-Modus für dich so einen grossen Unterschied?

Und ja, das steht nicht in der Dokumentation. So vieles steht nicht in der Dokumentation - bei BRL hapert es da ein wenig.

mpmxyz hat Folgendes geschrieben:

Was sollten die brl-Module denn deiner Meinung nach machen?
Sollen sie alles absichern, auch wenn das bearbeitete Objekt nur in einem Thread gebraucht wird?

Wofür gibt es denn das ?Threaded-Flag, wenn es nicht genutzt wird? Das ist doch genau für solche Dinge gedacht.

mpmxyz hat Folgendes geschrieben:

Mein Mandelbrot-Renderer hat beim Umschalten auf den Threaded-Modus etwa die gleiche Rechengeschwindigkeit, wie im "Not Threaded"-Modus.

Ist ja schön, dass du nur ein dutzend Objekte nutzt, aber bei mehr als tausend Stück sackt die Performance einfach furchtbar ein. Den Fraktal-Raytracer, den SPH-Simulator und den normalen Raytracer musste ich daher für Multithreading-Zwecke auf C++ portieren, da sie jeweils stark auf Quaternionen, Partikelobjekte oder Vektoren aufbauten.

Eine kleine GUI-Applikation, die nebenbei noch eine Datei schreiben muss oder wie bei dir ein simpler Mandelbrot-Zeichner gehen noch ziemlich gut mit dem Threaded-GC, aber bei Projekten mit grosses Objektanzahl ist Threaded eher Last als Gewinn.

Firstdeathmaker hat Folgendes geschrieben:

Es gibt doch Mutexe und Signals. Wenn BMax etwas nicht alleine schafft, kann man die entsprechenden Funktionen nicht durch Wrapper ersetzen wenn etwas mal nicht klappt?

Es lässt sich eben nicht alles mit Mutexes lösen Razz

Dass man Timer nicht in einem anderen Thread als dem Hauptthread verwenden kann, liegt schlicht an der drunterliegenden Struktur und nicht an gleichzeitigem Zugriff.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	mpmxyz	Sa, Jul 03, 2010 15:44 Antworten mit Zitat
Mit dem ersten Punkt wollte ich eigentlich nur klarmachen, dass es einige Gerüchte gibt, welche nicht wahr sind. Dazu gehörten die hier und da genannten "Speicherlecks". "?Threaded" bzw. "?Not Threaded" helfen bei dem Problem der Optimierung leider auch nicht weiter. Die Tatsache, ob ein Objekt gesichert werden muss oder nicht, kann man damit auch nicht beantworten. Ich habe bei einem extra für diesen Thread erstellten und veröffentlichten Test "nur" Einbußen im Bereich von 35% gehabt. Etwas in der Größenordnung von 85% habe ich nicht gehabt. (ein kleines Offtopic: Das Umstellen von TComplex-Objekten auf "Hardcoding" hatte bei mir eine Geschwindigkeitssteigerung von etwa 1000% gebracht. Schon ohne Multithreading bremst die Verwendung von Objekten das Programm aus.) mfG mpmxyz
Moin Moin! Projekte: DBPC CodeCruncher Mandelbrot-Renderer

mpmxyz

Sa, Jul 03, 2010 15:44
Antworten mit Zitat

Mit dem ersten Punkt wollte ich eigentlich nur klarmachen, dass es einige Gerüchte gibt, welche nicht wahr sind. Dazu gehörten die hier und da genannten "Speicherlecks".
"?Threaded" bzw. "?Not Threaded" helfen bei dem Problem der Optimierung leider auch nicht weiter.
Die Tatsache, ob ein Objekt gesichert werden muss oder nicht, kann man damit auch nicht beantworten.
Ich habe bei einem extra für diesen Thread erstellten und veröffentlichten Test "nur" Einbußen im Bereich von 35% gehabt. Etwas in der Größenordnung von 85% habe ich nicht gehabt.
(ein kleines Offtopic: Das Umstellen von TComplex-Objekten auf "Hardcoding" hatte bei mir eine Geschwindigkeitssteigerung von etwa 1000% gebracht. Schon ohne Multithreading bremst die Verwendung von Objekten das Programm aus.)
mfG
mpmxyz

Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Das Thread-Mysterium

mpmxyz

Betreff: Das Thread-Mysterium

Noobody

Betreff: Re: Das Thread-Mysterium

Firstdeathmaker

mpmxyz

Noobody

mpmxyz