[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 604e's suck (was Yaboot Config Question)

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(peter@llama.nslug. , 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 debian-powerpc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Taro Fukunaga

Reply to: