Olaf - I've converted your mandelbrot app
in [VB.NET]
|
From: Mike Williams on 30 Sep 2009 16:39 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:euEnpegQKHA.4692(a)TK2MSFTNGP06.phx.gbl... > 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 Are you running that as a /native code/ compiled exe? > VB.NET: > MT: 1.203 sec > ST: 2.344 sec > 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. I ran it exactly as you suggested, and exactly as I explained in my first response. I ran the mandelbrot.exe file in the Bin / Release folder. I suppose it is possible that I have a different version of the net framework installed than you have (I just got fed up ignoring MS requests to download it and so I let them do so). And of course you may be running the VB6 code as something other than a native code compiled exe, or perhaps you are running a different version of Olaf's code than I've got here. It may also be somehting to do with the different screen resolution (I haven't tried others yet). I'm just reporting the results as they happen on my own machine. > I didn't see the exact task. But, I might be willing to > attempt it - IF I have time. Here is what I posted (in the following paragraph). I specifically said that both versions (VB.Net and VB6) should be run exactly as it would be delivered to a user (which in the case of VB6 code is as a native code [not P Code] compiled exe, preferably using the various advanced compiler speed optimizations). The VB.Net code can be optimized however you see fit. The challenge was to write some code to load a 1024 x 768 pixel full colour ..bmp file from disk (an image that would typically contain hundreds of thousands of different colours, as do most photos) and count the number of unique colours it actually contains. I've specified a full colour (24 bit) ..bmp because such image files always contain an accurately countable number of unique colours and so we can accurately compare our results if we use the same .bmp image. The code should work on all machines of course, regardless of the colour depth at which they are currently running. Your timer should count the total time to both load the .bmp file from disk and count the unique colours, just to ensure that extra unmetered time is not spent loading the bitmap in such a way as to make it easier for the timed portion of the code to deal with. For test purposes both the VB.Net version and the VB6 version should be run on the same machine. We'll take an average of the first ten calls to the routine, with the routine itself each time loading the .bmp from disk anew and counting the colours as would normally be the case when writing a general purpose function to which the user can pass the name of any desired .bmp file. Let's provide a Button that the user can click so that the function is run anew each time he clicks the button, with the time displayed for each run on the Form somewhere, and then you can just add up the times manually and take the average. The code should be run in the condition that it would normally be delivered to the user, which in the case of a VB6 program is a native code compiled exe (we'll leave out any special compiler speed options for the time being just to see how it works without them). You have said that you will take this on /if/ you have the time, and of course since you were not involved in the original exaggerated claim for VB.Net it is entirely up to you whether you do so or not. But if you do then let me know. Mike
From: Tom Shelton on 30 Sep 2009 17:19 On 2009-09-30, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message > news:euEnpegQKHA.4692(a)TK2MSFTNGP06.phx.gbl... > > >> 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 > > Are you running that as a /native code/ compiled exe? > Of course. I would never make a comparison any other way :) >> VB.NET: >> MT: 1.203 sec >> ST: 2.344 sec > >> 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. > > I ran it exactly as you suggested, and exactly as I explained in my first > response. I ran the mandelbrot.exe file in the Bin / Release folder. I > suppose it is possible that I have a different version of the net framework > installed than you have (I just got fed up ignoring MS requests to download > it and so I let them do so). And of course you may be running the VB6 code > as something other than a native code compiled exe, or perhaps you are > running a different version of Olaf's code than I've got here. It may also > be somehting to do with the different screen resolution (I haven't tried > others yet). I'm just reporting the results as they happen on my own > machine. > I am running the compiled exe. The code is the code olaf gave me himself. I think the problem mike is that you modified the code and ran it in debug mode without realizing it. for instance, if i run it in debug i get: MT: 9.453 ST: 12.188 For the same size. No, I think you messed up Mike. >> I didn't see the exact task. But, I might be willing to >> attempt it - IF I have time. > > Here is what I posted (in the following paragraph). I specifically said that > both versions (VB.Net and VB6) should be run exactly as it would be > delivered to a user (which in the case of VB6 code is as a native code [not > P Code] compiled exe, preferably using the various advanced compiler speed > optimizations). The VB.Net code can be optimized however you see fit. > > The challenge was to write some code to load a 1024 x 768 pixel full colour > .bmp file from disk (an image that would typically contain hundreds of > thousands of different colours, as do most photos) and count the number of > unique colours it actually contains. I've specified a full colour (24 bit) > .bmp because such image files always contain an accurately countable number > of unique colours and so we can accurately compare our results if we use the > same .bmp image. The code should work on all machines of course, regardless > of the colour depth at which they are currently running. Your timer should > count the total time to both load the .bmp file from disk and count the > unique colours, just to ensure that extra unmetered time is not spent > loading the bitmap in such a way as to make it easier for the timed portion > of the code to deal with. For test purposes both the VB.Net version and the > VB6 version should be run on the same machine. We'll take an average of the > first ten calls to the routine, with the routine itself each time loading > the .bmp from disk anew and counting the colours as would normally be the > case when writing a general purpose function to which the user can pass the > name of any desired .bmp file. Let's provide a Button that the user can > click so that the function is run anew each time he clicks the button, with > the time displayed for each run on the Form somewhere, and then you can just > add up the times manually and take the average. The code should be run in > the condition that it would normally be delivered to the user, which in the > case of a VB6 program is a native code compiled exe (we'll leave out any > special compiler speed options for the time being > just to see how it works without them). > > You have said that you will take this on /if/ you have the time, and of > course since you were not involved in the original exaggerated claim for > VB.Net it is entirely up to you whether you do so or not. But if you do then > let me know. Well... lol. i just did it a few minutes ago - but I did it in C#. I used the Creek.jpg from my Pictures/SamplePictures folder. Also, it is a console app. So here is the code: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Drawing; using System.Drawing.Imaging; namespace CountColors { class Program { static void Main ( string[] args ) { int iterations = 10; int totalTime = 0; for ( int i = 0; i < iterations; i++ ) totalTime += CountColors (); Console.WriteLine ( "Average Time: {0}", new TimeSpan ( 0, 0, 0, 0, totalTime / iterations ) ); } private static int CountColors () { Dictionary<int, int> colors = new Dictionary<int, int> (); int startTime = Environment.TickCount; using ( Bitmap bmp = new Bitmap ( "creek.jpg" ) ) { BitmapData bmd = bmp.LockBits ( new Rectangle ( 0, 0, bmp.Width, bmp.Height ), ImageLockMode.ReadOnly, bmp.PixelFormat ); unsafe { byte* ptr = (byte*)bmd.Scan0; int padding = bmd.Stride - ( bmp.Width * 3 ); for ( int y = 0; y < bmd.Height; y++ ) { for ( int x = 0; x < bmd.Width; x++ ) { int color = BitConverter.ToInt32 ( new byte[] { ptr[0], ptr[1], ptr[2], 0 }, 0 ); if ( !colors.ContainsKey ( color ) ) { colors.Add ( color, color ); } ptr += 3; } ptr += padding; } } bmp.UnlockBits ( bmd ); } int total = Environment.TickCount - startTime; Console.WriteLine ( "Counted {0} unique colors in {1}", colors.Keys.Count, new TimeSpan ( 0, 0, 0, 0, total) ); return total; } } } Output (run in release mode): Counted 131763 unique colors in 00:00:00.1560000 Counted 131763 unique colors in 00:00:00.1250000 Counted 131763 unique colors in 00:00:00.0940000 Counted 131763 unique colors in 00:00:00.1090000 Counted 131763 unique colors in 00:00:00.0940000 Counted 131763 unique colors in 00:00:00.1100000 Counted 131763 unique colors in 00:00:00.0930000 Counted 131763 unique colors in 00:00:00.1100000 Counted 131763 unique colors in 00:00:00.0930000 Counted 131763 unique colors in 00:00:00.1100000 Average Time: 00:00:00.1090000 Press any key to continue . . . -- Tom Shelton
From: Mike Williams on 1 Oct 2009 02:41 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:uM481OhQKHA.4692(a)TK2MSFTNGP06.phx.gbl... > I think the problem mike is that you modified the code and > ran it in debug mode without realizing it. for instance, if i > run it in debug i get: > MT: 9.453 > ST: 12.188 > For the same size. No, I think you messed up Mike. No, I didn't. In fact I've just downloaded your zip file again (to ensure that I have an unaltered copy). I know the object of the exercise was to test threading in VB6 (which seems to work fine) rather than to test speed of execution, but nevertheless the large difference between the execution speed of identical VB.Net exe files on our two machines is rather odd. When I downloaded a fresh copy of your zip file just now I dragged the Release folder straight out of the zip and onto the desktop and I ran your VB.Net mandelbrot.exe file by directly double clicking it (is that what I should be doing?) and I got essentially the same result as before (9.18 multi threaded in maximized window). Perhaps there is something about the framework or the VB.Net setup on my machine that is causing the VB.Net code to effectively be unable to run in anything other than the debug mode, or perhaps double clicking the mandelbrot.exe file in the Release folder is not what I am supposed to be doing? Mike
From: Mike Williams on 1 Oct 2009 02:53 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:uM481OhQKHA.4692(a)TK2MSFTNGP06.phx.gbl... > Well... lol. i just did it a few minutes ago - but I did > it in C#. I used the Creek.jpg from my Pictures/Sample > Pictures folder. Also, it is a console app. So here is > the code: Okay. C# code wasn't the challenge though, so let me know when you've done it in VB.Net using a standard 24 bit .bmp file as stated in my original post. Mike
From: Tom Shelton on 1 Oct 2009 09:33
On 2009-10-01, Mike Williams <Mike(a)WhiskyAndCoke.com> wrote: > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message > news:uM481OhQKHA.4692(a)TK2MSFTNGP06.phx.gbl... > >> I think the problem mike is that you modified the code and >> ran it in debug mode without realizing it. for instance, if i >> run it in debug i get: >> MT: 9.453 >> ST: 12.188 >> For the same size. No, I think you messed up Mike. > > No, I didn't. In fact I've just downloaded your zip file again (to ensure > that I have an unaltered copy). I know the object of the exercise was to > test threading in VB6 (which seems to work fine) rather than to test speed > of execution, but nevertheless the large difference between the execution > speed of identical VB.Net exe files on our two machines is rather odd. > > When I downloaded a fresh copy of your zip file just now I dragged the > Release folder straight out of the zip and onto the desktop and I ran your > VB.Net mandelbrot.exe file by directly double clicking it (is that what I > should be doing?) and I got essentially the same result as before (9.18 > multi threaded in maximized window). Perhaps there is something about the > framework or the VB.Net setup on my machine that is causing the VB.Net code > to effectively be unable to run in anything other than the debug mode, or > perhaps double clicking the mandelbrot.exe file in the Release folder is not > what I am supposed to be doing? Running the code unmodified, I would expect that time at that large of a resolution. I was talking about the speed difference with the changes to the code to delay drawing until the end of the rendering. You claim that with those changes - which you would have had to make to the source - that the vb6 version was still twice as fast. For that to be the case, I'm saying you must have compiled and ran that source in Debug mode from the ide to get that result... -- Tom Shelton |