Well said. It's clearly a big improvement, and simple. Works well on all the machines I have available.
-Marshall On Sep 24, 7:04 pm, Dan Drake <[email protected]> wrote: > On Thu, 24 Sep 2009 at 08:32AM -0700, John H Palmieri wrote: > > So, back to the original question: for parallel testing, can we set > > the number of threads to be the output from multiprocessing.cpu_count > > ()? On t2, is it actually *bad* to use 128 threads, or is it just > > about the same as using 16? (The point was to have a non-idiotic way > > of setting the number of threads, and I'm trying to figure out if > > cpu_count() qualifies or if it needs refinement, or perhaps another > > approach altogether.) > > Here's one way to look at this: right now, as shipped, "make ptest" does > the wrong thing on 99+ percent of the machines that Sage gets used on, > because it uses 15 threads, and how many machines on which Sage gets > used can handle that well? > > With the patch (#6283), "make ptest" does the *right* thing on 99+ > percent of machines, and it's very easy to override it if necessary. > > I'm thinking that here, the perfect is the enemy of the good. We can > revisit this problem when sage-support is flooded with people > overloading their Sun machines when they run "make ptest". :) > > Dan > > -- > --- Dan Drake > ----- http://mathsci.kaist.ac.kr/~drake --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
