5 ms·
Witness, for example, Intel’s “new” Nehalem line - it’s great right? By Wintel standards, it is - but if Sun hadn’t lent AMD some people to design x64 and then
by iigs 17y ago
Witness, for example, Intel’s “new” Nehalem line - it’s great right? By Wintel standards, it is - but if Sun hadn’t lent AMD some people to design x64 and then supported the company by building its own motherboards to demonstrate what x86 multi-core could do, you’d be paying HP’s prices for Itanium desktops - Itanium performance, and Itanium security.
I call [whatever the highest HN-agreeable word that substitutes for "bullshit"].
The Itanium was never positioned for the desktop, and even if it was, it never had the performance to get the job done. It's slow, hot, and is a compromised design for desktop use.
AMD did to Intel what Toyota, Honda and Nissan did to GM in the 70s-90s: surprise and delight at the bottom end, and move upmarket slowly while the incumbent sleeps.
Intel made the mistake that Joel Spolsky famously warns us about -- don't rebuild things you don't have to; AMD bet on the opposite color and won big time.
most of the market, and many among Sun’s own staff, have no idea how the SPARC products line up against x86; no appreciation for the differences between Solaris and Linux; and no interest in learning how unloved products from Sun Ray to the CMT cryptology processors can produce huge savings and/or productivity improvements for customers.
Honestly, the more you know about "how the SPARC products line up against x86" the less palatable it is.
Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price.
On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks.
My experience (as an engineer in a multi-billion dollar company building from the ground-up over the last couple years) is that there's no compelling reason whatsoever to go with SPARC hardware unless you have to. We've purchased a few products with a legacy on SPARC, and these systems have been treated like appliances by the vendors -- they don't want us using Zones or ZFS, and they don't support us analyzing the applications using DTrace.
Linux is doing to Sun what Sun did to IBM. The difference is IBM had the benefit of more entrenchment and vastly deeper reserves. They managed to evolve away from "pushing iron as an end" to "pushing iron as a means to an end" -- where that end is consulting dollars.
- rbanffy 17y ago"Sun has too many irons in the fire. On one hand you have the few-core UltraSPARC processors that power the big iron. The servers are big, hot, and not clockspeed competitive with tier-1 x86 hardware costing 1/10th the price." I find it interesting to see comparisons based on clock speed becoming common again. Different architectures behave differently and SPARC performs differenty (read "better most of the time") than x86 at the same clock. I thought people learned that from the PowerPC Macs. I find this supremely ironic coming from a person nicknamed "iigs". Any half competent programmer could make a 6502 run rings around a Z80 with four times its clock in the Apple II days. "On the other end you have the T1/2/2+ many-core processors that are woefully anemic price:performers except possibly in trivially parallelized tasks." Like... Oh! web-serving! And virtualization. And database workloads. You must be right: those T1/T2 have no useful purpose. While Linux and x86 killed Sun on some workloads (it was Windows who killed the Unix workstation, BTW) being able to properly cast hardware to a given problem is a skill far too few people possess these days. Perhaps you should look more closely into your "legacy" Sun stuff and learn about the good parts.
- tptacek 17y agoAre you arguing that Solaris/UltraSPARC is a better real-world virtualization platform than x86?
- iigs 17y agoclock speed Yeah, I knew when I wrote that I chose poorly. I mean perf per core: that is to say, tasks that require clock speed. web serving, virtualization, database workloads Virtualization: Virtualizing Solaris is a practical non-starter -- every workload I've seen has fallen into one of two categories: either full system integrated applications (the appliance model that the majority of third party application providers seem to insist on these days) or common internet workloads (DNS, SMTP, HTTP). The former are more or less uniformly disallowed by vendor best practices -- nobody wants to do it. The latter is arguably better served by using the tried and true virtualization of the 1970s: preemptive multitasking multiple processes in a single host image. I have been attempting to advocate Solaris virtualization in our organization and have failed. I can't make a case for it that has justified even one server purchase (or reclaim). Web serving: $1000 PCs have been doing wire rate 100mbit static file serving and SSL for a decade or so. A lot of web workloads tend to coagulate around serializing resources (databases being the big one). In cases where that's not applicable, an arguably better solution is to cluster cheaper standalone machines. If there was a web workload that didn't apply well across multiple machines but could be run efficiently on multiple cores in the same image the T1/2/2+ would be a win. I don't know what that workload would actually be, however. Database workloads: Maybe, and probably for certain loads, but a Google search for "T2000 oracle" doesn't look promising. properly cast hardware I'll see your "properly cast hardware" and raise you "do the right thing for the business". Esoteric hardware shopping is fun for engineers but it's not sound decisionmaking for the stakeholders. Shame really, as I quite prefer the IIgs's Apple Desktop Bus keyboard over the spongy thing on this ThinkPad.