🚀 go-pugleaf

>>>>> "Christopher" == Christopher Browne <cbbrowne@acm.org> writes:

    Christopher> On the other hand, the two CPUs have to share: 
    Christopher> a) The same memory bus; 

This is only a concern when there is a cache MISS!


    Christopher> b) The same memory caches; 

Wrong, somehow.  Each CPU has its own L1 cache.


    Christopher> c) The same I/O buses.

True.  And in  this case, the OS schedules the things  nicely, as in a
single CPU system.  E.g. disk read  requests from any CPU would be put
on  the same  queue,  and then  served  by the  disk scheduler  (which
optimizes  the  performance with  the  elevator  algorithm).  It  only
matters when you generate 2x the amount of I/O operations.


    Christopher> If the CPUs are working on totally different sorts of
    Christopher> things, b) can lead in particular to "sucky
    Christopher> performance."

You're  wrong.   They  each  has  its own  L1  cache.   And  accessing
different sorts of things is actually  good in this case: if they were
accessing the same  things, they MUST invalidate the  L1 cache of each
other often, defeating the purpose of the cache.  If they're accessing
different things,  they each keep those  things in their  own L1 cache
happily.  And this generates much less cache-invalidation or refetch.


    Christopher> If both CPUs are /reading/ the same code, or
    Christopher> /reading/ the same memory locations, there could
    Christopher> conceivably be a big /WIN/ as a result; 

Obviously not.   They have  to invalidate the  L1 cache of  each other
often, making the L1 cache almost useless.


    Christopher> the first CPU already read the data, so it's in cache
    Christopher> so that the second CPU doesn't have to read it in.

Only true for  the external cache (L2 or  higher).  And usually, there
is just plentify  L2 cache to handle the needs of  both CPUs.  If not,
blame the motherboard designers.



-- 
Lee Sau Dan                     ���u��(Big5)                    ~{@nJX6X~}(HZ) 

E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee