Several Topics - Nov. 19, 2013

Rainer Weikusat rweikusat at mobileactivedefense.com
Tue Nov 19 16:35:19 EST 2013


glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
> In comp.lang.fortran E.D.G. <edgrsprj at ix.netcom.com> wrote:
>>>> "E.D.G." <edgrsprj at ix.netcom.com> wrote in message 
>>>> news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d at earthlink.com...
>> Posted by E.D.G. on November 19, 2013
>  
>> 1.  PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
>  
> (snip)
>
>>       This program translation project has become one of the most 
>> surprisingly successful programming projects I have worked on to date.  A 
>> considerable amount of valuable information has been sent to me by E-mail in 
>> addition to all of the information posted to the Newsgroups.
>  
>>       The original posts actually discussed calculation speed matters 
>> involving Perl and Python.  And responses indicated that there were ways to 
>> develop routines that could dramatically accelerate Python calculations. 
>> But it did not sound like there were any for Perl.
>
> In general, language processors can be divided into two categories
> called compilers and interpreters.  Compilers generate instructions for
> the target processors. Interpreters generate (usually) an intermediate
> representation which is then interpreted by a program to perform the
> desired operations. That latter tends to be much slower, but more
> portable.
>
> There are a few langauges that allow dynamic generation of code, which
> often makes compilation impossible, and those languages tend to be
> called 'interpreted langauges'.

These two paragraphs use the same terms in conflicting ways and the
assertions in the second paragraph are wrong: Lisp is presumably the
oldest language which allows 'dynamic code creation' and implementations
exist which not only have a compiler but actually don't have an
interpreter, cf

http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation

The main difference between a compiler and an interpreter is that the
compiler performs lexical and semantical analysis of 'the source code'
once and then transforms it into some kind of different 'directly
executable representation' while an interpreter would analyze some part
of the source code, execute it, analyze the next, execute that, and so
forth, possibly performing lexical and semantical analysis steps many
times for the same bit of 'source code'.

Some compilers produce 'machine code' which can be executed directly by
'a CPU', others generate 'machine code' for some kind of virtual machine
which is itself implemented as a program. The distinction isn't really
clear-cut because some CPUs are designed to run 'machine code'
originally targetted at a virtual machine, eg, what used to be ARM
Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
machines are supposed to execute 'machine code' which used to run
'directly on a CPU' in former times, eg, used for backwards
compatibility on Bull Novascale computers.

Prior to execution, Perl source code is compiled to 'machine code' for a
(stack-based) virtual machine. Both the compiler and the VM are provided
by the perl program. There were some attempts to create a standalone
Perl compiler in the past but these never gained much traction.



More information about the Python-list mailing list