I came across this quote:
"The .NET Common Language Runtime
(CLR) supplies at least one JIT
compiler for every NET-supported
computer architecture, so the same set
of CIL can be JIT-compiled and run on
different architectures."
I've looked around but can't find a definitive list of the JIT compilers supported by CLR?
Mainly there is one JIT compiler for every processor architecture the CLR runs on. In particular
x86
amd64
ia64
Less sure about the following.
PowerPC (XBox360)
ARM (Mobile devices)
Related
What are the (architectural) differences in implementing a programming language on the GraalVM architecture – in particular between Graal, Truffle, and LLVM using Sulong?
I plan to reimplement an existing statically typed programming language on the GraalVM architecture, so that I can use it from Java without much of a hassle.
There are at moment three options:
Emit JVM bytecode
Write a Truffle interpreter
Emit LLVM bitcode, use Sulong to run it on GraalVM
Emitting JVM bytecode is the traditional option. You will have to work at the bytecode level, and you'll have to optimise your code your before emitting bytecode as the options that the JVM has for optimising it after it has been emitted are limited. To get good performance you may have to use invokedynamic.
Using Truffle is I'd say the easy option. You only have to write an AST interpreter and then code generation is all done for you. It's also the high performance option - in all languages where there is a Truffle version and a bytecode version, the Truffle version confidently outperforms the bytecode version as well as being simpler due to no bytecode generation stage.
Emitting LLVM bitcode and running on Sulong is an option, but it's not one I would recommend unless you have other constraints that lead you towards that option. Again you have to do that bitcode generation yourself, and you'll have to optimise yourself before emitting the bitcode as optimisations are limited after the bitcode is set.
Ruby is good for comparing these options - because there is a version that emits JVM bytecode (JRuby), a version using Truffle (TruffleRuby) and a version that emits LLVM bitcode (Rubinius, but it doesn't then run that bitcode on Sulong). I'd say that TruffleRuby is both faster and simpler in implementation than Rubinius or JRuby. (I work on TruffleRuby.)
I wouldn't worry about the fact that your language is statically typed. Truffle can work with static types, and it can use profiling specialisation to detect more fine-grained types again at runtime than are expressed statically.
I know these technologies are all related but could someone please explain what each one is used for and how they fit together?
Oversimplification:
Graal - Java bytecode compiler. Can be used just in time (as part of a JVM) or ahead of time.
SubstrateVM - other things (runtime) needed to actually run ahead-of-time compiled Java bytecode without a JVM. This powers the "native-image" command of GraalVM.
Truffle - framework for implementing languages as AST interpreters which can be just-in-time compiled using graal. Some notable languages implemented are JavaScript, Ruby, R and LLVM bitcode.
GraalVM - most of these technologies packaged together in order to support different use cases, for example: running JVM programs (i.e. anything that compiles to Java bytecode) using Graal as the JIT compiler for better peak performance, ahead-of-time compiling JVM programs for fast startup and low memory footprint, running fast dynamic languages (JS, R, Ruby) that can interoperate without overhead, and so on.
Does Delphi support ARMv5 and ARMv6 CPU's and is there a way to make my app work on them?
The answer is no because Delphi compiles native code targeted at a specific CPU, in this case ARMv7 with NEON support.
David I posted this on the subject:
Brian Long gives additional Android requirements in his blog post at
http://blog.blong.com/2013/09/delphi-for-android-aka-delphi-xe5-aka.html?showComment=1378942045563&m=1
Here is what he lists from our Documentation:
Android requirements
Because the Delphi compiler generates native machine instructions, its
output is processor-specific. In other words it doesn’t target the
Dalvik Virtual Machine, where regular Android applications reside,
which are basically Java p-code applications that are executed by a
variant of the Java VM. Instead it generates raw machine code, as all
the current wave of Delphi compilers do (the long gone Delphi for .NET
was the exception to this general rule). So because it’ a compiler
compiling native machine instructions Delphi’s Android support has the
following requirements:
there must be a GPU
the CPU must be ARMv7 with NEON instruction support
the OS on the target device must be one of: GingerBread: Android
2.3.3+ (MR1 or later), which is API level 10 Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15 Jelly Bean:
Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17
and 18
Embarcadero clearly states in their manual what is supported.
As far as I know (and what embarcadero tells on the RAD studio road shows), for Android at least ARM v7 with NEON support is required.
Edit: The (German) data sheet states "Android-Smartphones und –Tablet-Computer: ARMv7-Geräte mit NEON-Unterstützung," on the bottom of the last page.
My understanding is that Xamarin's Ahead-of-Time (AOT) Compiler compiles Xamarin.iOS applications directly to native ARM assembly code (How Xamarin works).
What I don't get, however, is why it needs to be called "Ahead-of-Time" as opposed to just being an ordinary compiler. Is there any distinction between Xamarin's AOT compiler and a traditional compiler or is this just a marketing term?
How AOT compares to a traditional JIT compiler
Ahead-of-Time (AOT) compilation is in contrast to Just-in-Time compilation (JIT).
In a nutshell, .NET compilers do not generate platform specific assembly code, they generate .NET bytecode, instructions which are interpreted by the .NET virtual machine. This bytecode is portable, any .NET VM can run it, be it Windows Phone, Mono on Linux, or a JavaScript-based implementation. Unfortunately, because the code has to be interpreted by the VM it is slower than native code which can be executed by the processor itself. That's where JIT and AOT come in.
When a .NET application starts up, the JIT compiler analyzes the bytecode, identifies areas that could be sped up by being translated to native code, and compiles them. During execution, the compiler can also identify hot paths for compilation.
Unfortunately for .NET, Java, and any platform that would benefit from JIT, dynamic code generation is disallowed by the App Store terms of service. Since Xamarin can't perform JIT on the device and they know they're shipping to ARM devices, they can run a JIT-type compiler ahead of time (AOT) and bundle it into the binary.
How AOT compares to a machine code compiler
As mentioned above, AOT translates part of an interpreted bytecode to machine code. It doesn't eliminate the need for a virtual machine bytecode interpreter. The VM will run just as it would if, but occasionally see an instruction that says "Execute this chunk of machine code".
Is this just a marketing term?
No. The message that Xamarin was conveying in that paragraph was that their code performs faster than a simple byte code based language. For both iOS and Android, they are able to execute native code on hot code paths to improve performance. The terms AOT and JIT are technical details about how they do that.
I was wondering if there is any AOT compilation options for the mono for android platform (or anything planned?).
I am asking this because I will port a game using mono for android, and performance is really important, this is why I wanted to know if AOT compilation is available (or any other compilation option that can produce better performances)
I know that Monotouch uses AOT compilation, and that it can optionally use llvm as compiler in order to make some optimisations. So, I am wondering if the same options are available in mono for android.
Thanks in advance
AOT is not available in Mono for Android, I don't think it is on the road-map either.
As far as I understand JIT is not slower than AOT, rather the contrary, because JIT can use the information it knows about the environment it runs on to optimize code to it. An AOT compiler cannot know everything about the same environment.
This thread: Why is Java faster when using a JIT vs. compiling to machine code? has some answers that elaborates on this.
So I really doubt that you would get any performance improvements if there were an AOT compiler.