[Discuss] Interpreters vs Compilers

[Patrick]

On Wed, 12 Mar 2008 13:31:28 -0700 (PDT)
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.

On this very slow Armada 1700, I don't notice much difference
between compiled and interpreted programs.  Instead the most
noticeable difference is between graphical and command-line ones
[especially if the program builds a complicated window out of
many, many widgets.  For example, the `Servers' tab of GProFTPD's
main window].

But then, I'm not doing any serious number crunching.

> > 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?

Who, me?  Of course not.  ;-)

I think scripting languages come into their own, not when they do
all the work internally, but when they coordinate the actions of
other, compiled programs.  I liked what you [Alan] said later
about running compiled C / C++ modules as components of python
scripts, where you need the script to do some heavy lifting, but
don't want to wait around for the interpreter to interpret those
chunks.

Kind of blurs the line between compiled and interpreted code, so
it's not very helpful to throw that into a black-or-white
comparison.  But it does give you the best of both.

[Note to self: study python!]

> 
> 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.

Well I learned a lot.  :-)  Not so much from the slide-show
summaries as from the talk itself.

It's still a bit early for me to try writing and compiling my own
programs, GUI or otherwise.  Finding source packages that build
fairly easily, and tweaking those sources to suit my needs is
probably the best way to start.  I already have a `lync' [Lynx
for console mode] with double-wide margins so the columns are
narrower, and easier to read on the console [which is something
like 110x35 chars on this screen; too wide].

For now I'll keep scripting, mostly, and learn to incorporate
things like gxmessage and gtdkdialog wherever the script calls
for user interaction [yes, read foo ; if [ "$foo" = "foo" ]
stuff is easier to do, but less spiffy, and less educational].

There was a lot of other, universally helpful stuff I picked up
from the talk.  Multi-file projects; well that's a good idea for
scripting too.  I've found myself pasting the same few lines into
several scripts lately, and should toss these snippets into files
of their own.  I don't really need these extra file-names
cluttering up my PATH though.  For one thing, they'd eventually
short-circuit all the tab completions I've gotten used to.  ;-P

So I think I will start tossing them into a ~/.bashlib/
directory, and start scripts that need those snippets with an
	export PATH=~/.bashlib:$PATH
statement.

Can you say `include stdio.sh'?  I thought you could.  ;-)


> 
> Alan

Patrick.

-- 
Kludge, n.:
	An ill-assorted collection of poorly-matching parts,
	forming a distressing whole.
		-- Jackson Granholm, "Datamation"