Olaf - I've converted your mandelbrot app
in [VB.NET]
|
From: Mike Williams on 30 Sep 2009 13:26 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:uakBB2eQKHA.5032(a)TK2MSFTNGP05.phx.gbl... > http://www.tom-shelton.net/Mandelbrot.zip > > Forgive the project name spelling :) I fat fingered Mandelbrot. > And, when you run it - make sure you run the release version... I ran your VB.Net mandelbrot program, making sure that it was the release version (which I assume is the mandelbrot.exe file in the Bin / Release folder). This is on my Vista Home Premium Q6600 Quad Core with 3GB RAM and an ATI Radeon 4850 512 MB GDDR3 graphics card and these are the results when run with the Form maximized on my normal 1152 x 720 pixel display setting: VB.Net Program: 10.6 seconds (single threaded) 9.4 seconds (multi threaded) On exactly the same machine and under exactly the same conditions I ran Olaf's VB6 code that performs an identical job, running it as a standard native code compiled VB6 exe. These are the results from Olaf's VB6 program: VB6 Program: 2.3 seconds (single thread) 1.4 seconds (multi thread) As you can see, on this machine Olaf's VB6 code runs about four or five times faster than the VB.Net code when single threaded and about six or seven times faster than the VB.Net code when multi threaded. Mike
From: Tom Shelton on 30 Sep 2009 14:12 On 2009-09-30, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message > news:uakBB2eQKHA.5032(a)TK2MSFTNGP05.phx.gbl... > >> http://www.tom-shelton.net/Mandelbrot.zip >> >> Forgive the project name spelling :) I fat fingered Mandelbrot. >> And, when you run it - make sure you run the release version... > > I ran your VB.Net mandelbrot program, making sure that it was the release > version (which I assume is the mandelbrot.exe file in the Bin / Release > folder). This is on my Vista Home Premium Q6600 Quad Core with 3GB RAM and > an ATI Radeon 4850 512 MB GDDR3 graphics card and these are the results when > run with the Form maximized on my normal 1152 x 720 pixel display setting: > > VB.Net Program: > 10.6 seconds (single threaded) > 9.4 seconds (multi threaded) > On my machine, it takes: > On exactly the same machine and under exactly the same conditions I ran > Olaf's VB6 code that performs an identical job, running it as a standard > native code compiled VB6 exe. These are the results from Olaf's VB6 program: > > VB6 Program: > 2.3 seconds (single thread) > 1.4 seconds (multi thread) > > As you can see, on this machine Olaf's VB6 code runs about four or five > times faster than the VB.Net code when single threaded and about six or > seven times faster than the VB.Net code when multi threaded. First, this particular exercise was not really about speed - but about threading models. As for the speed difference, that is only in the display. And that is a well known side effect of gdi+. Which the version I posted, is still using. You can prove that it is the drawing that is the bottle neck, simply by chaning the is method in the MandelbrotCalculator from: Protected Overridable Sub OnRowCompleted(ByVal e As RowCompletedEventArgs) If RowCompletedEvent IsNot Nothing AndAlso _syncObject IsNot Nothing Then _syncObject.Invoke(RowCompletedEvent, New Object() {Me, e}) End If End Sub To Protected Overridable Sub OnRowCompleted(ByVal e As RowCompletedEventArgs) If RowCompletedEvent IsNot Nothing AndAlso _syncObject IsNot Nothing Then _syncObject.BeginInvoke(RowCompletedEvent, New Object() {Me, e}) End If End Sub That will remove the the drawing time from the thread timing - simply because the threads will not be waiting for the row to actually draw before proceding. Another way is to simply not draw in the RowCompleted event and then put a call to uxCanvas.Invalidate() in the RenderComplete event. This makes the drawing only happen for the final product. In that case, full maximized on my box (1680x1050), total time for multithreaded is 1.282 seconds and 2.203 seconds for single threaded. The orignal - multithreaded 4.87 seconds, and 6.51 single threaded. I'm not making excuses - I'm just pointing out I know where the bottle neck is and it's not in the threading or the calculations of the mandelbrot set. It's in the drawing. GDI+ works fine for simple games etc - where you have a framerate of say 60 or 70 frames a second, but when you are trying to draw several hundred frames per second it falls down. I've tried using GDI calls - but, they actually don't speed things up much. This may have to do with Vista - or it could be that you have to go through gyrations to get a gdi compatible DC from a gdi+ DC for the functions to even work. I'm actually thinking of trying out managed dx for this - I'm pretty sure I can achieve the desired frame-rates that way :) It just might take me a few days to implement that because I'm rather busy, and I don't have much experience with it - only played a bit here and there. But, lets be realistic here - not many applications need to be able to draw several hundered frames a second efficiently. If you need it in .net there are alternatives of course, but, it's not needed often. -- Tom Shelton
From: Tom Shelton on 30 Sep 2009 14:16 On 2009-09-30, Tom Shelton <tom_shelton(a)comcastXXXXXXX.net> wrote: > On 2009-09-30, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: >> >> "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message >> news:uakBB2eQKHA.5032(a)TK2MSFTNGP05.phx.gbl... >> >>> http://www.tom-shelton.net/Mandelbrot.zip >>> >>> Forgive the project name spelling :) I fat fingered Mandelbrot. >>> And, when you run it - make sure you run the release version... >> >> I ran your VB.Net mandelbrot program, making sure that it was the release >> version (which I assume is the mandelbrot.exe file in the Bin / Release >> folder). This is on my Vista Home Premium Q6600 Quad Core with 3GB RAM and >> an ATI Radeon 4850 512 MB GDDR3 graphics card and these are the results when >> run with the Form maximized on my normal 1152 x 720 pixel display setting: >> >> VB.Net Program: >> 10.6 seconds (single threaded) >> 9.4 seconds (multi threaded) >> > > On my machine, it takes: > > >> On exactly the same machine and under exactly the same conditions I ran >> Olaf's VB6 code that performs an identical job, running it as a standard >> native code compiled VB6 exe. These are the results from Olaf's VB6 program: >> >> VB6 Program: >> 2.3 seconds (single thread) >> 1.4 seconds (multi thread) >> >> As you can see, on this machine Olaf's VB6 code runs about four or five >> times faster than the VB.Net code when single threaded and about six or >> seven times faster than the VB.Net code when multi threaded. > > First, this particular exercise was not really about speed - but about > threading models. > > As for the speed difference, that is only in the display. And that is a well > known side effect of gdi+. Which the version I posted, is still using. > > You can prove that it is the drawing that is the bottle neck, simply by > chaning the is method in the MandelbrotCalculator from: > > Protected Overridable Sub OnRowCompleted(ByVal e As RowCompletedEventArgs) > If RowCompletedEvent IsNot Nothing AndAlso _syncObject IsNot Nothing Then > _syncObject.Invoke(RowCompletedEvent, New Object() {Me, e}) > End If > End Sub > > To > > Protected Overridable Sub OnRowCompleted(ByVal e As RowCompletedEventArgs) > If RowCompletedEvent IsNot Nothing AndAlso _syncObject IsNot Nothing Then > _syncObject.BeginInvoke(RowCompletedEvent, New Object() {Me, e}) > End If > End Sub > > That will remove the the drawing time from the thread timing - simply because > the threads will not be waiting for the row to actually draw before proceding. > > Another way is to simply not draw in the RowCompleted event and then put a > call to uxCanvas.Invalidate() in the RenderComplete event. This makes the > drawing only happen for the final product. In that case, full maximized on my > box (1680x1050), total time for multithreaded is 1.282 seconds and 2.203 > seconds for single threaded. The orignal - multithreaded 4.87 seconds, and 6.51 single > threaded. > > I'm not making excuses - I'm just pointing out I know where the bottle neck is > and it's not in the threading or the calculations of the mandelbrot set. It's > in the drawing. GDI+ works fine for simple games etc - where you have a > framerate of say 60 or 70 frames a second, but when you are trying to draw > several hundred frames per second it falls down. > > I've tried using GDI calls - but, they actually don't speed things up much. > This may have to do with Vista - or it could be that you have to go through > gyrations to get a gdi compatible DC from a gdi+ DC for the functions to even > work. > > I'm actually thinking of trying out managed dx for this - I'm pretty sure I > can achieve the desired frame-rates that way :) It just might take me a few > days to implement that because I'm rather busy, and I don't have much > experience with it - only played a bit here and there. > > But, lets be realistic here - not many applications need to be able to draw > several hundered frames a second efficiently. If you need it in .net there are > alternatives of course, but, it's not needed often. > And further - I said it was way slower drawing in the original post... So, it's not as if I didn't know this already and was trying to pull a fast one or anything :) -- Tom Shelton
From: Mike Williams on 30 Sep 2009 15:13 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:OwJPEmfQKHA.508(a)TK2MSFTNGP06.phx.gbl... > And further - I said it was way slower drawing in the original > post... So, it's not as if I didn't know this already and was > trying to pull a fast one or anything :) I wasn't suggesting you were trying to do that. I was merely reporting the results of running it on my own machine. > You can prove that it is the drawing that is the bottle neck, > simply by chaning the is method in the MandelbrotCalculator > from . . . . <snip> I commented out the drawing code in your VB.Net program and the execution time did reduce, to about 2.9 seconds, showing that the VB.Net drawing code was definitely slowing it down. However, even with your own code performing the calculations but drawing nothing at all and with Olaf's VB6 code performing the calculations and actually drawing the stuff Olaf's VB6 code still ran about twice as fast as the VB.Net code, at least on my owm machine. I know you have said that it is not about speed, and I appreciate that, but there are lots of people in these groups who appear to think that VB.Net runs ten times faster than VB6 (a quote by Cor Ligthert) whereas in real tests that does not appear to be the case. In this particular test Olaf's VB6 code runs about seven times faster than your equivalent VB.Net code when both of them are calculating and drawing, and the VB6 code still runs twice as fast as the VB.Net code even when you remove the drawing code from VB.Net. I'm not attempting to score any points here, you understand, I'm just reporting the results of running both the VB6 code and the VB.Net code on my own Quad Core machine. I'd be interested to see Cor Ligthert's (or Alex Clark's) VB.Net code for the little challenge that was set in a recent thread (counting the number of unique colours in a standard full colour .bmp file), especially since Cor Ligthert was the person who said that VB.Net is ten times faster than VB6 and Alex Clark did not specifically contradict him, but neither of them seem to have come up with anything yet. That task does not require any graphics to be drawn, so the apparent slowness of VB.Net at 2D graphics should not be a problem for VB.Net coders when writing code to peform the counting task. Mike
From: Tom Shelton on 30 Sep 2009 15:53
On 2009-09-30, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message > news:OwJPEmfQKHA.508(a)TK2MSFTNGP06.phx.gbl... > >> And further - I said it was way slower drawing in the original >> post... So, it's not as if I didn't know this already and was >> trying to pull a fast one or anything :) > > I wasn't suggesting you were trying to do that. I was merely reporting the > results of running it on my own machine. > >> You can prove that it is the drawing that is the bottle neck, >> simply by chaning the is method in the MandelbrotCalculator >> from . . . . <snip> > > I commented out the drawing code in your VB.Net program and the execution > time did reduce, to about 2.9 seconds, showing that the VB.Net drawing code > was definitely slowing it down. However, even with your own code performing > the calculations but drawing nothing at all and with Olaf's VB6 code > performing the calculations and actually drawing the stuff Olaf's VB6 code > still ran about twice as fast as the VB.Net code, at least on my owm > machine. > That is not the results I'm getting at all... I'm not sure what your doing here. but on my machine - maximized at 1680x1050 with the drawing code removed from the rowcomplete in the vb.net code... VB6: MT: 5.30 sec ST: 6.55 sec VB.NET: MT: 1.203 sec ST: 2.344 sec Vista Ultimate 32-bit, Core 2 Duo e6600, 4GB of ram (obviously not all used by Vista - but I tripple boot the machine with linux and windows 7, both 64-bit).... There is no way, that his was twice as fast with drawing code enabled. > I know you have said that it is not about speed, and I appreciate that, but > there are lots of people in these groups who appear to think that VB.Net > runs ten times faster than VB6 (a quote by Cor Ligthert) whereas in real > tests that does not appear to be the case. Cor exagerates the speed thing, there is no doubt. But, I think you tend that direction as well. Your statement above, just doesn't jive - unless you compiled and ran in debug mode. In the real world, there appears to be almost no difference for most tasks. > In this particular test Olaf's > VB6 code runs about seven times faster than your equivalent VB.Net code when > both of them are calculating and drawing Yep. The drawing is slow. I already said that. > , and the VB6 code still runs twice > as fast as the VB.Net code even when you remove the drawing code from > VB.Net. > I suspect, Mike, that if your statement is accurate - you are running it in Debug mode. Since that is the only way I can get those kinds of results - which is why I said to run it in Release mode. > I'm not attempting to score any points here, you understand, I'm just > reporting the results of running both the VB6 code and the VB.Net code on my > own Quad Core machine. I'd be interested to see Cor Ligthert's (or Alex > Clark's) VB.Net code for the little challenge that was set in a recent > thread (counting the number of unique colours in a standard full colour .bmp > file), especially since Cor Ligthert was the person who said that VB.Net is > ten times faster than VB6 and Alex Clark did not specifically contradict > him, but neither of them seem to have come up with anything yet. That task > does not require any graphics to be drawn, so the apparent slowness of > VB.Net at 2D graphics should not be a problem for VB.Net coders when writing > code to peform the counting task. I didn't see the exact task. But, I might be willing to attempt it - IF I have time. -- Tom Shelton |