It can be realistic that FP code which is not vectorized or that has other constraints (bounds checking, defined precision, etc) runs slower than the similar code compiled by a modern C/C++ compiler. I guess a 1-1.5 slowdown would be in the correct ballpark. But this is a different issue than the 2000 cycles issues you posted about: anyone can show with poorly written code than anything is slow.
The current release of the CLI is released under a license which is theoretically GPL-compatible.
Why don't you stop embarassing yourself? What you wrote is completely false. No wonder you don't understand anything about licensing and you don't understand why we don't want the MS-encumbered code to make its way into mono.
You're apparently doing the opposite of what any performance-conscious person would do: having the performance-critical code be managed and the driver code be unmanaged, no wonder you got slow results.
That's why people suggested the use of p/invoke, which in your case would have the loop in C#/managed code and the computePerlinNoise3D() function implemented in C/C++/asm in a shared library.
I'm not too familiar with the Mono project, but I'd bet that the SSCLI was probably a key tool for its (at least initial) implementation.
You lost your bet and it would be good in the future if you didn't bet an things you don't have any clue about. Mono existed and was functional long before rotor was released. Moreover, the mono project rejects contributions from people that looked at the rotor code.
If you use managed C++ for time critical code you're already doing something wrong. Using C++ and p/invoke would be an ok option and it would work just fine in mono, too. The numbers you quote are completely unrealistic, at least as far as the mono JIT is concerned (and I'd guess the MS runtime would be as fast as us, but I haven't checked). What is the function you're calling in C++ from managed code? As an example the following C function:
void nullf (double *array, int pos, int count) {}
takes 50 cycles of overhead when called from C# code on Mono on my 1.6 GHz Pentium M. Newer processors should take a little less, but that is the ballpark. So if you see a 2000 cycles overhead instead of 50 you're likely doing something wrong or you just invented the number (or you should be using mono:-).
Mono is being ported to run on mips and several basic programs work on it. You can help us complete the port so you'll have a chance of running silverlight on your system in the future:)
You're completely wrong. MS never open sourced the CLR (the CLR is their implementation of the spec, called CLI). MS released with a non-open-source license rotor, which was a crippled implementation of the spec (it is completely outdated and was useless even when they released it). And Mono is not based on it in any way: we even reject contributors that looked at the rotor source code.
You're missing the libgdiplus library: install it or compile it (take it from the same place you downloaded the rest of mono). Check the mcs -out option to give the binary the name you want. You can also just rename the file after compiling, you know. You'll still need the change to the source. The two broken lines will need to look like this:
It compiles just fine with: mcs -unsafe -resource:Rasterbator.MainForm.resources -r:System.Windows.Forms -r:System.Drawing -r:../itextsharp.dll *.cs copy the resulting.exe to the parent dir, because it expects to find the files and directories there when you run it.
It has a couple of bugs related to the directory separator: basically the programmer added code to make sure his program didn't run on Linux:-). See how ApplicationDirectory is created in MainForm.cs. There is also a similar bug when saving the final file. The app seems to work just fine after that change, kudos to the System.Windows.Forms team! This is with mono 1.1.13ish.
For embedded designs - Mono runs on ARM with MIPS soon to come, which makes Mono really the only choice for embedded platforms.
Well the compact framework runs on those processors too as does Portable.NET/DOTGNU.
I won't comment on MIPS, because mono has not been ported to it yet, but on ARM Mono is the most advanced.net-like environment. The compact framework has several restrictions in its implementation and in its base assemblies. Portable.NET has even more restrictions because it's missing tons of features both in the VM and in the base assemblies. Mono on ARM provides the full framework, Reflection.Emit, Remoting, P/Invoke, Gtk# etc: none of the other.net runtimes provide an extended feature set as Mono.
The ppc mono port has not been optimized as well as the mainstream x86 port, The pystones numbers are about 20% lower using IronPityhon on ppc vs CPython. Part of the issue is that the ppc systems I use still don't support the __thread C keyword which allows a faster runtime and GC implementation so my systems will benchmark a little slower. We expect to improve the port speed though, of course.
Most languages can do delegates. Sure, but your question was: "Tell me what.NET can do that similar VM'ed languages can't." Now the VM that comes closer to mono is the JVM. Java and JVM don't have delegates. There aren't other virtual machines currently that have comparable features.
Tail calls are optimizer tricks, not language specs. First, we were talking about VMs, but anyway this shows you don't have a good idea of the implications of tail calls. Sure JVM jits can perform the optimization, but they may not. Languages like scheme and lisp requires tail calls to be present and working or they blow up the stack. Mono implements the ECMA specified tail call instruction, so those languages can be implemented efficiently on top of the VM.
Value types Java doesn't have and it is a nice feature if you're not using objects to keep data. Value types also allow a more efficient implementation of many data structures and algorithms.
Interop with shared libraries sound like platform dependance, or is it more like the way Java can load it's classes dynamically? It's the feature called P/Invoke: seamlessly calling functions in external shared libraries implemented in C for example. Java has JNI, but the features are not directly comparable, P/Invoke is much easier to use.
Interop with different languages is a VM feature, you're surely well aware that the Java VM has a wealth of other languages available too? Sure, but there is no standard way for interoperation. And, anyway, it's hard to interoperate from languages like java that don't have unisgned integers, for example..NET has no platform independant GUI system yet. Gtk# works on Linux, windows, OSX. We're working on System.Windows.Forms, too, so that's going to be another option (we plan to have support for SWF in mono 1.2, some apps work already).
nor does it perform better than other VM-based languages. First thing: speed is not everything: mono gives you many more benefits, like arch-indep programs, integration between several languages, GC etc. That said, while we're obviously looking at improving mono's speed, we already do well enough for many tasks. If you look at the language shootout you'll see that mono is faster than the JVM in a few benchmarks (note also that they use the 1.0.5 version of mono which is very old and slower than the current release). We run some of the python benchmarks faster than CPython itself. So, we already perform better in some cases than a runtime that has been tuned and developed for 10 years and we're rapidly improving. We won't beat the JVM at every ebnchmark any time soon, but that is not an expectation that any reasonable person has. The expectation is to be fast enough for the job that needs to be done and mono fullfills that for many cases. In the other cases we'll improve, just file bugs reports for them:-)
Java is a better platform independant language since it's actually quite platform independant (in contrast to.NET). Mono runs on x86, ppc, amd64, sparc, s390 on Linux, Solaris, Windows, OSX. That pretty much covers 98% of the market for servers and personal computers. We're porting to more architectures, too. Java has been ported to more archs because it has been around for so much more time, but in practice Mono is just as platforms independent (even much more so since Sun, for example, will actually support fewer archs than Mono). Tell me what.NET can do that similar VM'ed languages can't, then see what those languages can do that.NET can't. I may be wrong ofcourse, but I just don't see why I would ever want to use.NET You're certainly wrong, mostly because you are uninformed. I suggest you study the specs (grep for delegates, tail calls, value types, interop with shared libraries, interop between different languages etc).
UNIX was nice 30 years ago. It's still nice. Agreed. Many of the unix concepts are perfectly fine today. This doesn't mean that Tk is still nice.
Tk's API is one of the better attempts at the same simplification to GUI APIs that the UNIX shell and pipe/filter model was for CLI APIs. It's not nearly as successful, but it sure seems like a better approach than just about anything else I've used. Tk was good for small apps, but the design it was built upon made it irrelevant, since it is so tied to Tcl and Tcl is unusable in many settings. Having to maintain forks for perl etc just show how much its design was wrong. After so many years that tk has been deployed, there isn't a single Tk app I'd want to use. Less than a year after mono 1.0 was released, beagle, muine, monodevelop, ikvm and other mono apps are in the top of the list of apps people want (see gnomefiles). As mono matures the number of apps will accelerate.
And Mono looks to become the next great evil dependency salad. I can't wait. Your drivel is showing. Please reply if you have technical issues to bring up, your uninformed rants are useless.
One of the differences between this and other GPL software is that, in this case, these issues will come up. I'm sure glad you can see the future, but frankly your divinations don't have much weight. Any piece of free software is under the threat of patents until the patent process is reworked to favour innovation instead of favouring monopolistic and patent-portfolio companies that don't do any innovation. The only difference between an open source project that will be sued and one that won't is that the projects that are irrelevant won't get sued. So it's very easy to avoid the patents issues: write software that few people will use and that doesn't generate sufficient economic changes. BTW: this works also for proprietary sw: the difference there is that the amount of revenue involved before a suit is much less, since in the case of free sw the negative publicity of suing a project is very big: see why the linux kernel was involved by the SCO idiots only so late and how they paid with self-destruction what they did.
There are quite a lot of very nice development platforms on free software systems, from integrated environments like Squeak to libraries that can be linked with many languages, like Tk. Tk was nice 8 years ago. Besides you can reuse Tk either by embedding the tcl interpreter or by changing the Tk code and plug a different language. Not exactly a good example of nice sw reuse.
at some cost in security since it's not as well adapted to sandboxing Mono is currently implementing the security sandboxing: if you ask security experts they'll tell you the security features in the CLI are well thought out.
Other than that last point, there are so many excellent alternatives already in use that I can't see any anything but Microsoft compatibility as being the "killer app" for Mono. Wait and see until the new apps based on C# and mono become mainstream in linux distributions: beagle, f-spot, muine, monodevelop.
But you are comparing apples and oranges. since glibc is much bigger than mscorlib.dll really. libc + libm is about 1780 KB of native code. mscorlib.dll is 600KB of IL code and compiles to about 1300 kb of native code. Even if corlib was twice as big, the jit is (and neeeds to be) a few orders of magnitude faster. And of course the jit needs to assemble and link the code or it wouldn't work. Oh by the way glibc is not part of GCC at all. I never said that anywhere: why do you bring up irrelevant issues?
And with so many projects in need of help (gjc/ parrot(perl6)/gnustep) do we need more? Considering that mono is pretty much in a more advanced state than any of those projects you should ask yourself why... The reality is that free software developers work on what the enjoy best: if you want some project to succeed, work on it, don't demand other people to do it.
When we started mono llvm was very immature and it still wouldn't be able to be used as a jit for the CLR since it misses many features. The mono jit has also been ported to more architectures than llvm. We're looking at adding more optimizations to the jit, but keep in mind that a jit has different contraints than gcc when compiling code. As an example, compiling from C# code to native code the base library of mono (mscorlib.dll) takes 20 seconds. Compiling the equivalent library with gcc (libc) which has roughtly the same size takes tens of minutes on the same box.
If the speed difference is so big, please file a bug report at bugzilla.ximian.com with your test case so we can check the generated code. You also may want to use the -O=inline option.
Slashdot Mirror
It can be realistic that FP code which is not vectorized or that has other constraints (bounds checking, defined precision, etc) runs slower than the similar code compiled by a modern C/C++ compiler. I guess a 1-1.5 slowdown would be in the correct ballpark.
But this is a different issue than the 2000 cycles issues you posted about: anyone can show with poorly written code than anything is slow.
The current release of the CLI is released under a license which is theoretically GPL-compatible.
Why don't you stop embarassing yourself? What you wrote is completely false.
No wonder you don't understand anything about licensing and you don't understand why we don't want the MS-encumbered code to make its way into mono.
You're apparently doing the opposite of what any performance-conscious person would do: having the performance-critical code be managed and the driver code be unmanaged, no wonder you got slow results.
That's why people suggested the use of p/invoke, which in your case would have the loop in C#/managed code and the computePerlinNoise3D() function implemented in C/C++/asm in a shared library.
I'm not too familiar with the Mono project, but I'd bet that the SSCLI was probably a key tool for its (at least initial) implementation.
You lost your bet and it would be good in the future if you didn't bet an things you don't have any clue about.
Mono existed and was functional long before rotor was released. Moreover, the mono project rejects contributions from people that looked at the rotor code.
If you use managed C++ for time critical code you're already doing something wrong.
Using C++ and p/invoke would be an ok option and it would work just fine in mono, too.
The numbers you quote are completely unrealistic, at least as far as the mono JIT is concerned (and I'd guess the MS runtime would be as fast as us, but I haven't checked). What is the function you're calling in C++ from managed code?
As an example the following C function:
void nullf (double *array, int pos, int count) {}
takes 50 cycles of overhead when called from C# code on Mono on my 1.6 GHz Pentium M.
Newer processors should take a little less, but that is the ballpark.
So if you see a 2000 cycles overhead instead of 50 you're likely doing something wrong or you just invented the number (or you should be using mono:-).
Mono is being ported to run on mips and several basic programs work on it.
You can help us complete the port so you'll have a chance of running silverlight on your system in the future:)
You're completely wrong. MS never open sourced the CLR (the CLR is their implementation of the spec, called CLI). MS released with a non-open-source license rotor, which was a crippled implementation of the spec (it is completely outdated and was useless even when they released it). And Mono is not based on it in any way: we even reject contributors that looked at the rotor source code.
You're missing the libgdiplus library: install it or compile it (take it from the same place you downloaded the rest of mono).
( "file://","");n g(0, ApplicationDirectory.LastIndexOf("/")+1);
Check the mcs -out option to give the binary the name you want.
You can also just rename the file after compiling, you know.
You'll still need the change to the source. The two broken lines will need to look like this:
ApplicationDirectory=ApplicationDirectory.Replace
ApplicationDirectory=ApplicationDirectory.Substri
Include a \ in the filename when saving if you don't fix also the saving code.
It compiles just fine with: .exe to the parent dir, because it expects to find the files and directories there when you run it.
:-). See how ApplicationDirectory is created in MainForm.cs. There is also a similar bug when saving the final file.
mcs -unsafe -resource:Rasterbator.MainForm.resources -r:System.Windows.Forms -r:System.Drawing -r:../itextsharp.dll *.cs
copy the resulting
It has a couple of bugs related to the directory separator: basically the programmer added code to make sure his program didn't run on Linux
The app seems to work just fine after that change, kudos to the System.Windows.Forms team!
This is with mono 1.1.13ish.
You might need to upgrade from mono 0.0.1 (before november 2001 when that class and method was added) to the latest release, mono 1.1.9.1.
For embedded designs - Mono runs on ARM with MIPS soon to come, which makes Mono really the only choice for embedded platforms.
.net-like environment. .net runtimes provide an extended feature set as Mono.
Well the compact framework runs on those processors too as does Portable.NET/DOTGNU.
I won't comment on MIPS, because mono has not been ported to it yet, but on ARM Mono is the most advanced
The compact framework has several restrictions in its implementation and in its base assemblies.
Portable.NET has even more restrictions because it's missing tons of features both in the VM and in the base assemblies.
Mono on ARM provides the full framework, Reflection.Emit, Remoting, P/Invoke, Gtk# etc: none of the other
The ppc mono port has not been optimized as well as the mainstream x86 port, The pystones numbers are about 20% lower using IronPityhon on ppc vs CPython. Part of the issue is that the ppc systems I use still don't support the __thread C keyword which allows a faster runtime and GC implementation so my systems will benchmark a little slower.
We expect to improve the port speed though, of course.
Mono runs IronPython just fine on linux/ppc, OSX, amd64 etc.
Most languages can do delegates. .NET can do that similar VM'ed languages can't."
.NET has no platform independant GUI system yet.
Sure, but your question was: "Tell me what
Now the VM that comes closer to mono is the JVM.
Java and JVM don't have delegates. There aren't other virtual machines currently that have comparable features.
Tail calls are optimizer tricks, not language specs.
First, we were talking about VMs, but anyway this shows you don't have a good idea of the implications of tail calls. Sure JVM jits can perform the optimization, but they may not. Languages like scheme and lisp requires tail calls to be present and working or they blow up the stack. Mono implements the ECMA specified tail call instruction, so those languages can be implemented efficiently on top of the VM.
Value types Java doesn't have and it is a nice feature if you're not using objects to keep data.
Value types also allow a more efficient implementation of many data structures and algorithms.
Interop with shared libraries sound like platform dependance, or is it more like the way Java can load it's classes dynamically?
It's the feature called P/Invoke: seamlessly calling functions in external shared libraries implemented in C for example. Java has JNI, but the features are not directly comparable, P/Invoke is much easier to use.
Interop with different languages is a VM feature, you're surely well aware that the Java VM has a wealth of other languages available too?
Sure, but there is no standard way for interoperation. And, anyway, it's hard to interoperate from languages like java that don't have unisgned integers, for example.
Gtk# works on Linux, windows, OSX. We're working on System.Windows.Forms, too, so that's going to be another option (we plan to have support for SWF in mono 1.2, some apps work already).
nor does it perform better than other VM-based languages.
First thing: speed is not everything: mono gives you many more benefits, like arch-indep programs, integration between several languages, GC etc.
That said, while we're obviously looking at improving mono's speed, we already do well enough for many tasks. If you look at the language shootout you'll see that mono is faster than the JVM in a few benchmarks (note also that they use the 1.0.5 version of mono which is very old and slower than the current release). We run some of the python benchmarks faster than CPython itself.
So, we already perform better in some cases than a runtime that has been tuned and developed for 10 years and we're rapidly improving. We won't beat the JVM at every ebnchmark any time soon, but that is not an expectation that any reasonable person has. The expectation is to be fast enough for the job that needs to be done and mono fullfills that for many cases. In the other cases we'll improve, just file bugs reports for them:-)
Java is a better platform independant language since it's actually quite platform independant (in contrast to .NET). .NET can do that similar VM'ed languages can't, then see what those languages can do that .NET can't. .NET
Mono runs on x86, ppc, amd64, sparc, s390 on Linux, Solaris, Windows, OSX. That pretty much covers 98% of the market for servers and personal computers. We're porting to more architectures, too. Java has been ported to more archs because it has been around for so much more time, but in practice Mono is just as platforms independent (even much more so since Sun, for example, will actually support fewer archs than Mono).
Tell me what
I may be wrong ofcourse, but I just don't see why I would ever want to use
You're certainly wrong, mostly because you are uninformed. I suggest you study the specs (grep for delegates, tail calls, value types, interop with shared libraries, interop between different languages etc).
UNIX was nice 30 years ago. It's still nice.
Agreed. Many of the unix concepts are perfectly fine today. This doesn't mean that Tk is still nice.
Tk's API is one of the better attempts at the same simplification to GUI APIs that the UNIX shell and pipe/filter model was for CLI APIs. It's not nearly as successful, but it sure seems like a better approach than just about anything else I've used.
Tk was good for small apps, but the design it was built upon made it irrelevant, since it is so tied to Tcl and Tcl is unusable in many settings. Having to maintain forks for perl etc just show how much its design was wrong.
After so many years that tk has been deployed, there isn't a single Tk app I'd want to use.
Less than a year after mono 1.0 was released, beagle, muine, monodevelop, ikvm and other mono apps are in the top of the list of apps people want (see gnomefiles). As mono matures the number of apps will accelerate.
And Mono looks to become the next great evil dependency salad. I can't wait.
Your drivel is showing.
Please reply if you have technical issues to bring up, your uninformed rants are useless.
IronPython 0.7 was released yesterday.
One of the differences between this and other GPL software is that, in this case, these issues will come up.
I'm sure glad you can see the future, but frankly your divinations don't have much weight.
Any piece of free software is under the threat of patents until the patent process is reworked to favour innovation instead of favouring monopolistic and patent-portfolio companies that don't do any innovation.
The only difference between an open source project that will be sued and one that won't is that the projects that are irrelevant won't get sued.
So it's very easy to avoid the patents issues: write software that few people will use and that doesn't generate sufficient economic changes.
BTW: this works also for proprietary sw: the difference there is that the amount of revenue involved before a suit is much less, since in the case of free sw the negative publicity of suing a project is very big: see why the linux kernel was involved by the SCO idiots only so late and how they paid with self-destruction what they did.
There are quite a lot of very nice development platforms on free software systems, from integrated environments like Squeak to libraries that can be linked with many languages, like Tk.
Tk was nice 8 years ago. Besides you can reuse Tk either by embedding the tcl interpreter or by changing the Tk code and plug a different language. Not exactly a good example of nice sw reuse.
at some cost in security since it's not as well adapted to sandboxing
Mono is currently implementing the security sandboxing: if you ask security experts they'll tell you the security features in the CLI are well thought out.
Other than that last point, there are so many excellent alternatives already in use that I can't see any anything but Microsoft compatibility as being the "killer app" for Mono.
Wait and see until the new apps based on C# and mono become mainstream in linux distributions: beagle, f-spot, muine, monodevelop.
The speed numbers are very similar in version 0.6 which implements basically the full python language semantics.
But you are comparing apples and oranges. since glibc is much bigger than mscorlib.dll really.
libc + libm is about 1780 KB of native code.
mscorlib.dll is 600KB of IL code and compiles to about 1300 kb of native code. Even if corlib was twice as big, the jit is (and neeeds to be) a few orders of magnitude faster. And of course the jit needs to assemble and link the code or it wouldn't work.
Oh by the way glibc is not part of GCC at all.
I never said that anywhere: why do you bring up irrelevant issues?
Depends if you really wanted to print an empty line as well. :-)
And with so many projects in need of help (gjc/ parrot(perl6)/gnustep) do we need more?
Considering that mono is pretty much in a more advanced state than any of those projects you should ask yourself why...
The reality is that free software developers work on what the enjoy best: if you want some project to succeed, work on it, don't demand other people to do it.
When we started mono llvm was very immature and it still wouldn't be able to be used as a jit for the CLR since it misses many features. The mono jit has also been ported to more architectures than llvm.
We're looking at adding more optimizations to the jit, but keep in mind that a jit has different contraints than gcc when compiling code.
As an example, compiling from C# code to native code the base library of mono (mscorlib.dll) takes 20 seconds. Compiling the equivalent library with gcc (libc) which has roughtly the same size takes tens of minutes on the same box.
If the speed difference is so big, please file a bug report at bugzilla.ximian.com with your test case so we can check the generated code.
You also may want to use the -O=inline option.