Differences between version 5 and revision by previous author of SymmetricMultiProcessing.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
Newer page: | version 5 | Last edited on Friday, April 16, 2004 7:32:29 am | by AristotlePagaltzis | Revert |
Older page: | version 4 | Last edited on Thursday, April 15, 2004 10:38:38 pm | by StuartYeates | Revert |
@@ -1,9 +1,15 @@
-A system with multiple identical (or at least similar)
[CPU]s having equal access to memory and to the [IO] subsytem(s). Contrast [NUMA] and AsymmetricMultiProcessing.
+A system with multiple identical [CPU]s having equal access to memory and to the [IO] subsytem(s). Contrast [NUMA] and AsymmetricMultiProcessing.
+
+''StuartYeates writes that they may be only nearly identical. However, such setups are extremly rare to the point of irrelevance. In practice, all [SMP] systems run with setups such as dual-Opteron, quad-Xeon, dual-PowerPC, or others, where the [CPU]s are perfectly identical.'' --AristotlePagaltzis
It is an accepted rule of thumb that due to the InterProcessCommunication "friction" required to synchronize tasks across [CPU]s, each additional [CPU] contributes about 1/6 less performance than the previous one. As a result, fitting more than four [CPU]s in a machine tends to cost heaps of money with surprisingly little to show for it.
On the OperatingSystem level, there is a wide span for the degree of symmetry expressed. On a fully symmetric system, any [CPU] may run any userland process, any kernel process, and any interrupt handler. This is rare in practice due to limitations in various platforms -- most of the time, the interrupt handler can only be run by the first [CPU]. In simpler [OperatingSystem]s, this is also the only [CPU] that may kernel tasks. In yet simpler system designs, even user processes are assigned to a fixed [CPU] and cannot move among [CPU]s.
In practice, a less symmetric system OperatingSystem design may not be a drawback. It is desirable to tie processes to a certain [CPU] as long the system load is evenly distributed among [CPU]s, because this maximizes the efficiency of [CPU] caches. Even in a completely symmetric system, an intelligently written scheduler will take this into account and try not to shuffle tasks around needlessly.
-Few normal applications
explicitly exploit SymmetricMultiProcessing,
[Java
] programs being
the exception here
, with their innate multithreadedness
which means things like
the [GUI] and
GarbageCollection run on sepreate CPUs from
the application logic
.
+Applications have to be
explicitly designed to
exploit the additional processing power available in an
[SMP
] system. This is not often
the case. It only commonly applies to multithreaded applications
, which are common in the [Java] world[1] where
the [GUI],
GarbageCollection, and application logic will often
run on sepreate [CPU]s.
+
+----
+
+[1] What else can you do when all your [IO] is blocking? At least there's nonblocking [IO] in more recent versions, but of course
the new classes add yet another layer to the already byzantine library
.