Hi Cesare, On Sat, Jan 23, 2010 at 1:09 PM, Cesare Di Mauro <cesare.di.ma...@gmail.com> wrote: > Hi Collin > > IMO it'll be better to make Unladen Swallow project a module, to be > installed and used if needed, so demanding to users the choice of having it > or not. The same way psyco does, indeed. > Nowadays it requires too much memory, longer loading time, and fat binaries > for not-so-great performances. I know that some issues have being worked on, > but I don't think that they'll show something comparable to the current > CPython status.
You're proposing that, even once the issues of memory usage and startup time are addressed, Unladen Swallow should still be an extension module? I don't see why. You're assuming that these issues cannot be fixed, which I disagree with. I think maintaining something like a JIT compiler out-of-line, as Psyco is, causes long-term maintainability problems. Such extension modules are forever playing catchup with the CPython code, depending on implementation details that the CPython developers are right to regard as open to change. It also limits what kind of optimizations you can implement or forces those optimizations to be implemented with workarounds that might be suboptimal or fragile. I'd recommend reading the Psyco codebase, if you haven't yet. As others have requested, we are working hard to minimize the impact of the JIT so that it can be turned off entirely at runtime. We have an active issue tracking our progress at http://code.google.com/p/unladen-swallow/issues/detail?id=123. > Introducing C++ is a big step, also. Aside the problems it can bring on some > platforms, it means that C++ can now be used by CPython developers. Which platforms, specifically? What is it about C++ on those platforms that is problematic? Can you please provide details? > It > doesn't make sense to force people use C for everything but the JIT part. In > the end, CPython could become a mix of C and C++ code, so a bit more > difficult to understand and manage. Whether CPython should allow wider usage of C++ or whether developer should be "force[d]" to use C is not our decision, and is not part of this PEP. With the exception of Python/eval.c, we deliberately have not converted any CPython code to C++ so that if you're not working on the JIT, python-dev's workflow remains the same. Even within eval.cc, the only C++ parts are related to the JIT, and so disappear completely with configured with --without-llvm (or if you're not working on the JIT). In any case, developers can easily tell which language to use based on file extension. The compiler errors that would result from compiling C++ with a C compiler would be a good indication as well. > What I see is that LLVM is a too big project for the goal of having "just" a > JIT-ed Python VM. It can be surely easier to use and integrate into CPython, > but requires too much resources Which resources do you feel that LLVM would tax, machine resources or developer resources? Are you referring to the portions of LLVM used by Unladen Swallow, or the entire wider LLVM project, including the pieces Unladen Swallow doesn't use at runtime? > (on the contrary, Psyco demands little > resources, give very good performances, but seems to be like a mess to > manage and extend). This is not my experience. For the workloads I have experience with, Psyco doubles memory usage while only providing a 15-30% speed improvement. Psyco's benefits are not uniform. Unladen Swallow has been designed to be much more maintainable and easier to extend and modify than Psyco: the compiler and its attendant optimizations are well-tested (see Lib/test/test_llvm.py, for one) and well-documented (see Python/llvm_notes.txt for one). I think that the project is bearing out the success of our design: Google's full-time engineers are a small minority on the project at this point, and almost all performance-improving patches are coming from non-Google developers. Thanks, Collin Winter _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
