Olaf - I've converted your mandelbrot app
in [VB.NET]
|
From: Schmidt on 3 Oct 2009 09:30 "Mike Williams" <Mike(a)WhiskyAndCoke.com> schrieb im Newsbeitrag news:eeSHPZCRKHA.488(a)TK2MSFTNGP05.phx.gbl... > Your calculations seems to be spot on there, ... > VB6: > MT: 1.32 sec > ST: 2.66 sec Well, it's hardware <g> ... Somewhat more predictable that. > The only reason I can think of why Tom Shelton's dual core is > not scaling linearly between running single or multi thread is > perhaps when running your code he has some background > task running which is using a fair amount of processor time? Now, what could that be then... ;-) No (bad joke), ...seriously - the only other reason I can think of is - (assuming Tom was testing the new compile with the timer- decoupled GDI-drawingcode and *not* commented that out) - that Toms machine is doing exceptionally bad with regards to any final rendering to the screen (GDI also affected a bit, not only GDI+) - the about 60 Refreshs per second are far less than the former ones (which were done on each incoming line), but if the MT-code runs about 1.8 seconds on Toms machine, then there are however about 110 Screen-Refresh "on todo" which definitely make some percentage in the calculation. But how many percentpoints, depends on the graphics- subsystem, if that can render hardware-based (usually the case) - or not. Another reason could be that Tom is running the VB6- version in a VM (though on the same hardware) - not likely - just to be sure...? Maybe Karl - or someone else could take an additional run again with the new MBSet.zip, to verify our both results on hardware with a "normally" working graphics-subsystem (at least, that the new version should scale with nearly factor 2 between single- and multithreaded, even with activated GDI-Refreshs). Olaf
From: Mike Williams on 3 Oct 2009 10:12 "Schmidt" <sss(a)online.de> wrote in message news:%23A2QY6CRKHA.220(a)TK2MSFTNGP02.phx.gbl... > But how many percentpoints, depends on the graphics- > subsystem, if that can render hardware-based (usually > the case) - or not. I think that Tom is running Vista, which means that he almost certainly won't be getting any GDI hardware acceleration. Mike
From: DanS on 3 Oct 2009 10:28 "Schmidt" <sss(a)online.de> wrote in news:#A2QY6CRKHA.220 @TK2MSFTNGP02.phx.gbl: > Maybe Karl - or someone else could take an additional > run again with the new MBSet.zip, to verify our both results > on hardware with a "normally" working graphics-subsystem > (at least, that the new version should scale with nearly > factor 2 between single- and multithreaded, even with > activated GDI-Refreshs). > > Olaf I don't understand the point to this entire excercise. Not true, I understand the original point, to rewrite your app in VB.Net to try to prove that the newer version is faster. But since your version draws the fractal, the .Net version needs to do the same. Disabling drawing adds another variable to the test, and therefore nullifies anything the test may or may not have proven/disproven. On this machine.....Athlon64 x2 running @ 3ghz w/3 gigs RAM, nVidia GeForce 8xxx w/512Megs RAM, maximized to 1400x1050....using the original zip Tom Shelton posted a link to, and, what I'm assuming is your version with whatever mod you just did........ VB6 MT = 1.40 - 1.45 seconds ST = 2.75 - 2.80 seconds ..Net MT = 35.312 seconds ST = 36.578 seconds ..Net frameworks installed here seem to be..... 1.0.x 1.1.x 2.0.x 3.0 3.5 (Identified via these instructions: http://msdn.microsoft.com/en- us/kb/kb00318785.aspx) So who knows why. I can provide streaming video of this test if anyone doesn't believe...... The point is, if GDI is way faster than GDI+, or whatever the argument is, and that is what is slowing the .Net version down, then the conclusion of *this test*, is that, in this case, VB.Net is not faster than VBc. It doesn't really matter if the underlying calculations run faster or not, the program as a whole does not, regardless of whether or not it's only because of GDI+. I'd like to see a compiled version of the .Net code since it's been optimized from the original linked .zip and see what differences it makes. From what I recall is that the only other code posted was c# code.
From: Tom Shelton on 3 Oct 2009 11:41 On 2009-10-03, DanS <t.h.i.s.n.t.h.a.t(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote: > "Schmidt" <sss(a)online.de> wrote in news:#A2QY6CRKHA.220 > @TK2MSFTNGP02.phx.gbl: > >> Maybe Karl - or someone else could take an additional >> run again with the new MBSet.zip, to verify our both results >> on hardware with a "normally" working graphics-subsystem >> (at least, that the new version should scale with nearly >> factor 2 between single- and multithreaded, even with >> activated GDI-Refreshs). >> >> Olaf > > I don't understand the point to this entire excercise. > > Not true, I understand the original point, to rewrite your app in VB.Net > to try to prove that the newer version is faster. > No. This was not about speed originally. It was about threading models. Others became intersted in speed. So the point of the disabled drawing was to show that the actual calculations were running at approximately the same speed. And that the bottleneck was in the drawing portion. > But since your version draws the fractal, the .Net version needs to do > the same. Disabling drawing adds another variable to the test, and > therefore nullifies anything the test may or may not have > proven/disproven. > It was simply to show where the bottleneck was. That's all. > On this machine.....Athlon64 x2 running @ 3ghz w/3 gigs RAM, nVidia > GeForce 8xxx w/512Megs RAM, maximized to 1400x1050....using the original > zip Tom Shelton posted a link to, and, what I'm assuming is your version > with whatever mod you just did........ > > VB6 > > MT = 1.40 - 1.45 seconds > ST = 2.75 - 2.80 seconds > > .Net > > MT = 35.312 seconds > ST = 36.578 seconds > > .Net frameworks installed here seem to be..... > > 1.0.x > 1.1.x > 2.0.x > 3.0 > 3.5 > > (Identified via these instructions: http://msdn.microsoft.com/en- > us/kb/kb00318785.aspx) > > So who knows why. I can provide streaming video of this test if anyone > doesn't believe...... > > The point is, if GDI is way faster than GDI+, or whatever the argument > is, and that is what is slowing the .Net version down, then the > conclusion of *this test*, is that, in this case, VB.Net is not faster > than VBc. > Yes - the drawing is slower. But again, this wasn't originally about speed at all - I could have told you before I started that GDI+ would not be able to draw as fast... If I had cared about speed I would have maybe abandoned the built in gdi+ drawing and done something else - but, I don't really care to make anyone install managed dx or something for a threading example. In other words, the point was the threading CODE - not the drawing. > It doesn't really matter if the underlying calculations run faster or > not, the program as a whole does not, regardless of whether or not it's > only because of GDI+. > > I'd like to see a compiled version of the .Net code since it's been > optimized from the original linked .zip and see what differences it > makes. From what I recall is that the only other code posted was c# code. The only changes have been described in detail. And that is simply to comment out the drawing code (the using g as grapics block) in the rowcompleted event and add a uxCanvas.Invalidate call in the RenderComplete event. Basically delaying the drawing until the calculations have completed. -- Tom Shelton
From: Tom Shelton on 3 Oct 2009 11:48
On 2009-10-03, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > "Schmidt" <sss(a)online.de> wrote in message > news:e4zZaR$QKHA.1372(a)TK2MSFTNGP02.phx.gbl... > >> [Addressed to Tom Shelton] Looks not right (yet) to >> me (your MT-result). With entirely disabled GDI- >> refreshs, the timing should scale nearly lineary with two >> threads (on a DualCore).Y our 2.77 seconds for the >> singlethreaded run look more plausible anyways... >> But on my machine the two-threaded timing scales >> down to nearly exactly the half of the singlethreaded >> timing - would mean - you should get about: >> ST: 2.77 / 2 = MT: 1.39 seconds on your 2.4 GHz-Dualcore. > > Your calculations seems to be spot on there, Olaf. I'm using a 2.4 Ghz > processor (the same 2.4 GHz Intel 6600 that I believe Tom Shelton uses, > except mine is a quad core whereas his is a dual core) and when running > maximized at the same 1680 x 1050 resolution that I believe Tom uses your > VB6 code gives me: > > VB6: > MT: 1.32 sec > ST: 2.66 sec > > The only reason I can think of why Tom Shelton's dual core is not scaling > linearly between running single or multi thread is perhaps when running your > code he has some background task running which is using a fair amount of > processor time? > > Mike > > Nope. And I never showed st mode in the new version of olaf's code - so here (3 runs of each) MT: 1.78 1.85 1.84 ST: 3.19 3.25 3.10 -- Tom Shelton |