Edward, he's not comparing managed vs. unmanaged, but .NET vs Mono.
On 10/03/13 14:19, 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.
_______________________________________________
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
