Mono from SVN is now able to use LLVM as a backend for code generation in addition to Mono’s built-in JIT compiler. “This allows Mono to benefit from all of the compiler optimizations done in LLVM. For example the SciMark score goes from 482 to 610. This extra performance comes at a cost: it consumes more time and more memory to JIT compile using LLVM than using Mono’s built-in JIT, so it is not a solution for everyone. Long running desktop applications like Banshee and Gnome-Do want to keep memory usage low and also would most likely not benefit from better code generation. Our own tests show that ASP.NET applications do not seem to benefit very much (but web apps are inherently IO-bound). But computationally intensive applications will definitely benefit from this. Financial and scientific users will surely appreciate this performance boost.”
Or use C++ for better performance. Or use Java for better portability.
<sarcasm>
Or use morse code and punched paper tape- because progress sucks and there’s no point in anything new.. right?
</sarcasm>
Honestly, I’ve had enough of your modernists with your fancy codes and paper tapes. OK, so stone tablets and chisels might not be quite as “sexy” but they get the job done and our storage longevity is excellent.
Is Java actually any more portable than Mono at this point?
The biggest difference in portability between the two that I can think of is that Java has an officially-supported-by-Apple port to Mac OS X.
– chrish
Yes, contrary to Mono, Java is everywhere.
There are Java implementations for:
– BlueRay players;
– Mobiles;
– Embeded systems (Cars, Ricoh copy manchines, Factory robots, and so on);
– All major OS;
And lets not forget that only the C# compiler and CLR are patent free, given the latest Microsoft announcement.
So with Java I have access to the complete library coming with the JVM, while with Mono I am restricted to the language and basic library.
Well you probably do not mean Java but JDK implementations. Unfortunately these implementations are often incompatible with each other etc etc. One could say that java tries to stretch the usefulness of the jvm so much that it is good at nothing. It is especially lacking as a systems programming language, something that mono excels at.
Since you are in the mood to spread some FUD,I will counter with that now Oracle is in charge of Java how long do you think that it is going to stay free?
My guess is probably not for long.
Soon your Java stuff will only be able to run on $100K oracle app server 🙂
How can they be incompatible if they pass the required tests to call themselves Java? if you’re talking about proprietary extensions specific to a given implementation or libraries out side the specification then of course there will be incompatibilities – but that is only relevant if you’re stupid enough to use those parts outside the official Java specification.
How the hell is that FUD? if you want assurance of being immune from patent claims then you have to stick to the ECMA stack – you don’t have access to Winforms, asp.net, ADO.net and so forth. But hey, lying for you is a second language given you’re versed in because you can’t face the facts and speak the truth.
Based on what evidence – the code is all GPL’ed, how can they release code under GPL then pull it back? they might decide not give it a free compatibility test but who gives a toss, call it ‘chocolate mochachino with cream on top’ and people will still consider it a Java implementation.
Which is based on a nothing. The difference between you and I – I actually read some damn stuff before posting on this forum; I know the difference between the Microsoft arrangement which pertains to the ECMA implementation and the Java working group where people can freely implement it but cannot call it Java unless it has been certified. But then again, lying is your forte.
And that is supposed to be funny?
Edited 2009-07-19 04:55 UTC
Well, no – that certified compatibility is important. If a platform has a certified JVM implementation available, as a developer I can confidently say our product will run on it. If all it has is something Java-ish, I assure you, I’m not touching that with a ten-foot pole. Too much chance of something going wrong, and me having to support it.
Amazing how that has impacted on JBoss taking off, people are really shying away from IceTea and all those other open source projects apparently dying spontaneously through the lack of ‘certification’.
Certification is no more important than Linux getting the blessing of it being SUS2003 or Mono being blessed as 100% compliant. Even if the implementation does pass the test, it still doesn’t negate the fact that there could be vendor specific bugs that’ll cause problems; so certification doesn’t equal absolute perfection nor does certification claim as such.
We’ve moved more or less our entire Java app stack (about 100 units) from Solaris to Linux, 32bit to 64bit, Java 1.5 to Java 1.5, Sun JVM to IBM JVM, more or less without big problems even though the amount of changes underneath the “Java app world” is dramatic.
Now please give me a similar example from the .NET world.
…
And?
…
No example? I thought so ..
Edited 2009-07-19 10:28 UTC
>>So with Java I have access to the complete library
>>coming with the JVM
With IKVM/mono you can invoke classes from java jars, or compile jars into a CLR dll. It works pretty darned well. Also C# P/Invoke is a lot easier than JNI, which means you’ve got access to C++/java/C#/python/F#,VB in a single stack.
For the last few years I have been leaning toward C#, but I reserve the right to use java.
Yes, since going by their supported platforms list, Mono supports Linux on quite a few hardware platforms, but it’s support for other OS’s is limited mostly to x86. It won’t run under HP-UX/Itanium, for example, or AIX/Power – operating systems common on big server hardware. Java does.
I’m a bit puzzled by the problem with slow JITting. Why can’t Mono serialize the jit-ted object code somewhere on disk, and read it back when it’s needed? Why does the compilation have to happen Just-In-Time anyway?
Mono has that option. Code can be compiled and loaded from .so files. The administrator can do it for system code or a user can set an environment variable with a directory to stash compiled code in.
Of course, the last time I tried using this (last year on x86-64) it made all Mono apps crash in strange random ways. I don’t think it’s been well tested.
It would work at first but later it wouldn’t. It could have been prelink, or maybe Mono updated on my system and it didn’t realize it had to recompile the code, or …
Not sure about Mono, but speaking for Java here and in general about JITing.
There are several types of optimization algorithms and during the execution of you program the VM (JVM, CLR, and so on) might reach the conclusion that a certain piece of code would benefit from a different type of optimizations and so recompiles the code again.
For example it might conclude that in all places a certain method is called, actually it is always the same object instance, so the indirect method lookup can be replaced by a direct method call.
Or it might see that a certain method is called so many times, and since its size is small enough, it could start expanding the code inline, instead of doing a call.
And so on.
Neither Mono nor Microsoft’s .NET runtime do this. They both behave the same as Java’s client VM – JIT the code once, the first time it’s called, and try to balance runtime speed with JIT time.
Java’s server VM does as you describe. It’s equivalent to using profile-guided optimization in C/C++ compilers, except it’s automatic. It also turns on a lot of compiler optimizations that are too expensive to perform in an interactive application.
.NET doesn’t have this. It does have an offline compiler, which pre-JITs an entire assembly with all the compiler optimizations turned on. The JIT doesn’t do anything at all at runtime.
Any particular reason Mono doesn’t always do pre-JITting?
Not sure. The pre-JITted native image is installed next to the CIL executable, so I assume it can’t normally be done by a regular user – it’d have to be done at install time. You certainly can’t run ngen on Microsoft’s .NET implementation without admin privileges.
Pre-JITing requires the generated code to be a shared library. This is required so that the same code for say System.XML can be used in two different applications that might end up loading the pre-generated code at different addresses.
The code produced by shared libraries is a bit slower than static code. Invocations need to go through at dispatch table (In Mono and ELF systems it is called the PLT table) and access to global variables also has to go through extra steps and usually ties up a register to keep track of things.
So all of these things mean that you end up with code that might not be as efficient as the static code.
We essentially let the sysadmin make the call
because if some one wants a really fast execution of code C/C++ has no match (has no portability). I belive though that LLVM is an exciting piece of SW technology as fas a ObjC2.0 and pixel shaders are concerned. The C frontend is inevitable for ObjC. The C++ is good for people prefering BSD licence. I wish OSNEWS makes also more references to Parrot which is a complementary exciting piece of SW technology.
So submit something!
not just that, llvm is an exciting piece of technology because its architecture allows for much better integration with the IDE (potentially allowing the actual frontend, or its components, be used instead of a scaled down parser, gaining more accurate code anlysis, code assistance and cumulative compilation);
because its IR bytecode and its runtime are language agnostic AND suit both managed AND unmanaged languages;
because it allows (at least on paper) either JIT’ed or AOT compiled code execution, and/or the optimization of code between runs;
and because it has the potential (though quite some manpower is needed to fulfill this) to be an alternative, instead of a complement, for mono and .net…
“…because if some one wants a really fast execution of code C/C++ has no match…?
really? every coded in assembly? portable? no. fast as can be? ya. check out http://www.menuetos.net/
scientific users will surely appreciate
Well, I don’t. If someone comes up to me saying (s)he’ll use mono/c# for speed, I’ll just send’em away telling to only come back when they produce provably better speeds, and yes, usually we have data to compare with. In this case I honestly think I’ll never see’em again, but I won’t really mind. It’s somehow weirdly entertaining to see an elephant on steroids, but in the end, an elephant is still just an elephant.
True. But many computational guys are using a combination of c/c++ and python right now. Python for ease of use and c/c++ for performance. If you can improve the speed of your easy glue language, it can do more things, before having to be turned into the performance language. As non performance intensive as some of my work is, I’ve discovered a few places where it would seem like python would be okay, but its just really too slow.
Maybe Vala and Genie are a better choice for this stuff – Mono/C# (Vala) and Python (Genie) syntax but C speed.
Too bad on windows I have to use GTK (instead of Windows GUI-API) while using Vala or Genie, but besides that I’m happy with their progress.
P.S. the only thing missing is now a BASIC and a PASCAL frontend/parser and the circle would be complete…
Edited 2009-07-17 20:36 UTC
I can say that on my workgroup at CERN, part of the ATLAS project, we used a mix of everything.
C++ for the cluster based, multithreaded application that processes data coming out of the particle accelerator.
Python for the configuring the applications and doing some automation tasks.
Java for the GUI applications monitoring the cluster.
Seems like google is LLVM jitting Python already:
http://arstechnica.com/open-source/news/2009/07/new-milestone-relea…