Paul Rubin: >IMHO the main problem with the Unladen Swallow approach is that it would >surprise me if CPython really spends that much of its time interpreting byte >code.<
Note that Py3 already has a way to speed up byte code interpretation where compiled by GCC or Intel compiler (it's a very old strategy used by Forth compilers, that in Py3 is used only partially. The strongest optimizations used many years ago in Forth aren't used yet in Py3, probably to keep the Py3 virtual machine simpler, or maybe because there are not enough Forth experts among them). Unladen swallow developers are smart and they attack the problem from every side they can think of, plus some sides they can't think of. Be ready for some surprises :-) >Is there some profiling output around?< I am sure they swim every day in profiler outputs :-) But you have to ask to them. >Plus, the absence of a relocating garbage collector may mess up cache hit >ratios pretty badly.< I guess they will try to add a relocating GC too, of course. Plus some other strategy. And more. And then some cherries on top, with whipped cream just to be sure. >Shed Skin as I understand it departs in some ways from Python semantics in >order to get better compiler output, at the expense of breaking some Python >programs. I think that is the right approach, as long as it's not done too >often.< ShedSkin (SS) is a beast almost totally different from CPython, SS compiles an implicitly static subset of Python to C++. So it breaks most real Python programs, and it doesn't use the Python std lib (it rebuilds one in C++ or compiled Python), and so on. SS may be useful for people that don't want to mess with the intricacies of Cython (ex-Pyrex) and its tricky reference count, to create compiled python extensions. But so far I think nearly no one is using SS for such purpose, so it may be a failed experiment (SS is also slow in compiling, it's hard to make it compile more than 1000-5000 lines of code). Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
