Does anybody notice that Sparc T1 have four main memory ports!

Four of them, each costs more than 200 pins!

This really matters!

Going back to cache size: if you have 1-2 cores/chip or 1-2 threads/core then cache is mostly about reducing latency and partly about reducing main memory bandwidth requirements. If you have a chip like the UltraSPARC T1 (or what Rock seems to be like), then I’d say cache is mostly about reducing main memory bandwith and partly about reducing latency.

How caches need to be optimised is not the only thing that I think will change with chips optimised for Thread Level Parallelism:
http://www.aceshardware.com/read.jsp?id=65000333

These presentation PDFs have some interesting bits of info on T1 and Rock:
http://www.cse.ucsd.edu/~rakumar/dasCMP/talk01.pdf
http://ru.sun.com/pdf/t-time/tremblay.pdf

Looking at the CPI figures for T1/Niagara on a “large scale commercial workload”, the L2 cache misses only reduce performance by about 18% even with 4 threads/core active. Or about the same as pipeline stalls (due to branches I assume) and L1 data cache misses, and less than L1 instruction cache misses.

Looking at the Rock simulated performance stuff, “hardware scout” can warm up the caches enough that a 1MB L2 cache can give the performance of an 8MB one without the technology. I wouldn’t be surprised if Rock has even less cache relative to its performance (compared to T1).

With regards to Sun helping customers choose, I’m not sure how much they can realisticly do to predict performance in advance (relative to x86). Nobody can do that (without doing actual measurements). If the OSs are different too, then it’s even harder. Most customers seem to make their architectual choices in advance and aren’t willing to re-evaluate which is best for every new project. Customers who really do care would probably be happy to get trial systems and compare the performance directly – after all, measured results are much better than vendor guesses.

On the other hand, Sun’s pricing on the T1 systems is quite aggressive. Enough that unless it hits one of the gotchas mentions previously, a T1 based solution would probably have better price/perf (and TCO) than Sun’s Opteron systems in most cases.

To whit my point about self-referentiality. Its not enough for Sun’s community of evangelists to tell each other how great Sun is. what else would they say? Sun needs to reach out to new customer sets, in order to drive sales. The existing base of Sun bigots just isn’t big enough, as quarterly results over the last four years have repeatedly shown.

2 way conversation is valuable but I am talking aboout n-way dialogue…

I disagree that Sun forums is necessarily the best place to talk about Sun. Remember I am an industry analyst, not a Sun analyst or Sun customer, per se.

Sun has less to lose, in revenue terms, as the space commoditises further. If customers choose to Apache itself, which many do, then Sun still has a strong play providing hardware.

My comments were not meant as a critique of Glassfish or other Sun JEE efforts, so much as a pointer to the fact Sun is reasonably well positioned to win Web 2.0 workloads.

Strato, for example, builds directly on open source componentry, rather than buying high dollar software from enterprise vendors. That is what many successful service providers do.

I’m sure I don’t need to tell you that part of the implementation of Sun’s J2EE application server is tomcat.

When you say that it “is designed for mid tier rather than OLTP, from a cache perspective”, do you have any similar customer examples? Since you say “from a cache perspective”, I suspect this is a prediction not a measurement. If so, do you think the cache is too small? My own prediction is that the T1 could stumble a bit on some OLTP setups but not because of the cache size – with the T1′s massive Thread Level Parallelism, cache size is less of an issue.

With regards to “could build a table, or online service, that recommended AMD, oldline SPARC or T-1 based on workload”, I think such a thing might give incorrect predictions too often to be useful. Certainly T1 systems would not be an option on workloads with non trivial amounts of floating-point operations, or where one T1 isn’t fast enough (and clustering isn’t an option) though.

The easist way I can think of to reasonably estimate how upgrading to a T1 system would go in advance with just one calculation would be as follows: measure the number of instructions per second executed on your current system (retired micro-ops/sec for x86), then figure on a top-speed T1 system doing about 7 GOPS (billion instructions per second) in comparison. So if your current system averages around 2 GOPS under maximum throughput then a 1.2GHz T1 would likely be about 3.5x faster. If actual results are significantly different then it’d probably due to: too many fp ops, I/O limits, too much hot lock contention, inherant lack of multi-threaded scalability in the application, bad porting, or something else.

Putting it another way, the less ILP (instruction level parallelism) there is on the running system, the better the T1′s TLP approach should work in comparison.

PS I haven’t used any Niagara/T1 systems myself. My “7 GOPS” estimate for a 1.2GHz 8 core T1 is based on what seems to be typical IPCs (instructions per cycle). Most server workloads would probably be within 20% of that, though that’s based on figures mostly taken from blogs.sun.com entries. I’d sure like to see a table listing IPCs (or GOPS) for systems before they were migrated to T1, and after (with hardware specs).

http://developers.sun.com/forums/

and

http://www.sun.com/forums/

its always a bad sign of potential groupthink.

you want i should blog on the trackback issue? i tend to see that as a smapo killing issue, perhaps…

In fact, it would be really great if you could talk to all the employees of Sun who blog and get them to understand that the Internet is a two-way conversation and that they shouldn’t avoid getting customer feedback by turning off trackback…