| News | Features | Interviews |
| Blog | Contact | Editorials |
| Mono LLVM Compilation |
| By Thom Holwerda on 2009-07-17 10:45:19 |
| 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." |
|
| RE: Comment by satan666 |
| By memson on 2009-07-17 12:41:58 |
|
> 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> |
 - Score: 1 |
| Slow JIT |
| By vivainio on 2009-07-17 12:51:09 |
| 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? |
| - Score: 2 |
| RE[2]: Comment by satan666 |
| By Mark Williamson on 2009-07-17 12:57:08 |
|
> Or use morse code and punched paper tape- because progress sucks and there's no point in anything new.. right? 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. |
| - Score: 5 |
| RE: Slow JIT |
| By zlynx on 2009-07-17 14:02:32 |
|
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 ... |
| - Score: 3 |
| RE: Slow JIT |
| By moondevil on 2009-07-17 14:03:39 |
|
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. |
| - Score: 1 |
| RE: Comment by satan666 |
| By chrish on 2009-07-17 14:17:09 |
|
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-App le port to Mac OS X. - chrish |
| - Score: 2 |
| I prefer Mono's JIT |
| By fithisux on 2009-07-17 14:33:11 |
| 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. |
| - Score: 3 |
| RE: I prefer Mono's JIT |
| By fretinator on 2009-07-17 14:56:59 |
|
> I wish OSNEWS makes also more references to Parrot which is a complementary exciting piece of SW technology. So submit something! |
| - Score: 2 |
| scientific users |
| By l3v1 on 2009-07-17 15:23:01 |
|
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. |
| - Score: 7 |
| RE[2]: Slow JIT |
| By ba1l on 2009-07-17 15:28:29 |
|
> 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. 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. |
| - Score: 3 |
| News | Features | Interviews |
| Blog | Contact | Editorials |