pypy: static vs. dynmic (was: [ann] Minimal Python project)
Paul Rubin wrote:
Christian Tismer <tismer@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@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/
participants (1)
-
Christian Tismer