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