🚀 go-pugleaf

I have found this discussion interesting, in part because I have a dual Celeron
"workstation" (300As @450/100).

While I cannot claim complete/through understanding of all the issues raised I
re-iterate a summary:

Because of their small 128k L2 cache Celerons are *likely* to be a poor choice
for building fileservers in particular and when operating in a SMP situation
*may* perform particularly poorly compared to CPUs with larger L2 caches - even
if those caches operate at 1/2 clock speed (PII/PIII).

(*likely* and *may* have been emphasized because the arguments have been
theoretical and no benchmarks or real-world tests have been offered to support
the theory - how ever reasonable it may be)  

This would be because the cache contents must be synchronized between CPUs over
a 100mhz or 66mhz bus, thus eliminating most of the potential benefits of the
Celeron's full-speed L2 and increasing the penalty for a cache miss.

If an application is not optimized for small cache size (i.e. 128k) it will
*likely* perform rather badly on a Celeron and perhaps worse on Celerons in SMP
configuration.

My personal experience with this particular system is that it performs rather
well - compared to what you ask? - well I had a K6 300 with 196MB RAM, built
this with one CPU and added a second.  Some operations are 5x faster than they
were on the K6, the system is more responsive under multi-task situations than
with the single CPU, but it is by no means twice as fast.

Here is a quick and dirty comparison - not ideal as many factors besides CPU
enter in (OS differences, UDMA implementation, different background tasks
running, etc.)  I ran each task separately, then started the PS filter and added
the other two -> all three at once.  Time 1 = single task, time 2 = all tasks at
once; min:sec. Booted W98, defrag disks, run tasks, boot NT...

                   W98                    WNT4.0sp5
              fat16-fat16   fat16-fat16   NTFS_C - fat16
Photoshop image
1			6:13		7:13
2			8:20	-25%	7:40	-6%
Premiere demo
1			1:58		1:55
2			4:00	-51%	2:02	-5%
File transfer
1			1:25		1:51		0:57
2			2:01	-30%	1:59	-7%	1:03	-9%

Photoshop 4.01, 7.4MB file (1730x1500 pixels) apply stained glass filter w/cell
size = 3, border = 1, brightness = 3

Premiere demo 4.2 run with a "speed test" from:
http://members.aol.com/simmike

File transfer - partition to partition, same IDE disk, 259MB

The results seem pretty clear cut - the second CPU helps quite a bit under
multi-tasking situations, and two of the tasks complete more quickly under W98
when run alone.

As for the topic of the thread - what about some server benchmarks??  Abit is
purported to have a dual socket 370/BX chipset board in the works - is it
possible some of the *potential* limitations of small L2 can be mitigated on the
motherboard?

Implications for Linux seem to be - design apps to minimize the impact of 128k
L2 to get the max benefit of Celerons (the C400 should be selling below $100
w/in 2 weeks...).

When I put this system together PII400s were running about $400ea.  The premiere
movie build runs at about the speed of a PII 400 when run alone.  The two
Celerons and converters cost less than $200.  The $$ saved on the CPUs went into
RAM.  By this fall or winter PIII 500s should be selling @ or below $200 I
think.  CPUs are not holding their value very well, compared to other
components.

CB

Totally Lost wrote:
> 
> The work done by Tomohiro Kawada and others has been interesting.
> I can think of a number of applications where dual/quad overclocked
> Celeron's can produce very cost effective clusters for number crunching.
> The crypt cracking teams will get a great windfall from this work.
> 
> I do performance studies and optimization for a living. One of the
> biggest problems people have porting applications from big iron
> SMP servers to X86 SMP servers is memory foot print and working
> set locality problems which make X86 SMP scaling difficult at best.
> 
> Big Iron SMP servers typically have larger L1/L2 caches with
> a much faster memory subsystem under them. The size of the
> working set directly predicts the performance of most
> applications. To help clients understand this I often use the following
> visual aid in my presentations, which is the output of a tool
> I use to measure the performance of their system as the working
> set size is increased:
> 
> Counts are thousands of MemOps/second.
> SunOS svr20 5.5.1 Generic sun4m sparc SUNW,SPARCstation-20
> 
> Set  Sequential Random
> Size  Cnt   Pct Cnt   Pct
> ----- --------- --------- 0%        25%        50%        75%       100
>    2K 29685 100 21271 100 |          |          |         *|          @
>    3K 29657 100 21244 100 |                              *            @
>    4K 29652 100 21231 100 |          |          |        * |          @
>    6K 29644 100 21264 100 |                               *           @
>    8K 29652 100 21203 100 |          |          |        * |          @
>   12K 29644 100 21245 100 |                              *            @
>   16K 29625 100 21221 100 |          |          |        * |          @
>   24K 10996  37 18120  85 |               @          *
>   32K  7943  27 16190  76 |          |@         | *        |          |
>   48K  7941  27 13716  64 |           @       *
>   64K  7939  27 12067  57 |          |@     *   |          |          |
>   96K  7943  27 10802  51 |           @   *
>  128K  7947  27  9877  46 |          |@  *      |          |          |
>  192K  7946  27  9837  46 |           @  *
>  256K  7909  27  9828  46 |          |@  *      |          |          |
>  384K  7773  26  9806  46 |           @  *
>  512K  7652  26  9766  46 |          @  *       |          |          |
>  768K  7619  26  9765  46 |          @  *
> 1024K  7580  26  9755  46 |          @  *       |          |          |
> 1536K  2164   7  9642  45 |  @          *
>    2M  2045   7  9634  45 |  @       |  *       |          |          |
>    3M  2044   7  9602  45 |  @          *
>    4M  2041   7  9595  45 |  @       |  *       |          |          |
>    6M  2038   7  9592  45 |  @          *
>    8M  2042   7  8823  41 |  @       | *        |          |          |
>   12M  2035   7  8720  41 |  @         *
>   16M  1863   6  8723  41 |  @       | *        |          |          |
>   24M  2023   7  8596  40 |  @         *
>   32M  1657   6  9590  45 | @        |  *       |          |          |
>   48M    10   0  8040  38 @           *
>   64M    40   0  6552  31 @         *|          |          |          |
> 
> The graph is plotted with all values relative to the first sequential
> value. The test reflects the performance losses due to the working
> set size impact on the VM/Cache/Memory subsystems. This includes
> TLB misses, cache misses and memory latency. Cache design and memory
> allocation coloring present very different responses to this test.
> Poorly colored memory with direct mapped caches shows up with early
> degradation slopes, while good coloring produces sharp fall-offs at
> each cache boundry.
> 
> This particular machine didn't have a lot of
> memory and started paging above 32M, with 32K L1 and 1024K L2 cache
> sizes. Increasing the working set by a single cache line
> often reduces the performance to the next larger (and slower)
> memory object.
> 
> In a real system, there are many sources that scale into the working
> set size(s). The size of the active interrupt service routines and
> OS scheduler are often near the size of L1/L2 caches on many X86
> systems, thus each interrupt flushes the cache and effectively runs
> at memory or L2 cache speeds. In an SMP system, both CPU's have to
> share the memory performance. If the L1/L2 caches are too small, then
> two processors are worse than one, because they will flush each other
> with distributed interrupts. The cost of flushing the cache by context
> switches and interrupts is two 2X ... memory cycles required to bring
> in the new context/interrupt plus the memory cycles required to replace
> the active process memory on exit. One reason that X86 SMP servers
> may scale, is that network interrupt loads that flush a uniprocessor,
> only impact one processor in a multiprocessor system ... especially
> if the interrupts are bound to a single processor. Ditto for the disk
> subsystems. SCSI controllers that have high interrupt loading can
> kill an SMP server if the interrupts are distributed. NCR825's are
> a very good example when used with very poor SCSI scripts and drivers.
> 
> Understanding the locality and working set sizes, some X86 vendors
> have post processed their kernel builds to improve locality and
> placement. The work done by the SCO Unixware team on the object code
> segments has produced remarkable results. These vendors often have
> large kernels and feature sets, with same/better overall performance.
> 
> Celron's with their 128K L2 cache can easily produce worse performance
> under modest to heavy load than a single processor in an SMP system.
> In many server systems, even dual PII's with 512K L2 caches fail to
> scale or produce negative results under modest to heavy work loads.
> In some applications, even Xenon's large caches fail to scale or
> produce negative results in comparision to uniprocessors of the same
> architecture. Simply put, it's not uncommon to find applications where
> two processors trashing the caches with SMP interrupts or shared memory
> produce much worse performance than the same system with only a single
> processor enabled.
> 
> Linux is not well multi-threaded, and has a pretty large foot print
> with very little locality in either the OS or it's primary applications.
> I would expect that for many users, dual Celeron's may have a negative
> performance impact much of the time.
> 
> To observe that Dual Celron's produce an observed improvement under
> certain lightly loading applications may be true. To assert that
> they scale under modest to heavy work loads is probably a huge mistake.
> To expect that they will scale well under Linux with heavy loads is
> almost certainly folly.
> 
> John Bass
> UNIX Systems Consultant
> 
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---


  -----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
   http://www.newsfeeds.com       The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including  Dedicated  Binaries Servers ==-----