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 -------
signature.asc
Description: Digital signature
