Date: Sun, 14 Sep 1997 21:47:30 -0700 From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net> To: Simon Shapiro <Shimon@i-connect.net> Cc: dg@root.com, Terry Lambert <tlambert@primenet.com>, missmanp@milo.cfw.com, freebsd-smp@freebsd.org Subject: Re: SMP in FreeBSD 3.x.x Message-ID: <199709150447.VAA04590@MindBender.serv.net> In-Reply-To: Your message of Sun, 14 Sep 97 21:28:53 -0700. <XFMail.970914212853.Shimon@i-Connect.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
>Hi David Greenman; On 15-Sep-97 you wrote:
>> >:-) was that aroud 30 processors is where scalability will fall off. We
>> >used Dynix + Oracle for O/S application model. Processor was Pentium.
>> >If
>> >I remember correctly, the P6-200 has worse instructions/memory/IO
>> >bandwidth
>> >ratios than Pentiums-66 does. That led to the conclusion that we will
>> >not
>> >grow beyond 30 either. I will not go into what the initial P7 was
>> >supposed
>> This contradicts a paper that was given at a recent Usenix-sponsored
>> conference that shows that the amount of main memory traffic in P6
>> systems
>> is *dramatically* reduced over Pentium systems. I forget the exact
>> ratio,
>> but it is something like 1/5th. This is entirely due to the superior
>> cache
>> architecture of the P6.
>For in-cache applications, this is very true. For RDBMS applications this
>is totally immaterial; In a typical database operation, very little of the
>data resides in the cache.
[...]
>RDBMS requires abot 2MB cache to handle the text. The dataset is so much
[...]
>Also, if you look at the text size of something like Oracle, you will see
>8-10MB, The cache represents 2-4% of that (in a P6). Before you mention
>ordered linking, shared libraries, etc. I'll haste to say that when I last
>looked, Oracle was statically linked (for a mix of good and bad reasons)
>and we used to run bets on the number of never-called functions in the code
>(the real number was about 1,100 or so).
[...]
Also, remember that not all the world is free Unix (I know you weren't
asserting that). There are several commercial software companies that
do extensive profiling and reordering of "basic blocks" of compiled
code to significantly reduce memory footprint of the binary (and in
the course of doing that, improving cache locality). Just because a
binary is 8-10MB doesn't mean that it is necessarily accessed
"randomly" on all platforms that use the Intel chips.
On the other hand, I don't think anyone would deny that a bigger cache
is always better, especially with lots of processors.
For what it's worth...
-----------------------------------------------------------------------------
Michael L. VanLoon michaelv@MindBender.serv.net
Contract software development for Windows NT, Windows 95 and Unix.
Windows NT and Unix server development in C++ and C.
--< Free your mind and your machine -- NetBSD free un*x >--
NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
NetBSD ports in progress: PICA, others...
-----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709150447.VAA04590>