On 4/15/2012 at 1:35 PM, Dawid Weiss wrote: > > - tests.threadspercpu seems to behave like a maximum JVM > > count rather a core multiplier - is that right? If so, > > maybe this param should be renamed? > > You're right, I don't know how it came to be threadspercpu... > it is actually the number of forked JVMs -- it should be > "tests.jvms" (sounds good?).
+1 > There is no reliable way to tell if a cpu is running in > hyperthreading mode or with real threads (multicpu > motherboards, for example) and from my experiments it seems > that going into hyperthreading does not speed up things > (possibly because Java has its own concurrent threads anyway > so everything's saturated already). On my machine (Win7 64-bit, 4 real cores + Hyperthreading -> 8 "cores"), leaving tests.threadspercu at the default "auto" maxes out at 4 JVMs. Running all tests from the top level, the sweet spot for me seems to be tests.threadspercpu=5 - this is about 8-10% faster than "auto". tests.threadspercpu=6 is also faster than "auto", but only by about 3-4%. (I have only done a couple trials, and this is on a workstation where I'm doing other stuff...) > > Would you like me to take a crack at modifying the RunningTests wiki page? > > Oh, this would be awesome if you could. I am wiki challenged... OK, I'll work on it later today. Steve
