On 9/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Message: 9 > Date: Fri, 16 Sep 2005 21:07:23 -0500 > From: [EMAIL PROTECTED] > Subject: Re: [Python-Dev] Variant of removing GIL. > Message-ID: <[EMAIL PROTECTED]> > > > Martin> However, this is really hard to do correctly - if it were > Martin> simple, it would have been done long ago. > > I don't believe difficulty is the only (or primary) barrier. I think > *someone* would have tackled it since Greg Stein did back in 1.4(?) or his > free-threading changes would have been incorporated into the core had they > yielded speedups on multiprocessors and not hurt performance on > uniprocessors. > > Skip >
It did yield speedups on multiprocessors. The uniprocessor part could've been solved just like most kernels do, one binary for UP and another for MP. That's what IBM, RedHat, Solaris, and almost all other modern kernels that support SMP machines do. In theory, if we had those changes in the CPython interpreter, we could've been running at 1.6 times the speed on dual processor machines today (according to Greg's benchmark data) and at the same speed on UP machines running the UP compiled CPython interpreter, which would not have had all the locking calls not needed on a UP machine that would hurt its performance. By now, we probably could've improved on the scalability of MP performance when running on machines with more than three processors. Mind you though, I'm not trying to oversimplify the issue. I was not using python yet at that time (I started around 1.5/1.6) and I didn't see all the info involved in the decision making process, so I'm sure there were other issues that contributed to the decision of not keeping Greg's free threading changes. My point is that not yielding speedups on multiprocessors and hurting performance on uniprocessors is not a good or valid reason to drop free-threading. -- Luis P Caamano Atlanta, GA USA _______________________________________________ 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
