Antoine Pitrou <pit...@free.fr> added the comment: Kristjan,
> Maybe the state of this discussion is my fault for not being clear enough. It's quite a bit simpler. The first 2.7 beta has been released and there's IMO no way such patches will be accepted. It doesn't seem to be a pressing enough issue to be considered a real bug. As you said yourself, most people actually aren't really affected, or not enough. > CPU threads are scheduled fairly on windows, and incredibly unfairly > on pthreads. pthreads doesn't schedule anything. The kernel does. I'm sure that on non-tiny periods (>= 5s) they are scheduled quite fairly. It's just that switching occurs less often and less regularly than you'd might hope. > Antoine, I understand that your point about do_yield, yet the results > for 3 seconds without it are telling on their own, and worthy of being > studied, which is why I suggested disabling it. As I said, they will render 2.x results completely wrong (at least under Linux). > Also, I think you will find that he imbalance in the throughput of the > threads won't go away even after 30 seconds. I'm actually not really interested in confirming this, but as I said there's no reason to think that the Linux kernel does a bad job. (the one reputed to do a bad job at scheduling, especially for desktop environments, is the Windows kernel) > I've improved my patch some more. I'll upload it soon. If you are interested in taking it further, I would recommend publishing your patch (and prebuilt binaries, if you care) somewhere else as well, because as I said there's probably no way it gets integrated during what remains of the 2.x timeline. Of course, other developers might disagree with me, in which case your patch /can/ be integrated. But I don't see a lot of interest showing honestly. > We just need to have an order of magnitude thing there. Duration of opcodes can vary by more than an order of magnitude. ccbench includes such testing by the way (different CPU-bound workloads) ---------- _______________________________________ 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
