Alan, So, I did try your suggestion and replaced List<int> with int[]. It did improve the performance of the code, but as I suspected, it also improved the performance in .NET, so the relative performance difference between the two CLIs is still 80-90%:
Windows .NET = 0.479 sec Mono 3.0.6 with -O=unsafe option = 0.882 sec -- Imre -----Original Message----- From: Olajos, Imre Sent: Monday, March 11, 2013 9:19 AM To: [email protected] Subject: RE: [Mono-list] Poor Mono performance Alan, This is NOT just a benchmark - my actual code looks similar to this, except it does a lot more things inside the body of the do-while loop. > If you change it from a List<T> to a T[], the time taken to execute the test > is about half. I'm sure that's true (and I will try that), but what I'm more curious about is why the big difference in the RELATIVE performance between .NET and Mono? If I change my code to speed it up in Mono, I'm sure that'll speed it up just as much in .NET, too - so, the relative performance of the code will remain more or less the same between the two CLIs. Is there anything I can do that would bring their relative performance difference closer to each other (e.g. below 20-25%)? By the way: > The majority of the time in this benchmark is spent doing array bounds > checking. I got the same poor performance from Mono with the -O=unsafe option, which I thought turns off array bounds checking, too. -- Imre -----Original Message----- From: Alan [mailto:[email protected]] Sent: Monday, March 11, 2013 2:07 AM To: Ian Norton Cc: edward.harvey.mono; [email protected]; Olajos, Imre Subject: Re: [Mono-list] Poor Mono performance The majority of the time in this benchmark is spent doing array bounds checking. If you change it from a List<T> to a T[], the time taken to execute the test is about half. This is true on both frameworks. These kinds of micro benchmarks never give an accurate picture of real world performance, unless your application actually only iterates List<T> and sums numbers. Mono also has different performance characteristics on Windows, Linux and MacOS, even for testcases as simple as this. Alan On 11 March 2013 08:30, Ian Norton <[email protected]> wrote: > On Sun, Mar 10, 2013 at 02:19:55PM +0000, edward.harvey.mono wrote: >> > From: [email protected] [mailto:mono-list- >> > [email protected]] On Behalf Of imreolajos >> > >> > Hi all! >> > >> > SpeedTest.cs >> > <http://mono.1490590.n4.nabble.com/file/n4658877/SpeedTest.cs> >> >> Did you read that code? All it does is a bunch of adds and multiplies. If >> that were *seriously* representing your workload, you would use C or >> assembly. The reason you code in .Net or mono is for the sake of high level >> classes and stuff that make development faster than coding C++. As long as >> performance is good enough, you call it and end product. If you need to >> tweak performance more, you need to dig lower level into C/C++/asm. >> >> There are lots of times when, as a programmer, you have to accept some >> performance sub-optimization with .Net or mono, just because the >> pre-packaged class or whatever you're building on top of doesn't do >> *exactly* what you want it to do. That's the price you pay for using a >> fully managed, high level, rapid development programming language and >> framework. For example, if you want a Queue that guarantees uniqueness... >> The standard queue doesn't guarantee uniqueness and the standard Hashset >> doesn't guarantee order. So you'd have to go find something else, or use a >> combination of Queue & Hashset, which is a sub-optimization caused by the >> fact that the data structure available to you isn't precisely what you want. >> >> In any event - the comparison of performance between .Net and mono is a >> valid thing to care about, if you have a valid test. Here's what you should >> focus on, if you care: >> >> The .Net framework and mono class library is a *huge* set of stuff. >> Microsoft has separate teams of developers for each category of stuff, and >> mono pulls in code from hundreds or thousands of independent sources. Guess >> what that means? Sometimes .Net will be faster, and sometimes mono will be >> faster. It depends on the specific class and version and OS (and even cpu) >> that you're running on. It depends specifically what you're doing. >> >> I don't have specifics, but here's a hypothetical: You might find that .Net >> 3.5 System.Drawing.Drawing2D.Blend running on windows 7 with an Intel 64bit >> processor might perform half as well as with the AMD 64bit processor, and >> mono 2.4 in centos might be 3x slower, but when you switch to mono 2.10 in >> fedora, it might be 2x faster than the fastest .Net, and when you try .Net 4 >> or 4.5, they might have optimized it ... You might find that one of these >> things has a slower startup and a faster runtime ... Thus making it better >> for certain types of Blend operations, while being worse for other datasets. >> >> I know this one in particular: General consensus on the Internet is that >> System.Security.Cryptography.AESManaged has a faster startup time and slower >> runtime than System.Security.AESCryptoServiceProvider. Even though they >> both do the same thing, they're each optimized differently. And guess what, >> from one version of .Net to another version... From one version of mono to >> another ... AESManaged performance will vary. And the performance depends >> on whether or not you have AES-NI instruction in your CPU (that produces >> approx 10x performance difference) and it depends on which version of .Net >> first included support for the AES-NI, and it depends which version of mono >> first included support for AES-NI. >> >> If you want to do a performance comparison, you need to find a job that you >> actually care about, and hardware that you actually care about, and test on >> that. You cannot make any generalization and expect it to have any >> validity, unless you *extremely* thoroughly benchmark all the different >> variables ... Change the CPU's, the OS's, 32bit and 64bit, with and without >> specialized hardware instruction sets, with and without certain Service >> Packs and KB patches applied ... Run on windows, mac, linux, ... Nobody does >> this much performance evaluation. You cannot make a generalization. > > Try doing greatest common divisor, mono tends to actually be faster than c! > > Ian > >> _______________________________________________ >> Mono-list maillist - [email protected] >> http://lists.ximian.com/mailman/listinfo/mono-list > _______________________________________________ > Mono-list maillist - [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
