Visit Your Local PBS Station PBS Home PBS Home Programs A-Z TV Schedules Watch Video Donate Shop PBS Search PBS
I, Cringely - The Survival of the Nerdiest with Robert X. Cringely
Search I,Cringely:

The Pulpit
Pulpit Comments
February 29, 2008 -- Azul Means (Big) Blue
Status: [CLOSED]

Yes, but what about that Moon shot you are working on ?

someMartian | Feb 29, 2008 | 1:36PM

Does it not seem we are moving more and more away from apps running on client machines to getting the same work done on some server? If the apps, like Final Cut Pro or Logic or whatever, can take proper advantage of something like the Azul device, we will see subscription based licensing sooner rather than later. For Apple guys, like myself, this is what dot Mac will look like--tiered subscriptions based on the availability of apps viz:
Basic $99 tier has email & iLife suite;
Advanced $129 tier has iWork or Office depending on M$'s willingness to license Office;
Pro $299 has Final Cut Pro & Logic
Pro Creative $599 has Motion, Shake, Soundtrack, & the rest of the A/V tools.

Mac | Feb 29, 2008 | 1:46PM

Very disappointed in this weeks column, Bob. You've been around long enough to know that it's hogwash to expect ANY type of computer to double in performance in three years. Are you seriously telling me that my notebook PC provides double the performance of a similar model from three years ago?

Windows XP tends to disagree.

Funny how you pour such scorn on IBM's marketing (which is admittedly a bit suspect) but seem to buy so wholeheartedly into the spin from Azul. I may never hear about Azul again, but there are plenty of IBM z9 mainframes (not to mention the upcoming z10's) that are supporting millions of simultaneous users.

Some of them are even running Linux.

The z10 may be an IBM product and I know how much we all love to roast IBM at the moment, but I believe the z10 is the absolute pinnacle of computer engineering - certainly a product that is worth further *informed* discussion.

Damian Funnell | Feb 29, 2008 | 2:01PM

"IBM never fully explains its own benchmarks nor does it even allow others to benchmark IBM mainframe computers."

How could they possibly stop you? Threaten a lawsuit? That wouldn't stop you from posting something on the internet, would it?

Tom B | Feb 29, 2008 | 2:19PM

Very disappointed in this weeks column, Bob. You've been around long enough to know that it's hogwash to expect ANY type of computer to double in performance in three years. Are you seriously telling me that my notebook PC provides double the performance of a similar model from three years ago?

Windows XP tends to disagree.

Funny how you pour such scorn on IBM's marketing (which is admittedly a bit suspect) but seem to buy so wholeheartedly into the spin from Azul. I may never hear about Azul again, but there are plenty of IBM z9 mainframes (not to mention the upcoming z10's) that are supporting millions of simultaneous users.

Some of them are even running Linux.

The z10 may be an IBM product and I know how much we all love to roast IBM at the moment, but I believe the z10 is the absolute pinnacle of computer engineering - certainly a product that is worth further *informed* discussion.

Damian Funnell | Feb 29, 2008 | 2:27PM

Geez Bob, did someone from IBM run over your dog ?

Mike E | Feb 29, 2008 | 2:28PM

There are certain things that are programaticaly much easier to acomplish on a "mainframe" than on a cluster of conventional desktops.

Also you've got Moore's a little fuddled. It's that the number of transistors should double every 18 months or halve in size and thusly reduce (not by half) power consumption.

In reality 18 months was an under estimate, 24 months is A LOT closer to reality.

And number of transistors in processors isn't the only thing going on in putting out a new mainframe so it's been 1.5 doubling periods not 2 and power consumption has gone WAY DOWN not stayed the same or gone up by the 15% expected.

I'd say this machine is very close to what I expected for performance claims and very close to the reasonable expectations for people looking to replace their older units.

The power savings are a big deal, not because the power itself is THAT expensive, it's cooling all that wasted power that's a problem because cooling equipment is not terribly efficient, so now you're wasting 85W due to heat instead of the 65W you'd think at first glance. With the new setup you're saving power, getting a near doubling in speed and not having to re-write your critical business systems, and programmer hours are A LOT more expensive than processor hours, even on a $20m machine...

As for the 1500 Intel boxes... well I got nothing on that... maybe there was some drinking going on down in the marketing department.

As for the Azul box it's not flexibility it's actually highly specialized and thusly inflexible. Not to mention that at $1000/core I seriously doubt it can replace the 4 complete beige box machines that one can build for the same price. I high highly doubt it. So maybe the beige box doesn't transparently accelerate your Java, most people who need their Java accelerated are running multiple instances anyways and are perfectly capable of moving processes to another machine, or hell even using an automated system from any one of the two fist fulls of vendors offering that.

The Azul system solves a very specific problem in a very specific way and at a magic bullet price, you're a fool if you think everything is suddenly going to run oodles faster in the datacenter.

Most things in the data center are NOT process bound, they're either I/O bound or memory bound and loading a thread off to an appliance over the network and then back to chew through some work is going to make it slower, unless you have a very specific compute bound application or one that's memory bound but somehow doesn't need more than 1GB per process...

And say you ARE in that place and things are somehow highly parallelized, highly compute-intensive, not I/O bound and don't require oodles of memory; you should probably look into using that new-fangled GPU processing and save yourself half a million dollars.

Noah | Feb 29, 2008 | 2:36PM

Sorry if that came off as harsh, I did like this article and I do think that Azul and other technologies like it DO for sure have a place, it's just not accelerating the whole datacenter as some magic bullet.

This article really was better than the preceding 3.

Noah | Feb 29, 2008 | 2:42PM

We are from Infiscale, makers of Caos, Warewulf, Perceus and a plethora of free open source HPC solutions. Our software powers the majority of systems at top500.org. The need to buy a single proprietary computer for 20 million is dead. With our software (that is even available embedded on some of the Intel motherboards) you can build a supercomputer with whatever you can get your hands on. It is the stuff that companies like Azul use to glue the multiple systems togeather. IBM even uses some of our stuff. Also, be sure to not just listen to the number of tflops or anything like that until you know what you will use your cluster for. For instance, certain things might like the z10, while other stuff might run considerably faster on a system made from using our stuff to glue 10k white box's togeather. The benchmarks for HPC are not like horsepower ratings you get for a car, and as far as java, most people try to keep java as far away from the cluster as possible. Just my 2 cents

Joe Dreak | Feb 29, 2008 | 2:51PM

We are from Infiscale, makers of Caos, Warewulf, Perceus and a plethora of free open source HPC solutions. Our software powers the majority of systems at top500.org. The need to buy a single proprietary computer for 20 million is dead. With our software (that is even available embedded on some of the Intel motherboards) you can build a supercomputer with whatever you can get your hands on. It is the stuff that companies like Azul use to glue the multiple systems togeather. IBM even uses some of our stuff. Also, be sure to not just listen to the number of tflops or anything like that until you know what you will use your cluster for. For instance, certain things might like the z10, while other stuff might run considerably faster on a system made from using our stuff to glue 10k white box's togeather. The benchmarks for HPC are not like horsepower ratings you get for a car, and as far as java, most people try to keep java as far away from the cluster as possible. Just my 2 cents

Joe Dreak | Feb 29, 2008 | 2:52PM

We are from Infiscale, makers of Caos, Warewulf, Perceus and a plethora of free open source HPC solutions. Our software powers the majority of systems at top500.org. The need to buy a single proprietary computer for 20 million is dead. With our software (that is even available embedded on some of the Intel motherboards) you can build a supercomputer with whatever you can get your hands on. It is the stuff that companies like Azul use to glue the multiple systems togeather. IBM even uses some of our stuff. Also, be sure to not just listen to the number of tflops or anything like that until you know what you will use your cluster for. For instance, certain things might like the z10, while other stuff might run considerably faster on a system made from using our stuff to glue 10k white box's togeather. The benchmarks for HPC are not like horsepower ratings you get for a car, and as far as java, most people try to keep java as far away from the cluster as possible. Just my 2 cents

Joe Dreak | Feb 29, 2008 | 2:54PM

I don't know why you are even bothering with the blade server concept. I know companies are still pursuing a blade design but its a joke. You talk about virtual machines being inflexible, try working with blades. They were obsolete before they ever took off.
As far as Java being as fast as C++, sure it is, when Sun says so. Don't beat up IBM for hiding their benchmarks and make it ok for Sun.
As far as 'Moore's Law' goes, it was really only a Theorum until you journalists(wannabe techies) got hold of it and made it a Law. Did it ever occur to you that maybe it has now been disproven?
The z10 may be more expensive per CPU but it more than makes up for it by not needing as much electricity to run. Let's face it Bob, peoples needs have changed. We can all get gobs and gobs of additional horsepower now but that is not the requirement anymore.

Architect | Feb 29, 2008 | 3:03PM

Bob,
I'm not sure that you can make this comparison this easily. What sets the mainframe apart from your 4 core Opteron (and any x86) is the reliability. Dividing cost by number of machines is only a fraction of the story, and misses out on the savings for not having to replace (and reprovision, and restore, and calm down the CxO) 1% of your x86 boxes every day.

If you're buying on cost and you are a small company (or a one-trick pony doing non-critical things like internet searches), this approach makes sense - especially if you can't achieve the economies of scale. If you want to run a real workload (like a bank, a hospital, a credit card company) you'd be crazy to consider anything other than a mainframe - unless you're ok with misplacing a period here and there in your millions of transactions per day.

Think of reliability as a "pounds of hardware" statement. Azul is ok if you're small, but scaling up just means you add more silicon and metal to fail.

Good article, just be wary of "one size fits all."

Brian | Feb 29, 2008 | 3:24PM
Well now Azul -- not just with its custom hardware but also with its unique multi-core Java Virtual Machine -- has made those arguments moot: Java finally IS as fast as C++.

Well, I'd really like to see that. That's actually impossible to achieve. Native code (C++, C, Pascal, etc.) will always (guaranteed) be faster than a byte-code - e.g. JVM, CLR. Guaranteed. Now MS did quite well with the CLR to give it very good performance on Windows - but sacrificed portability to do so. JVM keeps portability and runs slower. So call me a kook before I fall for that one.

delays caused by Java's automatic garbage collection routines. Azul handles garbage collection in hardware rather than in software, making it a continuous process that keeps garbage heap sizes down and performance up.

Hmmm...I'd really like to see this too. My only guess is that they really coded it into the EFI/UEFI/BIOS of the appliance and are just saying "the hardware takes care of it" as a result - since Marketing won't know the difference any how. It's a little hard for hardware to do that kind of task on its own. Again, call me a kook before I fall for that one.



Now, really the only thing that really makes sense, from how you've describe the Azul Appliance, is that it is simply a base computer with a number of hardware byte-code processors - which basically means dedicated hardware to processing Java code that runs a low-level implementation (Assembly) of a JVM. That would explicitly guarantee that it will only run Java applications, and thus only be good for big Java centric data centers. Certainly not something flexible, nor something that would extend to C, C++, or any other programming environment for that matter.

And flexibility is what this is all about, because Azul's assistance is provided both transparently and transiently. Java apps don't have to be rewritten to accept assistance from the Azul appliance. If it is visible on the network, the appliance can assist ANY Java app, with that assistance coming in proportion to the amount of help required based on the number of cores available.

Ah...yes...drop a box in an it magically works. Sorry - but no. At minimum you'd have to reconfigure the application to use the Azul Appliance, and more likely you'd have to plop in some JAR file that would enable it to see/find/use the Azul Appliance - a file that you'd then have to enable your application to run, and be able to use to determine what kind of work the Azul Appliance can help with. Nothing magic about it.



As other have said - I thought you'd been around long enough and were technologically smart enough not to fall for these things.

TemporalBeing | Feb 29, 2008 | 3:28PM
Native code (C++, C, Pascal, etc.) will always (guaranteed) be faster than a byte-code - e.g. JVM, CLR. Guaranteed.
That's only true until you start allocating memory from the heap. malloc() has to do many of the same things a garbage collector does—only the engineers spend less time optimizing it because a few extra milliseconds per allocation is less embarrassing than a half-second pause every couple minutes.

(If you're thinking of the bytecode/native code distinction--remember, if you have a Java CPU, Java bytecode *is* native code.)

Brent Royal-Gordon | Feb 29, 2008 | 4:21PM

"Well, I'd really like to see that. That's actually impossible to achieve. Native code (C++, C, Pascal, etc.) will always (guaranteed) be faster than a byte-code - e.g. JVM, CLR. Guaranteed. Now MS did quite well with the CLR to give it very good performance on Windows - but sacrificed portability to do so. JVM keeps portability and runs slower. So call me a kook before I fall for that one."

very true. only thing is azul's native code is java's bytecode - it's a Java Real Machine if you will (at least that's what the article said). So yeah, Java on Azul is as fast as C

horia314 | Feb 29, 2008 | 4:29PM

@TemporalBeing
You missed on a couple of very fundamental points.

That's actually impossible to achieve. Native code
(C++, C, Pascal, etc.) will always (guaranteed) be
faster than a byte-code - e.g. JVM, CLR.
Guaranteed.

Wrong. I wonder how you back your guarantee. It =can= be as fast, because the JIT (Just In Time) compiler converts the byte-codes to native assembler-style code on the fly. So the issue becomes how good is the compiler at generating JIT-optimizable code.

...hardware to processing Java code that runs
a low-level implementation (Assembly) of a JVM.
That would explicitly guarantee that it will
only run Java applications,

Wrong again. Although that's not what I think they did, it means it would only run a particular byte-code set. That's distinct from the language. You could write a Fortran compiler that would generate some particular set of byte-codes.

Chad | Feb 29, 2008 | 4:35PM

Native code (C++, C, Pascal, etc.) will always
(guaranteed) be faster than a byte-code - e.g.
JVM, CLR. Guaranteed.

Is that a money-back guarantee? Am I allowed to do runtime loop optimization for the test? Didn't Niklaus Wirth's compiler emit p-code?

BTW, Bob, we've had NTPL on Linux 2.6 since Fedora Core 2, in October of 2003. Are you talking about the Completely Fair Scheduler, which allows for better CPU access among those threads?

Bill McGonigle | Feb 29, 2008 | 4:36PM

There's so much MIS-information here it boggles the mind....

Java is JIT'd - *compiled* on-the-fly, and has been for the past 10 years. Code quality is quite close to "C/C++ -O2". So Sayeth an Expert: ME. I write the optimizing compiler inside the JVM, and have written optimizing compilers for Big Name Company's that got peak SpecInt scores.

Azul's CPUs are classic 3-address RISCs. NOT direct bytecode-execution engines. Like most 3-address RISCs, they make an excellent JIT target.

Finally: I *can* write a small program which will run 1,000 times faster in Java than in C - and also write the reverse - 'cause I know what the compilers can and cannot optimize. Bytecodes got nothing to do with performance; it's all about what the various C & Java-JIT optimizing compilers can do.

Cliff

Cliff Click | Feb 29, 2008 | 4:39PM

That darn Solaris, now it's a waste.

No x86, lousy at scaling to multiple cores.

Oh right, I forget this is a Sun Free Zone.

elmegil | Feb 29, 2008 | 5:09PM

srsly, pls writ bout smthg othr than ibm. kthx.

hello_kitty_sms | Feb 29, 2008 | 5:14PM

Back in 1996/7 I used JNI to get efficient computation with Java. Once the good JIT & hotspot compilers came in, A/B comparison told me it was a waste of effort. In some cases I even got faster execution from JIT than from the C++ compiler I was using.

Brian Davies | Feb 29, 2008 | 6:22PM

Back in 1996/7 I used JNI to get efficient computation with Java. Once the good JIT & hotspot compilers came in, A/B comparison told me it was a waste of effort. In some cases I even got faster execution from JIT than from the C++ compiler I was using.

Brian Davies | Feb 29, 2008 | 6:23PM

Back in 1996/7 I used JNI to get efficient computation with Java. Once the good JIT & hotspot compilers came in, A/B comparison told me it was a waste of effort. In some cases I even got faster execution from JIT than from the C++ compiler I was using.

Brian Davies | Feb 29, 2008 | 6:24PM

Oops - Captcha said it hadn't posted and made me do it again - twice!! Maybe a bug in Captcha

Brian Davies | Feb 29, 2008 | 6:27PM

Come on, Cringely, this is just stupid.

When you pay $20 million, you are not just buying 1500 PCs, you are buying an OS and a collection of surrounding software. Now you may think that OS and the software are obsolete and not worth that sort of money but, in that respect, you're no different from Linux-heads who don't understand why anyone pays for Windows.

The fact is that there is a class of people for whom, for better or worse, what Windows offers makes sense at the price; and likewise there is a class of people for whom zOS makes sense at the price. This article would have been a whole lot more interesting and useful if you had told us something about this class of people --- how much did they spend last year, is what they are spending rising or falling, are they replacing zOS with linux on PCs or are they simply shifting sideways to other IBM offerings (whatever AS/400 and RS/6000 are called these days).

Maynard Handley | Feb 29, 2008 | 8:48PM

I would think that AS/400 and RS/6000 would be called zOS these days

John | Feb 29, 2008 | 9:54PM

mmmm.... You are about 28% in your schedule to your trip to the moon... I guess you should stop spending your time in silly colored things, and focus on the Google price... The 1/3th milestone of your aggressive plan will be pretty soon!

In most of the engineering projects that means you should be reaching Design Validation.

Will be great to hear were the Team Cringely stands.

--CgS->

Carlos | Mar 01, 2008 | 12:15AM

Hmmm, that rather misses the point on Linux, processes have long been as light as threads on other OSs, and it has long had good threading.

How about something more plausible, like Erlang going mainstream? Once upon a time, the stuff of telcom high availability switches and such (Erickson claims as much as nine nines of uptime for their high end switches, running on 2 million lines of Erlang), and now going mainstream, and it's GPLed.

Ronald Pottol | Mar 01, 2008 | 4:45AM

Wow. Thanks Bob for the kind coverage... I hope we can power one of those data centers you rent virtual servers in someday soon.

As for some of the respondent comments - here are some follow-on notes:

- Azul's appliances deal with memory bound & I/O heavy applications as well as they do with CPU bound ones. Think Hyper-channel with a coffee-bean boost. Our sweet spot actually includes memory hungry, as well as I/O intensive java transactional applications. Some of our customers are currently running multiple Billions of individual transactions per month, per appliance (with each transaction having a nice chunk of I/O and memory footprint and bandwidth).

- No funny BIOS+Marketing tricks here. It's not all hardware (some very real GC software wraps it together), but our very real hardware support for GC (built into each of our core's instruction set) is what allows us to actually run highly responsive systems with heaps as big as 300GB heaps, and sustained allocation rates of 20GB/sec or more, all with GC actually keeping up concurrently. Non of that multi-second pause stuff, or those multi-minute java coffee breaks... [and these are real, customer systems I'm talking about, not silly lab games].

- Being able to handle these sort of numbers means that a measly 3GB heap, or tiny little 30GB heap is just a walk in the part for an Azul appliance. They are so far into our smooth operating range (while being so far out of a "normal" JVM's) that they "just work". Memory bound is our forte.

- Inside, the boxes are real, flat SMPs: up to 768 Azul cores in a symmetric configuration, with >100GB/sec of sustainable, fully symmetric memory bandwidth. Packing 48 cores on a chip, and full-mesh-interconnecting 16 chips (yeah, that's just under 2000 Multi-Ghz wires) that in turn drive 192 DIMMS is how we brute force this thing to life... Our engineers certainly had fun building this thing.

- Azul's JVM uses state of the art JIT compilers, that feed optimized code to our cores. Our CPU cores were designed specifically to make very good JIT compiler targets. No bytecode-in-hardware games here (that would be so 1990s...)

- You don't have to need or use our "monster" (14U,

- And finally, some "little" companies (like Bear Stearns, British Telecom, CitiStreet, Credit Suisse, Wachovia, etc. ) are using Azul in production, mission critical apps. Not the sort to forgive a misplaced decimal point in their transactions...

-- Gil. (CTO, Azul Systems).

Gil Tene | Mar 01, 2008 | 5:20AM

The comment posting thingy seems to have eaten up my line. The chopped off bullet above was:
...
- You don't have to need or use our "monster" (14U, 3300W) 768core/768GB boxes to gain from Azul's benefits. Our configs start at 96cores/48GB (5U). Many of our customers use us for 1-2GB heaps, and for dev/QA purposes.

-- Gil. (CTO, Azul Systems).

Gil Tene | Mar 01, 2008 | 5:29AM

Someone's been buying poor laptops. Being in the software development industry I purchase laptops and desktops every 3 years and yes, they damn well do follow moores law.

Of coarse I write alot of 3d graphic and utilize alot of multithreaded ray tracing/rendering applications. If there is a core missing (as there were 3 years ago) my clock sure as reflects it. Ever try to render a raytraced 30 second commercial in a day on your desktop..? Next year's purchase of an 8 core will take that day (days) and turn it into just hours.

Steveorevo | Mar 01, 2008 | 7:25AM

I don't think using the name tsunami was bad luck. It was bad marketing. Tsunamis have always been dangerous killers on a big scale. Relating this to technology, a tsunami was the big killer after the eruption of Krakatoa. According to Simon Winchester's fascinating book about the event, the eruptiuon of Krakatoa was the first global news event to be spread by the Internet of its day: the telegraph. But I digress...

Mikey | Mar 01, 2008 | 8:29AM

$13,333 per beige box is almost irrelevant if you are looking at "cost of ownership" and not "cost of acquisition." The major cost in running a server farm is the people. How many people does it take to run 1,500 beige boxes vs. running 1,500 instances of Linux under VM over the life of the machine(s) is the real question.



Those stories about someone running 40,000 instances of Linux under VM were a "test to destruction" and weren't intended to show how many people could run Doom or any other application. I'm also pretty sure that IBM, at the time, stated that 1,000 or 1,500 instances of Linux under VM was a more realistic situation.



The z10 is coming out three years after the z9 because IBM doesn't want to anger their customers by making their expensive purchase of a z9 look like a bad investment. The z9 isn't a desktop, it gets depreciated over a period of years, not weeks .



Trying to measure the speed of a computer today is about as accurate as consulting the entrails of a goat to predict the Democratic nominee for POTUS. The only speed measure that matters is how fast does it run _your_ workload. Sadly, IBM's benchmarks are for chargeback purposes.



Mainframes like the z9 and z10 have their place, you're complaining that place isn't in your basement running iTunes. That's silly.

Craig | Mar 01, 2008 | 10:03AM

Having 'grown up' working on IBM mainframes and compatibles (my first industry job was with Amdahl Corp.), I have heard the MIPS argument for a long time. But comparing mainframe CPUs with other computer CPUs is like comparing a Mack truck engine's RPMs to a motorcycle's RPMs and then claiming that the motorcycle is equal or better.


In the 'good ole days', IBM mainframes had 16 - 64 I/O channels. These were computers in their own right that could write directly to memory. So the main CPU was not involved in I/O processing, it simply issued a command for data and started processing the result when it showed up in RAM.


There was also the reliability factor. By the early 80's, memory had enough Error Check & Correction (ECC) bits that single and double bit errors could be corrected on the fly, while triple bit errors were detected and the memory page marked as bad and unused until the card could be replaced. Also, there were 'gates' built into the hardware to provide support engineers with the status of each step of the pipeline, cache memory, and several hundred other points, so that troubleshooting could identify the exact component to be replaced quickly--on site.


Personally, I jumped ship into the *nix world at the new millenium, and have not kept up with mainframe technology, but I am sure that it continues the tradition. I am certainly impressed with the capabilities of clusters and high-end Silicon Graphics/Sun/HP/etc. boxes. But real mainframes are not just jumbo versions of PCs, and their buyers do get what they pay for.


Later . . . Jim

JJS | Mar 01, 2008 | 12:16PM

Bob,

Now that your publishing career has dwindled to essentially reprinting press releases you don't understand it may be time to consider "hanging it up." As mentioned by numerous commentors, PCs and Mainframes are very different beasts in both processing capabilities, reliability, and manageability. I have a great deal of respect for the Linux operating system, but it's not yet anywhere near "Mainframe-class." Your column goes downhill from there, and frankly you sound more like a mouth-breathing PR flack than you do a serious commentator.

Erik The Red | Mar 01, 2008 | 1:12PM

When I started reading about Java I rolled my eyes. Having done troubleshooting on countless Java apps bombing, it's sad that it's still being forced on us. ColdFusion 7, which was built upon JVM's (Java Virtual Machines), bombs when someone farts. Java was the end of Netscape as their Java browser was one huge pile of junk. Then there's the many versions of JRE's that are required for various apps. Of course none of the JRE's can be installed together and of course you can't use new JRE's for older apps. Nice. Wow that Bill Joy and all the Sun Java developers are such geniuses. What a bunch of baloney.

Java is a mess and I applaud Cisco for allowing us to do PIX management from a good old .exe or another worthless Java app. Guess which one I picked?

allen shipley | Mar 01, 2008 | 2:01PM

The technology behind Azul is interesting, but it's an over-fit to most datacenter workloads and an over-fit for most CIOs who are hoping to have fewer vendors and not more. Finally, vendor viability is a concern for CIOs -- they aren't going to make a datacenter architecture-level bet on a highly specialized piece of non-repurposable gear from a vendor whose longevity is uncertain.

Azul's technical approach is unique and clever, so if the goal was to highlight an interesting piece of technology, mission accomplished. If the goal was to predict the future direction of computing, this is not it, unless by chance a big vendor buys Azul. Even if that happens, it's still a longshot as an architectural approach, and any acquisition will be at a price that causes Azul's backers to lose their shirts.

It's a troubled company that's consumed an absolute mountain of money, has been through legal wranglings with Sun, has had CEO turnover, and is now out searching for still more investment capital (or so I hear). This story isn't going to end well, Bob. You've been duped by the PR.

oops.bob | Mar 01, 2008 | 4:19PM

I can't say anything that was not already said above. So here goes a unique question, to have Azul's CIO posting here and you doing all this misinformation on your article, how much stock was it worth ?

ok | Mar 01, 2008 | 5:00PM

Unfortunately, most Java application bottlenecks aren't produced by slow-running garbage collection routines, but from poorly designed and implemented code that relies on even slower database and mainframe connections on the backend. Azul's solution is a great one for applications that have reached the level of caching and concurrency that *should* be present in most Java-based applications, but unfortunately, we see that this is just a fraction of the latency experienced in most applications we end up tuning. Three cheers for Azul, but for those of us in the trenches, the best (and most difficult) remedy is simply finding ways to better design, develop, test and monitor applications so that they run without a hiccup.

Clay Roach | Mar 02, 2008 | 6:09PM

> I wonder how many of those 40,000 parallel Linux images were simultaneously running Doom?

Doom!? You mean the revolutionary first person shooter from 1993? With 2d sprites and
My 3 year old cell phone can run Doom.

If you want a modern game that will show the limits of modern hardware try Crysis or MS Flight Simulator X.

paulwesterberg | Mar 03, 2008 | 4:29PM

Why not replace an IBM z9 with Platform Solutions Open Mainframe Server with Dual Core Itanium 2 CPU's?

Bryan | Mar 03, 2008 | 5:41PM

Is custom build really faster than general Purpose?

Many people think, that custom chips for appliances are faster for their respective task than general purpose chips. For such areas like graphical processing this is true. GPUs are so powerful, many people think about their usage in computing. But i made an interesting observation in the SPECjbb2005 list: The company Azul Systems developed a special purpose processor for Java. The top of the line 7280 system consists out of 16 processors and provides 872972 SPECjbb2005 bops. Thus the performance per processor is 54561 SPECjbb2006 bops. A single T2000 has an perfomance of 96523 SPECjbb2005 bops. Thus the general purpose processor UltraSPARC T1 (okay, almost general purpose) has twice the performance of the custom build Vega2 processor on a per core basis.

Another comparision is interesting to: Assume a workload that can be scaled horizontally . You need an aggregated performance of at least 850.000 SPECjbb2005 bops. You could use 1 Azul 7280 or 9 T6300 blades. You would assume that the Azul solution is more efficient. But the the 7280 takes 14 rack units and is rated with a typical wattage of 3250 Watts (as specified on their website). 9 T6300 would have a size of 10 rack units and round about 2700 watts. With Intel C2D the performance calculation would be similar, although not in the same power envelope.

The Azul system has an different advantage, it provides a single image to application, thus the java application would be able to use the full 756 Gigabytes of memory. But at the end, it´s an interesting evidence that custom build hardware isn´t necessarily faster or more efficient than general purpose hardware.

http://www.c0t0d0s0.eu/archives/3351-Is-custom-build-really-faster-than-general-purpose.html

anon | Mar 03, 2008 | 5:51PM

"My e-mail application runs on a four-core Opteron server," says a techie friend of mine, "but I've seen it have over 4,000 simultaneous connections - 4,000 separate threads (where I'm using "thread" to describe a lightweight process) competing for those four CPU's. And looking at the stats, my CPUs are running under five percent almost all the time. This stuff really has come a long way."

so those 4 cpus aren't doing anything? how is that impressive? does it mean all those connections are so slow that combined they aren't able to load up the cpus?

"...we now have data structures where no thread waits for any other. In fact, if one thread gets swapped out before it's done doing the update, the next thread detects this and helps finish the job."

ah, maybe you should do a little more research into how multithreaded apps work.

supersaurus | Mar 03, 2008 | 7:32PM

Uh... WTF?
Bob is off his meds again.

Kyle Huff | Mar 03, 2008 | 10:42PM

Bob,

Once again you must be commended for bringing out a story that stirs up the pot. The goal of the great journalist is never to fall prey to parrot the public relations of any side of a story or be a willing accomplice to brand marketing and blindness. It is to incite insight and fervor among the diverse recipients of the journalistic endeavor. Rarely in the recent IT news and blogosphere have I seen such a quick response of such emotion, technical depth and diversity on such a narrow and typically inane subject. Bravo!

The IT world today is comprised of two major pilars: technology and money. What many forget is that the moment you invest time (your life) and money in technology you become captive to that investment. Once you invest, you are inherently exposed, you have now an achilles heel against those who have not yet invested. That's why companies like IBM and Microsoft are always in fear of new garage start-ups and must fine tune their exposures into technological religious fervor and brand power for those who have committed to something already in the past, like the traditional mainframe.

What everyone always forgets is that business is a human endeavor and that despite the process and business transformation con artists each business is essentially unique and even as different as the DNA combinations of the humans who power a business. This makes it impossible, except for specific and narrow examples to ensure that any or technological advance will work for any IT environment except for those that don't exist yet.

The true business person may accept these technologies and consider them, but they know it can't guarantee it making them money. None, some or all of these technologies may be implemented into some IT environment and bring about the promised return on investment. Just look at the fine print in IBM's announcements and "Green Data Center" contracts. They actually promise nothing.

The savvy businessperson will be the one who can craft language in contracts and technology selection techniques that makes "green" truly "green" and financially viable and reduces risk by implementing penalties, reducing vendor/integrator profit etc. as it it integrates "green" into current IT environments.

I predict just like we saw ERP disasters for those who drank that Kool-Aid we will see "green" disasters in data centers.

Armonk Anti-Christ | Mar 04, 2008 | 12:37AM

For a datacenter mutil-vendor is more security not
less. This is the ending footnote for legacy MVS,
COBOL and JCL systems.

I would not hang my hat on any of it. But it is
amazing it has hung on this long. They finally turned off ENIAC, are there any pdp-11's out there. Any Perkin Elmers running?

What a giant server does is just hang a big bullseye on one target. But go IBM at least there is still some competition for the M$ megalith. Linux is the future, SUN has dropped
the ball and needs to update its architecture to
the HP model of hardware. But mid-range servers are where all the dollars gravitate. PC, Laptops are washing machines. So the specialized mega-computers are more bragging rights. Mainframes are dinosaurs roaming around waiting for the final
asteroid of technology to bludgeon them once and
for all.

KnightOfMalta

Jan Clairmont | Mar 04, 2008 | 9:03AM

Bob,
Every few years, someone resurfaces the idea that mainframes will die or have died because it is less expensive to aggregate a bunch of processors and interconnect them with a network or a "fast" switch. This started with minicomputers in the 1970's and really gained momentum with UNIX and Sun's "The Network is the Computer" campaign of the late 80's early 90's. The emergence of parallel super-computers in the early '90s, like Teradata's business intelligence engine and IBM's Scalable Parallel SP machines in the early to mid '90s, added to its momentum . In the 1990's, "Client Server" computing kept it going. However, in the late nineties, the operational costs of distributed networks grew rapidly as admin, network, software, environmental and outage costs began to supersede the price of hardware. And so the notion of the "mainframe" as a viable solution for consolidated workloads began to re-emerge. Ultimately this led to the current wave of virtualization and consolidation, in which Linux on system z, and z/OS on system z with "specialty engines," participate. At the same time the supercomputers and highly parallel machines got commoditized, leading to blades and Intel/Linux based super computers like "Blue Gene;" and configurations of commodity servers emerged in places like Google.

The twin trends of commodization/parallelization and consolidation/virtualization continue. Neither type of machine configuration will die. The very latest technology will be put into both commodity style Google-esque configurations and mainframes. To characterize the mainframe with the caricature of "old fashioned hardware" that will be swept away by the "modern" notion of distributed, parallel processing is really no different than the caricature of the massively parallel commodity machines as a "solution looking for a problem" that will ultimately be consolidated into more "sensible" classic mainframe-like designs. The reality is that both types of machines will continue to be of great use, and cross pollinate as time goes on. As for z10 being a PR triumph, there is plenty of hype from all corners of the server business, some of which is self-evident in the responses to your article. The very benchmarks that you talk about are a significant part of it. Generally speaking, they are far more parallel than many of the workloads actually run on IT. They are designed to show the advantages of highly parallel, highly distributed configurations. In fact it is fairly easy to see that the marketing agenda of all the vendors who wanted to prove that distributed client-server computing is better than the "old fashioned mainframe computing" is written all over the benchmark definitions. Think about it, the mainframe gets about 1/3 of IBM's vote on both TPC and SPEC. Whose marketing agenda do you think the industry standard benchmarks follow? I hope that your readers are not naive enough to assume that these benchmarks are pure technical works after an objective "truth." They are not.

The end result is that, over time, the many machines (including IBM's Power and x) have all been designed to that benchmark set and the mainframe is not. When the work does not match the parallel paradigm, the benchmarks fail to represent reality; and, their ability to show relative capacity falls apart.. Since the mainframe is designed for the more serialized environments of much of the work done in IT today, the benchmarks do not represent its relative capacity. Thus it is not worth the expense to run and publish them. IBM will stipulate that when Industry standard benchmarks are an accurate representation of real work, System p is by far our superior offering. We know that many workloads are not well represented by the benchmarks. Many of those workloads depend on low latency to shared data, whereas the benchmarks represent workloads where capacity depends on high bandwidth and low contention for " thread private" data. We also know that system z is the only machine designed specifically for large instances of the former workloads. The mainframe is also designed to run a mix of workloads which share files in memory. None of the benchmarks drives this. This mixed workload optimization is present in its virtualization implementations, PR/SM and VM, as well as in z/OS. Some of those characteristics also rub off on Linux on z.

One could argue that converting workloads to a more parallel form is a "small matter of programming". In fact such a programming revolution has been advocated by many for the last 35 years. While many new parallel codes have emerged, they have not displaced the SMP shared data programming model. Given the rising expense of programmers and the falling expense of hardware and software (even on mainframes), I would expect that the legacy codes will continue to drive both paradigms forward for many years to come. Fantasies abound on both sides of the issue. The fact is that technology and legacy will continue to grind away, creating a reality that doesn't live up to any of them. What is important is matching machines to the work they are going to do, not some idealized notion of which is "better", "faster", "more advanced", "mature" or "modern".

High core count designs like Azul, and Sun's Niagara machine, are extreme examples of parallel designs. Azul takes the idea a step further in making engines which are designed to run JAVA byte code in a native way. This is an example of specialized optimization for an appliance that performs very well for a particular type of load. IBM's cell processor is another example. These types of appliance engines will proliferate and get better at their tasks. Over time, the mainframe and other general purpose machines will find ways to integrate appliances into their configurations on better connections. A current example is the HOPLON game configuration, which teams a mainframe data server and administration with cell processors to do the physics.

Using system z for consolidation is a not a blanket solution. To use your example, servers running Doom would not be included in the consolidation unless they were running at very low utilization; and probably not then without the assist of something like cell--ala Hoplon. On the other hand, there are successful consolidations of Oracle databases on z Linux such as was done at the Government of Quebec. While the individual servers involved were not terribly busy, one could not say that they were idle, either. Such consolidation would not have taken place if the economics were simply based on hardware price and how fast the engines run. There is enough of this kind of opportunity for system z and its customers to keep Linux on z growing. There are many factors involved in server selection processes. The price/performance of the hardware is almost never the sole driver, and often it is not the principle driver, either.

Others have made points about Azul finances. Regardless of what happens, such machines will continue emerge. My guess is that none will "take over." The power of legacy will remain strong, unless someone comes up with an inexpensive replacement for programmers. Also, their reach will be limited by the specialized optimization that is inherent in their designs. Each of the "current" machine types has had years creating legacy. The mainframe is the granddaddy of them all, but it is less than 10 years older than UNIX, and only 20 years older than Windows. All three are middle aged, in that they are younger than you and I (well me, anyway). I used to say that Linux was the only one that has not yet reached drinking age, but it, too, is now approaching "young adulthood," creating a legacy of its own. That legacy is quite pervasive with applications running on embedded processors, clients, blades, Intel and UNIX servers, supercomputers and mainframes. It falls on both sides of the parallel/distributed versus virtual/consolidated divide. Some applications can reside on either side as well. Others are too heavily optimized for one side or the other.

I suggest that you read two books: The first is In Search of Clusters by Greg Pfister (Prentice hall). The second is Guerilla Capacity Planning by Neil J Gunther (Springer). Both authors have an appreciation for how workload affects machines, the applicability of benchmarks, and how relative capacity is not simply governed by "Moore's Law" which, by the way, applies only to microprocessors density and not to systems capacity.

Joe Temple
IBM Distinguished Engineer

Joe Temple | Mar 04, 2008 | 6:49PM

Bob,

Joe Temple is right. The mainframe or primary multi-function server is not dead and will never die. The history of computing shows us that we had only one good technique with centralized computing in the early days and then more options became available to the designer as new technologies emerged. Today we have many design options for the corporate IT designer/builder/re-modeler. IMHO, I believe that it's pretty safe to assume that tomorrow we will have more to choose from. On the other hand, none of the options have died, they have just transformed themselves and been optimized.

As each new design alternative has arisen, the share of the other changes to accommodate the total market. Sometimes the market size changes dramatically, as it did with the advent of the mini-computer and the microprocessor server.

History, however, does bring out several salient trends we must not ignore. In the beginning, there was the mainframe and it had the entire market share. As each new technological option arises and takes its place in the minds of corporate IT designers the mainframe has steadily decreased its share and has never truly grown back at any stage to its pre-eminent past. Yes, maybe MIPs, prices, shipment counts change for a while, but as each technology option emerges the original technology option, the centralized mainframe, inexorably loses just a little more in the eyes of the market. IBM has very aptly re-heated the mainframe to make it appear like it espouses many of the past emerging options, but let's remember that just like Joe talks about clusters and different types of computing having different characteristics we must always remember that despite all the open systems BS and the rhetoric of IBM marketing a proprietary OS mainframe is a mainframe nevertheless. And these words are coming from a veteran who survived OS/MVT, DOS, FS, Pacific, STS, Fort Knox and a thousand other IBM nightmares in my decades at the Blue Pig.

So the mainframe will never die, but it's future will never be as bright as it was at the beginning. It's like a collapsing supernova star, getting denser, stronger, gravitationally entrapping and better as it collapses and successfully services a smaller yet more loyal market following of technological religious zealots. It can be re-packaged, re-branded, with more "in" features and "cool" technologies, but it's still the same old concept and it still carries it proverbial technological baggage from the past.

As I have stated before, most humans in technology have a personal defining "moment" or a time when they were tested and triumphed. Unfortunately, it is normal human behavior to once having been intellectually tested the normal aging technologist's mind kinda calcifies and begins to resist change and closes itself to new radical design. This is why many embrace the mainframe, the mini-computer, Microsoft and yes, even Java and Linux. Once it works why take a risk again and change? (BTW, this is a great story for another time...where are the true innovators and risk takers in corporate IT?)

IBM is a brand that has successfully acquired strength and staying power out of this normal human behavior. It has built a culture around the mainframe and other areas of the IT business, much like Apple. Nothing wrong with that, but just as the alternatives like Azul, Linux, etc. shouldn't kill the mainframe and make IBM irrelevant, neither can IBM claim that its financial status, its history and technological options kill or reduce the potential of others that are just starting out in the market. That's just FUD.

The true top designers of the future will look at BUSINESS requirements, accept the limitations of past investments and technological decisions and move in the right application direction. As Joe Temple aptly stated, some applications are better in centralized environments versus highly parallelized and clustered ones. What was forgotten in that statement is that the true IT designer should be willing to change directions and mold the future applications to another technological model if the business case makes it possible and demands it.

The future can be a boring set of SAAS or ERP applications where IT is not a business differentiator, but a utility or service. I think not. I know there are smart people out there that realize that if every one is the same then there's no differentiator for a business to succeed.

Vive la difference. We are all zealots in a variety of churches of technology. Just don't commit the sin to call others sinners without accepting your sins as well!

The Armonk Anti-Christ

Armonk Anti-Christ | Mar 05, 2008 | 12:14AM

Mikey said:


I don't think using the name tsunami was bad luck. It was bad marketing.

You know, I'd have to agree 100% ... all I can say is it made a lot more sense after a couple of bottles of wine and some good bbq back when we were getting started ... at least we had actual marketing folks around to make up the new name (Appistry) when necessity dictated!


On to the main discussion ... Armonk makes a very good point when he argues that

IBM is a brand that has successfully acquired strength and staying power out of this normal human behavior. It has built a culture around the mainframe and other areas of the IT business, much like Apple.

But more than that - as he and several others have indicated in these comments, there will be an enduring place for hyper-optimized, low-volume, very capable boxes like the z10.
It's just that the place in question won't be nearly as broad as it has been historically.
In any case, I've expanded on this point in this post.


- Bob Lozano

Co-founder, Appistry

Bob Lozano | Mar 05, 2008 | 11:54AM