Don't forget too, that process creation is very expensive on windows, .Net sort of shortcuts this because it is deeply welded into windows.
On Mon, Mar 11, 2013 at 09:07:00AM +0000, Alan wrote: > 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
