interpreter vs. compiled

[Terry Reedy]

Duncan Booth wrote:
> Terry Reedy <tjreedy at udel.edu> wrote:
> 
>> 1. Portability: The Microsoft C# JIT compiler runs under Windows .NET
>> on x86/amd64 and maybe it64 and what else?  Just porting .NET to run
>> 0n Linux on the same processors was/is a bit task.  Does MONO have a
>> JIT also? 
> 
> Technically there is no such thing as a Microsoft C# JIT compiler: the C# 
> compiler targets IL and the JIT compilers convert IL to the native machine,  
> but C# is just one of the frontend compilers you could use.
> 
> Microsoft do JIT compilers for .Net Compact Framework that target ARM, 
> MIPS, SHx and x86. The Mono JIT supports:
> 
> s390, s390x (32 and 64 bits) Linux
> SPARC(32) Solaris, Linux
> PowerPC Linux, Mac OSX
> x86 Linux, FreeBSD, OpenBSD, NetBSD, Microsoft Windows, Solaris, OS X
> x86-64: AMD64 and EM64T (64 bit) Linux, Solaris
> IA64 Itanium2 (64 bit) Linux
> ARM: little and big endian Linux (both the old and the new ABI)
> Alpha Linux
> MIPS Linux
> HPPA Linux
> 
> (from http://www.mono-project.com/Supported_Platforms)
> 
> 
> So I'd say .Net scores pretty highly on the portability stakes. (Although 
> of course code written for .Net might not do so well).

Did you mean IL scores highly?  In any case, scratch 1. portability as a 
reason why CPython lacks JIT.  That leave 2. $ in the multimillions.

More
3. Design difference1: I suspect that IL was designed with JIT 
compilation in mind, whereas PyCode was certainly not.

4. Design difference2: The first 'killer ap' for Python was driving 
compiled Fortran/C functions (early Numeric).  If a 'Python' program 
spend 95% of its time in compiled-to-machine-code extensions, reducing 
the other 5% to nothing gains little.  CPython *was* and has-been 
designed for this.

The process continues.  The relatively new itertools module was designed 
and tested in Python (see itertools in Libary reference).  But the 
delivered module is compiled C.

tjr