Le samedi 28 avril 2012 à 15:03 -0600, Aaron Meurer a écrit : > On Sat, Apr 28, 2012 at 5:38 AM, Joachim Durchholz <j...@durchholz.org> wrote: > > Am 27.04.2012 23:57, schrieb Aaron Meurer: > > > > > >> Yeah, they don't really have any of that implemented. You'll have to > >> use your built-in OS services to reduce the priority, and you'll have > >> to run multiple instances of tox to do things in parallel. > > > > > > Urk. That is a showstopper for some of the scheduling things I was having in > > mind. > > Such as increasing granularity so more CPU cores can be put to good use. > > (I'm having a four-core machine here, and I have a server with eight at my > > disposal. Having to schedule large chunks like bin/test, bin/doctest and > > bin/test --slow in a separate process means that towards the end, only one > > core will do useful work.) > > Maybe you could look at using the IPython parallel framework in our > tests. Ondrej played with this a while ago, but that was with the old > framework. The idea is to run each test independently, and in > parallel. Back when we tested it before, there was a speedup. The > speedup was along the lines of n - 1/2, where n is the number of cores > (the -1/2 was because one core was used for the controller). > They've completely rewritten their parallel engine, so this will have > to be redone, but it might be worth trying if you want this.
pytest does that (with the xdist plugin). And it seems simple to set it up for multiple envs in tox: http://tox.readthedocs.org/en/latest/example/pytest.html#using-multiple-cpus-for-test-runs > >>> Hm. That leads me to another question: > >>> What were the reasons that we forked pytest for our own purposes? > >>> Do these reasons still hold, or should we now go back to using pytest? > >>> The issue was mentioned on the list, but I don't recall details. > >> > >> > >> I think Ondrej is the only one who can answer that, as everyone else > >> was not around when it happened. And Ronan recently submitted a pull > >> request that worked on making py.test work again, so he can probably > >> comment on the current state of things. Well, py.test works (almost) - I use it all the time. There are a few details to work out, but there doesn't seem to be any real obstacle towards making it the only supported test suite. Currently, I think that the main difficulty is the need to simultaneously support bin/test. -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
