On 10/1/2010 7:17 AM, Rui Maciel wrote:
Pascal J. Bourguignon wrote:

Nothing extraordinary here.  Common Lisp is more efficient than C.
http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf
http://portal.acm.org/citation.cfm?id=1144168

I don't know if you are intentionally trying to be deceitful or if you honestly 
didn't spent much
time thinking about this issue.  To be brief I will only point out the 
following topics:


a) no language is inherently more or less efficient than any other language.  
The efficiency
aspect is only related to how those languages are implemented (i.e., the 
investments made in
optimizing the compilers/interpreters)
b) Just because someone invested enough effort to optimize a specific 
implementation of language X
to run, under a specific scenario, a benchmark faster than some other 
implementation of language Y
it doesn't mean that language X's implementation outperforms or even matches 
every implementation
of language Y under every conceivable scenario.

    If the implementation has an omniscient compiler, yes.  If not,
some languages have serious speed penalties.

    Python has some inherent performance problems stemming from
its "gratuitous hidden dynamism".  That is, there are
bits of dynamism which are very unlikely, but not visible at
compile time, and thus very difficult to optimize out.
For example, it's possible to add an attribute to an object
from outside the object's class.  It's thus very difficult to
detect at compile time which classes could use static "slots",
and which could not.  Python allows replacing a function at
run time, even while another thread is executing in it.
(Even PHP disallows that.)  This breaks a wide range of
optimizations.  And then, of course, there's the "global
interpreter lock" problem.

    Dynamism is not the problem.  It's hidden dynamism, which
forces compiling for the worst case all the time, that's
the problem.

    Most of these problems come from CPython,
which is a naive interpreter.  The feature set of Python
is well matched to a naive interpreter.

    The organizational situation is a lot like the one with
Pascal and Wirth. There'a a very straightforward way to write
a recursive-descent Pascal compiler that compiles to a stack
notation.  Wirth wrote one of those, and insisted that the
language should be very close to what a compiler of that form
can do.  This eventually killed Pascal.

                                John Nagle
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to