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
