[Scip] Timing issues

[Giacomo Nannicini]

Thanks Stefano. I understand that kind of variance when you are
running multiple cores on the same CPU, and your numbers are in line
with my experience.
But here I'm talking about 4 distinct CPUs (each one with 8 cores -
this should be irrelevant) and running 4 single-threaded jobs. I would
expect the jobs to be scheduled on distinct CPUs, so that they would
not be competing for L3 cache. Unless the Linux kernel 2.6 scheduler
assigns two jobs to the same CPU even if there are free CPUs
available?

Giacomo

P.S.: beer: possibly ;-)

On Sun, Jul 14, 2013 at 9:17 PM, Stefano Coniglio
<stefano.coniglio at gmail.com> wrote:
> Hey Giacomo (and SCIPing people),
>
> you know, I guess that's a reasonable behavior, kind of solver independent I
> believe. Some months ago I run some experiments precisely to get a grip on
> "how unstable computing times become when forgetting that an X core machine
> differs from X independent ones".
>
> My setup was: 27 miplib3 instances (solved in under a minute --I needed
> quick results), CPLEX 12.x, a 4 core machine (with both TurboBoost and
> HyperThreading disabled). I solved each instance 100 times using either 1,
> 2, 3, or 4 cores at the same time, then averaged everything. I have some
> tabled data --but I guess that might be too much for the mailing list.
>
> The results I had are, overall, that the average, over all instances, of the
> maximum solving time using 4 cores can be up to 32% larger than the average
> solving time using a single core. My figures are, roughly, +22% for 2 cores,
> +24% for 3, +32% for 4.
>
> That +40% (200 over 500) seems kind of inline to me, although I have never
> run experiments with larger instances with higher solution times --and I'm
> interested in the outcome there.
>
> To me, the tagline is: "regardless of how high X is, an X core machine
> should run a single process a time, as much as possible)".
>
> -Stefano
>
> PS: did this earn me any beers? ;)
>