Multitasking

Übersicht BlitzMax, BlitzMax NG Allgemein

Neue Antwort erstellen

DAK

Betreff: Multitasking

BeitragMi, Okt 28, 2009 16:06
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich wollt mal fragen, ob iwer das Multitasking in BMax wirklich verwendet.

Ich mein, das war ja eins DER Features schlecht hin. Darauf wurde Monate und Jahre lang gewartet. MT ist als das Wundermittel überhaupt erwartet worden...

Bis jetzt hab ich hier aber nicht mehr als ein paar kleine Tests damit gesehen. Und selber gemacht hab ich damit auch nicht mehr.

Wie schauen eure Erfahrungen mit MT aus?

Braucht das iwer?... Oder is das eurer Meinung nach (so wie auch ein bissal meiner Meinung nach) nur ein weiteres tolles Feature, mit dem man für BMax hausieren gehen kann (alla "meine Programmiersprache kann OOP, DX, OGL, MT, ...")?
Gewinner der 6. und der 68. BlitzCodeCompo

hazumu-kun

BeitragMi, Okt 28, 2009 17:00
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich hab mir bisher nur eine paar kleine Proof of Concepts zusammengescribbelt, also ich bin dem MT gegenüber abgeneigt, weil es atm zein wenig zu kompliziert mit dem syncen ist, ich brauch es nicht, ich kann seriell viel besser arbeiten.
Warum kann es keine omnipotente Macht geben?
Weil diese omnipotente Macht in der Lage sein müsste, einen so schweren Stein zu schaffen, dass sie ihn nicht heben kann
-> nicht omnipotent

BtbN

BeitragMi, Okt 28, 2009 17:09
Antworten mit Zitat
Benutzer-Profile anzeigen
Die implementation in BMax ist einfach grotten schlecht. Eine sinnvolle synchronisation von mehreren Threads ist quasi nicht möglich, da jegliche BMax-Module das schlicht und ergreifend nicht eingeplant haben, und somit ein versehentlich und über 3 ecken ausgelöstes Event mal eben das Programm crashen lässt, da es Code, der für einen andern Thread gedacht ist, mal eben aus dem Event-Werfenden Thread aus ausführt.
 

E. Urbach

ehemals "Basicprogger"

BeitragMi, Okt 28, 2009 19:07
Antworten mit Zitat
Benutzer-Profile anzeigen
Habe es ausgiebig getestet, auch mit dem Laden von z.B. Tile-Daten im Hintergrund. Synchronisation ist grundsätzlich kein großes Problem, aber der extrem langsame GC, bei dem man nicht einmal ein Sleep(0) bzw. Delay(0) oder auch nur ein simples Yield() einbinden kann, ist der Knackpunkt.

Siehe hier.
Momentan ist also kein sinnvolles MT möglich.

tft

BeitragMi, Okt 28, 2009 23:39
Antworten mit Zitat
Benutzer-Profile anzeigen
Hallo,

also unter BM habe ich noch nichts mit MT gemacht, aber mit B3D. Dort geht es halt einfacher wenn man grundsätzlich einen anderen Weg einschlägt. Daduch das mehrer einzelprogramme laufen ..... mit der RunDll. Hat man Echtes MultiThreading. Den Tasking gibts ja auf dem PC nicht. Der Daten austausch unter den Programmen ist natürlich entweder durch UDP oder Memory Hacking nicht ganz einfach. Aber fiele dinge lassen sich damit toll machen. Zum beispiel asyncrone Lade Rutinen, Asyncrones Laden und Abspieln von Sound. Sortierrutinen für Level daten bei Landschaften und dehr grossen arealen. Wo man getrost auf echzeit verzichten kann. Netzwerk fähigkeit ohne das lästige Wait lag, wenn die Verbindung mal hängt. Mit etwas aufwand läst dich da fiel anstellen.

gruss TFT
TFT
https://www.sourcemagic.ch
Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!!

hazumu-kun

BeitragDo, Okt 29, 2009 15:21
Antworten mit Zitat
Benutzer-Profile anzeigen
Das was du da machst ist Multitasking mit UDP/TCP Pipe zwischen den Progs.
Wir reden von Threading:
EIN Programm(EINE BINARY) erzeugt paralell existierende Anweisungsblöcke die über das OS paralellisiert werden.
Warum kann es keine omnipotente Macht geben?
Weil diese omnipotente Macht in der Lage sein müsste, einen so schweren Stein zu schaffen, dass sie ihn nicht heben kann
-> nicht omnipotent

Jan_

Ehemaliger Admin

BeitragDo, Okt 29, 2009 16:09
Antworten mit Zitat
Benutzer-Profile anzeigen
Hm, ich weiß ja nicht, warum das so langsam sein soll...

Code: [AUSKLAPPEN]
Global Wert%=0


Function calc:Object(date:Object)
   Local i%,m%
   For i = 0 To (100000000)
      m=Float(m)+Sin (i)^2
   Next
   Wert=m
   Return "Blub"
EndFunction

Local m1=MilliSecs()
Local thread:TThread = CreateThread(calc,"Bla")
Local b=0
Repeat

   If wert <> 0 And b=0 Then
      Print Wert
      Print "Dauer1: "+(MilliSecs()-m1)
      b=1
      m1=MilliSecs()
      Local i%,m%
      For i = 0 To (100000000)
         m=Float(m)+Sin (i)^2
      Next
      Wert=m
      Print "Dauer2: "+(MilliSecs()-m1)
   EndIf

Until KeyHit(key_escape)


Zitat:
555556
Dauer1: 21678
Dauer2: 21466

Siehe da, ca. 98% der Geschwindigkeit bei der selben Berechnung. Habt ihr mal ein Beispiel, woran man sehen kann, dass es so grottig langsam ist?
(AMD Phenom 9650 Quadcore)
between angels and insects

BladeRunner

Moderator

BeitragDo, Okt 29, 2009 16:19
Antworten mit Zitat
Benutzer-Profile anzeigen
Zumindest meine Versuche Images im Hintergrund zu laden waren sehr vielversprechend. Allerdings habe ich nur an der Oberfläche gekratzt.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

BtbN

BeitragDo, Okt 29, 2009 19:32
Antworten mit Zitat
Benutzer-Profile anzeigen
Sobald in dem Thread etwas stattfinden, wobei der GC aktiv werden, bricht die performance enorm ein.

Firstdeathmaker

BeitragDo, Okt 29, 2009 21:18
Antworten mit Zitat
Benutzer-Profile anzeigen
Ja, der GC ist der Knackpunkt. Bisher habe ich auch immer nur mit Laderoutinen etc. experimentiert, aber nie Gedanken an das Aufräumen verschwendet, was bei richtigen Projekten ja wirklich notwendig ist.
www.illusion-games.de
Space War 3 | Space Race | Galaxy on Fire | Razoon
Gewinner des BCC #57 User posted image

Jan_

Ehemaliger Admin

BeitragFr, Okt 30, 2009 9:28
Antworten mit Zitat
Benutzer-Profile anzeigen
Ja, na klar aber mal ehrlich, wenn ich da etwas lade, dann wird das doch sowieso alles in Globale Variablen abgelegt. Da muss der GC nix machen. Sowie Berechnungen, Eigentlich laden wir doch rechenintensive Sachen aus, um sie nebenbei machen lassen zu können. Wo muss da groß aufgeräumt werden?

ein Größeres Problem sind die not Threading modulle. z.B. MiniB3d, versucht mal ein Mesh in Threads zu bearbeiten und wenn dann Renderworld kommt, kracht alles weg.
between angels and insects

BtbN

BeitragFr, Okt 30, 2009 15:41
Antworten mit Zitat
Benutzer-Profile anzeigen
Es geht ja nicht nur um primitives verteiltes laden(Was mit Images eh nicht geht, da die im Render-Thread geladen werden müssen), sondern um verteiltes Rechnen mit synchronistation zwischen den Threads.
Und hier kackt BMax total ab.

BladeRunner

Moderator

BeitragFr, Okt 30, 2009 15:43
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich laufe zwar Gefahr mich zu wiederholen, aber ich habe IMAGES in einem gesonderten Thread geladen und das lief ohne Probleme.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

Suco-X

Betreff: ......

BeitragFr, Okt 30, 2009 23:48
Antworten mit Zitat
Benutzer-Profile anzeigen
Mich können bloße Behauptungen auch nicht wirklich überzeugen, vielleicht könnte man das ganze mit ein paar Beispielen untermalen.

Mfg Suco
Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

BtbN

BeitragSa, Okt 31, 2009 3:41
Antworten mit Zitat
Benutzer-Profile anzeigen
Beispiel dafür, dass es auch sehr gut laufen kann:

BlitzMax: [AUSKLAPPEN]
SuperStrict

Framework BtbN.MinimalSDL
Import BRL.Math
Import BRL.Threads

?Not Threaded
Throw "This needs Threaded build!"
?Threaded

SDL_Init(800, 600, 32, "Mandelbrot")

Global threadCount:Int = 8

Global valsLock:TMutex = TMutex.Create()
Global scrW:Int = SDL_ScreenWidth, scrH:Int = SDL_ScreenHeight
Global xMin:Double = 0.0, xMax:Double = 1.0
Global yMin:Double = 0.0, yMax:Double = 1.0
Global iter:Int = 1000
Global bg_r:Int = 0, bg_g:Int = 0, bg_b:Int = 0

Global pixelLock:TMutex = TMutex.Create()
Function PutPixelThread(x:Int, y:Int, r:Int, g:Int, b:Int)
pixelLock.Lock()
SDL_help_PutPixelFast(x, y, r, g, b)
pixelLock.Unlock()
EndFunction

Function DoZoom(x:Int, y:Int, w:Int, h:Int)
Local sw:Int = scrW
Local sh:Int = scrH

valsLock.Lock()

Local SpanX:Double = (xMax - xMin)/Double(sw)
Local SpanY:Double = (yMax - yMin)/Double(sh)
Local oxMin:Double = xMin
Local oyMin:Double = yMin

xMin = xMin + (x - w/2) * SpanX
xMax = oxMin + (x + w/2) * SpanX
yMin = yMin + (y - h/2) * SpanY
yMax = oyMin + (y + h/2) * SpanY

valsLock.Unlock()
EndFunction

Function ThreadFunc_CalcMandelbrot:Object(inp:Object)
Local arr:Int[] = Int[](inp) ' [xFrom, xTo, yFrom, yTo, n]
If Not arr Then Throw "Error, data was not Int-Array!"

WriteStdout("Thread "+arr[4]+" starts~n")

For Local x:Int = arr[0] To arr[1]
For Local y:Int = arr[2] To arr[3]
valsLock.Lock()
Local iter:Int = .iter
Local c_x:Double = xMin + ((xMax-xMin) * (Double(x+1)/Double(scrW)))
Local c_y:Double = yMin + ((yMax-yMin) * (Double(y+1)/Double(scrH))) - 1.0
valsLock.Unlock()


Local cnt:Int = 0
Local z_x:Double = c_x
Local z_y:Double = c_y
For Local i:Int = 0 Until iter
Local xv:Double = (z_x * z_x - z_y * z_y) + c_x
Local yv:Double = (z_y * z_x + z_x * z_y) + c_y

If (xv * xv + yv * yv) > 4.0 Then Exit
z_x = xv
z_y = yv

cnt :+ 1
Next

If cnt = iter Then
PutPixelThread(x, y, bg_r, bg_g, bg_b)
Else
PutPixelThread(x, y,..
Byte( ((Sin(cnt+cnt)+1.0)/2.0)*255 ),..
Byte( ((Cos(cnt+cnt)+1.0)/2.0)*255 ),..
Byte( ((Cos(cnt+cnt)+1.0)/2.0)*255 )..
)
EndIf
Next
Next

WriteStdout("Thread "+arr[4]+" finished~n")

Return Null
EndFunction

Global threads:TThread[] = New TThread[threadCount]

Repeat
SDL_Cls()

For Local n:Int = 0 Until threadCount
Local arr:Int[] = New Int[5]
arr[0] = 0 ' FromX
arr[1] = SDL_ScreenWidth - 1 ' ToX
arr[2] = (SDL_ScreenHeight*n)/threadCount' FromY
arr[3] = (SDL_ScreenHeight*(n+1))/threadCount - 1' ToY
arr[4] = n
threads[n] = TThread.Create(ThreadFunc_CalcMandelbrot, arr)
Next

For Local n:Int = 0 Until threadCount
If threads[n].Running() Then threads[n].Wait()
Next

SDL_Flip()

If MouseHit(1) Then DoZoom(MouseX(), MouseY(), SDL_ScreenWidth, SDL_ScreenHeight)

If MouseHit(2) Then DoZoom(MouseX(), MouseY(), SDL_ScreenWidth/2, SDL_ScreenHeight/2)
If MouseHit(3) Then DoZoom(MouseX(), MouseY(), SDL_ScreenWidth/4, SDL_ScreenHeight/4)
Until AppTerminate() Or KeyHit(KEY_ESCAPE)

SDL_Quit()
End


Zum DL ner fertigen exe:
http://oromit.de/uploads/Mandelbrot-MT.exe
http://oromit.de/uploads/SDL.dll

Hauptproblem beim Threading ist, dass:
- Sobald in einem Thread irgendwie ein event ausgelöst wird, diese so behandelt wird, als würde es aus dem Mainthread kommen, was zwangläufig zu einem crash führt.
- Es nicht möglich ist, aus zwei threads auf den selben Grafik-Kontext zuzugreifen(Dafür kann BMax nichts)
- Der GC unheimlich lahm ist.

Suco-X

Betreff: .....

BeitragSa, Okt 31, 2009 3:54
Antworten mit Zitat
Benutzer-Profile anzeigen
Tjoa, dachte da eher an das vielgelobte Negativbeispiel!?
Und wenn wir schon dabei sind wären vergleiche zu anderen Sprachen die einen GC benutzen und MT unterstützen nicht verkehrt.
Also was ich im Prinzip haben will..Ein sinnvolles Beispiel für MT welches Blitzmax Defizite im Gegensatz zu anderen Sprachen hervorhebt.
Mfg Suco
Intel Core 2 Quad Q8300, 4× 2500 MHz, 4096 MB DDR2-Ram, GeForce 9600GT 512 MB

BtbN

BeitragSa, Okt 31, 2009 13:34
Antworten mit Zitat
Benutzer-Profile anzeigen
Hier mal ein Versuch meinerseits, events über zwei threads zu bewegen:
http://git.oromit.de/gitweb/gi...;hb=master

Im Ordner tests liegt auch ein Test, der ausser crashen und/oder einfrieren nichts kann. Die suche nach dem Fehler habe ich nach einigen Tagen aufgegeben.

Neue Antwort erstellen


Übersicht BlitzMax, BlitzMax NG Allgemein

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group