Apple Nearly Moved to SPARC

taskforce writes "Sun Microsystems Co-Founder Bill Joy claims that Apple nearly moved to Sun's SPARC chips instead of IBM's PPC platform, back in the mid-1990s. From the article: "We got very close to having Apple use Sparc. That almost happened," Joy said at a panel discussion featuring reminiscences by Sun's four cofounders at the Computer History Museum. An account of his entire presentation can be found on Cnet."

Comments

Dupe

[FTL]

Here we go again.

Re:Dupe

[Anonymous Coward]

So what. Some of us use dupes as a "value added service".

How is that ? Well, I actually have a life away from this keyboard and I don't read slashdot everyday. I didn't see this story the first time around, but thanks to the dupe I get to see it today.

Ok. So there is just a touch of sarcasm there. But there is more wasted space on this board because of people yelling "dupe", "you spelled that wrong", "you should have put a comma there", etc.

Its more difficult trying to find a post here that's actually on topic than it is to parse bad grammar.

If its a dupe then everyone that read it before knows it. There is no reason to wast space pointing it out.

Re:Dupe

[1u3hr]

If its a dupe then everyone that read it before knows it.

AFTER they've read it. Editors are supposed to filter, so we don't have to. If we simply ignore mistakes, they'll only get worse.

Some of us use dupes as a "value added service"

Every story ever published is archived. You can page through old stories if you want to, just look at the "Older Stuff" box on the right.

Fine dining

[Mostly a lurker]

Sun Microsystems CEO Scott McNealy had to be wined and dined at a Silicon Valley McDonald's before he gave up his reluctance to help launch the workstation maker in 1982

History does not record which of the many fine vintages available at McDonald's was selected on this illustrious occasion.

Re:Fine dining

[Neo-Rio-101]

So that explains the "Happy Meal Ethernet" driver for Linux on SPARC systems....

Re:Fine dining

[Megane]

Actually, "Happy Meal Ethernet" is the 100Mbit sequel to the 10Mbit "Big Mac Ethernet".

static void happy_meal_tcvr_write(struct happy_meal *hp,
unsigned long tregs, int reg,
unsigned short value)
{
int tries = TCVR_WRITE_TRIES;

ASD(("happy_meal_tcvr_write: reg=0x%02x value=%04xn", reg,
value));

/* Welcome to Sun Microsystems, can I take your order please? */
if (!hp->happy_flags & HFLAG_FENABLE)
return happy_meal_bb_write(hp, tregs, reg, value);

/* Would you like fries with that? */
hme_write32(hp, tregs + TCVR_FRAME,
(FRAME_WRITE | (hp->paddr ...

Re:Fine dining

[rubycodez]

can I suggest the McMerlot, July was a truly remarkable vintage!

Re:Fine dining

[Bert64]

I always thought Big Mac Ethernet was the first 100mb chipset (lance ethernet being their 10mb option), which was only available as an addon sbus card and never became widely popular (whereas the happy meal was shipped as standard on newer ultrasparc systems)

Re:Fine dining

[heinousjay]

So what wine would you recommend to go with shit on a bun?

Re:Fine dining

[Zenmonkeycat]

You know, if you let the Grape Minute-maid sit in the drink machines long enough, you end up with what I affectionately call "Jeebus Juice." Unfortunately, you also end up with an instant failure on any state health inspection.

Re:Fine dining

[NitsujTPU]

I only drank McMerlot until I saw Sideways. Now, I insist on McPinot Noir.

Re:Fine dining

[Paul Jakma]

For Linux?

It's the name of the driver on Solaris too, man hme. Maybe, just maybe, it's the Sun codename for the hardware concerned.

Re:Fine dining

[Megane]

I always thought Big Mac Ethernet was the first 100mb chipset (lance ethernet being their 10mb option),

All I did was a quick check on Google, and I found both answers. I always thought it was 10Mbit, so I went with that.

Re:Fine dining

[Tyger]

From my vague memories of doing admin work on Sparc...

le (Lance Ethernet) was the 10mb chip, bm (Big Mac) was 100mbit only, and hme (Happymeal) was 10/100.

Re:Fine dining

[wildsurf]

I think the iPod should have been called the MacNugget.

Re:Fine dining

[Weedlekin]

Or for those really special occasions, a super-size MacBollinger in one of those plastic cups that looks like a little champagne bucket complete with a gold-coloured straw.

Nearly... but not quite ... my friend!!

[Ganniterix]

This is boring ... shouldn't we discuss what is ... instead of would could have been? If we start considering the almost but not quite and what would have happned if ... I think there enough useless discussion going on already!

Re:Nearly... but not quite ... my friend!!

[enc.conf]

I think it would make a perfect scenario for a cheep holiwood sci-fi... Or just another tome of Mr. S.J's auto-biography.

Re:Nearly... but not quite ... my friend!!

[tezbobobo]

I think the point of historical review is to identify at which points mistakes were made. It is not to discuss what could have been but what might have been a better choice. Or to identify how the correct decisions where made. Different historical revision approaches could include functionalist, structuralist, or Great Man interpretations of how decisions where made and whether they were correct. Each would lend there own criticism. Simply because you have nothing to contribute to the conversations doesn't invalidate it. I don't think /. exists for your entertainment, but for a more technical discussion of IT matters. If you are not interested, I would try www.disney.com - I hear there are some nice Pixar movies there.

Re:Nearly... but not quite ... my friend!!

[Ganniterix]

Tsk Tsk Tsk ... You really must have a lot of time on your hands if you consider discussing this topic in such detail an important thing like that. Now if you were talking about something serious like I don't know ... what if the french revolution had never happned, how would the political scenario of europe shaped itself ... or like had the nazi's not gone greedy and invaded Russia what would the outcome of world war two have been ... Well if we were discussing the good and bad desicions over there I might say there might have been *SOME* time worth spending discussing. But discussing the what if's of this topic ... not that interesting... especially in a recycled posting on /.

Re:Nearly... but not quite ... my friend!!

[tezbobobo]

I don't particularly think thing like this *are* important. Yes, I'd much rather discuss those other things, even if you missed the subtlies of my point. However /. is a forum for discussing *this* sort of thing.

almost ?!?!?

[TTL0]

almost only counts in horseshoes and handgrenades.

Re:almost ?!?!?

[frogstar_robot]

almost only counts in horseshoes and handgrenades.

....and thermonuclear warfare.

Re:almost ?!?!?

[rmallico]

and nuclear weapons...

Re:almost ?!?!?

[Geoffreyerffoeg]

Nope, close isn't good enough for hand-grenades. They kinda have to go off to be useful.

"A court has convicted a man of trying to assassinate U.S. President George W. Bush and the leader of Georgia by throwing a grenade at them during a rally in May 2005....The grenade, which was wrapped in a cloth, apparently malfunctioned, investigators said."

Re:almost ?!?!?

[VolciMaster]

almost only counts in horseshoes and handgrenades.

... and nuclear weapons, but you only have to be upwind for nuclear weapons

SPARC was the dominant chip at the time.

[CyricZ]

For serious workstations, the SPARC was basically the dominant chip at the time. Indeed, it was at the top of its game. Even now we still see it used for mission-critical and high-performance tasks. So it's really no wonder that Apple would have considered such a switch.

Re:SPARC was the dominant chip at the time.

[Per Wigren]

Weren't most heavy workstations in Apple's primary domain (graphics, video, design) based on MIPS at that time, in Silicon Graphics' workstations?

Re:SPARC was the dominant chip at the time.

[dfghjk]

SPARC was the oldest, weakest, most primitive processor design at the time. Truly horrible. It was only successful to the extent Sun was successful. Even the dead Moto 88K was better.

Re:SPARC was the dominant chip at the time.

[Jeff DeMaagd]

Sparc probably would have been the wrong way to go as there never was a good portable version of the chips. Sure, there were some SparcBooks but IIRC, they never worked out well. PPC worked out a lot better as a general purpose architecture for longer.

Re:SPARC was the dominant chip at the time.

[Frumious Wombat]

As I remember from running simulations at the time, the top of the game was IBM's Power, with DEC's Alpha close behind, then followed by SGI/MIPS. The MIPS R8000 was the first hard-core contender, but they were already having trouble keeping up with DEC/IBM. Sparc was on anyone's radar because it was cheap (relatively), and all of the software written for the previous 3/XX generation could still run.

We used to be really psyched that the PowerMacs had a version of IBM's workstation chip inside (PPC 601/604 chips were in both PowerMacs and AIX workstations). A lot of people bought them for Mathematica as a result.

Re:SPARC was the dominant chip at the time.

[fitten]

Heh, the rumor was that SUN, before opening up the SPARC CPU, took it to Motorola and asked if Moto would build it. Moto looked at it and said, no, but we can make you something better, and showed SUN the 88k. Unfortunately, the 88k died but at least its bus lived on in the first PPC processors.

Re:SPARC was the dominant chip at the time.

[aminorex]

The SPARCv7 architecture was the pinnacle of 32-bit RISC ISA elegance. As a compiler writer, I found it to be far and away the best ISA target for code generation. The tagged integer instructions made it a dream for higher-level language compilers, the register windows made function calls cheap, and the orthogonality level of the ISA was far and away superior to MIPS and 88k, which were ad hoc and low level in comparison. Moreover, the upward path through superscalar pipelining, branch prediction, etc. -- all the basic architectural innovations of the 90s -- was smooth and predictable. The 64-bit support in more recent revisions is a bit of a hack, IMO.

It's executive system was always a stinky muddle. I'm glad I did not have to write a VM OS for it. But for actually running the productive code of applications, SPARC was an ideal architecture. Unfortunately, economies of scale have made non-x86 architectures less and less competitive for general-purpose computing. A deal with Apple might have changed that fate.

Re:SPARC was the dominant chip at the time.

[LizardKing]

Sure, there were some SparcBooks but IIRC, they never worked out well.

Well, Tadpole still make a business from selling SPARC based portables. Even Sun rebadges them and sells them.

Re:SPARC was the dominant chip at the time.

[BoomerSooner]

How would a deal with Apple have changed anything?

They'd still have a tiny market share and be moving to
Intel because 1.2GHz SPARCs aren't that impressive.

Granted if you throw 1024 or so of them together they're pretty slick...

Hell throw 1024 of anything together and they're pretty slick (except maybe 6502's or something like that! Wow fastest Apple II array ever!)

Re:SPARC was the dominant chip at the time.

[argent]

SPARC was only dominant in market share, and it was only dominant because the dominant vendor was using it. It's never been a high performance chip compared with other RISCs, and rarely even when compared with Intel

Re:SPARC was the dominant chip at the time.

[dfghjk]

Sadly, PowerPC was NOT a version of IBM's workstation chip. It's initial design was derived from Power but they were not the same. The 601 was a transition design and was not fully a PowerPC processor either.

Re:SPARC was the dominant chip at the time.

[mallardtheduck]

Hmm... [Begins eBay search for Apple II job lots...]

Alternative Headline

[Bloater]

Sun Microsystems Boasts "We're not quite good enough."

Re:Alternative Headline

[jcr]

They're still at it.. Remember Jonathan Schwartz trying to convice Apple to save Solaris from the ash heap of history a couple of months back?

-jcr

Good decision

[lordholm]

The SPARC V8 is quite clean and nice to work with, and is farley sane, with the exception of tagged arthmetics, the trap model and the visible pipeline, and missing standard interface to the MMU (yes I know of the ref-mmu).

On the other hand, the SPARC V9 is a horrendeus monster thar is just plain scary when dealing with supervisor level code. IMHO the PPC64 is much nicer than the V9, in many aspects.

But, on the other hand the PPC, has gone out of order, while the SPARC has stayed in order, making the CPU a hell to compile code for.

Architecturally, the PPC is a slight bit nicer than the SPARC, and as a plus, the PPC64 was defined exactly the same time as the PPC32 was, and thus they (PPC32 & 64) are very similar.

In my eye, it was a good decision to go for the PPC.

Re:Good decision

[T-Ranger]

Perhaps, but in business the question isnt necessaraly about the technology today. Its the old story of small fish, little pond, v. big fish little pond.

If Apple had gone with a the Sparc chip/platform, could Apple have influenced SPARC Internation more then they did with the Motorola/IBM/Apple setup? Interesting question. I know that one of the reasons cited for Apple moving from the PPC arch is that IBM has only been interested in investing in the POWER arch, all but ignoring the consumer grade PPC systems. I think that Apple could have sold at least as many AppleSparcs then Sun sold UltraSparcs, and therefor had a greater (relative) pull with SparcInternational then with IBM. Also, (and Im not sure on the timeline here), they could have gotten help with a 68k to Sparc transition from Sun, which had done the same thing (though, without binary compatability).

Re:Good decision

[lordholm]

"Fujitsu's SPARC VI is out of order"

True, but that one is a SPARC V9 and not a V8. But, I wasn't very specific in this issue, sorry for that.

"Sight bit? Two words, register windows"

Well, the reg windows do have their advantages, you get a smaller code size since you don't have to push stuff on the stack as soon as you make a function call, this also speed up the calls a great deal (also, this simplifies the work of the compiler somewhat). The back side is of course that you need to have an operating system that manages the register windows, and in some embedded applications this isn't an option.

Re:Good decision

[argent]

The SPARC V8 is quite clean and nice to work with, and is farley sane, with the exception of tagged arthmetics, the trap model and the visible pipeline, and missing standard interface to the MMU (yes I know of the ref-mmu).

And only 7 registers available for the compiler to generate code for. That's as bad as the 386.

Re:Good decision

[lordholm]

That depends on the ABI you are using. In the V8E there is another optional ABI that basically gives each process one window. The workings of this ABI basically gives you 32 registers to work with, just like the PPC and the MIPS.

Re:Good decision

[argent]

In the V8E there is another optional ABI that basically gives each process one window. The workings of this ABI basically gives you 32 registers to work with, just like the PPC and the MIPS.

HALLELULIAH! THERE IS A GOD!

Can you actually use this ABI from applications in Solaris, and call regular libraries from it? or at least are there "flat register" versions of them?

And... does teh compiler make good use of it? What's the performance difference in practice?

Re:Good decision

[lordholm]

No, not from Solaris, it's strictly for the embedded market. In order to support this you need special libraries, and support for it in the operating system.

I have not seen any figures on performance advantages, I would suppose that it is developed to be power efficient when switching between processes on a low process count system.

Re:Good decision

[argent]

No, not from Solaris, it's strictly for the embedded market. In order to support this you need special libraries, and support for it in the operating system.

Ah, so, it's irrelevant for our purposes and any actual Sparc code on a general purpose computer still has the overhead of a large register file and the register contention problems of a small one.

Had the workstation vendors worked together.

[CyricZ]

There has always been much speculation as to what the computing landscape would look like today had the non-Intel vendors worked together to produce a superior chip.

Indeed, the combined talents of the Alpha crew from DEC, with the PA-RISC developers from HP, the SPARC group from Sun, those behind the MIPS at SGI and MIPS Technologies, and the PPC people from IBM, for instance, could have come up with a CPU that completely trumped what Intel was putting out at the time.

Re:Had the workstation vendors worked together.

[dfghjk]

There's no reason to believe this at all. Adding more of the same level of engineeering expertise doesn't necessarily get you anywhere. Besides, it could be argued that all the processor groups you mentioned produced processors that were better than Intel offered at the time. They simply weren't enough better to make a difference. Odds are that combining the efforts of the competition would have made them all fail even sooner. HP joined Intel for IA64 and look where that got them.

Re:Had the workstation vendors worked together.

[Antique Geekmeister]

I think you can basically ignore the Alpha developers: after the the theft of Alpha technologies for the Pentium, and the theft of David Cutler's old work for developing NT (which David Cutler himself took illegally along with his merry band of software pirates he hired from DEC), repeating the Alpha work for a non-Intel chipset would have been playing to Intel's and Window's strengths.

Unless the old Alpha developers in a cooperative environment were able to sidestep old Alpha issues, or completely avoid the compromises Intel made to stuff Alpha technologies into the Pentium, then I think the Alpha developers were not in a good position to contribute much to such an endeaver.

Re:Had the workstation vendors worked together.

[dfghjk]

haha, Alpha had the grimmest, most threadbare instruction set imaginable. It's strength was it's ferocious clock rates that were enabled by abnormally deep pipelines and instructions that did relatively little (no integer divide!). The characteristics that Alpha had that caused it to be so loved are the same ones that cause the P4 to be so hated; relatively poor IPC, very deep pipelines, very high clockrates, huge caches to cover it's design weaknesses, and excessive power consumption. The love of Alpha was a cult. Yeah it was fast and 64-bit but it was a tremendous power hog for it's generation. No need to love Alpha. No one did but DEC.

BTW, Intel didn't steal anything from Alpha for the x86's. It's owned the team at the time. Cutler didn't steal anything from DEC either. A person owns the knowledge and experience inside his head. I'm sure if there was evidence of theft it would have been dealt with. DEC was a dinosaur that wasn't showing any signs of interest in Cutler's continued work. He left to take up his projects at a company that was interested in pursuing them.

Re:Had the workstation vendors worked together.

[ACMENEWSLLC]

>>Indeed, the combined talents of the Alpha crew from DEC, with the PA-RISC
>>developers from HP, the SPARC group from Sun, those behind the MIPS at SGI and
>>MIPS Technologies, and the PPC people from IBM, for instance, could have come up
>>with a CPU that completely trumped what Intel was putting out at the time.

ROFL - that is hilarious. Can you imagine the politics in a chip like this? By the time the chip meets everyone at these companys requirements you would have a horrific chip.

And as we all know, the chip itself really makes no difference. Look at x86 for example with all it's legacy routines that continue to haunt it. What makes the difference is marketing.

Had any one of these chips had the proper marketing department and sales force, Microsoft would have an OS for it. I have an NT 3.5 for Alpha CD somewhere. They did write 3.51 for PPC and reportably SPARC, but didn't release SPARC.
http://en.wikipedia.org/wiki/Windows_NT

Novell 4.11 with NDS has features that Windows 2003 AD still doesn't have. For example, while I can mark a drive compressed on both OSes, on Netware I can configure it to compress the file only after not used after x many days. And I can tell the OS to leave a file uncompressed after use for y many days. I can mark a file as executable or not, such as with *nix. I can do bulk operations on the directory which I still find difficult with Active Directory. With some lesser known options, I can put the same user in multiple leafs in the tree to associate the same user with multiple departments leafs, applications leafs, or what have you. In AD if I put my user objects in department leafs, I can't associate GPO's to groups of users such as managers from each department. I have to create a subcontainer leaf and put managers in there and associate the GPO to each of these leafs. What a pain.

Active Directory is still not where Netware NDS was 10 years ago. But that's not what matters. Marketing is paramount.

Re:Had the workstation vendors worked together.

[twodot72]

But these companies did produce faster chips than Intel without cooperation, and Intel still prevailed. Especially the Alpha was lightyears ahead of Intel, performance-wise, in its heyday. The reasons they still failed have nothing to do with lack of technical prowess.

Re:Had the workstation vendors worked together.

[Anonymous Coward]

You seem to have missed the last great Alpha, the 21264, which fixed most of your complaints. It was based on the superscalar high-IPC design that has become the standard on most performant CPUs since then. It didn't have the same kind of huge benchmark lead as the 21264, but it did lead the SpecINT and SpecFP tables for much of its history.

Re:Had the workstation vendors worked together.

[Rob_Bryerton]

It could be argued that marketing, not technical excellence, "made" Intel during the time period in question, not that the others "simply weren't enough better to make a difference".

/devil's advocate

Re:Had the workstation vendors worked together.

[Surt]

Indeed. In particular, it's unclear where the transistor budget would have come from for any sort of major innovation that none of the companies had thought of individually, yet could come up with as a group.

Now the market backing of 10 major companies working in concert might have made something sell, but technologically, there's just no reason to believe there would have been any magic.

Re:Had the workstation vendors worked together.

[TheGratefulNet]

No need to love Alpha. No one did but DEC.

sgi (at the time, known as cray research) used alphas in their supercomputers.

it kicked serious butt. and they were NOT DEC, last time I checked.

(although sgi and cray will probably go the way of DEC, sadly to say).

ob disc: I worked at both DEC and SGI in my past.

Re:Had the workstation vendors worked together.

[IntlHarvester]

Adding more of the same level of engineeering expertise doesn't necessarily get you anywhere

It has nothing to do with engineering expertise -- it's FAB investment. None of the RISC companies could afford to keep up with Intel in process technology, and the enormous cost of designing and producing your own chip basically sunk DEC and SGI.

I agree that it was probably politically infesible, but the RISC crowd invested far too much money into niche CPUs and it killed all of them (except IBM).

Re:Had the workstation vendors worked together.

[poot_rootbeer]

Indeed, the combined talents of the Alpha crew from DEC, with the PA-RISC developers from HP, the SPARC group from Sun, those behind the MIPS at SGI and MIPS Technologies, and the PPC people from IBM, for instance, could have come up with a CPU that completely trumped what Intel was putting out at the time.

Hey, this broth isn't tasty enough! Better bring in a few more cooks...

Re:Had the workstation vendors worked together.

[zbeeble]

>>They did write 3.51 for PPC and reportably SPARC, but didn't release SPARC.

I thought that Sun bought the rights for the Sparc version and then refused to release it. I can't find any sources to back this up though.

Re:Had the workstation vendors worked together.

[Antique Geekmeister]

It looks like you've never actualy been paid for code you've written, or you're so young you don't remember a time before DEC's development teams had already been reaped by corporate thieves. The company that pays you for the code normally owns it: it's released under whatever copyrights they use, or that are in your contract. David Cutler was a core author of VMS: DEC-owned, copyrighted code and trade secrets that he developed in his time at DEC turned up throughout the NT core when he and his merry gang of former DEC developers wrote it into NT. They didn't have time to develop it from scratch for Microsoft: they stole it wholesale from Cutler and his team's old work at DEC. The lawsuits were nasty: a fast Google search on "DEC David Cutler NT lawsuit" will give you plenty of reasonable references.

Second, there are literally hundreds of lawsuits and court precedents and clear law that say that patents, trade secrets, and copyrighted code are not "your knowledge to do whatever you want with". Cutler had at least trade secrets and copyrighted code he used wholesale in NT: take a look at the old memory management code and do a side-by-side comparison for examples of the violations.

Last, there was plenty of hardware design knowledge and architectural knowledge stolen from DEC and used in the Pentium series: DEC sued over at least 10 *distinct* patent infringements in Pentium development. It's hard to know how much money they got: DEC's policy of settling where possible instead of nailing thieves to the wall turned out to be shortsighted when Microsoft and Intel managed to steal such core technologies, make large amounts of money with them by integrating them into low-end systems, and impoverish DEC so badly that their core people retired and they couldn't be replaced.

Re:Had the workstation vendors worked together.

[Kadin2048]

I'm not sure you need to play Devil's Advocate to espouse such a position at all. In fact I'm not even sure that it's controversial.

Early-90s x86 architecture was soundly trumped by the competing RISC designs, at least in every benchmark I ever saw back then. Intel responded not with any sort of real technical brilliance, it was instead more of a case of them just throwing money and grinding away at the problem, packing more and more transistors onto the chip, and ratcheting up the clock speed. At the same time, their marketing department came up with the "Intel Inside" branding campaign, and got people to associate Intel Processors with the Windows OS on an almost subliminal level. And as their volume increased, the economy-of-scale brought costs down to the point where no other architecture could compete.

I can't think of any time in recent history when x86 has really been tops in any sort of pure performance measurement (except raw clockspeed, perhaps), but it won because of apparent price/performance.

Re:Had the workstation vendors worked together.

[be-fan]

haha, Alpha had the grimmest, most threadbare instruction set imaginable. It's strength was it's ferocious clock rates that were enabled by abnormally deep pipelines and instructions that did relatively little (no integer divide!).

The 21264's pipeline's were actually quite shallow for an out-of-order processor. At 7 stages, it was closer to the Pentium's 5 than the Pentium Pro's 10. It was quite a bit shorter than the pipelines of any modern, comparable processor. The PPC970 has a 16 stage pipeline, the UltraSPARC III has a 14-stage pipeline, the SPARC64V has an 11 stage pipeline, the Opteron has a 12 stage pipeline, etc.

relatively poor IPC, very deep pipelines, very high clockrates, huge caches to cover it's design weaknesses, and excessive power consumption.

I'll give you the power consumption, but take exception to everything else. The 21264's IPC was good, even by modern standards. The original 21264 got 626 SPECint_base per GHz and 844 SPECfp_base per GHz. The 21364 got 766 and 1299 for the same benchmarks. These figures put the original '264 substantially ahead in IPC versus its competition, and makes the '364 very competitive with modern processors like the Opteron and Power5. As for cache --- large caches aren't a design flaw, they are ncessary to sustain a chip that is substantially faster than memory. The P4 actually has fairly small caches, if you consier the fact that its L1 caches are tiny.

Re:Had the workstation vendors worked together.

[dfghjk]

I think you can make an equally strong argument that binary compatibility meant more than performance until such time when the performance difference wasn't great enough. It's not really a marketing success, but rather luck that IBM chose the Intel processor to begin with.

Re:Had the workstation vendors worked together.

[dfghjk]

Don't know that I agree. Binary compatibility counted for a lot and it still does.

If the investment in fabs was the issue then the problem must have been cost, yet IBM with the PPC architecture specifically targetted lower cost with its designs and it was ultimately unsuccessful. IBM has always been competitive with Intel regarding fab technology yet PPC untilmately failed on the desktop. Would the joining of all the other vendors have changed that? I don't think so.

Re:Had the workstation vendors worked together.

[dfghjk]

I never said anything about patents, etc. and trade secrets are not protected! I said that a person owns the thoughts that are inside his head. Is there proof made public that Cutler and/or his team used DEC property in the development of NT without permission?

Recreating what Cutler was working on at DEC is not automatically "theft" and lawsuits are automatic proof of theft either. Companies often settle out of court and that's not automatic proof.

Employees are frequently required to submit to a "no compete" clause. Some argue that that are not enforcable but sometimes an ex-employer will pursue one. One of the big disadvantages of a "trade secret" is that it's easy for them to no longer be secret, like when Cutler leaves DEC for MS.

Re:Had the workstation vendors worked together.

[dfghjk]

Alpha had deep pipelines for its day but not deep by today's standards. I recall the Pentium having 5 and thought the Alpha at that time was 9. If it was 7 then the difference was not so great. I do recall wanting to put one on a PCI controller but it took up nearly the entire PCI slot budget at the time. :(

I never meant to suggest that large caches indicated a design flaw although i clearly said that. The large caches were there for the exact reason you gave.

Re:Had the workstation vendors worked together.

[be-fan]

All the Alphas had a 7-stage pipeline. This was long compared to, say, a PPC 601 or a 603, but the Alpha was also a much more sophisticated CPU than those chips. Compared to chips like the UltraSPARC I and II (in-order designs), which had 9-stage pipelines, and the PPC 604e, which had a 6-stage pipeline, the 7-stage length of the 21164 and 21264 was quite reasonable. This is especially true for the '264, whose 7 stage pipeline is quite short for a massively out-of-order 4-issue processor.

Re:Had the workstation vendors worked together.

[Antique Geekmeister]

Yes, the work inside your own head can be a trade secret. Please go look it up: a casual description of trade secret laws can be found at http://www.marketingtoday.com/legal/tradesec.htm. And please read the contract of someone who gets paid for writing software, even 20 years ago. There's plenty of contractual law involving trade secrets and "the knowledge inside your own head".

There's also considerable evidence that David Cutler and his merry gang of software pirates stole exactly that: trade secrets and copyrighted code. Take a good look at the memory management of NT for examples. Re-compiling your old code, and reproducing the same trade secret knowledge for another company is in fact illegal, especially if it's a violation of your employee contract. David Cutler violated his contract, he hired his old employees to help him do it, and Microsoft profited directly from it. The extent to which his Microsoft supervisors knew of the violation is an interesting question, but they sure didn't hire him from DEC for his good looks or personal charm.

Intel's theft of Alpha technologies to use in the Pentium is a bit different. While there were many blatant violations of patents, there were also apparently a number of thefts of trade secret knowledge of exactly how to make registers work that fast: separate lawsuits were filed, and they're less public, because neither side wanted to expose core trade secrets in court if they could avoid it.

Re:Had the workstation vendors worked together.

[wildsurf]

Hey, this broth isn't tasty enough! Better bring in a few more cooks...

Whetstone Soup.

Re:Had the workstation vendors worked together.

[IntlHarvester]

None of the RISC CPUs were binary compatible with the CPUs previously used by their sponsors.

As for PowerPC, 970 wasn't that competitive with Intel's process, the chips were low-volume and ran very hot. But mainly Apple did it to themselves by creating a low-growth businss model that wasn't attractive to CPU vendors.

> Would the joining of all the other vendors have changed that?

No probably not, because Intel largely caught up. But it might have kept the RISC workstation/lowend server market alive.

Sun also switched from Motorola 68k

[Henriok]

..and Apple was about to. Sun was probably an obvious partner for Apple.
However.. I think going PowerPC was the by far best choice at the time with massive backing by almost everyone.
My take on history is that Apple have chosen the right processor architecture at any given moment taking account everything that was known at the time. In hindsight everything always looks different.

Re:Sun also switched from Motorola 68k

[dfghjk]

Almost everyone? Who are you talking about?

PowerPC was not considered the best choice by anyone outside IBM, Moto and Apple. It was clear at the time that ALL other processor alternatives offered superior performance to both Intel and PPC since IBM didn't design PPC to be the fastest processors of the group, it wanted PPC to be speed competitive with Intel at far lower cost. Apple bit on that. The downside of PPC was that Motorola proved just as incompetent carrying the family forward as it was with the 68K. PPC became nothing more than an embedded processor family that Apple had to promote as a desktop processor. The G5 might have changed PPC's fortunes had it's continued development been justifiable.

Re:Sun also switched from Motorola 68k

[Chanc_Gorkon]

I still think that in some ways Apple is making the wrong move again. I STILL say that within a few short years, Mac OS X will be bootable on ANY Intel machine and Apple will stop trying to fight letting it run on only Mac Intel Machines. I still think Apple may make hardware, but it will always be the super high tech and absolutely georgeous design. Microsoft or someone else will figure out how to get Windows programs running natively on Mac OS X on intel and that will be all she wrote for Microsoft.

Re:Sun also switched from Motorola 68k

[IntlHarvester]

Exactly - mod up. PowerPC was designed to be cheap moreso than it was to be fast.

The rumors are that Apple sells $2500 PowerBooks with a $30 G4 CPU. Ai.

Re:Sun also switched from Motorola 68k

[ArbitraryConstant]

"My take on history is that Apple have chosen the right processor architecture at any given moment taking account everything that was known at the time."

Even if PowerPC was the right choice in the early 90s, it's been the wrong one for 5+ years. IBM and Moto/Freescale don't care about desktop chips, and the time has passed when other chips can be pushed into service against AMD and Intel's best and brightest.

Re:Sun also switched from Motorola 68k

[dfghjk]

Curiously, the exact IBM sales pitch for the PPC before it was announced was "just as fast as Intel but half the cost". It was not only true that PPC was designed for cheapness but it was explicit in IBM's sales pitch.

Apple must have known it was buying into the only RISC processor line that specifically didn't target better performance than Intel. It's interesting to think how much sooner they would have been compelled to switch had Moto not done the vector instructions for Cisco and extended the life of the design.

Re:Sun also switched from Motorola 68k

[feijai]

Those crazy rumors. The Freescale MPC7447A (the G4 in the Powerbooks) costs $150 for a single unit. The chance Apple could get it down to $30 in volume is very close to zero.

Advanced Interface Design

[DaveRexel]

-TFA-
"McNealy added that he went to Steve Jobs' house to try to hammer out the user interface agreement. The Apple co-founder and CEO was "sitting under a tree, reading 'How to Make a Nuclear Bomb,'" with bare feet and wearing jeans with holes torn in the knees, McNealy said."
---

From just this one anecdote one does get the feeling that Steve might have taken over Sun eventually. The disappointment expressed by Bill Joy over the failed "close encounters" with Apple does indicate that they would have followed Steves leadership.

On a more serious note, the clash of the raging CEO egos would not have been beneficial for either company.

Re:Advanced Interface Design

[uncleFester]

On a more serious note, the clash of the raging CEO egos would not have been beneficial for either company.

.. but it would have been fun to watch. would probably make Larry Ellison look like he's been on Prozac all these years.. :)

-'fester

Re:Advanced Interface Design

[capmilk]

From just this one anecdote one does get the feeling that Steve might have taken over Sun eventually.

Funny, isn't it? Just the same thing happened between Apple and NeXT. Although Apple technically bought NeXT, NeXT took over Apple.

I'm glad they did.

Speculation that SGI would buy Apple.

[CyricZ]

There was a lot of speculation in the early to mid 1990s that SGI would buy Apple. SGI was doing quite well at that time, considering they had just released their very successful Indy line. Considering that both provided workstations for the same type of applications (multimedia-related, desktop publishing, and so forth), the systems from Apple could have offered a solid low-end line to complement SGI's more powerful systems.

What could have happened is an infusion of IRIX with Mac OS. We could have seen Mac OS on the MIPS, for instance. Not only that, but it would be a situation very similar to what we have now with Mac OS X: an excellent GUI built upon a solid UNIX-based core. Except in the SGI case the UNIX core would be IRIX, rather than a BSD/Mach conglomerate.

Re:Speculation that SGI would buy Apple.

[dfghjk]

It's far more likely that Mac OS would have been phased out entirely since, as you said, Apple would have been a low end line for SGI. SGI was an incredibly arrogant company and it would not have seen Mac OS as offering anything of interest to their current platforms (and that would have been right). If SGI had bought Apple, macs would have run SGI's OS'es until they ceased to be called macs, and of course they'd be out of business entirely today.

Re:Speculation that SGI would buy Apple.

[jandrese]

It always strikes me that if you listen to the rumors, there is ALWAYS a company gearing up to buy out Apple for one reason or another. I don't know what it is about Apple, but people really want to see it bought by some huge conglomerate for some reason.

I doubt SGI ever had any interest in Apple. They were positioning themselves in the server market at the time and Apple had nothing to offer them.

Of course that was back when Apple was tanking and speculation that everybody from SGI to Microsoft to Pepsi was going to buy them out.

Re:Speculation that SGI would buy Apple.

[argent]

Thank god that didn't happen.

Out of all the UNIX systems I've used, Irix beats out HPUX and SCO, but I'd rather have seen just about anything else as the base of Mac OS X than Irix.

And I don't know exactly what the timing was, but if SGI had a consumer OS they might not have had the same incentive to open up GL.

Re:Speculation that SGI would buy Apple.

[IntlHarvester]

Apple wanted to see themselves bought out by a huge conglomerate during their difficult periods back in the 90s -- and came very close with IBM and Sun. That's the source of all those rumors.

Lots of processors considered?

[RetiredMidn]

I seem to recall seeing a demo of a Mac with a Motorola 88000 RISC processor running my 68000 binary code (Lotus 1-2-3) under emulation, a predecessor to the PowerPC effort.

Oops, I may be in violation of an NDA...

/. sure is a good place for dredging up obscure technical memories.

Re:Lots of processors considered?

[IntlHarvester]

Wasn't the "Star Trek" Intel port done at about the same time? I also have heard stories that DEC Alpha was considered. So it does sound like they looked at everything.

Re:Lots of processors considered?

[RetiredMidn]

Wasn't the "Star Trek" Intel port done at about the same time?

Now that you mention it, yeah. We were given a separate presentation at Lotus about Star Trek, including a demo. (Damn, there goes another NDA.)

To be honest, I remember thinking at the time that Star Trek wasn't really thought through. Certainly the execs at Lotus didn't get it (which says more about the execs than it says about Star Trek). DOS/Windows apps were not going to run under Star Trek (certainly not with the desired user experience). "Porting" these apps to the Mac OS APIs wasn't going to be all that easy. And converting Mac applications of the day, many of which were written in processor-dependent ways, to a new processor architecture would be much more difficult than the conversion of more modern applications today.

It was neat technology, but it didn't solve a problem people thought they had.

I kinda went off topic there; please don't hurt my karma.

Re:Lots of processors considered?

[IntlHarvester]

> It was neat technology, but it didn't solve a problem people thought they had.

I always had the impression that Star Trek was dry run of their 68K emulator technology, which was a problem that needed to be solved.

And I suppose you could argue that if they were going to switch to Intel eventually, they should have done it sooner rather than later.

Re:Lots of processors considered?

[RetiredMidn]

I always had the impression that Star Trek was dry run of their 68K emulator technology

Interesting thought, but I really don't think so. AFAIK, Star Trek was not emulation; it was the Mac OS APIs recompiled and re-hosted on a different platform. I've seen conflicting reports about how it was really implemented, but (forgive me), Cringely's is the most credible, IMHO. It is possible they learned a thing or two that helped them with the PowerPC platform transition.

And I suppose you could argue that if they were going to switch to Intel eventually, they should have done it sooner rather than later.

Personally, I've never believed that. I worked closely with both the 680x0 and 80x86 architectures in the 80's, and, form my perspective as a user of the instruction set, I found the 68K vastly superior to work with; the only thing the Intel platform had going for it was the fact that IBM had made it a de facto standard.

Architecturally, the Pentium started to close the gap, but the power consumption issues were pretty significant. My five-year-old fanless PowerBook G3 is still a pleasure to use over the Dell laptops my last employer supplied me with.

IMNSHO, Apple's Intel switch wasn't inevitable, it just makes sense at the moment. And I harbor a suspicion that Apple won't necessarily stay mono-architectured. Mac OS X binaries, by design, can accommodate multiple (not just two) processor architectures. Apple will pursue the direction(s) that make the most sense as things play out over the next few years.

Re:Lots of processors considered?

[mad.frog]

And I harbor a suspicion that Apple won't necessarily stay mono-architectured. Mac OS X binaries, by design, can accommodate multiple (not just two) processor architectures. Apple will pursue the direction(s) that make the most sense as things play out over the next few years.

If this is the case, one wonders why Apple hasn't tried emulating something like CLR or JVM as a standard "architecture" to forestall future such changes. Obviously native code is required for some things, but at this point, a well-crafted virtual machine code (JIT'ed at load time) would seem to be more than adequate for most things...

Re:Lots of processors considered?

[laird]

"one wonders why Apple hasn't tried emulating something like CLR or JVM as a standard "architecture" to forestall future such changes"

There's not much reason to want to run an OS and applications via a virtual machine; Apple (via NeXT) has something much better -- a compiler and OS that compiles native binaries for all processors and then runs the appropriate binary on load. I used to use a NextStation (68040, I think it was) to develop on, then deploy on x86, HP PA/RISC and 68040's, all running NextStep, or on x86's running NT with the OpenStep runtime. It worked like a charm. Yes, the "fat binary" is a bit larger than a single-platform binary, but resources (UI, bitmaps, data) tend to be larger than the actual compiled code in most app's that I saw. Of course, you can easily strip out the unneeded platforms if you really need to save the disk space. :-)

The only reason that I can think of that Apple is moving from PPC to Intel, rather than supporting PPC and x86 (i.e. AMD, etc., as well) is that they've set up a mutually beneficial corporate relationship. It's an even more interesting deal looked at from the other side. That is, while Mac OS X has always been a highly portable OS (even though Apple only shipped PPC's), Intel's been pretty much locked into Windows. So it's as big a deal for Intel to move a bit away from MS to support Apple as it is for Apple to support Intel.

Re:Lots of processors considered?

[bill_mcgonigle]

Mac OS X binaries, by design, can accommodate multiple (not just two) processor architectures.

At one point OpenStep was shipping binaries for 4 platforms 68k, x86, SPARC, and HP, IIRC. Somebody must have had a MIPS version in the lab.

Steve Jobs isn't going to let Intel run roughshod over Apple. Unfortunately for that strategy, XScale is the next logical place for Mac OS X to go, and that's Intel's also.

NOTE TO MODS:

[mrchaotica]

The parent post is an aphorism, not a troll. At worst, it could be offtopic.

Back in the day..

[turgid]

...late '80s/very early '90s there was something called the ACE Consortium.

This was formed by the likes of DEC, Compaq and SCO at the time when IBM had not long brought out the dreadfully underpowered, expensive and proprietary PS/2 line of personal computers running the pathetic MS-DOS and mediocre OS/2.

Most people were running PeeCees which were essentially 16-bit with a single user, single tasking operating system running on dreadfully slow CISC (8086, 80286, 80386) processors will pitifully small amounts of RAM (512k-1MB) and nary a GUI.

The ACE consortium was designing a MIPS-based (32-bit RISC) open specification for a replacement to the IBM-PC and PS/2 architectured which would run a UNIX SYSVR4 derivative and a nice GUI (was it with X?).

The project died a death. I can't remember why.

When I was 15 I longed for a RISC UNIX workstation in the house instead of the 12MHz Compaq SLT/286 we had (for business use).

MIPS lived on in post-VAX pre-Alpha workstations at DEC and then at SGI. itanic Kool Aid all but killed off MIPS. The only two major RISC architectures from the era which survive are SPARC and POWER/PowerPC, and for a couple of years it looked like SPARC was dead too.

The spirit of Alpha lives on in Athlon and Opteron.

Re:Back in the day..

[dfghjk]

First, when the ACE Consortium was formed Intel was selling 486's. The 486 was not dreadfully slow compared to RISC competition although its floating point lagged. Intel PC's also had far more memory than you suggest and Windows (even OS/2) was well established at that time. The competition for ACE was not 16-bit, single-tasking low performance DOS machines like you say.

Second, Microsoft was a member of ACE and Windows NT was built to run on ACE machines as well as PC's. For those who wonder why NT/2000/XP boots the way it does, the reason is that PC's run special boot code that emulates an ACE bootstrap environment. It could be argued that ACE was the preferred platform for NT and MS internally built ACE workstations as reference platforms. Much of the NT code was developed on them. The ACE machines inside MS had EISA busses and used PC peripherals. ACE even included a spec that allowed ACE machines to use PC expansion cards with modified option ROMS.

It's conceivable that ACE intended the workstations to run a UNIX derivative but I doubt MS saw it that way. It's far more likely, had ACE succeeded, that its main platform would have been Windows. ACE machines, despite their MIPS processors, ran DOS applications! Sorry, ACE wasn't a UNIX workstation, it was a PC replacement that ran MS OS'es in addition to UNIX variants.

Now, about ARC---the PowerPC version of ACE...

Re:Back in the day..

[BuR4N]

"When I was 15 I longed for a RISC UNIX workstation in the house instead of the 12MHz Compaq SLT/286 we had (for business use)."

You should have bought an Acorn Archimedes, 1989 it was probably the best you could get without spending a fortune. I got myself this one as a replacement for my Atari ST, http://www.old-computers.com/museum/computer.asp?s t=1&c=697 .

Re:Back in the day..

[turgid]

The 486 was a dog compared to a 30MHz SPARC, both in integer, and especially floating-point.

When the Pentium 100 came out, it was almost as fast as RISC processors that had come out 5 years previously.

Yes, in 1990, some people were buying PCs with 2MB RAM, but most people were still running machines with MSDOS with 1MB of RAM at most.

x86 processors finally caught up with RISC workstations when the AMD Althon came out. The Pentium III nearly caught up, but not quite. We're now into 1999. That's a good decade after ACE was formed.

Another half decade later, and Alpha is king in the form of AMD Opteron.

I have a 486 with Slackware on it. I can assure you it performs nothing like a RISC workstation, and it has 20MB of RAM and a 100MB hard disk.

Re:Back in the day..

[turgid]

My dad wouldn't let me have anything that wasn't "PeeCee compatible" since that's what all businesses and Right Thinking Folk(TM) used, even if it was technically inferior.

I wasn't allowed an Amiga either (before the Archimedes came out)...

He's still stuck on Windows and curses it every time I speak to him.

I've been doing Linux and UNIX since 1995 (when I left home).

Re:Back in the day..

[dfghjk]

ACE was formed in 1991. At that time the 386 was dead and the 486 was available at 50MHz. The Pentium was introduced in 1993. It was superscalar and offered integer performance similar to the best RISC processors of that day, certainly faster than RISC from 1988! Such comparisons are silly. Incidently, the first Pentiums were 60 and 66 MHz. It took another cycle and a different pinout before the Pentium went 100 MHz.

As for GUI's, OS/2 1.1 (the first with a GUI) was introduced in 88. Windows/386, the first fully virtual, fully preemptive version of Windows was introduced in 87. Windows 3.0 in 90 and 3.1 in 92. Windows was not the exclusive desktop at the time but it was certainly established. Compelling Windows apps that forced the PC world over to Windows started appearing around 92, not much after the creation of ACE. Word started dominating WP beginning in 92. There was still a lot of DOS use but the PC world was hardly as you describe (slow 286's and 386's).

Memory cost the same for PC's as it did for workstations. If anything, PC's with their compact instruction sets and small footprint OS'es made better use of memory than workstations did. Don't know what your point is there. Workstations had more memory typically but they needed it and their prices reflected it. Business ppl didn't buy workstations.

Claiming that the Athlon was substantially better than the P3 is silly. It had a slight IPC advantage and eventually a clockrate advantage, but the two designs offered similar performance. While the Athlon was introduced in 99, 8 years after ACE (not a good decade), the first of the P3 designs was introduced in 95, only 4 years after ACE.

AMD's Opterons aren't Alpha's and it's a good thing. Alpha's sucked and the P4 looks much more like and Alpha than the Opterons do. DEC had good engineers and contributed nicely to the PC world, most notably with their PCI work, not their processor designs. They gave use PCI bridges and a nice ethernet controller.

If we are comparing experience with these machines, my first PC was an IBM 8088 machine. I started work for a major PC manufacturer in 87. I did OS/2 1.0 and 1.1 work, UNIX systems programming and NT driver development. I did firmware programming work for that company starting in 88. My first machine there was a 10Mhz 286 and I used every type processor and most speed grades since then. I had extensive experience with the 960, Alpha, and PPC 603 in addition to all the Intel x86 processors. I worked some with the i860, the Moto 88K and the Itanium. I'm quite familiar with the history of the processors, OS'es and ACE. You can have your Slackware 486 machine. I got rid of mine long ago and wouldn't be bragging if I was still using one.

Re:Back in the day..

[IntlHarvester]

x86 processors finally caught up with RISC workstations when the AMD Althon came out.

Actually, the original 200mhz Pentium Pro had higher SPEC scores than any RISC chip available at the time (although there was a revised Alpha a couple months later). The PPro pretty much put the final nail in the coffin of ACE/ARC/PREP and all the other RISC PC efforts, and the beginning of the end of the RISC Workstation. By the time Athlon came out, everyone had already pretty much given up except Sun.

Re:Back in the day..

[turgid]

By the time Athlon came out, everyone had already pretty much given up except Sun.

Yes, *sigh*. They all climbed aboard the itanic, which is still promising jam tomorrow.

Don't read too much into CPU spec scores. Yes, the PPro was impressive when it came out, but as with all x86 intel CPUs, the memory and I/O bandwidth was a problem. They were never intended for anything other than PeeCees. Sever and workstation applications were an afterthought, as anyone with any experience of SMP systems will tell you.

If only the i860 had lived...

Re:Back in the day..

[IntlHarvester]

> There was still a lot of DOS use but the PC world was hardly as you describe (slow 286's and 386's).

Turgid is right about this one. In 1991, there were still AT and even XT machines on the market, and 1MB would have been the stock RAM. The early 486 machines cost well over $5000 and it took a couple years for the chip to filter down to regular machines.

Re:Back in the day..

[turgid]

A more mature attitude will help you along in life.

Aw, shucks. Thanks for the tip, buddy.

and exaggerate the awesomeness of the competition

I don't exaggerate the competition. You young 'uns forget how truly dreadful the IBM compatible PCs of yesteryear were. They had to be to be compatible, since software was written far closer to the bare metal back then.

A PS/2 with OS/2 1.1 or better was a better machine than the ST, Macs, and RISC PCs/Archimedies' available at the same price points

Absolute drivel, hogwash and verbal faeces.

Did you ever write code on a 286 (or 8086 for that matter)?

Re:Back in the day..

[ArbitraryConstant]

"PeeCee"

It's hard to take you seriously when you say that.

"They were never intended for anything other than PeeCees. Sever and workstation applications were an afterthought, as anyone with any experience of SMP systems will tell you."

Actually, they optimized for 32-bit protected mode performance at the expense of real-mode performance. It hurt them because there was still a lot of real-mode software being used, but they were fine for UNIXes and NT.

Re:Back in the day..

[turgid]

Actually, they optimized for 32-bit protected mode performance at the expense of real-mode performance.

So? What the hell has that got to do with SMP servers? RISC chips had been "optimised for 32-bit" for a decade already, and most had long movedo on to 64-bit.

It hurt them because there was still a lot of real-mode software being used, but they were fine for UNIXes and NT.

They sucked and still do for Unix on SMP boxen.

In a previous life, I used to build software (many gigabytes daily) on 64-bit SMP RISC and 32-bit intel Xeon boxes. The cheap (and hot and unreliable) 4-way 1.9GHz Pentium IV Xeon Dell boxes were fast with one user, compared to the 64-bit RISC boxen.

Put 2 users on, and the Dell boxes sucked.

Then along came the 4-way Opteron box, with a lower clock frequency than the PIV Xeon, but NUMA architecture and twice as many registers, and it was faster with 1 user and scaled linearly with many users.

The 4-way Dell Pentium IV Xeon was shown up for the pocket money toy that it was. Oh, and it broke too.

Re:Back in the day..

[ArbitraryConstant]

"So? What the hell has that got to do with SMP servers? RISC chips had been "optimised for 32-bit" for a decade already, and most had long movedo on to 64-bit."

Merely pointing out an example of where they picked server/workstation performance over traditional PC performance. Pentium Pros were adequate for 1 and 2-way systems, and they cost significantly less than the RISC systems you would have needed to beat them.

"They sucked and still do for Unix on SMP boxen.

In a previous life, I used to build software (many gigabytes daily) on 64-bit SMP RISC and 32-bit intel Xeon boxes. The cheap (and hot and unreliable) 4-way 1.9GHz Pentium IV Xeon Dell boxes were fast with one user, compared to the 64-bit RISC boxen."

And here I thought we were talking about Pentium Pros. Pentium Pros have very little to do with the Netburst chips you are now criticizing, it's unfair to treat the two as similar as you are doing.

The Yonah chips that have just been released are decended from Pentium Pros, and while I hesitate to make SMP comparisons because there is not yet any Xeon version of the chip, they can keep up with the closest comparable RISC chip with a fraction of the power (eg a dual-core Yonah at 2 ghz uses about the same amount of power as a single-core PowerPC 970FX at the same clock speed, while either of the cores can beat the FX at almost anything other than FP performance).

Re:Back in the day..

[be-fan]

AMD's Opterons aren't Alpha's and it's a good thing. Alpha's sucked and the P4 looks much more like and Alpha than the Opterons do.

Um, what? You're right that the Opterons aren't Alpha, but wrong in saying they are closer to the P4. The Opteron's FPU pipeline looks incredibly like the 21264's, right down to the dual assymetric pipes. The load/store setup and L1 cache setup of the two architectures are very similar, down to the 64kb/64kb L1 cache sizes. The 21264's integer pipeline is much shorter than the Opterons (7 versus 12), and much much shorter than the P4's (20+). The 21264, in its more modern iterations (eg: the 21264B and 21264C) are higher IPC designs than the Opteron, in both integer and FP. What is your basis for the claim that the Alpha is closer to the P4?

Re:Back in the day..

[dfghjk]

Alphas in their day had far deeper pipelines than competitive processors with the specific goal of running at much higher clock rates, much as the P4 is today.

Comparing design specifics for processors of different eras with hugely different transistor counts and process technologies doesn't make a lot of sense to me. If you care to believe the Opteron is the evolution of the Alpha then more power to you.

Re:Back in the day..

[dfghjk]

This account of processor history http://www.pcmech.com/show/processors/35/2/ seems to disagree.

486's were not nearly so expensive at that time considering they had discontinued the 386 by 1991.

Re:Back in the day..

[dfghjk]

The i860 sucked as a general purpose processor and was intended as a coprocessor for PC's. It's exception handling was the worst ever divised! Don't cry for the i860, it was the i960 that truly suffered. It was Intel's original plan for 32-bit until they were compelled to do the 386.

Re:Back in the day..

[be-fan]

All processors lengthen the pipeline in order to reach higher frequencies. It's a basic engineering tradeoff. The difference between the P4 and the Alpha was that the P4 massively traded-off IPC for clock-speed, while the Alpha didn't. The Alpha's 7 stage pipeline (which was substantially longer than only the simplist RISC chips) was offset by sophisticated branch prediction (for the time), so its IPC remained quite high. The P4's long pipeline wasn't offset by correspondingly good branch prediction. Thus, the P4's IPC is only about 2/3's as much as a 21264's.

The Opteron isn't the "evolution" of the Alpha, but it takes many many basic design cues from the Alpha. An Alpha and an Opteron are much more similar to each other than either are to a P4. The Opteron's design is *very* similar to a 21264's, especially in the back-end. Consider:

1) Both CPUs cluster their integer units into ALU/AGU pairs. The 21264 has two such pairs, the Opteron has three such pairs.

2) Both CPUs use 64KB/64KB L1 i/d caches with 2-way set associativity.

3) Both CPUs have a similar number of in-flight instructions (72 versus 80).

4) Both CPUs move some decode work to the i-cache by using pre-decode bits in the cache. Both use the same number (3) of decode bits.

5) Both CPUs have asymmetric dual FPUs, one for FADD one for FMUL. The 21264 puts complex float instructions (sin, cos, sqrt) in the FADD unit, the Opteron puts it in the FMUL unit.

6) Both CPUs handle register renaming in the FPU pipeline almost exactly the same way. The Athlon's FPU pipeline is basically the 21264's with one extra unit (the FPMISC unit), some extra registers (for SSE), and some extra pipeline stages (since it runs at a much higher clockspeed).

7) Both CPUs use a memory crossbar.

The Opteron and 21264 are cleary different architectures --- the decoders are (necessarily) completely different, the two CPUs handle register renaming in the integer units completely differently, and the load-store units and TLBs in the two CPUs are different. However, its hard to miss the similarities in the high-level organization of the two chips. To a first approximation, calling the Opteron the offspring of a K6 and a 21264 would not be a strech.

Re:Back in the day..

[calidoscope]

ACE was formed in 1991. At that time the 386 was dead and the 486 was available at 50MHz.

You're a bit misleading there - IIRC, the 50 MHz 486's weren't avaliable until the end of 1991 and the 386 wasn't yet dead - as late as 1993, many (US) government contracts prohibited the purchase of 486 machines (you wanted speed - well try a 33 MHz 386/387). And except for the 386 ports of UNIX, the only software that supported the 32 bit mode of the 386 ISA were the 386 DOS extenders.

The RISC machines of that era could run rings around the Intel machines - MIPS was a strong contender (this was before MIPS became part of SGI) and HP was shipping 66 MHz PA-RISC systems at the end of 1991.

Re:Back in the day..

[IntlHarvester]

Hmm, I might have been off by a year or two. But the 386 certainly wasn't discontinued by 1991. Here's a list of IBM models for example:
http://www.seds.org/~spider/ps2/ps2hist.html

Re:Back in the day..

[IntlHarvester]

The memory and I/O bandwidth found in RISC "PCs" (Macs for example) wasn't really any better than what was in Pentium Pro PCs.

That was always the generic rip on "peecees", but at some point around 2000, with RAMBUS and 400Mhz buses and fast/wide PCI, PCs lapped the architecture of any RISC workstation. SGI's special 'crossbar' architecture Intel workstations was getting blowaway by Compaqs within six months of release.

Re:digg?

[frederik]

Isn't quite a large part of history old "news"?

I hear....

[Slashcrap]

...that Sun are also considering switching to Sparc for their servers. You know, if things don't work out with the Opteron they need a backup strategy.

I kid, I kid....

a company of "almosts"

[penguin-collective]

Sun almost created several great desktop window systems. Sun almost set a standard for web-based application delivery with Java. Apple almost picked Sun's SPARC architecture. Sun almost set the standard for server operating sytems. And then there are things that Sun achieved, briefly, and lost, like dominance of university departments.

I leave it to others to diagnose the exact causes of Sun's repeated failures. I can say this much for myself: I won't buy another Sun product again, ever, nor will I ever trust any of Sun's promises again.

Re:a company of "almosts"

[Animats]

That's very insightful.

Someone should write a book on how Sun blew it with client-side Java. They gave the product away and spent tens of millions marketing it. In a marketing sense, they succeeded; everybody has a Java interpreter on their desktop. Yet almost nobody uses them any more. Why?

Part of the problem is that Sun's top technical people, including Joy, never really figured out GUIs. Sun went through three bad in-house window systems before finally giving up and going with X-Windows. Then in the Java era, they went through the AWT and Swing eras, both of which combine complexity with poor performance.

So Sun ended up as a "server company", the place SGI went after they failed to survive the transition to low-cost graphics.

Re:a company of "almosts"

[Decaff]

Yet almost nobody uses them any more. Why?

You are wrong. Java client-side development is far from dead - it is growing, and at the end of last year overtook MS WinForms as the most popular client-side development platform in North America. There are even 'shrink-wrapped' commercial Java applications based on Swing that are amongst the best in their class (the financial package Moneydance is a good example).

Then in the Java era, they went through the AWT and Swing eras, both of which combine complexity with poor performance.

Easy to say, but wrong. AWT was not poor performance because it was the native GUI. Swing went through years of poor performance, but .... got better. Now it is hardware accelerated.

It is easy to take cheap shots at a technology by on recycling common myths based on the way things were 4 or 5 years ago. However, to post facts it is a good idea to actually try the technology as it is now. Swing on Java 1.5 is neither memory hungry or slow.

Re:a company of "almosts"

[Hezaurus]

>> Yet almost nobody uses them any more. Why?

> You are wrong. Java client-side development is far from dead - it is growing, and at the end of last year overtook MS WinForms as the most popular client-side development platform in North America.

Hey! You didn't count all the gazillions of mobile phones out there that all (well >95%) run java.

> Swing went through years of poor performance, but .... got better. Now it is hardware accelerated.

What you mean is that some of the drawing operations are accelerated. 1.5 is quite good and 1.6 will finally get rid of the famous 'gray rect' for good. Most of the components that are geared towards heavy use (e.g. JTree, JTable) are top performers already.

The event handling framework is quite complex (you can do practically anything with it) and the fact that each java class behaves almost like a dynamically linked library in more static languages will keep the start-up performance forever behind.

> Swing on Java 1.5 is neither memory hungry or slow.

The memory usage hasn't shrank since I was introduced to java. The extra hit that comes from the VM and GC is major pain in small applications but negligible in bigger ones. Class data sharing for java's built in classes (introduced in 1.5) helps too little in that respect and I don't expect major improvements in that area, at least not in the near future. Speed is getting better and better with every release and I expect java 1.6 (Mustang) to finally put an end to this everlasting java is slow whining.

Re:a company of "almosts"

[Decaff]

The event handling framework is quite complex (you can do practically anything with it) and the fact that each java class behaves almost like a dynamically linked library in more static languages will keep the start-up performance forever behind.

You might think so, but it really doesn't. Try the following: Install a significant Java application like JEdit or Moneydance. Time it's startup. I typically get start-up times of 3-4 seconds. That is faster than most KDE apps on the same machine!

The memory usage hasn't shrank since I was introduced to java. The extra hit that comes from the VM and GC is major pain in small applications but negligible in bigger ones.

I don't find this. I can start up trivial Java apps in just a few megabytes, and even Swing apps like JEdit can run in 8MB. That is nothing on modern machines. As for the GC being a major pain - it can be finely tuned these days, so much so that real-time APIs can be implemented even on standard VMs.

My impression is that performance and memory efficiency has improved significantly since Java 1.4.x.

Re:a company of "almosts"

[AdamTheBastard]

Sun 'almost' gave us OpenOffice.org?

Re:a company of "almosts"

[Decaff]

"That is nothing on modern machines."

I've heard that since I started at the University in '98. Java is still dead slow.

Why do people say this? No modern benchmark shows Java as slow. This is false.

And, 8MB IS nothing on modern machines. Things have changed a little since 1998, you know!

For desktop applications:
The interfaces are slow, quirky and isn't responsive enough.

Sorry, no. This simply is false and without foundation. I challenge you to open a modern Java app line JEdit on a modern VM and find anything slow or unresponsive about it.

The fscking garbage collector grows slow over time.

No, it doesn't. When this happens, it is a feature of inefficient memory use in code, not the garbage collector. I have batch processing code in Java that handles millions of objects, and the GC is fine.

With java, you have to send a signal to get the VM to do a threaddump, or connect a debugger to the debug-port .. except that you often don't have access to the source code since you're "just" a server admin.

All this can be done with modern tools that automatically connect to server apps, like Eclipse or NetBeans.

And you not having the access to the source code is Java's fault? Sounds like a management problem.

Bah! I hate java.

I would suggest you hate your work situation and the quality of code you have been given to deal with. This is nothing to do with Java.

Re:a company of "almosts"

[Decaff]

AWT had poor performance because JNI is a piece of shit.

Er, no. AWT did not use JNI. JNI was not released until years after Java first appeared with AWT.

It was also buggy as shit.

No it wasn't - AWT was simply not very portable, but it worked fine. It worked according to its specification.

Java's desktop footprint is largely the business desktop, where application selection is done by fiat.

And this is relevant how?

Re:a company of "almosts"

[mallardtheduck]

Java will ALWAYS be slower than native code. It takes time to translate java bytecode into native machine code. This cannot be optimised away.

Java is certianly no less memory hungry than it origininally was, the only difference is that 10 years ago, the average machine had about 16MB of RAM, so java using 8MB was rediculous. Nowadays we have 512MB-1GB in the average machine, so 8MB is almost unnoticed.

Other reasons why I dont like java:
*Encourages taking the OO pradigm to rediculous levels. (I have seen people put all their "utility" methods in seperate classes, just so they don't end up with unused code in their application.)
*Non-Free (A fully featured Free implementation is a while off.)
*Java applications *never* conform to any OS's standard look, no matter what OS you run them on. (Linux java sort-of uses Gtk, Windows (sun) java uses its own widgets, Mac java uses Aqua, but does not conform to Apples UIG.)
*Java applications cannot take advantage of OS-specific features, so often OS-specific "helper" apps are written, reducing the application's portability.

Re:a company of "almosts"

[Decaff]

Java will ALWAYS be slower than native code. It takes time to translate java bytecode into native machine code. This cannot be optimised away.

Apart from the fact that there is nothing to prevent Java being compiled directly to native code (there are many such compilers), the process of translating to native code is fast.

Look at it this way. You have a C program supplied as source code. It takes a few seconds to compile, then runs at native speed. Does that few seconds mean that C can never run at native speed? Of course not. You now have a Java program supplied as byte code. It takes a few seconds after starting to translate to machine code then runs at native speed. Does that few seconds mean that Java can never run at native speed? Of course not. Most Java apps run for far more than a few seconds - often for weeks or months server side. The few seconds it takes to optimise are totally insignificant.

It also depends what you mean by 'native code'. Different compilers can produce different qualities of native code. The Java Hotspot optimiser has the ability to profile and re-optimise native code at runtime, taking avantage of highly-processor specific features, so it could well be faster than a pre-compiled C binary that is targetted at a general class of processors.

Java is certianly no less memory hungry than it origininally was, the only difference is that 10 years ago, the average machine had about 16MB of RAM, so java using 8MB was rediculous. Nowadays we have 512MB-1GB in the average machine, so 8MB is almost unnoticed.

This would be true if Java did not run perfectly well on small memory devices, which often have only a few tens of kilobytes.

*Encourages taking the OO pradigm to rediculous levels. (I have seen people put all their "utility" methods in seperate classes, just so they don't end up with unused code in their application.)


This is odd, as most people I know who really understand OOP say that Java has far too little OOP. Code can be just as used or unused in utility classes as in superclasses - this is irrelevant to the argument. Inheritance is simply a different way of packaging functionality.

*Non-Free (A fully featured Free implementation is a while off.)

This is not an issue for a large number of developers. GNU Classpath and Kaffe do a reasonable job and are totally free. This is simply a political issue you have with many implementations, it has nothing to do with the language itself (free implementations can be certified as Java without losing their 'freeness').

*Java applications *never* conform to any OS's standard look, no matter what OS you run them on. (Linux java sort-of uses Gtk,
Windows (sun) java uses its own widgets, Mac java uses Aqua, but does not conform to Apples UIG.)

Sorry, wrong. If you use SWT Java applications ARE the OS's standard look, because the use the OSes standard GUI. Mac Java does conform to Apple's UIG. Guess why? Apple wrote the version of Swing for their systems. On Vista, Swing is going to pixel-by-pixel identical to native apps - as Microsoft have realised the importance of Java client side and are helping with this.

*Java applications cannot take advantage of OS-specific features, so often OS-specific "helper" apps are written, reducing the application's portability.

Like what? Both Swing and SWT have full OS integration, allowing you to use things like drag-and-drop, directX etc. The Java Native Desktop Integration API allows full use of features such as system editors, browsers, file system etc.

Re:a company of "almosts"

[Listen Up]

"It is easy to take cheap shots at a technology by on recycling common myths based on the way things were 4 or 5 years ago. However, to post facts it is a good idea to actually try the technology as it is now. Swing on Java 1.5 is neither memory hungry or slow."

Excellent. Our entire enterprise RFID manufacturing system runs %100 J2EE and J2SE transparently and efficiently on multiple different architectural platforms. Today's Java technologies are absolutely incredible and light years ahead of the old, ignorant, and misinformed myths of the past.
 
Client-side Java is taking over our company as well, because it is becoming easier and easier to simply serve applications remotely over the intranet than to install them on each individual computer. Plus, the Java application server is exceptional.
 
With Java 1.6 and beyond (especially with Matisse) I expect Client-side Java to really take off. From a personal perspective, I am looking forward to writing in %100 pure Java %100 of the time in the future.
 
I wish all of the people who ignorantly complain about Java would stop comparing poorly written Java applets or poorly written opensource programs to true professional commercial server and client side Java applications. And I also wish all C/VB programmers would simply stop what they are doing and learn proper OOP.

Re:a company of "almosts"

[Listen Up]

Again, another excellent comment.

Re:a company of "almosts"

[Listen Up]

Your entire post is completely ignorance in action. None of what you say about Java is true whatsoever.

Re:a company of "almosts"

[Decaff]

With Java 1.6 and beyond (especially with Matisse) I expect Client-side Java to really take off.

I expect it will take off, but largely without anyone noticing. The recent Sun/Microsoft co-operation seems to have paid off in terms of the quality and integration of Swing with the Vista GUI. Although I personally have no objections to the Java 1.5 standard look and feel, Swing under Vista should be totally indistinguishable from native apps and fully integrated. There will be many Java apps around with no-one being able to tell.

Of course, this makes things more complex for developers, trying to choose between client-side and web applications!

Re:a company of "almosts"

[Listen Up]

Again, another excellent post.

Re:a company of "almosts"

[Listen Up]

"Someone should write a book on how Sun blew it with client-side Java. They gave the product away and spent tens of millions marketing it. In a marketing sense, they succeeded; everybody has a Java interpreter on their desktop. Yet almost nobody uses them any more. Why?"

What rock have you been living under? A large majority of new features in the upcoming Java 1.6 are solely desktop related:

http://java.sun.com/developer/technicalArticles/J2 SE/Desktop/mustang/index.html

On a side note, OpenGL -and- DirectX planned in the future. Hello Java gaming!!!

Re:Dupe [OT]

[frdmfghtr]

I agree...while the two linked articles touch on the almost-merger and use of PPC over SPARC, one focuses on the merger/acquistion story and one focuses on the PPC vs. SPARC decision.

Half brother/half sister stories? Cousins?

Re:we know

[xusr]

I know you were trying to be humorous, but Alzheimer's is hardly a tasteful target; it is a serious disease that is a source of extreme pain for many people. Please be more conscious next time when attempting to crack a joke.

Maybe.

[Anonymous Coward]

I leave it to others to diagnose the exact causes of Sun's repeated failures.

There's a certain arrogant complacency and aloofness from the "vulgar real world" within Sun's higher engineering echelons. Someone needs to tell Scott. I'm not talking about the Bill Joys of this world, but the prima-donna engineers who sit a couple of levels down destroying good projects at the review process because they didn't think of it first or they didn't get to do it themselves or because it was done by a different part of the company.

I'm sure this goes on in all large companies.

Re:Sun should port x86 Solaris to intelMac

[turgid]

The main problem x86 Solaris faces is providing driver support.

That problem is being addressed and started with the Solaris 10 project many years ago. Solaris 11^H^H Nevada will again be a vast improvement.

Solaris 10 x86 runs better than Linux on modern laptops. Solaris 10 rules.

Isn't that...

[Black Parrot]

Isn't that kinda like "I almost got laid"?

Re:Isn't that...

[aztektum]

In their last meeting, Apple reps. were rumored to have consoled them by saying, "Don't worry, it happens to a lot of chip makers."

Re:Isn't that...

[EddyPearson]

No. It isn't. And i find the fact that more than one slashdotter relates SPARC architechture to their sex life, upsetting (but not surprising)

Re:Isn't that...

[UnanimousCoward]

Laid? You know you're posting to /., right?

Apple procs have enough probs

[lopie]

Haha, there is great proof over at http://www.phooty.com/modules.php?name=News&file=a rticle&sid=37 about an Apple editor.

Cell would have been even better

[SteeldrivingJon]

They should have gone with the Cell. It's even better than Sparc.

NOTE FOR THE SARCASM-IMPAIRED: This comment is meant as a spoof of the unavoidable Cell comments that come up in any Apple CPU discussion. The anachronism is intentional.

Re:Cell would have been even better

[Dr. Cody]

No spoof ever came with a caveat twice its size.

Conclusion: You suck at the Internet.

Wouldn't Have Made a Big Difference

[Alon Tal]

Most probably, the only difference today would have been that we would be reading about Apple dumping _Sun_ for Intel, rather than dumping IBM for same. Reminds me of an Isaac Asimov story called "What If-", in which a newlywed couple meets a man who owns a gadget that can show them alternate realities, if key events in their past had taken a different course. For example: Would they be married had they not accidentally met on a train ride, etc. They keep going back to different points in their past: The day they met, the date of their wedding, and of course, everything is radically different, which aggravates the wife to no end ("This marriage is just based on chance, an accident..."). Right before everything gets really ugly, the husband deparately says: "Show us what we would have been doing at this very moment, had we not met on that train", and, surprisingly, they see themselves, exactly as they are right now, sitting together, happily married.

Re:Wouldn't Have Made a Big Difference

[argent]

Would have made a huge difference. If Apple had gone to Sparc they'd have gone out of business before Jobs got back, because SPARC is almost as bad a processor architecture as x86, and Sun doesn't have the resources of Intel to just bull through the problems through sheer force of process.

Other Great Almosts in History...

[GigG]

I almost had sex with Farrah Faucett when I was 13 and she and I were in the same airport (JFK). Almost = we were both there and I certainly thought about it.

Re:Other Great Almosts in History...

[Vladimus]

I almost had sex with Farrah Faucett

Who?

Re:Other Great Almosts in History...

[IANAAC]

Watch "That 70s Show". We all had that exact same poster on our bedroom wall when we were teens.

Re:Other Great Almosts in History...

[nugatory]

/. doesn't do subtlety - so that one-word "who?" which should be modded up to a +5 is probably destined to languish unappreciated - but at least it happened in a discussion of great almosts.

They also looked at Alpha

[Ian.Waring]

... before they consumated their relationship with IBM (5 initiatives on offer, including one called Pink - the domain of then Apple employee and ex-VMS engineer Roger Heinen). KO was a big fan of the Apple Desktop Bus and it's simple connectivity, but vetoed Digital Semiconductor providing the chips. Or maybe that was Jack Shields in the Executive Commitee, who drove everything vertically integrated to go eat IBM's lunch by 2007...

Fokelore in DEC at the time anyway. How much of it was true may be a different story.

Ian W.

Cool threads CPUS + MacOS?

[moshennik]

With the new Cool threads CPUs (up to 32 threads per CPU), with low heat and energy consuptions SUN is years ahead of competition. It would be interesting if Apple made a play on it.

Re:Cool threads CPUS + MacOS?

[argent]

Don't forget the low single-threaded performance! That's one of the big advantages of SPARC, after all!

Re:we know

[Anonymous Coward]

Yeah, he forgot where he was posting

More History

[FrankDrebin]

The Macintosh line would have been replaced by the SPARtan, leading to memorable models like the iSpart.

And the secret SPARC OS project was called...

[OneDeeTenTee]

Sparcler.

obligatory George Carlin quote

[Laebshade]

"here's a phrase that apparently the airlines simply made up: near miss. Bullshit, my friend. It's a near hit! A collision is a near miss." - Airline Announcements, George Carlin

Re:obligatory George Carlin quote

[Laebshade]

You don't get it. George Carlin is implying that by calling it a "near miss" you're downplaying the seriousness of it. Call it what it is, a "near hit".

Abnormally deep pipeline?

[argent]

It's strength was it's ferocious clock rates that were enabled by abnormally deep pipelines and instructions that did relatively little (no integer divide!).

7 stages is not an "abnormally deep pipeline", and divide-step is absolutely conventional RISC design. The Berkeley RISC used divide-step. Sparc started out with divide-step. There really isn't a huge difference between Alpha's ISA and any other RISC, the difference is in the small details... whatever criticism you have of the Alpha, you can't in fairness leave the other RISCs out.

Alpha also had great execution control. The memory barrier instruction (also in Power, by the way, and eventually picked up by Sparc) let the compiler control the pipeline far better than Itanium's "I can't believe it's not VLIW" design or MIPS "just guess" delayed branch. And the huge register file gave the compiler much more leeway in scheduling instructions.

The biggest problem with the Alpha was that it jumped prematurely into 64-bit with both feet, so that even if the compiler generated 32-bit code (the -taso option) it was still moving 64-bit words around and throwing away half the result.

Re:Abnormally deep pipeline?

[dfghjk]

Not sure 7 stages is right, thought it was 9, but I won't argue it. It was deep at the time.

PA-RISC and Power had far more powerful instruction sets than Alpha at the time Alpha was introduced.

Re:Abnormally deep pipeline?

[argent]

You're right, it was 9.

Power PC (6xx and G3) was 4, which is about the minimum for pipelines to be useful: the "traditional" pipeline model has 5 stages: fetch-decode-execute-memory-writeback.

The original Pentium had 5, but the P6 core (Pentium Pro, Pentium II, and arguably Pentium III and the new Core Duo) had 14. P4, of course, is the poster boy for deep pipelines.

There were too many versions of SPARC right from the start, I don't know how many stages it had... probably not very deep because the register model made deep pipelining difficult... though Sun got up to 14 with the US III.

MIPS had anything from 4-8 stages depending on the implementation. The R4000 would have been on the table at the time, and it had 8.

Deep, yes, but not abnormally so.

As for the "power" of the instruction set... Power might have had all kinds of goodies, but the Power PC didn't get them until the G4.

Don't really know enough about PA-RISC to comment on that. I only got into HP after HP bought Compaq... and all our HP-UX boxes are Itanium. Given my experience with HP I'm quite prepared to believe that PA-RISC was good, but thatnks to Itanic I'll never know.

The point is, Alpha was not simply "insane clock and pipelines". The huge register file and the use of memory barrier to let the compiler manage so much of the pipeline interlocking were also critical to letting it retire instructions effectively without losing clocks to pipeline bubbles.

Re:Abnormally deep pipeline?

[be-fan]

Which Alpha had a 9 stage pipeline? The '064-'264 were all 7-stage designs. The 604 had 6 pipeline stages, not 4. The Pentium Pro had 10 pipeline stages, not 14 (though, some sources erroneously report 14). US I and US II had 9 stage pipelines.

Re:Abnormally deep pipeline?

[argent]

Which Alpha had a 9 stage pipeline? The '064-'264 were all 7-stage designs.

I thought that, but I checked on various sites and found 9. Maybe that's floating point?

Anyway, it definitely wasn't "abnormally deep".

Re:Abnormally deep pipeline?

[calidoscope]

Given my experience with HP I'm quite prepared to believe that PA-RISC was good

It was good.

Remember that the PA-RISC was designed by hp, and not the printer company with the remnants of Compaq and DEC.

Re:Abnormally deep pipeline?

[be-fan]

The 9 stage length is in the case of a load/store instruction. Since it is usual for the minimal pipeline length to be reported (ie: for single-cycle integer instructions), 7 stages is a more accurate figure for the Alpha.

Re:Abnormally deep pipeline?

[argent]

Ah, that's probably the discrepancy in the 6xx, too, because I got 4 rather than 6.

Re:Abnormally deep pipeline?

[argent]

I was being cynical: it seems like HP under Carly systematically looked at their product line... and got rid of all the best products. So anything they decided to dump must have been the good one.

Re:Abnormally deep pipeline?

[be-fan]

Actually, you're right that the 601 and 603e, as well as the G3 have a 4-stage pipeline. The 604e has a 6-stage pipeline to support its larger instruction window.

Re:Abnormally deep pipeline?

[argent]

Interesting. That would explain why the first G3 Macs were slower than the last 604e-based ones.

Of all sad words of tongue or pen...

[dpbsmith]

Of all sad words of tongue or pen, the saddest are these: "It might have been."

(Sorry, I couldn't think of anything Whittier).

Well if they *almost* used SPARC

[alfrin]

Isn't that like, "I almost got laid with man"

Money, not engineering

[Foerstner]

That's pretty much the way it went.

If the workstation vendors had picked a chip...any chip...they might have had a chance. Their combined investment might have countered Intel's, and their combined volume might have increased their economies of scale to the point where workstation price/performance remained competitive. (In the early days, this actually happened...around the Motorola 6800, which most vendors used, and which, for a while, held the x86 world in awe.)

In reality, each company had its pet chip, and both management and engineers were too caught up in not-invented-here to survive.

I got very close to getting laid once

[55555 Manbabies!]

It almost happened.

Dominant but not innovative

[jd]

Apple has always gone with trying to be the most creative. The Apple Newton was a good example. Great idea, creative for the era. In many ways, it wasn't Apple's fault that the technology of the time simply wasn't up to what they wanted with the Newton. The same is true for the original Macs and why they were not simply an evolution of their very popular Apple II line.

So, if innovative and creative are the name of the game, I'm actually surprised the Sparc was considered at all. The MIPS would have been a better choice, from that perspective as well as in terms of novel design. Not sure if the Transputer was still in circulation at that time or not, but that really SHOULD have appealed to Apple - parallel processing was starting to get people's attention and the Transputer was the best design out there. Arguably, in some ways, it still is - it is horribly difficult to get SMP to scale beyond 32 processors on a single node, but a High School student could build a 1024 processor Transputer block.

What other processors really stand out...? There were some interesting efforts to build processor-in-memory systems at that time - again, it would have been highly novel (which Apple liked) and would also have been fast (no delays in fetching from main memory). High-level processors (that could run 3rd generation or even 4th generation languages as the instruction set) would win on novelty, but never got anywhere, so would probably have fallen under Apple's radar entirely.

Asynchronous processors were also beginning to take off. Great for novelty, would have been superb from an IP standpoint (the rest of the industry wouldn't know HOW to clone them, even if they wanted to) but again really didn't make as much of a splash as a lot of people thought.

A better bet for Apple, actually, might have been to buy out a small-scale CPU manufacturer like Inmos and build a CPU that perfectly met their requirements. It would not have cost substantially more than buying the PPC from IBM, it would have given them "editorial control" over the instruction set, and they could have recouped the investment by selling the processor as well as the computer.

To me, that would have been one hell of a "what might have been" - a cross between Transmeta (ten years early) and SGI (who were doing very nicely at the time).

No MIPS for MIPS

[fm6]

You might get that impression, because SGI was the best-known maker of graphics workstations, and for a long time they used MIPS chips exclusively. But I don't recall any other GWS company using MIPS at all. I think HP's PA-RISC was as big as MIPS for a while. Plus POWER and SPARC had significant market shares.

I don't know the hard figures, but I think SGI never really dominated the GWS market. They just got most of the press because a ton of Hollywood SFX were generated on their MIPS workstations.

The fact that Apple considered SPARC and settled on POWER has a certain pathetic fan-boy air to it. The Mac is supposed to be the ultimate end-user system, "the computer for the rest of us", a system that's really easy to use. Such a system is (in theory) mostly purchased by technically naive people who don't need all that extra processing power. But Apple always had to have the coolest hardware, engineering it themselves when they could, and buying the fanciest stuff when they had to buy off-the-shelf. Which is why their manufacturing costs used to be out of control, and it took them so long to get prices down where they could compete seriously with PCs.

Then again, the Coolness Factor has probably done more to sell Macs then any supposed superiority in usability.

Re:No MIPS for MIPS

[IntlHarvester]

By the time period discussed, Apple had gone far away from the "computer for the rest of us" idea, and was selling high-end graphic machines that cost $8000+.

Re:No MIPS for MIPS

[damsa]

Not quite, the mid 90s was when Apple introduced its consumer brand of computers, the Performa. Early 90s, yes you can either buy a Honda Civic or a Quadra 900.

SPARC was dominant, except...

[msauve]

for the fact that for 1993 (one year prior to Apple's introduction of the PowerPC Macs, so contemporaneous with the decision process for the move to a RISC CPU), market shares were:

HP PA-RISC 31%
Sun SPARC 25%
MIPS 20%
IBM RS/6000 12% (the architecture upon which the PowerPC was based)

I don't think most people consider "middle of the pack" to be a dominant position.

Re:How much more metaphores?

[Valdrax]

Two points:

1) You have nouns and verbs confused. Neither Sun, Apple, jar, nor bean are verbs (and JAR is actually an abbreviation for Java Archive).

2) "Archives" and "programs" are also real-world words lifted for used in computers. An "archive" is a repository where you store historical records, and a "program" is a document that lists what acts will be performed (in order) at an event like a symphony or ballet.

Re:Sun should port x86 Solaris to intelMac

[Zontar The Mindless]

What driver problems?

I've installed it on about 7-8 different machines and it's done great on all of them.

Solaris isn't intended as a multimedia, gaming, or use-my-latest-bleeding-edge-tech-toys OS, it's intended to provide a stable platform in order to get work done.

If you put it on a generic workstation or server box, it pretty much kicks butt.

Really?

[ral8158]

In other news, SCO nearly moved to actually producing a product.

You left out ARM

[LWATCDR]

Apple could have gone with ARM which might have really been a big win. The ARM family probably is the most popular RISC cpu on the planet now. No reason that the ARM could have an FPU or vector processor.
Imagine several XScale cores with some vector units all on a single die.

No, not really.

[Anonymous Coward]

I worked at Apple at the time.

No, many processors were not considered.

The transition was to be to 88K. The engineers worked that out, and a IIsi with 88K chips in it was created for development. When the idea was turned over to the PHBs, the PHBs decided that switching to 88K was stupid and that the switch would be to PowerPC instead. Using PowerPC instead of 88K was called just "a packaging issue" by the PHBs, although it required a lot of effort since the emulator was written in 88K assembly.

The idea of moving to PPC was because 88K was only made by one company (who owned the IP), whereas PPC had the AIM (Apple-IBM-Motorola) alliance behind it and the IP was available to all 3 (presumably Apple could make CPUs if the other two refused). Since SPARC was wholly owned by SUN, it would not have merited serious consideration.

Star Trek was different. Star Trek had no emulator, it only ran recompiled binaries. Actually, it couldn't run those either, it didn't run binaries, the demo was just the Finder and System compiled together in one big compilation unit.

Also, as far as I know, Star Trek was never officially demonstrated outside the 3 companies involved (Apple,Novell,Intel). There was only one group in the company (Gifford Calenda's) behind it, and they only had control over operating systems, not any other technology or evangelism. Although early demos of MAE (Macintosh Application Environment, which ran Mac apps on various UNIX machines) were actually the Star Trek code recompiled for different platforms. This is what Morris Taradalsky (sp?) showed at WWDC on an IBM RS/6000.

MAE came a bit later, it did have an emulator, but it was a different emulator than the PPC machines used. It ran on SUNs and IBM RS/6000s, I don't recall what else.

My guess is Bill Joy (or other SUN person in question) got MAE confused with the PPC transition effort.

Re: where's the nukes?

[Nethemas the Great]

Dont' forget the thermo-nuclear weaponry. Why is it no one ever gets that saying right...

"Close only counts in horseshoes, hand grenades, and thermo-nuclear weaponry."

--Neth

Re:How much more metaphores?

[kumanopuusan]

Sun can also be appled as a verb.

Re:Sun should port x86 Solaris to intelMac

[Slashcrap]

Solaris 10 x86 runs better than Linux on modern laptops.

The wealth of evidence you have provided for this claim has totally convinced me. Some people say that extraordinary claims require extraordinary evidence, but then they've probably never met a Solaris zealot.

Re:How much more metaphores?

[Forbman]

Let me jar your head loose from your ass with this 2x4... *whack* (hey, I even used 'loose' correctly...)

So, "jar" certainly can be used as a verb.

If you've played baseball, you've probably been beaned by a pitch at least once. So, there again, English Major, another noun that is also quite properly used as a verb.

An "Archive" is in one usage a repository for historical purposes, whether it be an electronic backup, a printout stored in a document storage library or file cabinet, a laser-etched stone tablet, whatever, and it is also used to refer to *any* collection of files (and possibly directories) of files joined into one entity, like a "tar" file (Tape ARchive). Jar files are really just zip files in disguise anyways.

Sun & Apple as verbs? OK, you probably got us on that one.

As is common also in the English language is the usage of words in a vernacular fashion, which takes root usually as part of a specialized jargon for a given domain area or topic, so your complaint may be applicable to the usage of English in general, but in this area maybe not so germane.

So while complaining about these apparant travesties of language justice, will you write letters to me to all the sports writers in the world to stop using "athleticism", as if it means anything real? I could come up with a couple more if you want. Like, "he sure is hobbled by that 'left acl'" (no mention that it's partially torn or sprained or otherwise injured, just that it is). And WTF is a "high ankle sprain", "sports hernia" or "groin injury"? At least "turf toe" means something - basically a seriously jammed/dislocated toe joint.

8Mb is 8Mb!!!

[tjstork]

>And, 8MB IS nothing on modern machines. Things have changed a little since 1998, you know!

When you go around making statements like that, its highly likely that "Java is pretty fast" statements should be taken with a grain of salt!

Re:8Mb is 8Mb!!!

[Decaff]

When you go around making statements like that, its highly likely that "Java is pretty fast" statements should be taken with a grain of salt!

Why exactly? Memory use has nothing to do with speed. 8MB for an optimising high-performance VM, full-featured GUI library and a full-featured application like JEdit IS small! If you look at an equivalent non-Java application like Kate, it can require tens of megabytes.

I generally take comments which are simply opinions not backed up by evidence with a pinch of salt.

Re:8Mb is 8Mb!!!

[Listen Up]

The %100 pure Java RFID solution our enterprise uses is www.tagsware.com . We have begun moving all of our manufacturing and client processes to Java and we have never been happier. Fast, efficient, and powerful as well as allowing us the freedom to remove ourselves from hardware limitations by allowing us to run all of our applications on both modern and legacy x86 machines, PPC machines, and other custom hardware with %100 Java custom hardware code.

Re:How much more metaphores?

[Valdrax]

Let me jar your head loose from your ass with this 2x4... *whack* (hey, I even used 'loose' correctly...)

I'm so proud for you.

"Jar" is the only thing you've mentioned that can be used as a verb outside of the context of applying the noun's meaning as an action. "I was jarred by the scene I saw." Of course, JAR isn't meant that way since it's an abbreviation of something different. "Beaned" comes from old slang for a person's head. In any case, none of the words the original AC were talking about were being used as verbs, all that could have their origins as nouns, and at least one of the words (Apple) can't be used as a verb at all. Your "great revelation" is nonsense.

As is common also in the English language is the usage of words in a vernacular fashion, which takes root usually as part of a specialized jargon for a given domain area or topic, so your complaint may be applicable to the usage of English in general, but in this area maybe not so germane.

Really!? No kidding!? Why that's almost exactly what I was arguing.

"Archive" and "program" are words adapted from their original meanings. All computer terms that have gained any traction down the to word "computer" are either adaptations of existing words, acronyms, or corporate trademarks and servicemarks. They were "real-life" words too. In my opinion, "Apple," "Sun," and "Bean" are all a far sight better than Intel 80286 and IBM 3270 or Athlon and Opteron if you ask me.

So while complaining about these apparant travesties of language justice, will you write letters [...]

Wait, why am I the guy writing letters of pointless complaint in your little fantasy world? I'm not the one complaining that we should stop using real world words for computer terms. I'm just the guy who pointed out that his complaint is self-contradicting since his counter-examples were "real world" words too and that he can't keep his parts of speech straight.

(Sure, I should've left out the bit about parts of speech since it was extremely petty, but you people are completely insane trying to counter-argue that I wrong since some of the words can be used as verbs in completely different contexts from the ones the computer terms originated from.)

Re:Sun should port x86 Solaris to intelMac

[Listen Up]

The download is free. So, download Solaris 10 and try it yourself.

Since NeWS wasn't a "bad window system"...

[argent]

Sun went through three bad in-house window systems before finally giving up and going with X-Windows.

I know about Sunwindows, and NeWS, so what were the other two?