howto: Dual CPU or Dual Core on Windows

[LaKing@D250.hu]

Some users might find this information usefull. Especially users with configs like: Dual Xeon or Opteron, AMD X2, and other dual CPU systems, or systems with several processors.

R5 seems to run in a single thread on a single CPU. However, we may want to use all power we can get, so here is a way how to do that:

Open Reaktor twice. Press Ctrl+Alt+Del in the task manager - processes, Right Click on Reaktor5.exe set CPU affinity, and assign only a single CPU to that thrad. For the second thread the second processor .. and so on.

Midi is going to both apps, and u can select wich R5 thread uses wich soundcard output.

My Case:
I have a Dual Xeon 3.2Ghz and a notebook as sequencer.
The Xeon PC has also 2 Monitors (DVI), so i start Reaktor twice and put each fullscreen on a monitor. I set the MOTU828 Soundcard outputs and use Midi Over Lan. After setting CPU affinity, each R5 runs on his own processor.

I suggest to turn Hyperthreading off, on all systems.


cheers

[penaten creme]

thx for this tip.
i am hoping NI is faster with their update than hp&co with the new amd-double-mobiles, but maybe i could need your tip

[LaKing@D250.hu]

In general, a software written for a single cpu, needs almost completley to be rewritten from scratch for multiple processors.
I think we cant expect that from NI, or if they do such an update (what they should) they will release it as reaktor 6 or hatever. (Ye, but those updates should be free)

[ernest.meyer]

There are a couple of utilities around to provide permanent cpu assignment. Microsoft provides an undocumented DOS utility called imagecfg.exe, here is a page describing it:

http://www.robpol86.com/Pages/imagecfg.php

Of course this means you need to know how to use DOS, and acutally alters the reaktor binary.

I think on anandatech there is a utility called TaskAssign.exe but it requites an additonal process running in the background.

[ernest.meyer]

Now I tried it--and with affinity set I'm not sure actual cpu usage goes down. Any other experiences?

[BobTheDog]

I am a litlle confused why not just run two instances of Reaktor, why are you bothering to set affinity?

Cheers

Andy

[ernest.meyer]

Im not sure running two instances actually forces each intance onto separate cpus. If the applicsation is not multiprocessor aware it can start multiple threads which I'm lead to believe may run on either cpu, but only one ever runs at one time even if there is another on the other cpu.Theoretically, interprocessor communication introduces overhead in such situations.

[ernest.meyer]

Now an interesting phenonemon: today I got Kontakt up on a AMD X2 3800 machine and it uses ***alot*** less cpu than on a pentium 4 2.6ghz. Also it is dual processor aware, assigning alternate voices to each cpu for polyphonic paths. Monophonic logic runs on just one cpu and is the limiter.

Reaktor on the other hand doesnt know there is a second cpu at all so the cpu meter registers exactly double what is reported for the process (in the task manager process list). Also it appears AMD processors could be using more of an average cpu usage when reporting to windows how loaded it is, whereas Intel processors appear to report closer to minimal usage.

[BobTheDog]

emeyer wrote: Im not sure running two instances actually forces each intance onto separate cpus. If the applicsation is not multiprocessor aware it can start multiple threads which I'm lead to believe may run on either cpu, but only one ever runs at one time even if there is another on the other cpu.Theoretically, interprocessor communication introduces overhead in such situations.

Running two instances will not force them onto seperate processors but why is this important? The only real issue is cache usage and on a busy system even if a thread is running on one processor/core you can not be guaranteed that your cached data will still be available in your next timeslice.

Also you can introduce problems by setting the afinity to a single processor as the scheduler can now only place that thread on that processor even if the processor is very busy and the other processor isnt.

I think you may have made a typeing mistake with "If the applicsation is not multiprocessor aware it can start multiple threads " I think your probably meant "If the application is multiprocessor aware it can start multiple threads ".

If you have two processors or cores then two threads of execution can be running at exactly the same time. If you write a program with two threads that are doing heavy work each can run at exactly the same time and use 100% of a processor/core, this gives you 200% cpu utilisation from a single process.

A nice simple overview of the NT scheduler can be found at http://www.808multimedia.com/winnt/kernel.htm
and a nice simulator type thingy at http://www.808multimedia.com/winnt/simulator.htm

Cheers

Andy

[ernest.meyer]

HI bobthedog

Actually this is correct: if the application is not multiprocessor aware, then it can start multiple threads or processes, each of which Windows XP may assign arbitrarily to either processor.

Regarding cache usage: it can have very negative effect on cpu usage if the threads or processes are affecting each other's data. The amount depnds whether the architecutre uses write through or write back coheriency mechanisms.

In AMD X2 there are separate caches but they are 'tightly coupled' to prevent 'cache incoherency'. That is meant to mean this: if one cpu writes to a memory address in the same memory space as the other processor, then the same data is 'written through' to the storage space used by the cache for the second cpu on the chip. This also means if the 2nd cpu is currently processing data at that address, the 2nd cpu's pipeline is meant to be invalidated and the cpu reprocesses the data to use the new value. However I dont know if AMD X2 fully implements a complete multiprocessor write-through architecture.

Typically this mechanism still involves latency as pipeline depth increases, and so actual latency is inconsistent across cpu families. Software is therefore advised not to rely on write-though invalidation anyway (unlike Cray supercomputers where the exact latency is always known). Instead it is meant to use things like 'semaphores', 'mutexes', and 'condvars' which are software programming techniques to maintain data coherency across concureent processes. But whatever, this is only required for data WRITEs. Data READs dont cause cache incoherency and so require no such cross-checking.

Dual processor systems (to contrast with 'multiprocessor cores') instead use what is called cache "write back" (rather than "write through") to maintain cache coherenecy. This means: when one cpu writes data to cache, the data is just written back to main memory. The second cpu is meant to detect their has been this writeback by monitoring dma channels. The 2nd cpu is then meant to copy the data from main memory to its own cache. This is obviously much slower than using write-though with tightly-coupled caches.

I'm told dual-Xeon processors are significantly faster than two separate pentiums because they use a second-level 'shared' cache between the two cpus, between the "first levbel onchip cache and main memory. This means you can get a huge power-hungry cpu on each separate cpu chip and then use hybrid interconnect to a common shared multiport memory which can provide better performance, because it can be much bigger, but it is also very expensive and moreover gets very hot and needs large noisy fans.

Dual-core chips, because both cpus and cache are in the same chip, are cheaper to build. It is a point of view really to say whether there is one or two caches, when you get into the reality of it, it is much more complicated than that. For example the caches could share rows and have separate columns; they may or may not have separate memory management units for virtual-to-physical translation; and they may have different line sizes. Because the storage areas for each chip are translated from physical to virtual memory, and alot of other interconnect is required, the actual physical wiring between the cache and cpu is not really the deciding factor in whether the cache is considered "split" or "unified".

Sun reasearchers have believed that line size is the most significant characteristic with respect to actual performance. Line size is the number of bits in one "data line" which is invalidated upon data write. For example if you have a 128-bit line, then reading or writing just one bit to that line means all 128 bits need to be refreshed from/to main memory. Each of these cache lines has one "tag" which indicates its validity and a direct linear physical/virtual translation mapping for that set of consecutive addresses.

Now with dual cpus it gets much more complicated because there are multiple ways to divide up the rows, columns, tags, and also, how much gets invalidated if one cpu writes to the other cpu's memory space. AMD had coined a thing called "hypertransport" technology and from what I've read about it so far I can't be sure how it actually works, but generally from a hardware design standpoint, the most important thing about caches tends to be balancing the line size with likelihood of data invalidation, main memory access speed, and the amount of time it takes to calcuation a virtual->physical address.

- Ernest

[BobTheDog]

Hi Ernest

emeyer wrote: HI bobthedog Actually this is correct: if the application is not multiprocessor aware, then it can start multiple threads or processes, each of which Windows XP may assign arbitrarily to either processor.

Sorry what do you meen by multi-processor aware then? Are you talking about multi-process awareness? I was taking the stand that any multi-threaded process was multi-processor aware (as long as it is written correctly to work on more than one processor by protecting shared resources with locks of some kind).

What you say about cache coherency and pipelines is quite correct but as caches are pretty small things when running audio processing code which deals with large amount of memory access; the cache I would think is is pretty limited and really only usefull for the threads timeslice, so being placed on another processor for your next timeslice is not much of an issue.

I work developing large smp systems usually from 32 to 512 processors, (the largest machine the company I work for has made is a 10240 processor machine) and to be quite honest in most cases we ignore the onboard chip cache or shared cache completely, the machine is left to handle everything as best it can. Of course when it comes to benchmarking we look at things differently

Cheers

Andy

[ernest.meyer]

It depnds if you are running the same data through each processor. If not the cache can be ignored for all intents and purposes. Of course audio has to be mixed down to a small number of streams.