I don't have the technical background to follow a lot of this thread,
but I've been studying pthreads, and it seems that whether a certain
process gets executed more quickly on a multiprocessor computer depends
on how well the process uses threads for concurrency. So in a
compilation scenario, a make that can issue several compilation steps at
once would be ideal. Does make (or I guess the compiler) take advantage
of multiple threads, or is there some other strategy being used?
I hope this isn't a stupid question :-)
-- Taro
On Sat, Apr 07, 2001 at 05:42:44PM -0300, Peter Cordes wrote:
> On Sat, Apr 07, 2001 at 04:26:02AM -0700, Andrew Sharp wrote:
> > I'm afraid it's even worse than that. I haven't looked up the
> > design specs on the web or anything, but I believe the Daystar
> > design is quite poor in a number of ways, some of them not really in
> > their control. First, it's not SMP, it's really AMP, or Asymetric
> > MP: only processor 0 gets interrupts. The processor affinity
> > algorithms in the 2.2 kernel, lame as they are, cause poor
> > performance on this kind of MP architecture. I wouldn't be
> > surprised if 2.0 kernels, which had almost no processor affinity
> > code, would show better scaling on these systems. Secondly, only
> > one processor at a time may use the bus off the daughter card, and
> > are multiplexed by bus transaction, not by bus cycle. L2 cache
> > thrashing is a definite possibility.
>
> Now that I think about it again, maybe the problem is just that the L2
> cache is on the mobo, as well as being shared, so the CPUs have to go
> through the bottleneck bus to get to it.
>
> > But the worst part is that the
> > 604e is but a very pale shadow of the 604, with it's half wide data
> > and address busses and basically non-existent L1 caches. It's
> > specmark numbers for a 200 are below those of a 200MHz PentiumPro.
> > So, yes, your 650 Athlon, what with 133 or 200MHz memory bandwidth,
> > would spank that snot out of a 4 way 604e @ 150MHz.
> >
> > With almost no disk accesses, my dual 200MHz 604e compiles a certain
> > kernel config achieving only about a 50% scaling, which is down
> > right pitiful, but better than nothing! My dual SparcStation20 and
> > my dual celeron system achieve greater than 95% scaling on the same
> > kind of [fairly silly] test. Such is life.
>
> It's hardly "fairly silly". Compiling is an important benchmark, since a
> lot of time will be spent actually compiling.
>
> Thanks for that info. BTW, only 2.4 kernels support my quad Daystar (2.2
> handled dual CPU daystars). Also, the older Daystar Digital Genesis MP (not
> MP+), like I have, uses 604 CPUs, not 604e. I looked up some info on 604
> and 604e before I bought the system (second hand last summer), and IIRC 604e
> has better out-of-order execution and stuff like that. I guess that just
> makes the memory starvation worse, though! I've got two 64MB DIMMs in the
> right slots for interleaving to work, but that doesn't help the memory
> latency. I think they still have less bandwidth than the 66MHz SDRAM in my
> P200MMX. (I ran some lmbench tests.) How much would a CPU upgrade card
> help? Anyone tried compiling a kernel or something with e.g. a dual G4 CPU
> card in an old system with interleaved memory? G3 and G4 cpus have
> per-processor cache, instead of the shared 512kB my system has, so they
> should do a lot better.
>
> /proc/cpuinfo:
> processor : 0
> cpu : 604
> clock : 150MHz
> revision : 3.5
> bogomips : 299.50
>
> ...
> proc 1,2, and 3 identical
> ...
>
> total bogomips : 1196.53
> zero pages : total: 0 (0Kb) current: 0 (0Kb) hits: 0/0 (0%)
> machine : Power Macintosh
> motherboard : AAPL,9500 MacRISC
> L2 cache : 512K unified
> memory : 128MB
> pmac-generation : OldWorld
>
>
> --
> #define X(x,y) x##y
> Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca)
>
> "The gods confound the man who first found out how to distinguish the hours!
> Confound him, too, who in this place set up a sundial, to cut and hack
> my day so wretchedly into small pieces!" -- Plautus, 200 BCE
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
Taro Fukunaga
[EMAIL PROTECTED]
