Archived from groups: alt.comp.periphs.mainboard.asus (
More info?)
In a word, yes, but read below.
Here's a waffle that covers many of the issues:
Ordinary Programs:
A standard user-world program usually has only 1 thread. CPU's execute
threads - threads are what are scheduled to run. Some standard user programs
are written as single threaded, but under the hood do use multiple threading
unbeknownst to the programmer EG some client database stuff. If a program
has only 1 thread then it can't use more than 1 CPU.
You can see how many threads a process has by starting task manager - Ctrl
Alt Del, Task Manager and on the processes tab, on the view menu, click
Select Columns and Tick Thread Count. Most processes have 2 or 3 threads,
but usually the 2nd and 3rd threads are little to do with the programmer. IE
some underlying subystem has started the thread hidden from the programmer
because they are using database or network functions.
Programs "Yield":
Most programs trundle along and for example need to read or write a disc
file (or network, cd, dvd user, etc). So they ask the OS to do a read or
write and *stall* waiting for the IO to complete. This is one of the usual
ways by which a windows program "yields" - gives up CPU use.
The OS can run multiple programs - by time slicing, and on a dual CPU system
by having 2 CPU's to run 2 threads on at the same time. So in this scenario
2 programs can be active at the same time - both can stall waiting for IO
freeing the CPU to idle or something else. 1 Program that does a lot of IO
can bring a dual cpu system to its knees - these programs are rare (EG
partition format).
Async IO
asynchronous: this is where a program asks for say a disc read to be done
and asks to be informed when the IO is finished, but in the mean time
continues processing rather than stalling. Increasingly common practice - it
used to be rare to find async IO outside a server class app.
The OS is designed to accept IO requests asynchronously - all IO's are run
internally async - and from multiple threads at the same time (think about
32 processors with 32 active threads & dozens ready to run). So for each
disc drive there can be a queue of IO's form. This is where NCQ abilities on
SATA drives kick in - the IO's can be serviced by each drive in the most
efficient order for each drive by that drive.
Disc Bound:
So, if you are running 2 apps each with 1 active thread, but on a system
without NCQ your system *may* not go too well because they (could be /) are
competing for the 1 drive. If the drive had NCQ it may be marginally better
(a few percent). If you had raid, it may be better again.
Multithreading:
Server class apps tend to be strongly multithreaded (EG 10, 20 or more
threads), use asynch IO (IO completion ports the best form in Windows), have
multiple user-request-process threads, use their own memory cache and so on
to acheive performance - they tend to eat RAM to reduce IO's to serve
multiple users and thrive on multiple CPU's. The enemy of server class apps
is IO - IO's have to be coded to be async to free CPU's / processes (IE
threads) to do work for other users or go idle waiting for IO's to finish.
Process Bound:
A process bound app (EG Prime95) will consume all CPU it is given and not
stall. Sometimes the Algorithms in such processes can run in parallel on
split input / output data streams (EG same files, alternating blocks of
data) and so are very good contenders for multithreading...
Process intensive apps that naturally support multithreading are the best to
make 'quick' use of dual CPU's - I can see that many games and encoding
algorithmns fall into this class. However converting any standard program to
a multithreaded program is not trivial. It is a programmers job to make
these changes... Some process intensive tasks just do not lend themselves to
this.
____
If you want the very best user experience, then IMHO Dual CPU's are the bees
knees. I have not yet had the opportunity to use a dual core system (soon),
but expect that to be just as *smooth* as dual CPU. You get a really smoothe
user experience with dual CPU's!
If you are a single program at a time user and that program does not lend
itself to multithreading, then you will get very little benefit.
If the only thing that stops you from doing more faster is the
responsiveness of your system, you run many apps at the same time (and they
are active at the same time) then GET ONE NOW (particularly if you are self
employed, charge by the hour etc. - you will be able to charge 2 hours per
hour
!
If you use apps that either are or will be soon multithreaded then """""".
HTH.
"James" <anonymous@nowhere.no> wrote in message
news:vOqdnbqDFN91SibfRVn-3w@bright.net...
> Mark A wrote:
>
>> It is not just a question of power. It is also a question of which
>> software can take advantage of two processors at once. Right now, there
>> are not many desktop applications that can do that, and frankly, I don't
>> think that will change too much in the near future. The dual core CPU's
>> are better suited to servers where multiple CPU intensive applications
>> are running at one time.
>
> Are you absolutely positive that the dual core CPUs are only an advantage
> to applications that are designed to use them? If so, then the extra CPU
> core just sits there and does nothing otherwise?
>
> James
>
Facebook
Twitter
Instagram