[RC5] Help with justification of running Dnet at work
havoc at totalhavoc.net
Fri Mar 17 11:01:31 EST 2006
And how do you go about launching a second copy or dnet in a windows
From: rc5-bounces at lists.distributed.net
[mailto:rc5-bounces at lists.distributed.net] On Behalf Of Slawek
Sent: Friday, March 17, 2006 10:50 AM
To: D.net Discussion
Subject: Re: [RC5] Help with justification of running Dnet at work
You wrote to <rc5 at lists.distributed.net> on Fri, 17 Mar 2006 10:39:46 -0500:
ES> To answer you comments on Hyperthreading. All of my clients, even my
ES> dual-core and SMP boxes, run with D.net using a max of 1 Thread. I know
ES> there are performance issues when let D.net use the max number of ES>
threads or 1 thread per logical processor.
Unfortunatelly that's not the problem I'm talking about.
The problem is what happens if d.net client works with one thread and there
is a user application which works with another thread. Those are two threads
working at the same time and effectivelly performance of both of them
(including user's application) gets hurt.
I'm talking about launching d.net with two threads just to simulate the
problem - think of one d.net client's thread as user's application and the
other d.net client's thread as a simulationg of "normal" d.net client. Watch
how first d.net thread (simulating user's application) got hurt by starting
the other one (simulating "normal" single-thread d.net client).
With best regards, Slawek. E-mail: sgp at telsatgp.com.pl
ES> -----Original Message-----
ES> From: rc5-bounces at lists.distributed.net ES>
[mailto:rc5-bounces at lists.distributed.net] On Behalf Of Slawek ES> Sent:
Friday, March 17, 2006 9:33 AM ES> To: D.net Discussion ES> Subject: Re:
[RC5] Help with justification of running Dnet at work
ES> Hello, Earl!
ES> You wrote to "'D.net Discussion'" <rc5 at lists.distributed.net> on Fri,
ES> 17 Mar 2006 08:30:59 -0500:
ES>> Can anyone provide me with some help. Again, I am putting info ES>>
together on the project and how it runs. What would be great is an ES>>
explanation of the source code showing that is only runs when idle. I ES>>
have ES> ES> benchmarks run on my laptop but as you can see the instructor
doesn't ES> ES> believe them.
ES> Well, I'd say that it is true that d.net slows down at least some of
ES> the computers.
ES> That are a few reasons why:
ES> 1) Hyperthreaded processors. HT processors can execute more that one
ES> logical thread at the same time using one processor. Unfortunatelly ES>
doing that means processor has to divide it's processing power to two ES>
processes. This means: - all of the caches are split: including program ES>
memory cache, data memory cache and branch prediction cache ES> - processor
has to do some more operations to support multiple ES> processes running at
the same time ES> - and most important: processor has to split it's set of
virtual ES> registers to two processes, which means that code highly
optimised for ES> given processor - where the processor can optimise it's
execution speed ES> when run only one process at the time, it may be even
slower that 50% ES> of it's original speed when two processes are run at
the same time.
ES> The main problem here is that (at least when I've taken a look at it)
ES> HT processors doesn't support processes' priorities when talking about
ES> hyperthreading and it means that even if process with priority ES>
"realtime" is run together with a process with priority "idle" those ES>
processes would spare processor's resources evenly (yes, really, check ES>
it if you don't believe).
ES> 2) Operating systems frequently does different tasks in the background.
ES> On some OSs system's "dile" priority is lower that anything user ES>
program may use. If any process wants to constantly run at "idle"
ES> priority, such system tasks would not run at all. Such tasks are ES>
comonly used to clear freed memory, optimise disk cache usage and so on ES>
- and it really hurts if those tasks are not run at all.
ES> 3) Some operating systems doesn't strictly follow the rule "if there's
ES> any process with higher priority than this one, than skip this one and
ES> execute process with higher priority". Other scheduling rules (too ES>
complicated to explain here) can make a difference in good direction in ES>
normal circumstances, but if d.net client is run... it is run for some ES>
time even if higher priority tasks wants the processor...
ES> 4) Should your system use dynamic speed fans, it would work lauder when
ES> you launch d.net client. If your fan aren't able to cool the system at
ES> 100% usage it's possible your processor (or other chips) are working
ES> with throttled down clock after some time of heating up using d.net ES>
ES> Those problems may apply to you or not.
ES> You may quickly set-up a test using d.net client only (it would not
ES> catch all of mentioned problems):
ES> 1) Set up one d.net client to run constantly with normal priority (like
ES> normal program do) and measure it's performance.
ES> 2) Launch second copy of d.net client while first one is still running
ES> and check if first's client's performance decreased. If it did - you've
ES> just decreased performance of normal priority program.
ES> With best regards, Slawek. E-mail: sgp at telsatgp.com.pl
rc5 mailing list
rc5 at lists.distributed.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3109 bytes
Desc: not available
Url : http://lists.distributed.net/pipermail/rc5/attachments/20060317/c630dc92/smime-0001.bin
More information about the rc5