Le dimanche 01 novembre 2009 à 17:09 +0000, Michael Sparks a écrit : > > Can you explain what effect you're aiming to achieve with this change?
As the message on python-dev says: make switching latencies more predictable (rather than wildly varying), and reduce the overhead of the GIL itself (in terms of spurious system calls, for example, and therefore of wasted CPU time with multiple threads). > The reason I'm asking is because using kamaelia[2] it should be > possible to craft a bunch of useful test cases or benchmarks - as > long as I know what I'm supposed to be testing :-) Well, it would be nice if you had an existing multithreaded py3k workload so as to test it with the newgil branch. (as far as benchmarks go, I've written ccbench which tries to test the things I was interested in when starting this experiment) > Similarly the generator scheduler sleeps in a thread - either > foreground or background - until something needs running) Similar > points go for GUI code etc as well. As a result having mixed workloads > is common, so if this reworking should have a benefit, we should be > able to practically test for in with kamaelia :-) Well if you are somehow unsatisfied with long (GUI, IO, etc.) latencies in your workload perhaps the new GIL will improve things. If you are satisfied with the current GIL, however, I think it's unlikely you'll notice any difference :-) > [1] I find python.org mailing lists a real pain in the neck because > the mail server throws away perfectly valid mails from my mail server, > so I have to really want to send something if I want to send anything > - because it means I end up having to use google's web gmail interface You should contact the postmaster or mail admin at python.org, IMO. (I don't like the Google stuff either, and I tend to run away from everything Google groups) Regards Antoine. _______________________________________________ concurrency-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/concurrency-sig
