I checked in a change so that the client never overcommits
the CPUs by more than a fraction.
I.e. suppose a 4-CPU host.
If there's a GPU job that uses 0.2 CPUs, and a multithread
job with avg_ncpus=4, BOINC will run them together.
But it won't run the multithread job at the same time as a single-th
A 50% reduction means that the threads have large amounts of interthread
communication. A 25% reduction happens in the case where the threads are
started, and run to completion before any interthread communication occurs.
My statement was a floor for the performance hit, your statement is closer
t
On Wed, Aug 19, 2009 at 4:16 PM, Mark
Silberstein wrote:
> I claim ( actually not only me, there's been some research on that on large
> machines) that the slow down wouldn't be 25% but 50%, since the perf. of
> multithreaded application would be dominated of the perf. of the slowest
> thread. Cons
> The Multi threaded application would slowdown by 25%. (half of half of the
> CPUs are in use).
I claim ( actually not only me, there's been some research on that on large
machines) that the slow down wouldn't be 25% but 50%, since the perf. of
multithreaded application would be dominated of the
Ah. Missed that.
Sorry.
Eric
On Wed, Aug 19, 2009 at 12:06 PM, wrote:
> Actually, on a 4 CPU system Dave was talking about allowing 2 CPUs or 50%
> of the CPUs to overlap.
>
> The single threaded applications would each have a slowdown of 50% as they
> shared their single CPU 50/50 with the mu
Actually, on a 4 CPU system Dave was talking about allowing 2 CPUs or 50%
of the CPUs to overlap.
The single threaded applications would each have a slowdown of 50% as they
shared their single CPU 50/50 with the multi CPU task.
The Multi threaded application would slowdown by 25%. (half of half
On Wed, Aug 19, 2009 at 11:53 AM, Eric J
Korpela wrote:
> On Tue, Aug 18, 2009 at 4:34 PM, Mark
> Silberstein wrote:
>> But, by slowing down the
>> multithreaded app performance, it'd make it, I'd say, not really beneficial
>> to bother with multithreaded implementation.
>
> We're only talking abo
On Tue, Aug 18, 2009 at 4:34 PM, Mark
Silberstein wrote:
> But, by slowing down the
> multithreaded app performance, it'd make it, I'd say, not really beneficial
> to bother with multithreaded implementation.
We're only talking about an (NCPU-1)/NCPU slowdown (25% on a 4CPU
box). Besides, it's a
OK, in that case, add the light weight negotiation.
jm7
"Kamran Karimi"
To
Sent
The current method of communicating the number of threads to an MT app (via a
command line argument) is a simple solution that works.
However scheduling MT apps along with single-thread apps can always be
improved.
-Kamran
___
boinc_dev mailing list
Subject
Re: [boinc_dev] boinc_cvs Digest,
Vol 57, Issue 17
I believe (correct me if I am wrong please) that control information is
passed through a memory buffer. The request for specific CPU usage should
be passed through that. If it is optional, the project can play nice if it
can, but can ignore the request if it is very difficult. Even better would
Nicolás Alvarez wrote:
> The robustness principle is often misunderstood. The idea is that, given
> invalid input data, it shouldn't *crash*. Which doesn't mean it should behave
> as if the invalid data wasn't there.
>
> a...@home, for example, crashes with a segmentation fault if given --nthre
El Martes 18 Ago 2009 20:53:50 Lynn W. Taylor escribió:
> Nicolás Alvarez wrote:
> > El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
> >> No, I don't.
> >>
> >> It seems that you're arguing that the BOINC science applications should
> >> be fragile -- that they should expect a pristine and
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
>> No, I don't.
>>
>> It seems that you're arguing that the BOINC science applications should
>> be fragile -- that they should expect a pristine and unchanging
>> environment and not try to anticipate the inevitable
El Martes 18 Ago 2009 20:45:19 Lynn W. Taylor escribió:
> No, I don't.
>
> It seems that you're arguing that the BOINC science applications should
> be fragile -- that they should expect a pristine and unchanging
> environment and not try to anticipate the inevitable errors.
>
> I can't say it bett
No, I don't.
It seems that you're arguing that the BOINC science applications should
be fragile -- that they should expect a pristine and unchanging
environment and not try to anticipate the inevitable errors.
I can't say it better than Jon Postel: be conservative in what you do,
be liberal in
El Martes 18 Ago 2009 20:25:09 Lynn W. Taylor escribió:
> Which is more surprising to the end-user:
>
> - Crashing without warning (with our without notifying the project)?
>
> - Quietly handling a new parameter?
>
> Seems an easy choice.
What do you mean with crashing "without warning"? Would you
I'd like to question the whole idea of overcommitment.
When the app is multithreaded, but the internal implementation is not
data-parallel, i.e. it requires sync b/w threads and works by phases, the
slowdown will not be 1.5, but rather the performance of the slowest thread.
Typically with multith
Which is more surprising to the end-user:
- Crashing without warning (with our without notifying the project)?
- Quietly handling a new parameter?
Seems an easy choice.
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 20:13:19 Lynn W. Taylor escribió:
>> There is no reason to *not* correctly hand
El Martes 18 Ago 2009 20:13:19 Lynn W. Taylor escribió:
> There is no reason to *not* correctly handle "surprising" command line
> options.
There is no reason for the client to mess with data given by the project
before handing it to the app. What next, the client adding tags to XML input
files
In this kind of context, anything else is really sloppy programming.
There is no reason to *not* correctly handle "surprising" command line
options.
... especially if the projects can change them.
Nicolás Alvarez wrote:
> El Martes 18 Ago 2009 19:50:52 Kamran Karimi escribió:
>> This works fine
El Martes 18 Ago 2009 19:50:52 Kamran Karimi escribió:
> This works fine if the app treats such argument as optional. So BOINC apps
> should just ignore any command line options they don't understand. Projects
> can change the name of these arguments on the server, so a clash can be
> avoided.
Exa
-boun...@ssl.berkeley.edu on behalf of Nicolás Alvarez
Sent: Tue 8/18/2009 3:24 PM
To: boinc_dev@ssl.berkeley.edu
Subject: Re: [boinc_dev] boinc_cvs Digest, Vol 57, Issue 17
El Martes 18 Ago 2009 17:12:43 Eric J Korpela escribió:
> I have a couple thoughts. I agree that it's probably better to
El Martes 18 Ago 2009 17:12:43 Eric J Korpela escribió:
> I have a couple thoughts. I agree that it's probably better to
> overcommit in cases like this. Haven't been following the discussion
> closely, so maybe these have been suggested.
>
> 0) Multithreaded applications should all have a -num_
On Tue, Aug 18, 2009 at 1:33 PM, David Anderson wrote:
> I don't want to require apps to be able to dynamically change their
> parallelism.
> This would greatly increase the difficulty of developing multithread apps.
It depends to a large extent on the app. But I agree it shouldn't be
required.
I don't want to require apps to be able to dynamically change their parallelism.
This would greatly increase the difficulty of developing multithread apps.
Also I'd like to avoid running apps at different priorities.
That would make BOINC more obtrusive (real or perceived) than it is now.
I'm che
I have a couple thoughts. I agree that it's probably better to
overcommit in cases like this. Haven't been following the discussion
closely, so maybe these have been suggested.
0) Multithreaded applications should all have a -num_threads command
line option that sets the maximum number of threa
rkeley.edu
Subject
Re: [boinc_dev] boinc_cvs Digest,
Vol 57
Consider this case:
a 4-CPU system with a long high-priority 1-CPU job
and a bunch of 4-CPU jobs.
With your proposal,
it would run the 1-CPU job and the other 3 CPUs would be idle for a long time.
What's the right thing to do here?
If we run the 4-CPU jobs, we reduce the amount of CPU time that
th
This does not really quite fix the problem. Unfortunately, if you have an
N processor machine, a task that needs to run high priority, and an N
processor task that wants to run, then you will have N+1 processors
assigned unless N==1. A worse example would have N-1 tasks with deadline
pressure and
31 matches
Mail list logo
