[Fwd: Re: [Discuss] Interpreters vs Compilers]

[John Blomfield]

-------- Original Message --------
Subject: 	Re: [Discuss] Interpreters vs Compilers
Date: 	Wed, 12 Mar 2008 17:30:46 -0700
From: 	John Blomfield <jabfield at shaw.ca>
Reply-To: 	jabfield at shaw.ca
To: 	Alan W. Irwin <irwin at beluga.phys.uvic.ca>
References: 	<47D81241.70209 at shaw.ca> 
<Pine.LNX.4.60.0803121307310.3922 at ybpnyubfg.ybpnyqbznva>



Alan W. Irwin wrote:
> On 2008-03-12 10:26-0700 John Blomfield wrote:
>
>> My presentation "Writing programs for Linux" at last night's monthly 
>> meeting gave rise to some spirited discussion, when I remarked that 
>> compiled languages resulted in faster execution times than 
>> interpreted languages and tended to be preferred by programmers for 
>> larger more complex problems. There were many reasons put forward as 
>> to why this should be and some doubted there was any significant 
>> difference in practice.  I was unable to answer these questions 
>> authoritatively since I just use a language when it suits my 
>> particular purpose and use the rule of thumb "big or fast program = C 
>> or C++" and "small and quick to write = Python, bash etc."
>>
>> The attached link is a result of a quick google that tends to support 
>> my pragmatic view of life:
>> http://furryland.org/~mikec/bench/
>
> The "speed" benchmark there (which was simply an empty loop with many
> iterations) confirmed what I said at the meeting; loops are really
> inefficient for both perl and python.  You get roughly a factor of 200
> decrease in speed in the python case and roughly a factor of 100 in 
> the perl
> case compared to C++.  There was a thread sometime ago here on relative
> speeds of python/perl/C where David Bronaugh did some tests which also 
> told
> a similar story for a loop which did a simple calculation (addition of
> integers?) within the loop.
>
> The question I really would like to see answered is why are both perl and
> python so slow on loops? I hypothesized last night that the 
> interpreter did
> some compilation for each iteration of the loop, but it was asserted that
> interpreters only do the compilation of the code in loops once.  I don't
> believe for an instant that some difference in optimization (another
> possible explanation discussed last night for the slowness of python and
> perl for loops) is going to cause a two orders of magnitude change in 
> speed.
> So does anybody have the authorative answer to this question?
>
I don't have anything more authoritative to add than I did last night, 
except to say again, that Python and Java for example compile their 
source code into "bytecode" which is slightly optimized code but it is 
not machine code. A byte code file still has to be interpreted, which 
means translated into machine code instructions line by line by the so 
called "Virtual Machine".  Each platform needs the Virtual Machine 
running to run a bytecode file.  In the case of a loop, the loop is in 
bytecode and must be interpreted line by line every time through the 
loop, into possibly many many machine instructions.  In the case of a 
compiled C program the binary is in machine instructions that the CPU 
understands without interpretation, hence the speed.  The optimization 
in C is very very good, so good that it is almost impossible for the 
average programmer to do better using Assembler.  I once did some 
programming of micro-controllers, which are quite slow compared to the 
typical PC, in both Microchip Assembler and Microchip C and the C 
compiler always won.  This one of the reasons most hardware is 
programmed in C, including Linux and Python I think.  Python certainly 
uses a lot of built in mathematical functions that are written in C to 
help speed its execution.

Its all a question of horses for courses!  Scripting languages like Perl 
and Python are often referred to as the "glue" that sticks the C and C++ 
modules together.  So if you want Zoom Zoom go C!

John Blomfield

> I enjoyed your talk, John.  There was something for everybody there, but
> unfortunately those who as yet have not programmed at all were (AFAICT)
> underrepresented in the audience.  I recommend you make the presentation
> available on our website so those who missed the talk can benefit.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and 
> Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state 
> implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting 
> software
> package (plplot.org); the libLASi project (unifont.org/lasi); the 
> Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>