> -----Original Message-----
> From: Christopher Spence [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 16, 2001 1:16 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Comment on 'Practical Oracle 8i'
>
>
> Well, I just got this book, and just started reading through it.
> Looks good so far. Just would like to comment on something I saw.
>
> Must say BookPool.com is so awesome. 40% off most books
> (which I bought
> three this time) and paid $4 for 5 day shipping yet I get it
> the next day on
> my doorstep. Got to love that.
>
> Page 28:
>
> I will quote:
>
> "A greater number of slower CPU's is often better than a
> fewer number of
> faster ones."
>
>
> To some extent I believe this is true especially with the
> efficient use of
> caching in most OS's. But with the larger caches on unix
> cpu's, 4Mb, 8Mb.
> There is a loss of performance when a process runs on a cpu,
> then context
> switches and then placed on another cpu. All the cached
> tlb's are then
> sitting on another cpu and need to be reloaded. Although the
> os will try to
> reschedule recently run processes on the same cpu, that doesn't always
> happen on a busy system. Also the fact that faster cpu's return the
> processes back faster.
>
> Although on the other hand, with more cpu's, more can get done
> simultaneously but at a slower rate. And there would be fewer context
> switches with many more cpu's.
You, of course are right. SMP is an overhead. The additional problem
with the slower CPUs is that the bus on the machine is usually slower
then on newer machines with the screamingly fast CPUs. Slower bus and
oracle means that large scatter/gather ISO and memory requests will
compete for the bus resources slowing the machine down. Interrupt
arbitration (the time spent by the system bus (a.k.a. "chipset") to
decide which CPU should be honored by the pending interrupt) is also
a huge drain on the slower buses. That can bring systems with the slower
buses to the grinding halt. One needs buses and OSes which support memory
mapped access ("IntelliIO","NgenIO") and large quantities of IO per second
all while featuring advanced CPU cache interconnects which will diminish
the impact of cache synchronization on the system.
It is worth noting that oracle, nd the same applies to all huge software
systems, does not make very good or efficient use of CPU caches. With
oracle, cache flushes and invalidations will happen frequently, as well
as TLB invalidations and flushes. In order to behave well on virtual memory
systems, it is necessary that the programs obey the locality of reference
principle, which is very hard to do if you are using a huge software system
written thousands of programmers and using thousands of subroutines. With
oracle, modern super pipelined, super scalar chips with several execution
streams will not do much. The thing that counts is the raw chip frequency
and the speed of memory access (DDRAM,EDO,Rambus). To make a long story
short, I do prefer a system with more fast CPUs over the system with fewer
fast CPUs because the architecture improvements on the modern buses are
amazing
and must be used.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Gogala, Mladen
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
