Slashdot Mirror
Sun's MAJC vs Intel's IA-64
Shauna writes "Ars Technica has an informative article on the differences and similarities between Sun's new MAJC and Intel's IA-64 plans on the design-level. I think it shows in a round-about way that MAJC is going places while Intel sleeps. " The article is definitely designed for the chip fetishists in the audience.
Lisp machines, Intel i384(?) [ OOP ], etc. have failed because their abilities were emulated in faster-evolving general purpose chips. A special purpose chip may only be upgraded every three years or so versus, one or two times a year for Intel, PowerPC, etc. The solution for Sun is stay RISC'ish, but to adjust the instruction mix to be favourable to that used in JAVA code.
MAJC developers connection
A chat with the lead designer for the MAJC architecture
MAJC 5200 chip press release From MAJC docs page: First MAJC implimentation presentation.
Some comments... Firstly, I don't think it was made clear that the MAJC architecture can execute compiled C/C++ as easily as Java. You'd also probably be using a dynamic compiler like HotSpot rather than a JIT compiler. I think the guy got it wrong about the functional units being data agnostic - the registers definately are though. Still, you can (pretty much) execute 4 of any type of instruction at once - the first block is slightly different compared to 2-4 (which are indentical), though I don't know how. The very interesting STC concept is much easier to do with the Java programming model (because of certain issues with data) compared to C/C++. They don't say how easy it would be to apply STC to C/C++ though - might be impossible in the general case, though possible in some "limited" cases. The MAJC does also have scoreboarding for instructions for dynamic execution times eg loads, though I'm not sure if this applies to things like FP multi/div/sqrt etc. There's a couple of other interesting things the guy missed - the cross-bar data switch and the steaming data ports, for example. Though apart from that, I think it was a pretty decent review.
With regards to the first chip - the MAJC 5200, it's supposed to "tape out" (get first physical implimentation) by the end of the year and sample in Q2 next year. The 5200 has 2 CPU units on chip (with a shared L1 data-cache and a seperate L1 instruction caches), will be made on a .22 micron process, run at 500Mhz and consume 15W.
Here are some "here's how fast it is" stuff from the PR:
btw, Sun have a 2000 processor array for simulating their UltraSparc-III chip and they do do some pretty accurate simulations, including things like booting Solaris. In the MAJC 5200 PDF/PS file, they also quote some (estimated) speed-ups gained from using the STC technique for the SPECjvm98 suite of programs - they get from 40-60% or so, which I think is very impressive. The MAJC 5200 also has a graphics pre-processor (it's going to be used in Sun's new high-end graphics systems) and they quote some triangle processing figures with different levels of lighting detail. I don't really get what they mean, but they quote from 60 million triangles/s to 90M/s or so, which is in about the same region as the PlayStation2, or about 4x faster than the fastest current mainstream PC graphics card. However, that doesn't mean you can use 60m-90m in real world stuff...
In general, the chip is aimed at "low end" (though for Sun, "low end" equates to less than $100,000 generally) embedded solutions.
The first MAJC chip, the 5200, has a 32-bit 400Mhz embedded Rambus 'bus' for main memory - though it's actually a point-to-point link. If you read the details you'll find that (like with most new high end stuff) the MAJC uses a cross-bar switch instead of a bus, which is much faster and more scalable, but more expensive. It also has a 66Mhz (64bit?) PCI connector, has 2 250Mhz UPA connectors (UPA is Sun's equivilant of PCI). You can also line up a load of 5200s in a row, connecting one of the output ports to the next's import port, so you can pipeline a complex algorithm (eg graphics) across multiple chips.
compress: +51%
jess: +56%
db: +62%
javac: +67%
jack: +64%
mpegaudio: +55%
Personally, I think that's very impressive.
It's hard to believe threaded programming is used as little as this guy says it is. Every hiring manager who hears the word "thread" turns green and starts vomiting cover letters from people who write threaded programs it's just so trivial. Parallel programming is so simple your development times drop and your productivity shoots up.
As an embedded developer, I can heartily say: not bloody likely.
Would you risk the future of your company on a processor that is optimized for an interpreted language (ahh, memories of old Wang minis with BusinessBASIC CPUs!)?
They had a shot at the embedded market with the microSPARC. They missed badly.
Sun needs to pick a direction, and quickly. SGI is hot on their tail in the high-end workstation / super-server market. Linux / FreeBSD is eating away at their mindshare in the ISP / internet market. Motorola is killing them in the embedded market.
Oh yeah, the Javastation is going to save them. Sure.
Just about as likely as me going to my boss and suggesting building a system around a mutant CPU from this drowning company.
Embedded machines are not the only domain for this chip. It's scalability should make it the ideal choice for a server with hundreds of thousands of threads. So it not a bad thing at all to produce something like this.
Also Java has been rather unsuccesfull on the desktop but is quite succesfull on the server and is also gaining momentum in the embedded machines world. JIT is not the same as interpreted (which you are suggesting). JIT stands for just in time compilation. Another thing sun is working on is dynamic compilation which JIT taking advantage of profiling information collected during execution. One major advantage of dynamic compilation over static compilation is that you can use information that is only available during runtime for optimizations. One of those optimizations could be discovering paralellism. And its exactly this type of optimizations that is beneficial on a MAJC architecture.
Also the ability to combine a MAJC core with a DSP on one die seems like a killer feature to me for embedded machines where every extra chip increases the price of the product.
You seem to be under the impression that its not going well with SUN at this moment. Truth is that SUN one of the more succesful companies of the last few years, especially in the server market.
SGI on the other hand has had quite some reorganizations over the past time.
Linux doesn't have to be a threat to companies like SUN. SUN gets its most revenue from hardware, not from software.
"Just about as likely as me going to my boss and suggesting building a system around a mutant CPU from this drowning company."
Probably your boss won't consult you for this. In case you haven't noticed, I responded to each argument in your post, if you think I forgot one or don't agree: do reply.
Jilles
The Ars review incorrectly claims that Vertical Multithreading (switching threads at the hardware level when there's a cache miss) is unique to the MAJC architecture.
In fact, this is the basis of Tera Comupter'sMTA (Multithreaded Architecture) processors that are already being evaluated at the San Diego supercomputer center.
Threading is fine if/when you need it, but if used inappropriately can slow rather than speed development. If you need true concurrency, then you have no choice, but if you're using it as a way to "get around" blocking I/O, you're better switching to a single threaded event driven approach. Debuggging explicit state representation is easier than debugging multithreaded apps.
IMHO multiprocessing is easier to debug than multithreading since you don't have the potential problems of shared data structures unless you're explicitly using shared memory.
"Java ... is quite succesfull on the server
People keep saying that; perhaps I'm overlooking the obvious, but I sure don't see this."
OK, I can't put any examples out of my big hat and I'm to lazy to go and search for it. But considering the huge amounts of investments made by SUN, IBM and others on getting Java to work on any platform you can name, they must expect some return on their investment. You do the math, but that tells me Java is increasingly succesfull on the server.
"So if JIT is the solution, why do we need this beast at all? "
As I explained later on in my post, a dynamic compiler like hotspot can do something a static compiler (typically used for C) namely using information gathered at runtime to perform optimizations. This is a major advantage on architectures that require the compiler to optimize the instruction stream for the processor. Further more Java and threads are a good combination (one of the reasons for Java's success on the server). And MAJC is very good for running multithreaded stuff.
"If you're looking for paralleism in the instruction stream, we call that pipelining."
VLIW chips like MAJC and IA-64 do the pipelining in software (at least discovering paralellism and optimizing the instruction stream). It's not new I know. I just explained why a dynamic compiler has an advantage over static compilers in doing so.
"In short, all the claims they make about benefitting from multi-threading can be equally applied to other CPUs. What's left is marketing spew, positioning this as "Java-optimized". Which sure isn't going to help them in the market I know."
The market you are working in is changin rapidly. With fast chips getting dirt cheap, the rules of the game are changing. Coding everything in assembler is not really an option anymore because that slows down time to market. Similarly, more and more is implemented in C++ rather than C on many embedded platforms. I work together with Axis (a swedish company building embedded machines) for my research and I know their main problem is the fact that they have to maintain a huge source tree of C++ code (100K+ LOC). This slows them down in introducing new products.
So because of this, Java will become an option in your market too.
"In short, all the claims they make about benefitting from multi-threading can be equally applied to other CPUs."
I don't see that, the article was quite convincing in comparing IA-64 and MAJC. Only time will tell which is the faster processor since neither is available at this moment. Something tells me IA-64 will be a major disappointment. Maybe SUN will screw up on MAJC but the architecture doesn't sound half bad. More likely is that intel and motorola will 'borrow' some of the ideas for this processor in their next generation CPUs.
As has been pointed out before, Linux is not yet a good math on high end server platforms because it lacks certain features. Probably this will be resolved in due time but for now linux is not competing in that area.
"Price/ performance for Sun hardware"
Hardware and OS licenses are only small portion of the cost on big servers. These things have to be maintained by expensive staff and they have to run expensive, tailored software. If price performance of the hardware/OS was the only consideration, they would have been out of business long time ago.
On the long term I can see Linux replacing Solaris. Obviously all the UNIX giants (Sun, IBM, SGI) know this and are generally cooperative towards Linux (at least more then a certain Redmond based company).
Jilles