Fortran vs Python - Newbie Question

[Steven D'Aprano]

But seriously... I'm not a language or architecture guru. Is there any
real difference between a JVM and an interpreter? I mean, I have some
general feel that bytecode is a lower-level, more direct and more efficient
thing to be interpreting that Java or Python source, but at the bottom
level, you are still running an interpreter which is going to be
(significantly?) more inefficient than executing native machine instructions
directly on the CPU, right?

Thirty (or more?) years ago, the differences between compilers and
interpreters was fairly large. Interpreters would scan the source code of
each and every line. If you had a loop, each line in the loop would be
parsed each time around the loop. Despite 30+ years of progress, that's
still the model that many (most?) people have in their head when they
think of "interpreted language". That's why "interpreted" is the Kiss of
Death to anyone interested in speed -- whether true or not.

def if_(): # interpreted function
exec 'x = 0'
exec """for i in range(100):
exec 'x += i'"""
return x

def cf(): # compiled function
x = 0
for i in range(100):
x += i
return x

timeit.Timer('cf()', 'from __main__ import cf').repeat(3, 1000) [0.054703950881958008, 0.038740158081054688, 0.041306018829345703]
timeit.Timer('if_()', 'from __main__ import if_').repeat(3, 1000)

[16.228797912597656, 16.261317014694214, 15.885524034500122]


But these days, and probably for the last decade at least, the nice neat
lines between "compiled" and "interpreted" is much fuzzier. So-called
interpreted languages don't parse the source code every time it is run.
They compile to byte-code, which is interpreted in a virtual machine in
the same way that compiled code is interpreted in a real machine.

Even that distinction isn't necessarily cut and dried. On modern CPUs,
machine code itself can be implemented in a mini-language, which naturally
is interpreted by an interpreter built into the CPU. The "real" machine on
the CPU is likely to itself include "virtual" machines, up to and
including entire emulators of other CPUs.

(Note: for each and every generalization I have made, there are almost
certainly exceptions. I think that just supports my contention that the
generalizations about "compiled" and "interpreted" languages are more
misleading than useful.)

Why is Python able to automatically compile source into bytecode on the
fly (when needed) but Java still forces you to do so explicitly?

That probably has more to do with different programming models than
different technologies. I'm sure somebody could build an interactive
complier/interpreter for Java like Python's. If nobody has, it is probably
more to do with nobody seeing the need of such than because it can't be
done.

I suspect that the advantages of an interactive system are much less for
languages like Java that have static type declarations.

I don't mean to bash Java - I think it has it's place as well, but I
mean to note that Java is very carefully marketed whereas Python's image is
not managed by a major, international corporation.

Exactly. And that's why I think it does Python no favours at all to
keep emphasising the interpreter over the compiler. It gives too many
people the wrong idea.

 

[Dennis Lee Bieber]

Thirty (or more?) years ago, the differences between compilers and
interpreters was fairly large. Interpreters would scan the source code of

But these days, and probably for the last decade at least, the nice neat
lines between "compiled" and "interpreted" is much fuzzier. So-called
interpreted languages don't parse the source code every time it is run.
They compile to byte-code, which is interpreted in a virtual machine in
the same way that compiled code is interpreted in a real machine.

Over 25 years ago we had UCSD Pascal... Which compiled to byte-code
(P-code). 25 years ago I had Alcor Pascal on a TRS-80 -- which compiled
to byte-code (though the "object" file was an ASCII hex representation
-- one could physically do "linking" by cut&paste on object files <G>)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Alex Gibson]

Your experience with Fortran is dated -- see below.


Gfortran, which supports Fortran 95 and a little of Fortran 2003, is
part of GCC and is thus widely available. Binaries for g95, also based
on GCC, are available for more than a dozen platforms, including
Windows, Mac OS X, and Linux. I use both and consider only g95 mature,
but gfortran does produce faster programs. Intel's Fortran compilers
cost about $500 on Windows and Mac OS and $700 on Linux. It's not
free, but I would not call it costly for professional developers.

Speaking of money, gfortran and g95 have free manuals, the latter
available in six languages
http://ftp.g95.org/ . Final drafts of Fortran standards, identical to
the official ISO standards, are freely available. The manual for Numpy
costs $40 per copy.

Sun also provides its sun studio ide and compilers(c , c++ and fortran) free
of charge on x86 linux
just have to register for free.
http://developers.sun.com/sunstudio/downloads/

Alex

 

[Tim Roberts]

Sheesh. Do Java developers go around telling everybody that Java is an
interpreted language? I don't think so.

What do you think the "c" in ".pyc" files stands for? "Cheese"?

Well, I'm being a bit argumentative here, but it's hard to deny that the
use of "compiled" in the context of .pyc (or .javac) is very different from
the use of "compiled" in the context of running gcc. Once upon a time,
Basic enthusiasts would have used the word "tokenized" to describe .pyc
files.

A .pyc file is, in fact, interpreted by an intermediate language
interpreter. I don't understand why anyone would be embarrassed by that.
Is it fast enough? It certainly is for MY needs.

 

[Michael Tobis]

I feel obligated to fan the flames a bit by pointing to
http://www.fortranstatement.com/ a site which advocates discontinuing
development of Fortran and does a good job of summarizing the problems
with the contemporary development of that language.

I am not convinced that a new high performance language (Chapel,
Fortress, etc.) is necessary. Rather, I feel that FORTRAN 77 is a
mature tool, and that it, in combination with a powerful dynamic
language (Python being my choice) is entirely sufficient for any
foreseeable scientific computing.

Fortran 90 and successors (F9* in the following) provide a baroque and
elaborate effort to bolt modern computing methods over a finely honed
special purpose tool (F77) that manages large numerical arrays
spectacularly well. It is as if you decided to add a web search engine
(an elaborate, developing set of requirements) to grep (a finely honed
special purpose tool). It makes much more sense to add greplike
features to your websearch tool than to try to foist
"Grep95" (competing with the Google search engine) on everyone who
ever needs to find a misplaced text file.

F77 interfaces smoothly and neatly with Python. F9* continues to be
the single most difficult case for interoperability with any other
contemporary algorithmic language. Fortunately there is hope within
the new standard, where an "interoperability" flag will force F2003 to
deliver arrays that are exportable. In exchange for this balkiness,
F9* offers crude and verbose implementations of encapsulation and
inheritance.

I am sure Dr Beliavsky and some others are productive with F9*, but I
would strongly advocate against it for anyone in a position to make a
choice in the matter. Some people are competent with hand-powered
drills, but I wouldn't set up a furniture production line with them on
that basis.

The performance and library advantages of Fortran are all available in
F77. Higher level abstractions can easily be wrapped around the low
level structures using Python and f2py. Making the combination
performance-efficient requires some skill, but making a pure Fortran
implementation efficient does no less so.

I don't think we should or can abandon the excellent infrastructure
provided by the Fortran of a generation ago. However, I am totally
unconvinced that there is a point to a backward compatible extension
to F77 that tries to support OOP and other abstractions unimaginable
in the early days of Fortran.

F77 and its numerical libraries are mature and complete. I think we
should treat it as a remarkable set of packages, and move on.

For any purposes I know of not involving an existing F9* legacy, I
believe that Python plus F77 is as good as or superior to F9* alone.
This includes the total time needed to learn the tools, (I think it is
easier to learn Python, F77 and f2py than to learn F9* alone to any
comparable skill level.) total time needed to develop the code, whole
system performance, testability and maintainability. Once Python gets
a first-class array type things will be even smoother as I understand
it.

mt

 

[Terry Reedy]

| Well, I'm being a bit argumentative here, but it's hard to deny that the
| use of "compiled" in the context of .pyc (or .javac) is very different
from
| the use of "compiled" in the context of running gcc.

Besides the fact that the object code does not corresponded to the public
interface of any *current* processor, the compilation process is quite
similar. Linear source code is parsed using standard techniques to produce
a syntax tree. The tree is walked to produce object code in a different
language. A certain amount of optimization is done.

For instance, CPython compiles a 'while ' statement to a conditional jump
past the end before the body and an absolute jump to the begining at the
end. I am quite sure that gcc does essentially the same thing. If CPython
(by 2.4, at least) recognizes the condition as a constant whose Bool value
is True, it removes (optimizes away) the loading of the constant and the
conditional jump that would never happen. Again, this is the same as gcc
will do, I am sure, with at least some flag settings.

| Once upon a time,
| Basic enthusiasts would have used the word "tokenized" to describe .pyc
files.

Perhaps, but they would, I think, have been wrong. Tokenized Basic to the
best of my knowledge, is a reversibly compressed version of the source
file. The 'while' keyword, is there is one, is replaced by a number, but
no parsing is done.

Terry Jan Reedy

 

[Mel Wilson]

| Once upon a time,
| Basic enthusiasts would have used the word "tokenized" to describe .pyc
files.

Perhaps, but they would, I think, have been wrong. Tokenized Basic to the
best of my knowledge, is a reversibly compressed version of the source
file. The 'while' keyword, is there is one, is replaced by a number, but
no parsing is done.

Almost reversibly. The giveaway was when you listed your BASIC
program and all the keywords came out upper-case, regardless of what
case you'd typed them in.

Mel.