Re: Are Sunblade 1000s slow?
I was referring to the effects of cache+memory layout characteristics. On the
E4500 I use, each CPU has 8M of cache and with 14 CPU's thats a lot of active
process space that can stay in cache. The memory difference comes from the
how many non-contigues memory requests are made and can be handled quickly.
DDR-400 is great for many applications, but the more random the access
patterns, less of an advantage it has. That is where the heavy load on a
system makes a big difference. What architecture is best is very dependent on
what the application is and the load characteristics.
I do agree that there are many places where the Sun system suck compared to
the current the current competition. But as the load and number of processes
climb, the UII & UIII system performance curves still show significantly
better performance then one would expect from such outdated technology.
On Tuesday 07 October 2003 21:51, Andrew Sharp wrote:
> On Tue, Oct 07, 2003 at 06:45:26PM -0500, Steven Wilcoxon wrote:
> > My experiances with dual and quad x86 systems that should blow an E4500
> > out of the water have shown me that in multiprocessor applications, as
> > the load increases, the E4500 handles the loading much better.
> >
> > My personal opinion as to why is related to the CPU cache and memory
> > architecture. In x86, each CPU has a smaller amount of cache and then
> > bottlenecks at the memory. In the E4500, even though each CPU is slower,
> > the higher number of CPU's and the layout of the memory makes it much
> > harder to slow down.
> >
> > Now I need to get my hands on a good Quad Opteron to see how that feels!
>
> When was the last time you tried a dual xeon w/2MB cache with a
> real server chipset? No need to plunk down the bones for an Opteron.
> And let's not forget the 2MB cache P4 that Intel just released. That and
> dual channel DDR 400 memory, and the memory on these systems is faster
> than the cache on all but the latest US3 systems, so the memory
> bottleneck argument is pretty much over, too.
>
> a
<SNIP>
--
S.W.
aka Learner
http://www.TerminusPoint.com
Reply to: