|
|
View Full Version : multiple CPU Q
vslayer 02-09-06, 04:28 AM hypothetically: if i was to spend 6000EU on a computer with 4x opterons in it, would that have 4x the processing power of individual computers, or would it jsut allow me to run 4 tasks at maximum efficiency. and what operating systems would support this setup?
leopold99 02-09-06, 04:39 AM hypothetically: if i was to spend 6000EU on a computer with 4x opterons in it, would that have 4x the processing power of individual computers, or would it jsut allow me to run 4 tasks at maximum efficiency. and what operating systems would support this setup?
it would allow you 4 times the throughput of a single processor
i have no idea what kind of software you would need
windows is a pre-emptive multi-tasking operating system
i don't think that is what you want is it?
like i said, i don't know what kind of os you would need
grazzhoppa 02-09-06, 05:24 AM hypothetically: if i was to spend 6000EU on a computer with 4x opterons in it, would that have 4x the processing power of individual computers, or would it jsut allow me to run 4 tasks at maximum efficiency. and what operating systems would support this setup?
The second one: it would just allow you to run 4 tasks at maximum efficiency.
Unless you were running software meant to use 2 or more CPUs at the same time. From what I've seen, these are "Business" or "Enterprise" level apps that will cost you $1000+ (600+ euros?).
Windows would support all those cpus. But someone out there could probably tell you how some Linux version can do it better...
People that get a computer like that usually have a specific task they need to do. Like running a server shared by more than 1 main application, or a heavy loaded server running one main app that can use 4 CPUs at a time.
The truth is, you won't even get maximum efficiency. When a bus-based shared memory multiprocessors (as opposed to something like a cluster) gets above 2 CPUs, there is typically not enough memory bandwidth to handle all the CPU's peak usage. It can handle the average bandwidth needs, but not peak.
Given that I've said that. The number one thing you'll notice with a multiprocessor is how snappy it feels! If you're like me and you multitask a lot, switching between applications a great deal, you know its sometimes slower than you'd like. Sometimes you don't even realize there is that second or so delay between switching where the OS must do a context switch, swap out some pages (which brings me to my next point get at least 1-2 GB of RAM or you're wasting your money), etc. With the multiprocessor, there is no switch, it can keep 4 processes running at all times. Trust me when I say that makes it feel MUCH more responsive.
Also, if you do anything computationally intensive, such as encoding, complex calculations, etc. Many of those applications are now being written to handle multiple CPUs/cores. So applications are catching up.
-AntonK
river-wind 02-09-06, 12:16 PM IIRC, Windows XP home only works with one CPU, and XP Pro can currently only handle 2 CPUs. Windows Server can utilize more (up to 16?).
So for desktop applications, yes, linux would be better.
Either that or FreeBSD, or Solaris x86
Multi-CPU programming has been around, as it has been common in higher-end server/mainframes for years. When most PowerMacs became dual-proc about 6 years ago, Mac application writers had to learn threaded-code techniques to access that power. Now that dual-core and multi-proc systems are more common in the x86 Windows world, Windows programmers get to learn this stuff. :D
As AntonK mentions, though, you have real-world limitations in the system that will reduce your performance gains from adding more CPUs. There is a lot of overhead in keeping the data in sync, so that one CPU doesn't overwrite the numbers produced by another CPU. Code can be executed out of order (as coded), but needs to be put back together at some point so that dependant code can be dealt with.
For example:
a=1
b=2
c=a+b
The code above can be automatically divided up to run in parallel on multiple CPUs or CPU cores, but only to a certain extent. The assignments for ‘a’ and ‘b’ (lines 1 and 2) don't rely on any outside data, so each line can be calculated by itself, in any order. However, the assignment for 'c' requires that the 'a' and 'b' assignments have already occurred. So the systems needs to be able to do the following
1)figure out what code can be run out of order
2)how many threads can be run in parallel in the system (you can have more than one thread per CPU core * number of cores)
3)how to schedule the dependent code to run only after the other code is done (no matter which proc handled it).
All this coherency overhead and scheduling logic increases in complexity as you add more procs. So in the best situations, roughly, 1 CPU=100% performance in real world applications, 2 CPU=185% performance, 4 CPUs=333% performance.
Now, some of this is supposed to be handled in the code by the applications programmer; working the code to most efficiently break up non-serial execution blocks into threads that can run mostly independent of each other. But often, this isn’t the case. Many times, the easy way out is taken by applications designers, and code is threaded only so much as different logical sections of the code can be run in parallel (as opposed to hinting for line-by-line distrobution execution, as above). For instance, games are hard to run in parallel, as they are heavily user dependant and inner-dependant. Graphics depend on physics and user input, physics depends on AI, sound depends on the event system. But you can run the drawing routines apart from user input threads, and you can run the physics thread one frame behind everything else in its own thread, and still provide good-enough user feedback.
So instead of worrying about detailed threaded design to maximize parallel execution efficiency, games often split general tasks amongst the available processors, and then let each bit run pretty much in order, regularly syncing data between the threads.
Where multiple CPUs in a desktop or laptop really shine is where AntonK mentioned – Snappiness, otherwise known as user-response time. If the system is chugging along, and you click on an icon, a single CPU has to switch contexts, move things out of cache or even RAM, figure out what you want, and respond – all while still running the background task. This can sometimes take a while.
On a multi-CPU system, one CPU will be much more easily freed for user-interaction, while the other CPU can focus on it’s heavy lifting.
In these areas, where it’s not the application that manages the thread resource allocation, but the OS, that multi-CPU systems rock. As long as applications have some basic form of threading built into them, the modern OS’s can work magic.
If a given application is single-threaded, it will only run on one CPU, and the OS can't do anything to split the workload out to other CPUs. OoO execution is still an option, but a bit more complicated. That single-threaded app, though, won't bog down the whole system, as the other cores would be completely free for OS work.
edit: I've sort of muddied the waters RE: OoO execution and threading. To be clear, they are different concepts, and I only mention both of them because they both effect data coherency, both need to be dealt with at execution time, and both complicate the other when they are being used in tandem.
OoO can actually help a lot on a single threaded app, but you would have recieved that boost just as well with one processor.
-AntonK
Blindman 02-11-06, 02:50 AM I have recently been contracted to do a safety assessment of a new local rail line.. Having little time I wrote the solution in VB Dot NET. So a typical output would require about 10-15hours CPU time. As I was pushed I did not create a multi threaded application, I simply ran the application twice on the dual processor machines. It simple to see you CPU load on a multi CPU system, just get up the Task manager and look at the cpu usage. In this application running in parallel I got twice the processing power without the need for complicated inter process communication. Multi CPU systems rock.
I am on the verge of creating multi user single motherboard applications.. This is a massive override of all OS's basic premise. One desktop one user. OS's should be able to accept multiple focus points. I should be able to type in this document as some one with a second keyboard an mouse can edit the same document at the same time..
Multi focus is what is needed in new OS's (lynx freaks don’t go blabbing about terminal access for this is not the same.)
First off, my guess, and this is only a guess.... is that you could cut off 5-7 hours off that run time if you wrote it in something a little more powerful than VB .NET. All .NET software has a lot of overhead. My guess is you could improve the SINGLE THREADED efficiency of your program pretty easily, just by using a real language.
-AntonK
|