[Scip] system vs. user time

[James Cussens]

Thanks Michael and Timo,

I think I have got to the bottom of this and thought I would share it, 
since it may be useful for others.

This strange distribution of time between user and system time was 
produced running a 32-bit kernel on a 64-bit machine. Switching to using 
the 64-bit kernel made the problem go away.

James


On 03/03/11 00:08, michael.winkler at zib.de wrote:
> Hi James,
>
> I wanted to add that if the reason is really time measurement that you
> could also try to change it from cpu to wall clock time by changing the
> parameter set/timing/clocktype to 2. But maybe it's another reason,
> because your numbers look very strange. Was there no endless loop? Do you
> have a SCIP statistic on your run where you can see where the time was
> spent?
> If you don't know already, if you have valgrind you could determine
> exactly were the time is spend by first compiling your programm with the
> "-g" option and run it by
> "valgrind -v --tool=callgrind your_executable_with_options_and_parameters".
> This will create an file "callgrind.out.PID" (PID process id) and you can
> look at all your lines of code where exactly the time is spent by open the
> output file with "kcachegrind".
>
> Best, Michael
>
>> Hi James.
>>
>> A quick, wild guess: If the enumeration in your sub-SCIP tree is very fast
>> (e.g. because you do not solve LPs there), it might be that measuring the
>> time already takes most of it. I experienced this once with a highly
>> symmetric MIP.
>> In this case, you might want to try to disable time measuring in SCIP
>> completely, by setting the Boolean parameter timing/enabled to FALSE. The
>> remedy of this is obvious: you cannot easily stop your sub-SCIP by setting
>> a time limit but you need to set another limit, e.g. number of nodes or an
>> external limit from the Unix shell.
>>
>> Cheers,
>> Timo
>>
>>
>>> I've just used SCIP to solve a large problem. I used UNIX time to time
>>> it, which gave me this result:
>>>
>>> 64.85user 66315.90system 19:24:06elapsed 33%CPU (0avgtext+0avgdata
>>> 1968896maxresident)k
>>>
>>> It's notable that virtually all the time is spent on system calls. It
>>> may well be that nothing is "wrong" but I would be interested to know
>>> (1) if such behaviour is common and (2) if there is anything worth
>>> trying to reduce the time spent there.
>>>
>>> I'm using a subscip to find good cutting planes - most of the time is
>>> spent doing this. The subscip has only binary variables and "and"
>>> constraints and uses depth-first search. My guess is that much time is
>>> spent allocating memory for the tree, but I haven't investigated this
>>> properly yet.
>>>
>>> James
>>>
>>> --
>>> James Cussens	         ---- NEW CONTACT DETAILS ----
>>> Dept of Computer Science&
>>> York Centre for Complex Systems Analysis             jc at cs.york.ac.uk
>>> Room 326, The Hub, Deramore Lane              Tel  +44 (0)1904 325371
>>> University of York                            Fax  +44 (0)1904 500159
>>> York YO10 5GE, UK                        http://www.cs.york.ac.uk/~jc
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> http://listserv.zib.de/mailman/listinfo/scip
>>>
>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> http://listserv.zib.de/mailman/listinfo/scip
>>
>

-- 
James Cussens	         ---- NEW CONTACT DETAILS ----
Dept of Computer Science &
York Centre for Complex Systems Analysis             jc at cs.york.ac.uk
Room 326, The Hub, Deramore Lane              Tel  +44 (0)1904 325371
University of York                            Fax  +44 (0)1904 500159
York YO10 5GE, UK                        http://www.cs.york.ac.uk/~jc