Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: What your fair.py is doing is demonstrating the superior behaviour of a time-based GIL interrupt to a bytecode based one. I have no quibbles with that and I agree that it is superior. But I also think that your example is a very artificial one. On average the duration of the bytecodes evens out between threads and so they should give a fair first approximation.
But this is not what I was talking about when considering fairness. Your test only measures each thread end to end, and it demonstrates how a bytecode based gil yilelding system wil let the two threads work in lockstep, even though each loop in one thread is cheaper than the other. Fair enough. But fair scheduling between threads doesn't show up here. To demonstrate fair / unfair, I've modified fair.py to add two more runs, where three threads of the "fast" variety are run for identical number of rounds. This is when you will se a difference between the linux and the mac based GIL implementations. For your info, on my windows dual core office box, with regular windows gil: D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py Sequential execution slow: 3.384000 (0 left) fast: 0.177000 (0 left) Threaded execution slow: 3.435000 (0 left) fast: 3.568000 (0 left) Treaded, balanced execution: fast A: 0.973000 (0 left) fast C: 0.992000 (0 left) fast B: 1.013000 (0 left) Treaded, balanced execution, with quickstop: fast A: 0.977000 (0 left) fast C: 0.976000 (252 left) fast B: 0.978000 (17601 left) And now, same box, with the unfair GIL: D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py Sequential execution slow: 3.338000 (0 left) fast: 0.177000 (0 left) Threaded execution fast: 0.382000 (0 left) slow: 3.539000 (0 left) Treaded, balanced execution: fast A: 0.362000 (0 left) fast B: 0.464000 (0 left) fast C: 0.549000 (0 left) Treaded, balanced execution, with quickstop: fast B: 0.389000 (0 left) fast A: 0.447000 (240480 left) fast C: 0.360000 (613098 left) The two last cases are the interesting ones. With unfair scheduling, one thread takes almost twice as long to complete its 1000000 inserts than another. And if they are all stopped when the quickest one finishes, one thread has more than 600000 iterations to go. This is what I mean by fair/unfair scheduling. Cheers, Kristján p.s. Yes, I agree that time based GIL yielding is better. I intentionally didn't want to confuse the matter with that in 2.x. I wanted to address the other issues that are wrong. ---------- Added file: http://bugs.python.org/file16951/fair.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8299> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
