Hi Collin, 2010/1/25 Collin Winter <collinwin...@google.com>
> 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. Absolutely not, of course. > You're assuming that these issues > cannot be fixed, which I disagree with. > No, it's my belief, from what I see until now, that it'll be very difficult to have a situation that is comparable to the current one, in the terms that I've talked about (memory usage, load time, and binaries size). I hope to make a mistake. :) > > 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. I agree (especially for psyco), but ceval.c has a relatively stable code (not mine, however :D). 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. > Optimizations are surely a point in favor of integrating U.S. project in the main core. Psyco, as I said before, is quite a mess. It's hard to add new back-ends for other architectures. It's a bit less difficult to keep it in sync with opcode changes (except for big changes), and a port to Python 3.x may be suitable (but I don't know if the effort makes sense). 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. > I see, thanks. > > 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? > Others have talked about it. > > 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. > OK, if CPython will be compilable without using C++ at all, I retire what I said. > > 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? > No, I'm referring to the portions of LLVM used by U.S.. Regards resources, I was talking about memory, loading time, and binaries size (both with static and dynamic compilation). > > > (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. > I made only computation intensive (integers, floats) tasks with Psyco, and it worked fine. I haven't made tests with U.S. benchmark suite. > > 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 > I see, and I'm very happy that Google invests resources on improving Python execution speed. What I've exposed is just my point of view: performances aren't good enough to justify the problems it brings. I hope to see U.S. issues solved and the project completely integrated in CPython to make it available to the Python community. Cheers, Cesare
_______________________________________________ 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
