[Scip] Timing issues

Thorsten Koch koch at zib.de
Sun Jul 14 15:59:18 MEST 2013


Dear Giacomo,

if they system has 4 cpus it has a NUMA memory architecture.
https://en.wikipedia.org/wiki/Non-Uniform_Memory_Access

It is very difficult to get reliable benchmarking out
of such a machine. We did some experiments with a similar
system and it is very hard.

First you have to tie processes to cores.
But this is not enough. You also have to allocated the
"local" memory of he particular CPU. This is not easily
done.

> 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?

Can happen.

Best regards,
Thorsten




Am 14.07.2013 15:48, schrieb 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? ;)
>>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
> 

-- 
The important thing is not to stop questioning.
Curiosity has its own reason for existing.          -- Albert Einstein
______________________________________________________________________
Dr. Thorsten Koch / Konrad-Zuse-Zentrum für Informationstechnik Berlin
www.zib.de/koch  /          Takustraße 7, 14195 Berlin-Dahlem, Germany
koch at zib.de     /                     Phone +49-30-84185-213, Fax -269
_______________/  DFG Research Center "Matheon"  http://www.matheon.de

Kooperativer Bibliotheksverbund Berlin Brandenburg  http://www.kobv.de
digiS: Servicestelle Digitalisierung Berlin
http://www.servicestelle-digitalisierung.de
______________________________________________________________________


More information about the Scip mailing list