[RC5] Help with justification of running Dnet at work

Slawek sgp at telsatgp.com.pl
Fri Mar 17 10:49:58 EST 2006


Hello, Earl!
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> client.

 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



More information about the rc5 mailing list