Checkpoints for multithread projects

[Pepo]

Well, you can call me ignorant, but... both BOINC Manager and BoincTasks do say in tandem (in the task's Properties window "CPU time at last checkpoint". Thus, on a 8 core rig it HAVE TO flow (up to) 8 times faster than the wall-clock elapsed time. Doesn't it??

Cpu time is the time of each core. So 12 seconds wallclock gives a 1*12=12 at one core and 8*12=96 on 8 cores cpu time.

Of "each core" == of "any of used cores", or "all used cores"?
CPU time is exactly the time used by a process - a sum through all used cores. So yes, 12 seconds wallclock can give up to 8*12=96 sec CPU time on 8 cores. Exactly 8 times too much.

Or have I missed something

[jjwhalen]

Well, you can call me ignorant, but... both BOINC Manager and BoincTasks do say in tandem (in the task's Properties window "CPU time at last checkpoint". Thus, on a 8 core rig it HAVE TO flow (up to) 8 times faster than the wall-clock elapsed time. Doesn't it??

Cpu time is the time of each core. So 12 seconds wallclock gives a 1*12=12 at one core and 8*12=96 on 8 cores cpu time.

Minus (of course) the time n core(s) are multitasked away to something else, like servicing a GPU

[Pepo]

Well, you can call me ignorant, but... both BOINC Manager and BoincTasks do say in tandem (in the task's Properties window "CPU time at last checkpoint". Thus, on a 8 core rig it HAVE TO flow (up to) 8 times faster than the wall-clock elapsed time. Doesn't it??

Cpu time is the time of each core. So 12 seconds wallclock gives a 1*12=12 at one core and 8*12=96 on 8 cores cpu time.

Minus (of course) the time n core(s) are multitasked away to something else, like servicing a GPU

Or running the whole OS and BoincTasks etc.
Sure, therefore I wrote "up to".

[Pepo]

After some time, I've again an Aqua MT task, and ... do not understand what I see: the "used CPU time" and "CPU time used since the last checkpoint" get divided by the number of used threads. (BT 0.78)

Why this?

[fred]

After some time, I've again an Aqua MT task, and ... do not understand what I see: the "used CPU time" and "CPU time used since the last checkpoint" get divided by the number of used threads. (BT 0.78)

Why this?

Last time I tested this, the times where * number of threads, so to get the real time it needs to be divided by the nr of threads.
But it may be a matter of taste. I find it confusing when a project ran 1 hour and states it ran 8 hours (8 threads).

[Pepo]

...it may be a matter of taste.

...which is off course true.

After some time, I've again an Aqua MT task, and ... do not understand what I see: the "used CPU time" and "CPU time used since the last checkpoint" get divided by the number of used threads. (BT 0.78)
Why this?

Last time I tested this, the times where * number of threads, so to get the real time it needs to be divided by the nr of threads.

no time is " * number of threads", it is simply a measured value "used CPU time"...

I find it confusing when a project ran 1 hour and states it ran 8 hours (8 threads).

I guess the "Elapsed time" part is there to show the elapsed time, a.k.a. "how long did the project run".
Why should the "used CPU time" part show the same value as the "Elapsed time" part? (Except the cases of throttling and busy system.)
There is also the "CPU %" indicator (0-100%) showing how effectively did the project utilize its granted resources.
Will there actually be any difference in "used CPU time" between an 8.00C Aqua and 1.00C Rosetta?

[fred]

...it may be a matter of taste.

...which is off course true.

Is there somebody else with an opinion?

[Pepo]

Another argument in my favor ():
Imagine BOINC will finally manage to run tasks with variable number of threads - varying during their run. BT would have to divide each CPU time quantum with the most recently observed thread count?

[jjwhalen]

...it may be a matter of taste.

...which is off course true.

Is there somebody else with an opinion?

I'll weigh in on this: I'm with Pepo - the indicated (CPU time) of multicore/multithreaded tasks should preferably show the aggregate of all cores summed together, as was done in earlier versions of BT.  If for no other reason, then to be consistent with the results that appear in AQUA's database, e.g.,

9 Oct 2010 10:22:07 UTC   12 Oct 2010 1:24:19 UTC   Completed and validated   51,639.81   172,210.50   13,577.28   D-Wave's Iterative QUANtum Algorithms : Multi-Threaded v1.14 (mt1)

[fred]

Another argument in my favor ():
Imagine BOINC will finally manage to run tasks with variable number of threads - varying during their run. BT would have to divide each CPU time quantum with the most recently observed thread count?

Ok I'll change it back to what it was.