pypy: static vs. dynmic (was: [ann] Minimal Python project)

[Christian Tismer]

Paul Rubin wrote:
> Christian Tismer <tismer at tismer.com> writes:
> 
>>>>... that can be
>>>>achieved with a static system.
>>
>>With a dynamic system, you can have backwards compatibility as well,
>>together with the flexibility to try alternatives on-the-fly rather
>>easily. Changing some very internal things to try something out is
>>still not easy, but with welded C code, this is almost impossible.
> 
> 
> Can you explain what you mean by static vs. dynamic?

Yes. Please see below.

> Is PHP a static system or a dynamic one?  I ask this because the PHP
> interpreter has been benchmarked as quite a bit faster than Python.
> Of course that must be partly because the PHP language doesn't use
> abstract objects so extensively, so the interpreter doesn't have to do
> as many dictionary lookups all the time.

Sorry, I don't have enough insight into PHP to
answer that question. And I doubt I will ever
have that, since what I saw my son programming
in PHP was much too perlish to invoke my interest :-)

(although I'm happy to see him programming at all,
hoping he will get back to Python in some future.
At the moment, he's trying to distinguish form his
father, which I can understand...)

I will try to explain my current perception of
static and dynamic in the context of building
a Python compiler. Please excuse that I'm writing
out of the top of my head. This is more a feeling
than exact information. Somebody will augment this
for sure, and I appreciate it.

What is STATIC?
---------------
Regardles of PHP (someone more enlighted may judge this),
by static I mean something like a C compiler, which is
fed by a number of C sources, which are fixed at some
compile time, with no chance to get changed.
There is exactly one build process, which leads to
an executable, and that's it. From then on, this
executable has to fit everything, for every application
and for all time, until another version is compiled.

The static executable is also almost always not
optimized for the platform, the processor brand,
the amount of physical memory available, and the
applications to be run.

Finally, the static build is also dependant of a C
compiler created by somebody, where it has no real
control about. This is especially true for closed
source platforms like Windows, but also open sourced
compilers like the gcc family are huge projects,
very difficult to understand for average programmers
like me, so they are black holes as well. That makes
optimizations into something like a try and error
game instead into a scientific project.

I admit that the last argument is not specific to
the static tag, it is just an observation that
comes for free. Implementing one's own system,
specifically designed towards the language to implement
and not trying to solve the world's needs for a compiler
surely creates an easier to understand and optimize
tool.

What is DYNAMIC?
----------------
Dynamic means to avoid compling lots of your system
based upon a fixed set of C sources, with some typical
C compiler. You try to avoid C at all. Instead, you
try to express as much as possible with a language
that is dynamic by nature (for the implicit definition
of dynamicness every Python programmer should feel).

You rely on the fact that your Python code will be
fed into a specializing compiler which is able to
do several things which a C compiler normally cannot
do:
- The executed code is analyzed at runtime. This gives
   the compiler the opportunity to optimize code driven
   by the needs of the actual application. This can lead
   to very different implementation of certain interpreter
   activities, in a very application dependant manner.
- The machine code can be created with knowledge of the
   actual hardware platform, to any thinkable extent!
   If there is a machine specification available that
   matches the current hardware, every speciality of the
   hardware can be used for optimization. To my knowledge,
   there is no such extensive optimization available at
   this time, but it is possible and likely to appear.
   The compiler can take measures of cache lines, main
   memory size and access time, special register sets
   in the CPU, everything is possible.
   This is out of the scope of a static C compiler.
- By avoiding the so-called C runtime system, or minimizing
   it to the absolutely necessary, the fence between
   Python code and library implementation of Python objects
   vanishes. This opens these things to optimization at
   runtime. There is no longer a Python interpreter, written
   in C, and a set of Python objects, implemented in C, with
   the interpreter calling methods of these objects.
   Instead, the optmization of the interpreter (written in
   Python) can dynamically decide, wheather it makes
   sense to call a method of certain objects in a
   pre-defined manner, or it can try a specialized
   version of that method (again written in Python),
   and it can implement this method inlined into the
   specialized version of the interpreter,
   that makes sense in just that current context.

   A C compiler has no chance to do something comparable,
   simply because it does not have the runtime info,
   but especially since it has no idea of Python at all!
   By writing almost everything in Python, we are able
   to generate every possible optimization, since we still
   have the full knowledge of the abstractions, of what we
   wanted to implement, of our objects and of our targets.*

This is what I call 'dynamic', and this is what I hope
to be the

                       __future__ of Python

dynamically y'rs -- chris


P.s.: *
   This is btw. something that would be lost by using
   macros, unless we invent a macro language which does
   know what it is doing. Almost all macro language I've
   seen so far did a dumb textual or tuple replacement.
   This is what language designers do when they don't know
   how to continue.
   Macros are a powerful extension to weak languages.
   Powerful languages don't need macros by definiton.

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/