CASTalk.com

HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Joe Seigh wrote:

HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.

Huh? Sun has been producing systems with more than 32 CPUs for

some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.

Joe Seigh wrote:

CJT wrote:
Huh? Sun has been producing systems with more than 32 CPUs for
some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"

In the applications. If you ignore scalability issues in applications,
i.e. everything essentially runs single threaded, then you're putting
a 32 way system up against 32 single processor systems on a commodity
basis. Sun is not a commodity vendor like Dell is so I don't think
they're going to win out on that basis.

Download Apache, install Apache, run Apache, put some load on it, now
count the Apache processes and threads.

Or: Download samba, install samba, run samba, power up 32 clients which
connect to the samba file server, count the samba processes.

The real question is: Is there any serious server application which does
*not* use >32 processes or threads if under load?


Matthias

Scott Moore wrote:

CJT wrote On 12/06/05 09:37,:

Joe Seigh wrote:



HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.


Huh? Sun has been producing systems with more than 32 CPUs for
some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"



If you have highly threaded apps, they are going to do well on
Niagara. If your app is single threaded, it isn't going to see
improvement.

That's pretty much it.

Scalability is a measure of how much improvement in performance you
get when you add extra processors (assuming you have enough threads
to exploit the processors and aren't overwhelmingly i/o bound). You
don't automatically get 2x performance when you double the number of
processors.

For the most part it is caused by contention on locks by the threads
which goes up exponentially with the number of threads/processors.
You can reduce your locking granularity but eventually even that won't
help due to the exponential nature of the contention.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Matthias Wieser wrote:

Joe Seigh wrote:


In the applications. If you ignore scalability issues in applications,
i.e. everything essentially runs single threaded, then you're putting
a 32 way system up against 32 single processor systems on a commodity
basis. Sun is not a commodity vendor like Dell is so I don't think
they're going to win out on that basis.


Download Apache, install Apache, run Apache, put some load on it, now
count the Apache processes and threads.

Or: Download samba, install samba, run samba, power up 32 clients which
connect to the samba file server, count the samba processes.

I know for a fact that Samba has scalability issues with locking on their
internal (session?) table look ups since they were briefly looking at
RCU for preemptive user threads. That never went anywhere since it
required a kernel mod but I don't think the problem magically went away.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Joe Seigh wrote On 12/06/05 12:07,:

Scott Moore wrote:

CJT wrote On 12/06/05 09:37,:


Joe Seigh wrote:




HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.


Huh? Sun has been producing systems with more than 32 CPUs for
some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"



If you have highly threaded apps, they are going to do well on
Niagara. If your app is single threaded, it isn't going to see
improvement.

That's pretty much it.



Scalability is a measure of how much improvement in performance you
get when you add extra processors (assuming you have enough threads
to exploit the processors and aren't overwhelmingly i/o bound). You
don't automatically get 2x performance when you double the number of
processors.

For the most part it is caused by contention on locks by the threads
which goes up exponentially with the number of threads/processors.
You can reduce your locking granularity but eventually even that won't
help due to the exponential nature of the contention.

Thats an obsolete, single core model. Multicore does not have that kind
of contention for locks, because there are more processors to run.

Scott Moore wrote:

Scalability is a measure of how much improvement in performance you
get when you add extra processors (assuming you have enough threads
to exploit the processors and aren't overwhelmingly i/o bound). You
don't automatically get 2x performance when you double the number of
processors.

For the most part it is caused by contention on locks by the threads
which goes up exponentially with the number of threads/processors.
You can reduce your locking granularity but eventually even that won't
help due to the exponential nature of the contention.



Thats an obsolete, single core model. Multicore does not have that kind
of contention for locks, because there are more processors to run.

Really? http://www.acmqueue.org/modules.php?nam ... ge&pid=328
(this was one of the links in the article)

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Joe Seigh wrote:
<snip>

If you have highly threaded apps, they are going to do well on
Niagara. If your app is single threaded, it isn't going to see
improvement.

That's pretty much it.


Scalability is a measure of how much improvement in performance you
get when you add extra processors (assuming you have enough threads
to exploit the processors and aren't overwhelmingly i/o bound). You
don't automatically get 2x performance when you double the number of
processors.

For the most part it is caused by contention on locks by the threads
which goes up exponentially with the number of threads/processors.
You can reduce your locking granularity but eventually even that won't
help due to the exponential nature of the contention.

If Sun get the SPECweb2005 result they refer to on their webpage
accepted ( http://www.sun.com/emrkt/trycoolthreads/ ) that should be
enough to convince people that the hardware scales well - up to it's
single chip limit.

The software scalability issues remain pretty similar, although I would
imagine that a single chip design should have good latency
characteristics in a multithreaded environment due to the shared cache
and rather simpler requirements for cache coherency :)

So, it looks like it could be a good choice for certain apps or mix of apps.

Pete

Joe Seigh wrote:

HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free).

Looks like you'll get a chance to prove it :->

The Verilog for the T1 chip is being open-sourced.

http://www.sun.com/smi/Press/sunflash/2 ... 206.4.html

It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.

I guess all those E10Ks, E6900s, F12Ks, F15Ks,
E20Ks, and E25Ks running highly scalable
commercial workloads just don't exist, then.

Russell

Ningi <ningi@eggsandspamblueyonder.co.uk> wrote:

If Sun get the SPECweb2005 result they refer to on their webpage
accepted ( http://www.sun.com/emrkt/trycoolthreads/ ) that should be
enough to convince people that the hardware scales well - up to it's
single chip limit.

I guess it depends on one's definition of "scaling" whether it would
be necessary to see a result from the same system with fewer cores at
the same frequency.

rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Looks like you'll get a chance to prove it :-

The Verilog for the T1 chip is being open-sourced.

http://www.sun.com/smi/Press/sunflash/2 ... 206.4.html

It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.

I guess all those E10Ks, E6900s, F12Ks, F15Ks,
E20Ks, and E25Ks running highly scalable
commercial workloads just don't exist, then.

Yes, but how many of those workloads are suitable for Niagara? I bet I
can count the # of E25K's used for web serving on one hand, minus
several fingers.

I think Niagara will certainly be interesting for a lot of server
stuff, web serving, collaboration/email and some java stuff seems
likely. Beyond that is...uncertain. Certainly, it's not the kind of
machine you'd use for SAP...

DK

CJT wrote:

Joe Seigh wrote:

HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.

Huh? Sun has been producing systems with more than 32 CPUs for
some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"

In the applications. If you ignore scalability issues in applications,

i.e. everything essentially runs single threaded, then you're putting
a 32 way system up against 32 single processor systems on a commodity
basis. Sun is not a commodity vendor like Dell is so I don't think
they're going to win out on that basis.

Anyway, follow the links in the HP article.


--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

CJT wrote On 12/06/05 09:37,:

Joe Seigh wrote:


HP has a web page emphasizing the scalability problems
http://h71028.www7.hp.com/ERC/cache/280 ... 0-121.html
What? HP plans to never put out a 32 way system themselves,
ever?

I have my own ideas on how to achieve scalability on a
32 way (besides lock-free). It will be interesting if
Sun comes up with any ideas of their own, though I guess they
can't publically admit there are scalability problems
before they come up with a solution.


Huh? Sun has been producing systems with more than 32 CPUs for
some time, and getting near linear scaling, as I recall. What are
these "scalability problems?"

If you have highly threaded apps, they are going to do well on
Niagara. If your app is single threaded, it isn't going to see
improvement.

That's pretty much it.

"David Kanter" <dkanter@gmail.com> writes:

I think Niagara will certainly be interesting for a lot of server
stuff, web serving, collaboration/email and some java stuff seems
likely. Beyond that is...uncertain. Certainly, it's not the kind of
machine you'd use for SAP...

Bullshit. There's nothing wrong with Niagara itself in terms of SAP. SAP
doesn't require maximum possible single thread performance, make much if
any use of FP, nor does it max out memory bandwidth. OK, badly written
ABAP will, but badly written code will always be a problem with no solution.

Now you are correct in terms of the machines they are selling that have
Niagara today, they are small and relatively inexpensive, and you need
higher reliability than they probably offer (certainly for the DB and CI)
It would probably work nicely for an app server, but I really don't see
any reason to use anything other than Linux on x86 for app servers these
days since price/performance rather than pure reliability tends to be more
important there.

Any servers running with high load averages where processes aren't being
preempted due to the timeslice expiring, where memory bandwidth is not
being maxed out or nearly so and which use little or no floating point
are going to have better per socket performance on Niagara than anything
else they can run on today. And that's a pretty big market, even if it
doesn't include 100% of the server space. Whether Sun chooses to target
Niagara on the high end reliability side of things is another matter, but
that lack has little to do with Niagara's design, merely its current
implementation.

--
Douglas Siebert dsiebert@excisethis.khamsin.net

Give a man a match, and he'll be warm for a minute. Set him on fire, and
he'll be warm for the rest of his life.

Joe Seigh wrote:

Scott Moore wrote:


Scalability is a measure of how much improvement in performance you
get when you add extra processors (assuming you have enough threads
to exploit the processors and aren't overwhelmingly i/o bound). You
don't automatically get 2x performance when you double the number of
processors.

For the most part it is caused by contention on locks by the threads
which goes up exponentially with the number of threads/processors.
You can reduce your locking granularity but eventually even that won't
help due to the exponential nature of the contention.



Thats an obsolete, single core model. Multicore does not have that kind
of contention for locks, because there are more processors to run.


Really?
http://www.acmqueue.org/modules.php?nam ... ge&pid=328
(this was one of the links in the article)

The intuitively obvious (at least to me) conclusion to this is that
multi-processor scaling is just like a big fanout in a chip:

The solution to exponential problems is logarithmic scaling, i.e. you
must subdivide into multiple layers of 1:N blocks.

If you have a problem for which you cannot figure out a reasonable (or
even not so reasonable!) way to do this, then you'll get a kick in the
butt from Amdahl's Law.

Terje
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"