AMD, Transmeta Edge Up In Market Share

prostoalex writes "The new Mercury Research report on the microprocessor market is out, and it looks like the little guys are gaining ground. AMD now owns 15.7% of the market, instead of 15.6% a year ago, while Transmeta and other manufacturers went from 1.7% to 1.8% in a single year. Intel owns 82.5% of the market instead of 82.8% a year ago. News.com.com also notices: 'The competition between the two companies will shift into high gear over the remainder of the year. On Sept. 23, AMD will release the Athlon64, a new desktop chip that can run 32-bit and 64-bit software.'"

Comments

Hrmm

[acehole]

If AMD are releasing thier 64 bit chip early, does intel have any plans to? or are they still insisting that desktop users arent ready for 64 bit chips?

Re:Hrmm

[Bloodmoon1]

Actually, Intel does have the 64 bit Itanium processor for "enterprise solutions". Though based on the last half of your post, you were wondering about desktop processors, in which case the answer probably goes something to the effect of, "Apple has had the G5 for about a month now, AMD will have the Athlon 64 in a month and a half, and we have nothing. Better up the P4 clock rate to 5 GHz in the next 6 months and pray Joe Idiot still thinks it's faster." Just my assumption at the next Intel marketing move.

Re:Hrmm

[borgdows]

or are they still insisting that desktop users arent ready for 64 bit chips?

Bill Gates (1985) - "No one needs more than 640kb of memory"

Intel (2003) - "No one needs more than 32-bit processors"

Re:Hrmm

[Juanvaldes]

I'm a mac user and all but really, you will probably be ablet o get a Athlon 64 at the same time you can walk into a apple store and buy a G5.

Re:Hrmm

[finallyHasANickname]

Not to put too fine a point on it, but don't such questions ultimately redound to philosophy? Who needs a widget? Before scoffing/flaming/shrugging, gimme just a coupla extra sentences' worth.

I paid more than $100 for the extra 2 megabytes of RAM necessary to get Turbo C++ 3.0 for DOS working on my 10 MHz Cyrix-based AT clone (i.e., i80286, 80286, '286, 286, depending when you "label"). It was worth every penny.

The thing that might most merit your attention here is something I learned very quickly after getting just the first few programs to work. The permutations of what I could program might as well be considered infinite. Get this: It is difficult to completely reign in (or even fully to comprehend) the vast and diffuse capabilities of a 10 MHz beige box limited to the 80286 instruction set and bend-over-backwards-in-the-Protected-Mode 16 MB of RAM physical ceiling. This weak piddly hardware has--I said has, not had--more capability than I could explore in ten lifetimes as a creator of software. When the companies continue to crank out traincar loads of what (for now in the "Pre Palladium Rollout Era") is still pretty general-purpose hardware, "limitations" are matters of philosophy of science, which is where I started, come to think of it. I guess my age is showing, but I think (that is, when I think well) it is all (literally) awesome, and it has been thus for about a half century and counting.

Re:Hrmm

[dpilot]

Well so far Intel is 82.5% right with their strategy, but that's down from being 82.7% right a year ago.

But speaking of benchmarketing, it would be REALLY fun to see some sort of CPU shootout, *all done with gcc*. Most of us either buy applications, or compile them ourselves, using gcc.

Really, Spec means very little to us. Quake, Unreal, etc fps are meaningful to those of us that play those games. To the Linux crowd, at home, business, and universities, gcc is how we get executables.

Apple recently got a black eye for using gcc for benchmarking, but perhaps erroneously. Intel does wonders on benchmarks, but I hear rumblings that they have Spec-tuned compilers that may not yield results as good on things that don't look like Spec.

When the masses, such as we are, compile, we use gcc. (I agree that most masses just buy Quake, Unreal, Photoshop, etc.) But I argue that a small subset compiles, and a smaller subset yet forks over for commercial compilers.

Re:Hrmm

[miketang16]

Ha.. I would hardly call Itaniums true 64 bits'. Look at their first attempt, 48 bits. =p I haven't read much up on Itanium 2's and although I believe they are 64 bits, they're not the best standard, which AMD holds with their x86-64 arch.

Re:Hrmm

[Bj�rn]

There is also Intel's rumored Yamhill 64-bit technology, which is supposed to be a more direct answer to the Athon64. Se The Register.

Re:Hrmm

[timeOday]

Apple has had the G5 for about a month now, AMD will have the Athlon 64 in a month and a half, and we have nothing. Better up the P4 clock rate to 5 GHz in the next 6 months and pray Joe Idiot still thinks it's faster.

Well, what if it actually IS faster? The benchmarks I've seen of the G5 and AMD 64 bit CPU are not that much higher than the current P4. I happen to think either of those 64 bit chips running Linux (or MacOS, if it has proper 64 bit support) will be super cool, but it's hard to put my finger on why.

Re:Hrmm

[IPFreely]

If you are refering to address space, AMDs first implementation has 40 bit physical address space, 48 bit virtual address space. Their spec states that later implementations will have up to 52 bit physical address, 64 bit virtual address.

I can't speak for G5 or IA64, but they probably have similar limitations, either specific implementation or general design.

Re:Hrmm

[maraist]

Ugh. 64bit != faster
In fact there is no imperical evidence that any 64bit implementation is faster at doing <=32bit calculations.

What 64bit means is a radical archetectural shift, which affords (both to compiler writers and to the CPU designer's management) an excuse to add other radically new technology that is independent of bit-depth. Namely, we're spending the money, might as well pack-the-punch.

AMD64, for example uses a new CPU-mode which gives them cart-blanche ability to deprecate / add instructions (within practical reason). Further, they encorporated more registers..

The Unreal xxx (don't remember which flavor) game was recompiled for the x86-64 and achieved a 15% performance boost, but even they admited that most of this was due to the extra registers.. Note, explicit register-count augmentation is now like a 20 year old concept (see RISC).

And just to further the point, the AMD Hammer encorporates a memory controller which is bound to provide a few percentage point boosts.

The real pratical benifit of 64bit requires a 64bit native OS.. Namely the API calls to and from the OS should allow full 64bit ints by default.. Failing to do so requires clunky code which splits the address space into gig-sized segments. I'm specifically thinking of Linux >4Gig file access as an example.. To randomly access such a file, you first specify the page-number, then a relative position within that page.. That's extra required calculations.. Which was the whole thing avoided by going 64bit.

Yes we're starting to see more and more true-64bit API elements, but the vast majority of library code still assumes 32bit limitations. (think tar,gzip when not using stream-modes).

Re:Hrmm

[jgalun]

"Better up the P4 clock rate to 5 GHz in the next 6 months and pray Joe Idiot still thinks it's faster"

If Joe Idiot thought that it would be faster, he'd probably be right. I think the important question is why do you assume that the Athlon 64 will automatically be faster than a P4 5GHz? What does "Joe Idiot," doing word processing and browsing the web, need a 64 bit CPU for? Is he creating massive databases?

Course, Joe Idiot doesn't need all the power of a 5GHz P4 either. But he should decide between the P4 and Athlon 64 based on price/performance for the applications he uses, not decide for the 64bit machine because you think it's cooler somehow.

Re:Hrmm

[ProtonMotiveForce]

Clue: Umm, 5GHz processor...It _would_ be faster, rocket surgeon. Maybe "Joe Idiot" is a bad choice of names since he seems to be a little smarter than you think.

A real 'Joe Idiot' thinks a 64-bit processor is somehow going to be faster, when in fact it will do aboslutely nothing for 'Joe Idiot', or for most people with desktop machines.

Re:Hrmm

[Flywheel]

Intel wil introduce a low energy and low price version os Itanic, IMO to compete directly with Opteron 244.

Re:Hrmm

[finallyHasANickname]

Well that 'philosophy' is the difference between encoding video to mpeg-4 in two hours or two weeks.

I hear ya. That reminds me of a military suspense movie I saw. An important part of the movie's plot was that the protagonist/investigator gets hours' worth of human leg work done while an expensive computer does an edge sharpening algorithm to one still image of medium resolution in order to reveal a person's identity. It was a sort of race. Gimp or Photoshop on any PC from the past few years could do it in a blink. On my old 100 MHz 486, that kind of operation would have taken maybe 20 seconds.

Still this focus on comparitive horsepower neglects something Sartre might have pointed out. There are an astronically large number of possibilities.

When you consider truly primative hardware--say, an 8-pin PIC--then it doesn't have that aura of creative opportunity about it. It could very well be because there is such a drastic diminution in capability, in, say, "downgrading" in imagination from significant fractions of a gigabyte of RAM down to several dozen addressable registers, a.k.a. RAM, that the effect might actually be more of a measure of emotion than of technical utility. If there is enough room in, say a cheap PIC chip's ROM to store a program with about 30 RISC instructions, and if the instruction set (actually only ~28 to ~33 instructions in the whole set) then the finity of possibility is much more evident. The permutations ("software possibilities") would be "on the order of" a googol, but that is substantially shy of infinity. ("Substantially shy of infinity" is silly just as infinity minus 8 is silly.) I suppose our perception of "near infinity" is perceived as if asymptotic. Near infinity in possibility might have the definition of "perception of freedom", depending when you ask and how, like choosing the focal length for a camera. Is there really any significant difference between 30 kilometers, a light year and infinity while setting the focal length for a camera? That is a question about the person's notion of significance! It is a cousin of ethics; it is a value judgment.

When a "small mind" thinks in terms of infinitesimally small differences of still non-identical objects or possibilities--say, the adage that you cannot enter the same stream twice--this hair-splitting is what increases the quantity of distinctions. In that case, by virtue of the "thinner slices" being more numerous, there is still immensity of perception because the denominator threatens to hit zero "soon".

When a more macroscopic observer does something like that there is a sort of intinsically jaded sensibility. "Yeah. I know. We've done that already. What we need to be thinking about is..." Is what? Typically some possibility only recently made possible--say nanotubes or three-figure prices on thin computer monitors. Now I'm supposed to pay attention to thin computer monitors? According to the electronics retailer, yes. Why? Does anyone have the guts to answer, "Because it has fallen into your price range and because we need to peddle this high-margin item ASAP to optimize utilization of square footage in our retail electronics store."? Probably not. That is, in turn, because it is handier overall to pretend that this is all "new technology" and that I am supposed to say wow on cue and to refrain from being impressed when not stimulated for impressions.

I am not trying to digress on a rant against marketroids. I am trying to get a grasp on a continuum between a sort of microscopic versus macroscopic notion of scaling perceptions. Either way, microscopic or macroscopic, the effect is the same: excessively large quantities of objects or possibilities come into consideration. Reaction against that, IMO, is "hidden" below the premises that bring about "snide" comments like, "I know. We've done that already. What we need to think about is newer gizmo X." (For example, a microsopic perspective would disagree th

Re:Hrmm

[absolutezeroLAN]

Indeed it would be interesting to see a processer shoot out between the two companys, however if AMD doen't move any faster than they are and gain more market % they can just forget about any future of taking Intel.

Re:Hrmm

[WoTG]

Too bad there won't be any 64 bit Mac OSX to go with it. (Granted Windows for x86-64 isn't out yet either)

Is there a 64bit Linux distro for Macs?

Re:Hrmm

[Bloodmoon1]

You are one piece of WinTel marketing work, Pentium Girl. Faster clocks does not a faster processor make. Ok, let's just fucking forget the 5 GHz thing for a minute, since you can't quite wrap your brain around slightly dry humor, or the fact this means a P4 would probably have a pipeline somewhere in the area of, oh fuck, I don't care, I'm not going to have an attack over it like you, let's just say 1 million stages, and half the time it will have to throw away pre-fetched intsructions, slowing it realistically to 2.5 GHz. Perhaps you are Joe... no, no, fuck that, Jill Idiot.

Just keep plugging away on a 32 bit "fast P4" while we're all using horribly slow 64 bit G5's (Which, even NASA says are faster) and Athlon 64s. Me thinks you may have been one of the real 7337 (or whatever the hell HaX0r girls write instead of Leet) early adopters who probably owns a Itanium and are upset you don't have a real 64 bit processor.

And fuck it all. I have a +5, you're a 1. Normally this is meaningless to me, except here for me to say that yes, I am better. And, as the AC attached to your comment has pointed out, why the hell aren't we all using 10 GHz 16 bit processors, or fuck, why not 1 THz 2 bit processors? I don't care. Give me a 233 MHz G3 over any InHell pile of steaming dog shit any day of the week. Just my .02 Pentium Jill. And now to reply to your actual waste of precious disk space, that is now causing me to waste time responding to your waste:

Clue: Umm, 5GHz processor...It _would_ be faster, rocket surgeon.

Clue: Umm, Rocket_Surgeon... You are an idiot.

Maybe "Joe Idiot" is a bad choice of names since he seems to be a little smarter than you think.

No, he's not. Otherwise Winblows would not have ~95% of the OS market and Intel would not have ~85% of the processor market.

A real 'Joe Idiot' thinks a 64-bit processor is somehow going to be faster, when in fact it will do aboslutely nothing for 'Joe Idiot', or for most people with desktop machine.

Going back to the 5 GHz thing, since you've had some time to comprehend the things I wrote earlier and calm down some, or hell, just using the current 3 GHz or whatever those piles of refuse ship at now. And average Joe Idiot has a use for a clock speed near 3 GHz or higher for typical Joe Idiot style tasks how again? He fucking doesn't. Average NASA Rocket_Scientist (Hey, those do exist) likes the 64 bit thing. As will anyone else. Oh no, God Help Us! A company is giving us a real performance boost instead of dumbass clock speed increases! Whatever shall we do! You get me a 5 GHz P4, or better yet, use P3s since they are better (tell me I'm wrong Jill, it will fall on not caring about your dumb assumption ears) and a 5 GHz G5 or Athlon 64, and I promise the 64 bitters will smoke the 32s without any sort of re-writes to any modern day OS. Except maybe Windows, because nothing works on that. And then you may procede to smoke Robert Blair's jones. That, by the way, was an inside joke, and I couldn't give a fuck less if you get it or not. I'd actually prefer if you didn't and instead just swore of technology forever and became a hermit in the northen most reaches of the Yukon for the rest of your days. Yeah, that would be nice.

Re:Hrmm

[ProtonMotiveForce]

Did that "AMD" tattoo on your pantyline hurt? You're clearly convinced you're some kind of iconoclast cyber-genius, but most of your gibberish is old hat.

First, if Intel released a 5GHz P4 this year, it would be the fastest chip out there without question through 2003. I don't understand what kind of congenital brain defect is responsible for you and the AC claiming otherwise. End of story.

Intel and Windows have the market because they are the best solution for more people. You dirty geeky nerds don't count, and nobody really cares about your "Worst OS Ever!" inside jokes.

Lastly, you are seriously d u m b. Right now Intel has the fastest solution. It also happens to be higher speed MHz. I never claimed all higher speed chips are faster. It just happens for you, unfortunately, that this is true right now.

Re:Hrmm

[Bloodmoon1]

Now Jill, don't get your panties in a wad. Intel is shit. Pure, unremarkable shit. As is MS. They are examples of marketing prevailing over engineering. Intel's P4 is still slower than the highest end G4s and AMDs, and G5s hand P4s their asses. And for the record, I also could give a shit less about AMD, I'm more of an Apple zealot. But more than that, I also am willing to except the truth. I still contend back in the early 90's Apple was crap, and first gen design iMacs (Monitor and CPU in one case) are very flakey. I just hope one day you will stop getting all of your techinal info from Intel press releases. Good to see you still avoided responding to most of my post, pussy. Seriously, I will give you $100 US or (sucker) Canadian if you agree to swear off technology forever and become a hermit. Also, I will no longer reply to any posts on this topic unless it is a post negotiating your hermit surrender terms. Jobber.

Surely?

[Black Parrot]

Surely those 0.1% differences are below the threshold of noise in the marketplace, if not in the sampling methodology?

BTW, I thought I had heard on the news that AMD was really hurting these days. Again. Anyone know?

Re:Surely?

[Sleeper]

I guess that means that nothing really changed. That is little guys at least stay in game. Which is probably good news at the moment.

Re:Surely?

[akuma(x86)]

Nowhere in the article do they mention if the market share numbers are for "unit volume" or "revenue share". There's a huge difference.

You could have 50% market share on a unit volume basis, but if all you're selling are money losing Durons, then that really doesn't help you much.

AMD sells their product for substantially less than Intel. You heard right, they are hurting these days. They're bleeding money and have no product that is currently able to command the higher prices of a Pentium4. They've pretty much bet the company on Athlon64. If they can execute and deliver that product, then they can survive.

Re:Surely?

[brettper]

Well if they've gone up 0.1% but the market is 10% smaller than they're not doing so good are they?

NB to any number nazis out there: these numbers are made up but the point is the same

WTF???

[gowen]

0.1 of a percentage point? Whats the betting that is *well* inside the bounds of sampling error.

Nothing to see here, move along.

Re:WTF???

[sporty]

That kinda depends. If the data is taken from door to door, yeah. Bu if it's taken from sales records, no.

Re:WTF???

[gowen]

But if it's taken from sales records, no

Who's sales figures? The chip manufacturers can only tell you what they've shipped to PC manufacturers, which isn't the whole story. The PC manufacturers can tell you their sales, but there are rather too many of them to get everyone's figures.

So, even on sales figures, there are sampling effects.

Re:WTF???

[sporty]

Probably AMD's and/or Intel's. After all, you can't wind up with an AMD or Intel chip on your desktop w/o it originating from them.

If they cook the books, yeah, you'll have a huge error, but their sales records must be kept proper, w/ no rounding errors. If they make errors, they are paying too much taxes and what not to the gov't.. or to little.

I doubt the rounding errors on numbers THAT big would be 1% but even less significant. But there are lies, bigger lies, and statistics :)

Umm

[Michael's a Jerk!]

This increase is tiny - it's not statistically sound. It's smaller then the sampling error.

That said, I've just bought a Dev Kit from Transmeta, and I love it.

Other and Transmeta...

[MosesJones]

This is what gets me about Transmeta, saying that they increase their share when in a category called "other" which increases 0.1% means that Transmeta is up...

How ? Transmeta don't have enough sales to get in a category of their own, they may have DECREASED their marketshare but another minor player could of increased theirs thus making the overall sector go up.

I know that here at Slashdot we must all bow to the altar of Transmeta because their processor approach is all open sourced and they own no patents and follow the OSS way so purely... oh wait they don't ? You mean they do have patents and they don't release their architecture ? Oh it must be because Linux is their primary OS... nope again. No its because they gave Linus a job.

The story here is that Intel remain the massive player, AMD has made some minor in-roads but is still not gaining marketshare in the way they would really like, and that the figures actually represent and quarter on quarter DROP in sales percentage for AMD.

In otherwords a way to say this is that AMD have LOST nearly 1% of share over 3 months which isn't so positive.

But hey, if we can bash Intel and bump Transmeta why let the facts get in the way.

Re:Other and Transmeta...

[BrainInAJar]

"they may have DECREASED their marketshare but another minor player could of increased theirs thus making the overall sector go up"

My guess, VIA

Re:Other and Transmeta...

[perly-king-69]

My guess, VIA

Seconded. Their C3 &c chips on the mini-itx boards are going from strength to strength

Re:Other and Transmeta...

[silvaran]

I know that here at Slashdot we must all bow to the altar of Transmeta because their processor approach is all open sourced and they own no patents and follow the OSS way so purely... oh wait they don't ? You mean they do have patents and they don't release their architecture ? Oh it must be because Linux is their primary OS... nope again. No its because they gave Linus a job.

Holy chill there batman. Take a look at the article, will you? This isn't editorializing or /. elitism or anything you seem to imply, this is paraphrasing. RTFA:

Other manufacturers, a grouping that includes Transmeta, increased their collective market share from 1.7 percent to 1.8 percent.

The slashdot summary, meanwhile, says the same thing:

While Transmeta and other manufacturers went from 1.7% to 1.8% in a single year.

Tit for tat -- this is the only mention of Transmeta. You read waaaaay too much into it. Take your allegations elsewhere.

Re:Other and Transmeta...

[MosesJones]

I did RTFA which is just as bad. What does it matter than Transmeta is part of others ? This is a statistically irrelevant increase which is lept on to hype Transmeta.

If the article writer had been a decent journalist it would have read

"No change in Processor Sales"

Which the editors should have realised it was, rather than just seeing Transmeta and hitting "post"

Re:Other and Transmeta...

[mercuryresearch]

Your interpretation is correct.

Actually, Transmeta's share was unchanged. The increase in "other" was due to VIA (who is many times larger than Transmeta, FYI.)

Re:Other and Transmeta...

[anthonyrcalgary]

I wonder how much of "other" is attributable to the C3's. I know several people and businesses that love the things.

Re:Other and Transmeta...

[mercuryresearch]

About 3/4 of VIA's business is C3s, the other 1/4 Eden (which is pretty much as C3 as well.) Nearly all of the "other" category is VIA, not Transmeta.

I have several Eden-based systems here under test, EPIA mini-itx based. They're cute and very low power, and it appears there is a small but growing niche for them based on the stats I've compiled.

x86-64 - horror strikes again

[oakad]

Is not this terrible that 30 years old, not very good architecture now gained a pass into the 21'st century? Was it not enough to extend the 8085 first to 8086, than to 80286, than to 80386 and now to x86-64? When will this end?

Re:x86-64 - horror strikes again

[BrainInAJar]

As soon as users stop caring about their software investments.

Re: x86-64 - horror strikes again

[Black Parrot]

> Was it not enough to extend the 8085 first to 8086, than to 80286, than to 80386 and now to x86-64? When will this end?

With the x86-640KB, if a famous prediction attributed to Bill Gates is true.

Re:x86-64 - horror strikes again

[oakad]

It could be much better to take an advanced RISC core (like PPC) and add an additional (legacy) instruction decode unit to it (anyway, x86 does instruction recoding internally). Simply adding stupid extensions to the old instruction set is not the best policy for anybody.

Re:x86-64 - horror strikes again

[yoshi_mon]

As soon as users stop caring about their software investments.

But, with the CPU power that that there is now why does this have to be an issue anymore? If AMD can make a chip that is 32 bit backwards compatable why can't there be an inbetween chip that moves us to a new architecture? (Yes yes, I know that having the transistors for a fully backwards compatable architecture and having those for a new architecture is not the same thing but don't tell me that it can't be done.)

And even failing a full hardware solution it's more than possable to recompile even Windows for a diffrent platform and have a Windows issued eumlator which is co-designed by the chip makers so that we can bridge the in-between gap.

No, I think it's more the fact that Intel is greedy and would rather keep pushing it's old tech so that it does not lose any more market share than it allready has to AMD and other smaller co's. If they ever were to get a true monopoly again we might see some real innovation out of them but as long as the focus is on quarterly reports rather than what's really good for computing I doubt much will change.

Re:x86-64 - horror strikes again

[oakad]

It is not very cheap in terms of the effort invested, however chips are cheap because of the unprecedented market penetration. No one can really estimate the loss gained from inefficiency.

Re:x86-64 - horror strikes again

[turgid]

When will this end?

As soon as there is no longer any money to be made.

Re:x86-64 - horror strikes again

[BlowChunx]

Intel, greedy? Yes. Wanting to push its old tech?

Then why the heck did they spen over a billion dollars to develop the Itanium? IIRC, they scrapped the first version because the software x86 emulator was just too dang slow.

Re:x86-64 - horror strikes again

[Malor]

(warning: I'm just tossing this out from memory without doing any double-checking on it first, so read with caution and pay attention to replies.)

I believe that's basically what they're already doing.

If I understood what I read correctly, the "X86" CPUs on the market aren't really X86 CPUs anymore. Instead, they are essentially a super-fast hardware emulator of an instruction set. The real instruction set of these chips doesn't resemble X86 *at all*; the chip decodes on the fly from the X86 macro-ops down to the chip's native micro-ops, which are smaller and simpler and easier to track when running in parallel across several execution units.

That's part of why most software emulation is so slow -- you are in essence comparing generalized software solutions to incredibly well-engineered hardware solutions.

If we had a different instruction set, would we really benefit? For the vast majority of us, even the Slashdot crowd, no. The compiler guys would probably like it a lot, but very few programmers work in anything lower than C. The actual "machine language" is mostly unimportant. And it's not even REALLY the machine language of the chip anymore!

Even assembly coders, these days, are writing in a form of interpreted language. The "bare metal" guys aren't REALLY at the bare metal anymore; even they are working at a level of abstraction.

Re:x86-64 - horror strikes again

[jwe21]

Aren't the modern chips RISC underneath anyway? The underlying architecture hasn't stayed the same, it's just a compatibility interface. Yes?

Re:x86-64 - horror strikes again

[JanneM]

Even assuming it _is_ just a recompile that's needed (and, especially for OS:es that is far from the case), you still need to convince those holding the source to actually do it. If MS doesn't see a profitable enough market, they will not "recompile for a different platform", and you are sans Windows for your platform. If Oracle doesn't want to bet on the new architecture, you won't have your database available. The same goes for much of the rest of mainstream computing today.

OSS is interesting, as it - like Unix before it - partly changes that equation. With the source out there, a chip maker can do the port themselves, without having to rely on another company to be good to them.

Intel _has_ tried to introduce different platforms in the past - they had a RISC chip going for some years, for example, that never went anywhere. But, no platform ==> no third-party software ==> no system builders to pick it up.

Oh, and both AMD:s and Intel's 64 bit offerings _do_ already provide exactly that backwards bridging you're talking about. So where's the problem?

Re:x86-64 - horror strikes again

[afidel]

Intel actually is TRYING to break from x86 with the Itanium line, they invested Billions and billions of dollars to do so. They had a hardware x86 emultator tacked on that is so anemic that it is outperformed by a chip two generations older at the same clock speed (the P3 running at Itanium speeds trounces it for legacy 32bit code), throw in the fact that it is WAY behind the current 32bit chips in clock speed and you get a not-so-impressive product if the majority of your code is legacy. Then they decided their software tech was good enough that they could get better performance out of a software translator, they did, but only about 30% faster average then the hadware unit, still too slow. Compare this to AMD with the Athlon64/Opteron which runs 32bit code at least as fast clock for clock as the previous generation (ususally faster due to larger cache), and is running at about the same clock speeds. On the software emulation as part of a platform switch, it has been done twice, once with Apple and the 68k->PPC transition (quite sucessfull), and once by DEC and the Alpha team with FX!32 which was a software translation layer that would dynamically recompile x86 NT4 programs to native Alpha code, it didn't work all that well despite the Apha being vastly superior to anything Intel made at the time.

Re:x86-64 - horror strikes again

[gfody]

its not as bad as it seems. as much as it sounds like another extension, x86-64 really is innovative. the memory controller is built into the cpu now, there are tons of new instructions, and 64bit registers are something every programmer longs for.

I think introducing some radically different architecture will never work out (intel kind of proved that), amd is going the right direction innovating inside the box

Re:x86-64 - horror strikes again

[afidel]

Not only that but x86-64 gets rid of most of the really annoying parts of x86 anyways. There are more registers, they are more sanely layed out, and there are multiple sets of them available. All the people moaning about the cruft build up of x86 living on haven't looked at what AMD did with x86-64. If they are capable of understanding then they should go and look at the AMD whitepapers, if they aren't then they should stop whining because it doesn't effect them anyways =)

Re:x86-64 - horror strikes again

[Anonymous Coward]

the 8085

The what? You're lecturing us on the horror of Intel IA-32 architecture and you don't even understand the history!

4004 -> 8008 -> 8080 -> 8086 -> 80186 -> 80286 -> etc.

There was also a 4040 descended from the 4004 but that was a dead end. Yes there really was a 80186 but it was never used officially by IBM in any PC model, hence very few clone makers used it either.

No, retaining backwards compatability with the IA-32 ISA is not a bad thing. The physical chip architecture is nothing like those old CISC 80286's and there is very little overhead or complexitity introduced by having an IA-32 decoder and a little bit of microcode.

There is just too much existing software for IA-32 out there to just dump it. Even Intel know this, which is why an Itanium also has an IA-32 emulation layer.

Re:x86-64 - horror strikes again

[Anonymous Coward]

To clarify (Because now I sound like I'm clueless), there was an Intel 8085, but it was simply the 5v package of the 8080. It did not offer any software improvements over the 8080 and is really just an 8080 with different physical characteristics.

The 8086 was the evolutionary stepstone from the 8080; the 8086 added 16bit addressing & data. There 8088 of course had only 8bit data with 16bit addressing.

Re:x86-64 - horror strikes again

[dpilot]

Just make sure that as you try to replace the 30 year old horror known as X86 that you're not getting yourself in even deeper. Philosophically, Intel appears historically to have placed hardware squarely in the driver's seat. Perhaps that has even been the right move, as X86 has won out over software-wise more elegant competition.

IA64 (or IPF, if you prefer) continues that tradition of designing hardware, and forcing software to accomodate. In this case, they've gone even further in exposing the intimate details of the hardware architecture to the compiler, and it's taken until the past 6 months to make the combined processor/compiler become competitive.

So if it IS the new heir-apparent, what happens on the first true Post-McKinley core?
How will McKinley-compiled code run on Post-McKinley?
How will Post-McKinley-compiled code run on McKinley?
Are the good old days of fat binaries back?
How long will it take for good Post-McKinley compilers to evolve, after the hardware is available?

Before throwing away X86, as horrible as we may think it is, we need to make sure we're going to do better.

Re:x86-64 - horror strikes again

[LizardKing]

Yes there really was a 80186 but it was never used officially by IBM in any PC model, hence very few clone makers used it either.

An ex-colleague had an 80186 PC in that small timeframe before the 80286 was available. He had been a contractor at the time, and just had to have the latest bit of kit. He used the 186 box for a few months and then it went into the back of his garage when the 286 came out. When he told me this about six years ago I thought he was bullshitting me, but he dug the machine out to prove it. Can't remember the brand name of the manufacturer though.

Chris

Re:x86-64 - horror strikes again

[gilesjuk]

Itanium is basically a new design and it doesn't run much better does it.

Motorola and IBM are ahead of Intel when it comes to RISC and 64-bit.

Re:x86-64 - horror strikes again

[Ninja Programmer]

If I understood what I read correctly, the "X86" CPUs on the market aren't really X86 CPUs anymore. Instead, they are essentially a super-fast hardware emulator of an instruction set. The real instruction set of these chips doesn't resemble X86 *at all*; the chip decodes on the fly from the X86 macro-ops down to the chip's native micro-ops, which are smaller and simpler and easier to track when running in parallel across several execution units.

x86 instructions, are just the architectural instructions and are not called macro-ops. Intel's notation for their internal instructions is to call them microops. AMD's K6 notation was RISC86-ops, and AMD's Athlon notation was to call them macro-ops.

However, it is very important to point out that they don't resemble RISC instructions either. Although they have many of the same properties, they generally can be over 150 bits in length, for example. These instructions also don't exist on any code address per se, and thus could not really be considered a full instruction set in of themselves.

Another thing that should be pointed out is that modern post-RISC out-of-order executing RISCs themselves are also forced to have some kind of alternative instruction set representation as well (since some of them perform complex operations, such as the PowerPC's double write instructions, or any "test-and-set" kind of instructions, and they are stored in internal reorder buffers)

Re:x86-64 - horror strikes again

[FooBarWidget]

So does that mean everything will run faster if, say, we port GCC to compile to the chip's "native" instruction set and then recompile the kernel and all apps?

Re:x86-64 - horror strikes again

[benzapp]

This is absolutely true, the AMD Athlon K6, and the Nexgen Nx586 with its AMD K5 branding were all RISC processors with a translation unit.

The Nx586 actually had the ability to switch from 386 mode to its non-standard RISC instruction set, and there was some talk of making it PowerPC compatible back in the days of OS/2 PowerPC Edition.

To my knowledge, AMD removed such functionality from the design after they acquied NexGen...

Re:x86-64 - horror strikes again

[maraist]

Aren't the modern chips RISC underneath anyway?

A) There is an impedence mismatch between the compiler and the CPU when using x86 assembly.

A.1) The compiler can have a tremendous understanding of how the code can most efficiently be run under most archetectural circumstances, yet has to assume the most common-dumbest implementation (e.g. should it trust hyper-threading, should it trust AMD's or Intels number of virtual/renaming registers). Yess you can recompile dll's/.so's for each projected archetecture but this is rare.

A.2) Compilers must masquerade assembly to trick the CPU into operating more efficiently; this requries very CPU-version-specific coding.

A.3) Newer generations of a CPU will react differently to the masqueraded code, and thus the number of CPU-specific DLL's becomes undesirable.

B) Extra effort on the compiler/developer side is justifiable (Q3 DLL's for each modern CPU, for example). But there is also effort on the CPU side. This effort exists as extra propagation delays (or worse, clock ticks) that are spent guessing how best to translate antiquated x86 code into a form that facilitates modern processing techniques. Stack-based floating point operations for example, explicitly documents backwardly compatible tricks which tell it how to act more like a register file.. There are issues with data-dependency calculations in the CPU such that more than 4/8 general register can be used.

C) There are enormous losses involved in memory alignment of the instructions. One of the most important aspects of RISC is that all instructions are the same size, so no clocks are wasted figuring out what the next instruction is (to say nothing of the next 3 parallel instructions). Having a "RISC-like core" is somewhat meaningless if you still have to have the instruction-align.

D) Like the I-align, there are wasted propagations/clocks decoding old x86 multi-step instructions.. AMD/Intel both refer to the vectored-instructions; those that are so complex that they are special cased and who's performance is sacrificed at the benifit of simpler instructions.. No modern Compiler should ever produce these instructions (since they're rather well known), BUT the CPU must still check for them.

E) Even though the compiler can masquerade code such that the CPU can allocate dozens of registers, there are certain compilation techniques that can only work when you have a large number of addressible registers. Loop-unrolling for example... This is where you have say a nested loop and your inner-most-loop is pretty tight.. If you have dozens of explicitly addressible registers, and the code doesn't have data-dependency issues, then you can have the inner loop only require a single clock tick per iteration; performing all calculations in parallel and into differing registers.

Modern x86 cpu's can automatically register unroll only the most trivial loops (memory copies and some slightly harder things who's data-dependencies don't span too many instructions). Often a nested loop is written one way for clearity, but a compiler can determine that the nesting can and should be reversed for performance.. But if there just aren't enough registers, it is not worth doing so.. The CPU can not make such a dramatic translation behind-the-scenes.

F) calling conventions: easily the biggest hit in performance since this consistutes an ever bigger percentage of modern programming (think VM's where every op-code requires multiple function-calls). Larger explicit register sets allows for more optimal setup/tear-down. Some techniques like SUN or Itanium's rolling windows can also be incredible for diverse-but-not-deep coding styles (again VMs). Even simple Alpha/SGI MIPS constant reg-sets with dedicated in/out registers are enormously helpful in avoiding memory access.

The x86 with it's orignal 4 regs (with 1 dedicated out) requires stack manipulation.. Yes L0/L1 cache concepts help this, but we still have push/pop stack management overhead. Pe

Re:x86-64 - horror strikes again

[Dun Malg]

So does that mean everything will run faster if, say, we port GCC to compile to the chip's "native" instruction set and then recompile the kernel and all apps?

No. The "native instruction set" isn't available directly. The CPU is essentially hard-wired as an x86 emulator. This may sound inefficient, but in reality it works quite well. The real instruction set is essentially designed to take the crufty x86 code and siphon off the bathwater, leaving mostly just the baby; it's not meant for direct programming. In theory, they could design a brand-new CPU with a fresh instruction set, but who would buy it?

Re:x86-64 - horror strikes again

[Glasswire]

While people moan about all the architectural defects of the x86 instruction set, they don't want the disruption that recode and recompile requires for the state of the art to evolve to a new architecture.

Itanium's EPIC (explicitly parallel instruction computing) which requires development tools to stage external instruction organization is a radical departure conventional CISC/RICC deisgn and generates performance that consistantly exceeds vitually all RISC processors.
(Check the actual benchmarks and you won't wonder why Apple didn't bench the G5 against HP's zx6000 dual Itanium workstation with the new 6Mb Madison cores)

If would be nice if the people who want an new paradigm had a talk with the lazy folks who want to continue to use the same damn binaries forever -maybe Itanium would get a fairer shake then.

Re:x86-64 - horror strikes again

[maraist]

Itanium is basically a new design and it doesn't run much better does it.

Actually, the Itanium is a bueatiful CPU design (from a compiler standpoint). It is very radical, though I wouldn't say ideal or even best-in-class. My only beef, really is that it wastes time, effort, and embarrasment by trying to be x86 compatible. There are actually assembly codes in the official documentation to bother with this obviously failed task.

I don't feel like double checking, but the Itanium was able to achieve remarkable SPEC scores even at lower MHZ. It's Instrs / sec are phenomenal, even for proprietary VLIW (which tends to be better than typical RISC/CISC). It definately has a lot of head-room to grow; they left plenty of room for at least two generational modifications (in the assembly language at least).

While people complain that it leaves too much work for the compiler, there is no reason why a future version couldn't apply the same sort of concurrent instruction profiling that modern x86 CPUs utilize. Thus a compiler could still be stupid (except for the requirement of data-dependency analysis), and produce code that could be made to work better in future CPU releases. Sure in 20 years, the Itanium (if it doesn't die in the mean-time) could be plagued with compatibility issues, but that's nothing that a detail-egnostic architecture wouldn't have to worry about as well.

Motorola and IBM are ahead of Intel when it comes to RISC and 64-bit.

In marketing yes.. IBM, like AMD is pushing their 64bit CPU onto the general masses.. Something Intel isn't publicly considering. The reason the Itanium is expensive is that it's floating-point-centric.. I don't recall the actual percentage but it's like half of the damn core-CPU. The register files are freaking enormous for both inter and FP. To say nothing of the cache-size.

Like IBMs Power4 -> PowerPC, Intel could strip an Itanium down and market to the common man.. BUT, they are not in the most amical environment to do so.. They have to compete against AMD64 now.. Their strategy is either to make an Itanium/Pentium hybrid (cheapest migration strategy is likely to be a literal glue of the two CPUs together with a CPU mode to switch between them), or come up with something completely new, but lose market-share-time-to-market to AMD.

Before Apple decided to adopt 64bit, Intel seemed to push the devalue-64bit-on-the-desktop strategy. AMD was merely looking for a nich, so they were safe. Itanium has been making headway in research institutions (not too sure about production environments, however), so it was theoretically only a matter of time before Itanium could out-seat SUN/Alpha/IBM.

Now people are going to start finding "killer apps" for 64bit environments (high performance integer-based graphics / calculations that previously required slower FP).. I see multi-media and other memory intensive tasks being able to benifit certain nich desktop users today. (And of course just about every server environment). (Imagine doing photoshop filtering of a 500meg image; more than 4 gig of memory could very well be used; especially if multiple images are open simultaneously). And you can bet Apple is going to exploit any advantage of 64bit they can to win market share from the PC line.

So a market will exist for 64bit on the desktop relatively soon.. AMD will have a solution up and ready for the desktop-consumer..

So, once again, and in summary, I feel it is marketing, not technology that is to blame.

Re:x86-64 - horror strikes again

[Loki_1929]

" Is not this terrible that 30 years old, not very good architecture now gained a pass into the 21'st century? Was it not enough to extend the 8085 first to 8086, than to 80286, than to 80386 and now to x86-64? When will this end?"

When you design a better architecture which can run almost every application made over the past 20 years, and which can be implemented in such a way as to fit the average consumer's computer budget of about $1000 for a complete system while still leaving room for profit.

Good luck, let us know when you're done.

Re:x86-64 - horror strikes again

[istartedi]

this terrible that 30 years old, not very good architecture now gained a pass into the 21'st century

Yeah. Those monolithic *NIX kernels have got to go.

I'd say more, but I've got to disconnect and pull all the copper wire out of my house right now.

Re:x86-64 - horror strikes again

[MyHair]

If we had a different instruction set, would we really benefit?

My limited understanding is that some of the architechture/instruction set of x86 makes it difficult to virtualize. Better virtualization could really benefit us--the Slashdot geek crowd--today. Look at VMWare.

Re:x86-64 - horror strikes again

[bobeszcica]

(Check the actual benchmarks and you won't wonder why Apple didn't bench the G5 against HP's zx6000 dual Itanium workstation with the new 6Mb Madison cores)

Perhaps because that machine costs over 20,000 USD (with 8GB RAM, mind you, but what drives up the price is not the memory but the CPUs), while Apple's costs 3000?

Re:x86-64 - horror strikes again

[dvdeug]

A.1) The compiler can have a tremendous understanding of how the code can most efficiently be run under most archetectural circumstances, yet has to assume the most common-dumbest implementation

That's true for any two chips that run the same architectures; why is it better to have to compile for x86 and MIPS then to compile for x86 and (possibly) x86-64 and have the choice of running the x86 binary on the x86-64?

Re:x86-64 - horror strikes again

[maraist]

That's true for any two chips that run the same architectures; why is it better to have to compile for x86 and MIPS then to compile for x86 and (possibly) x86-64 and have the choice of running the x86 binary on the x86-64?J

If I understand your question well enough, then that's easy. You don't have a choice about compiling different binaries for different "platforms", where a platform is both an OS and a particular piece of hardware. Linux distributions, for example, simply must compile their entire software line for each and every platform they wish to support (with a few source-only distro's as the exception).

When you have a 100% compatible platform, however, the added cost of producing a completely separate distribution with archetectural flags fine tuned to each varient is too high.. To say nothing of the confusion of having 5 or six different boxes on the shelves.. People can barely find the difference between mac and PC logos, to say nothing of a pentium v.s. AMD. Then think of the administrative overhead of having to lug around 3 or 4 sets of Linux distro's to administer the likely diverse computer pool.

Same applys to windows software; while it's not too hard to swap out dlls for the appropriately platform-dependent compiler optimizations, it costs money to do so.

Again if they choose to market to differing platforms, that's a choice that says, "get these additional customers".. When optimizing for compatible varients, what are you gaining? A 5-20% increase in performance and thus a slightly happier person... It's much easier to say "optimized for Pentium 4" (with a stupid audiable logo).

So now back to your statement.. What's so special about x86-64? Why should we bother differentiating it?

Well, in Linux we have to recompile the kernel suite for the 64bit kernel anyway.. So there is a clear need for SOME differentiation.. Moreoever, given that x86-64 owners are somewhat sophisticated, packaging isnt necessary; only downloads.. Thus the cost is merely reduced to setting up the configuration and building the ISO and allocating disk space on the mirrors.

Of course I say all of this as a lay person's speculation.

Re:x86-64 - horror strikes again

[dvdeug]

You don't have a choice about compiling different binaries for different "platforms", [...] the added cost of producing a completely separate distribution with archetectural flags fine tuned to each varient is too high

Almost no one ever produced software for Alpha or PowerPC NT. Likewise, not much proprietary Linux software is available for non-x86. The confusion of having 5 or six different boxes on the shelves is the same whether those boxes are for x86 variants or completely different architectures.

There were some programs compiled for both the 286 and the 386, because there were different enough processors. IMO, anyone who would be willing to make a new package for AMD-new-64 would do so for x86-64, because it makes that much difference. Certainly most of the Linux distributions that handle different architectures plan on having seperate x86-64 distributions.

64-bit apps/CPU on the desktop

[sonicattack]

As far as I understand, the kind of applications most likely to benefit from going 64-bit are mostly database apps, where access to a 64-bit address space helps when working with huge datasets, and applications doing a lot of integer computations (cryptography?).

Could anyone point out for me a list of benefits for going 64-bit on the "desktop" too?

Regards

Re:64-bit apps/CPU on the desktop

[Nicolas MONNET]

The next gen Linux thread library will benefit significantly from having a 64 bit adress space, I remember from reading the whitepaper. Just an example.

Re:64-bit apps/CPU on the desktop

[afidel]

Anything that needs to access files larger than 4GB or which can use more than 4GB of ram will benifit. Desktop programs that fall in this category include anything dealing with video, people dealing with multitracking audio, CAD/CAM, rendering, and others. It also makes software design somewhat simpler because you don't have to worry about paging nearly as much with a 64bit systems.

Re:64-bit apps/CPU on the desktop

[JBv]

Well... In my very naive opinion I would say the the faster the CPUs the more information they can process per amount of time. This increae in processing power calls for even more complex applications and greater pools of data to be indexed and/or held in memory.

So I think that now, you might not feel the need for > 2 Gb of ram, but in a year's time you may "think differently" (TM).

Re:64-bit apps/CPU on the desktop

[finallyHasANickname]

Could anyone point out for me a list of benefits for going 64-bit on the "desktop" too?

Let's say you're in your cubicle in the year 2015, and someone tells you to write a software application to help manage the virtual DVD player for all the quaint movies. (Who knows? Maybe there will come a day soon when the sum total of, say, AOL/Time/Warner's content can be bought in a boxed set with the box weighing an ounce in its predominant storage media while the content owners will gripe at the "whole farm" being downloaded by the self-mutating Morpheous 15.0 finding the cops faster than they can find it.) Oops. I digressed.

In this scenario, with you programming in 2015, there is one movie per file, and each file has about 4.5 gigabytes on it. Let's say you use plain old C programming, and you want to go all the way to the end of the file for some reason. Then you'd use fseek(). I just typed "man fseek" into cygwin. Ha ha! The joke is on me. The second argument to fseek(), which is crucial to choose how many bytes into the file you'll be going, is type "long int". These days that is typically 64 bits. I mean, that is 64 bits anyway. Thus, by a complicated way, we have seen that the difference is practically invisible--"transparent" as it turns out--but that we can presume that that second argument to fseek() can be passed in one measly register without a chapperone. It will run infinitesimally more quickly--like we didn't know that already? Kewuhl! Ok. Maybe that's a bit of an overreaction, but if you think that is is an overreaction, then get off of /., and get a real life (like the folks surfing sportsillustrated.com). Jeez. Do I have to tell you everything?

On a more serious note, I bet this 64-bit advancement is far less important than the 32-bit advancement was. One desktop-oriented way of thinking about this is to note how much graphics work is jobbed out from the main processor these days. For that reason, graphics card vendors can put one or several 64-bit chips on the graphics card, and who cares if each chip can talk Intel-ese machine language? It is very likely that little more than terse commands will need to be given to high performance graphics hardware. Meanwhile, in other bandwidth matters, the RAM is even more of a severe relative bottleneck now. Maybe that in itself is sufficient reason to widen every possible pipe. There is only so high a velocity at which the "fluid" can move through it.

Re:64-bit apps/CPU on the desktop

[sonicattack]

Thanks! I get the impression that those applications mentioned are pretty specific, and close to "workstation" stuff anyway, where you would want to invest in a system designed for these kind of tasks, 64 bit or not.

The "average desktop user", without these specific needs, won't, if I understand this correctly, benefit directly from the fact that the application now is 64 bit. More likely the increase in performance of "Joe User's" desktop computer comes from other architectural improvements in the system, not directly from the transition from 32 -> 64-bit.

Re:64-bit apps/CPU on the desktop

[gfody]

I mainly write asm optimized graphics routines (DSP filters/analysis/occasional special effects) and I can't wait to get my hands on a 64bit cpu. the basic strategy behind writing efficient filters is to process a register at time (32bit register = 4 8bit pixels, 2 16bit pixels, 1 and 1/3 24bit pixels or 1 32bit pixel)

mmx gives you some 64bit registers but you can only use a handful of instructions with these. with 64bit registers I should be able to double the performance on any filter that isn't already saturating the memory bandwidth (and cut cpu cycles in half regardless). not to mention the new instructions.. ah, anyways what I'm getting at is 64bits will be an extreme improvement in anything dspish (fft/mpeg encoding/streaming music/video/photoshop/filters/effects/etc/etc) but not instantly. most of this stuff is already hand optimized for 32bit mmx/sse and will need to be reoptimized for 64bit. I doubt recompiling some c++ with a 64bit compiler is going to get you any free performance.. maybe on database apps

Re:64-bit apps/CPU on the desktop

[afidel]

That is basically correct for the immediate future, then again my graphics card has many times more ram then my first PC and I use it to the max all the time. Current PC's generally ship with half a gig of ram, doubling every 18 months that means the average retail pc will exceed 4GB in less than 5 years, not tomorrow but not so far off either. Besides it doesn't cost Joe User all that much for the extra silicon and keeps those of us who do use the stuff from having to pay "workstation" markups like those Sun used to command (hmmm, ~$60K for a 2cpu workstation with 12GB of ram, soon I will be able to get more performance and the same amount of ram for well under $10K)

Re:64-bit apps/CPU on the desktop

[PsychoI3oy]

call it me being cheap but i can't wait for AMD to release 64bit procs to the desktop. why? cause after a quarter or 2, the cost of AthlonXP's will drop and i'll have a cheaper chip to drop in my mobo.

that being said, 64bit processing must be good for desktops or why would apple have gone with it? the fact that they run a BSD based os is a Good Thing(TM) because we already know BSD's will support 64bit procs already (and winders has no plans to support it till longhorn, IIRC) such that open source will be a better option for the people out there that just have to have the latest and gratest. i see the 64 bit processors as an advantage to people doing things like multimedia or 3d stuff (pixar moved to g5's, didn't they?). developers might like it but it'd be silly to develop on a 64bit machine when the target market is all 32 bit machines. i dunno, bigger is better, it's a step forward, and it might be one of those things we have to see to realise how great it is. (i.e. win2k _actually_ being a better os than it's predecesors, despite initial hiccups)

Re:64-bit apps/CPU on the desktop

[BrainInAJar]

Actually, I can't remember who I was talking to (someone who plays with low level stuff all day for money), but he said something to the effect of the windows/linux VM can't deal properly with more than 1 Gig of ram without slowing the system down, so if you aren't using >1gig of ram (like having a couple iso's on a ramdisk), then your system is actually slower than if you had 1024M.

Re:64-bit apps/CPU on the desktop

[turgid]

Could anyone point out for me a list of benefits for going 64-bit on the "desktop" too?

CAD, video recording/editing, 3D games, various scientific applications, software development etc.

I am old enough to remember when 32-bit PCs were just coming out, people had exactly the same questions and scepticism. "Who could possbily need 32-bits," and "16-bit processors are faster at the moment anyway."

There was a small number of wise and insightful people who adopted 32-bits early. The rest of us had egg on our faces when our 286's could no longer run the new software, or could only run cut-down, crippled versions.

Re:64-bit apps/CPU on the desktop

[EddWo]

There will be an AMD64 port of Windows before Longhorn. It is expected early 2004. Also an IA64 and AMD64 version of the .NET CLR and Libraries so existing .Net applications can be ported with minimal changes if any.

Re:64-bit apps/CPU on the desktop

[tomstdenis]

To play devils advocate here....

Giving developers more address space, faster processors, etc gives them *less* incentive smaller, more modular and optimized code.

This is why, for instance, word processors are 200MB now instead of the couple of KB they used to be.

Personally I agree that from the getgo RISC should have been used but the memory model didn't support that idea. when you are coding an 8086 with say 1KB of ram [in an MCU environment] being able to say

add al,[si]

instead of

mov ah,[si]
add al,ah

Not only saved one register but would be smaller [and in this particular case...faster].

Now that desktop computers have on average at least 64MB of ram and most embeded systems come with at least a MB or two of memory it makes little sense to use CISC anymore.

I think the transmeta route is fairly ingenius. What would be cool though is if you could optimize for the transmeta offline [e.g. churn for more time optimizing] and feed the transmeta VLIW core directly or still feed it x86. Get the best of both worlds, e.g. x86 compatibility and the ability to create super-optimized apps for it.

Tom

Re:64-bit apps/CPU on the desktop

[EddWo]

<a href="http://www.microsoft.com/presspass/press/20<nobr>0<wbr></wbr></nobr> 3/Apr03/04-09AthlonOpteronPR.asp">Here is the press release</a>

Re:64-bit apps/CPU on the desktop

[JBv]

Not being a low level programmer, I would guess that he is referring to a method of acessing memory by pages, which requires additional calculations since you first access first the memory location of the page and the the relative offset. I don't know for certain what is the limit for current 32bit cpus/OS, but I suspect it's 2Gb.

I remember (in my student years) having to split 'large' matrixes in ~64k chunks when I was programing in DOS on my AMD 386 with 4Mb of ram. Not the most efficient way of doing things. Fortunately someone gave me a copy of djgpp, which allowed me to use 32 bits on that machine. This was about 1994 I think. Just on the virge of the 32 bit revolution of windows NT, 96 and 3.11+32s libraries.

Re:64-bit apps/CPU on the desktop

[alienw]

All programs will benefit. 64 bits allows for more than 4 gigs of RAM, without the nasty paging crap. There are more registers in the CPU, so programs compiled for it will run much faster. Obviously, it's good for computationally-intensive tasks (such as video encoding or 3D graphics). There's a reason why most GPUs are 256 or 512 bits these days -- it really does help.

Re:64-bit apps/CPU on the desktop

[tomstdenis]

I don't need to actually make a processor to know what sort of shit I would be interested in.

Just like you don't have to be a lumberjack to write books.

So, how about you shut the fuck up?

Tom

Re:64-bit apps/CPU on the desktop

[tomstdenis]

Damn skippy. Nutella!

Re:64-bit apps/CPU on the desktop

[tomstdenis]

Again your argument has no merit.

I mean, I imagine society would be cool if we all shared and didn't have money. I have no idea how to make that a reality.

I'm writing a book but I don't know how a press works. I write software but I don't know how a processor works.

So what?

Amd has the Opteron Weapon.

[arcanumas]

Well , it seems that AMD will be doing some serious damage to Intel with it's new Opteron. From what i read the sales haven't yet reached their peak and we might expect a new change to these statistics.
From what i understand AMD is moving very aggressivley right now and Intel has yet to produce a sign of response.
One can not help but wonder what the future will hold....

Transistor stats

[danormsby]

Are these numbers in dollars or processors?

I guess Intel would increase market share if we get stats on number of transistors sold.

Spooky

[Anonymous Coward]

If you rearrange the letters in "amd transmeta athlon", you get "a short talent madman"... And here I though Bill Gates had nothing to do with this.

Re:Spooky

[CausticWindow]

Well, if you rearrange it further you get:

"Amd not thermal satan"

How does that fit into your theory?

Re:Spooky

[tcc]

Your theory works and is cool, cool until I get

"Then... A Mad Anal Storm"

Which is probably due to too many goatse.cx hidden links clicked in my humble life.

volumes ?

[mirko]

What about sales volume ?
Why do we only have percentages ?
What does this survey count ?
IT looks like they forgot ARM half a billion units, or Motorola and IBM increased sales of G[345] procs.

This 0,1% increase/decrease is unsignificant and this article is as noisy as these meaningless figures.

Re:volumes ?

[CrazyWingman]

What does this survey count ?
IT looks like they forgot ARM half a billion units, or Motorola and IBM increased sales of G[345] procs.

RTFA!

Mercury's numbers include so-called x86 processors shipped for inclusion in desktops, notebooks, servers and Xboxes.

In Other News

[TrancePhreak]

"Floating Point Error found in method to calculate market share." It could happen!

Re:Intel

[ftvcs]

I don't see Transmeta and other manufacturers kicking Intel's ass soon because they are targetting a smaller amount of users with their ~1Ghz processors.

Not yet that is.

Wow Transmeta's popularity is through the roof!!

[Stubtify]

Going from 1.7% to 1.8% is a 6% increase!

yeah sure, gaining ground...

[KillerLoop]

... what's a decade between friends anyway when you celebrate 1% of gained marketshare in 2013.

Light on details..

[wfberg]

Is this marketshare in units or dollars? AMD's prices are lower, so they may ship more units per %point than Intel does. Also, Intel may ship the same amount of processors, or even more, but lose a few bucks because people decide against buying bleeding edge and go for celerons etc.

Also, which market are we talking about? XBoxes count, but other console chip manufacuters such as Hitachi are not included. Or maybe they're just too cheap and included in the 'other' category?

Also note that a 0.1%point change doesn't mean anything. 45.63241% of convincing sounding statistics are too accurate to be true (margin of error 41.553%).

You'd be better of just looking at the fundamentals of the companies (or their divisions), like SEC filings, quarterly results etc. If you add up all the numbers of the competitors you've compared, hey presto, you can determine their relative marketshares in the market comprised of their aggregate customerbase.

Lies, damn lies, and then this!

Re:Light on details..

[thegrommit]

Is this marketshare in units or dollars?

Regardless of which measurement is used, that same report showed that AMD's market share is much lower than in Q3 2001. While its nice that their situation seems to have stabilised, what counts is whether X86-64 takes off. If it doesn't, they're screwed.

Re:Light on details..

[pfafrich]

Also note that a 0.1%point change doesn't mean anything. 45.63241% of convincing sounding statistics are too accurate to be true (margin of error 41.553%)

It may well be significant. Lets rewrite these interms of actually numbers sold. At a guess say 10,000,000 chips sold. Now 1.7% of 10 millions 170,000 and 1.8% is 180,000 would you say the difference between 170,000 and 180,000 is significant? As another post said thats a 6% increase enough to put a smile of Linus's face.

Percentages are not a golden standard, they only make sense when you know the sample size. Very large samples mean very small levels of significance.

Now we don't have much to go on from the article but there are a few hints as to why these numbers might make sense:

Mercury's numbers include so-called x86 processors shipped for inclusion in desktops, notebooks, servers and Xboxes. Microsoft incorporates Intel processors into its Xbox gaming console.

this gives some evidence that they may actually have access to factory door numbers of chips.

A second reasons is the very high stability in the market. Last year intel was up 6%, this year down 0.3%. This is not a volitile market and small changes are big news. Consider the male female ratio, its flat as a pancake through the years. Even a .1% change is enough to get a lot of people worried.

A third bit of evidence is the number of decimal places used. Its common practice to only quote the significant digits, all numbers are quoted acurate to 0.1% sugesting that Mercuary know significance to this level. Giving Mercuary some credit, they are well respected market anaysists who have are far more demanding audience audience (wall street brokers) than the slashdot crew. Quoting insignificant numbers could get them seriously fried.

So there is little we can tell, we working on 2nd hand data where the information needed to decide on the significance has been ommited. On balance I'd trust Mercuary who have paid staticians on board more that a slashdotters.

Re:Light on details..

[wfberg]

Also note that a 0.1%point change doesn't mean anything. 45.63241% of convincing sounding statistics are too accurate to be true (margin of error 41.553%)

It may well be significant. Lets rewrite these interms of actually numbers sold. At a guess say 10,000,000 chips sold. Now 1.7% of 10 millions 170,000 and 1.8% is 180,000 would you say the difference between 170,000 and 180,000 is significant? As another post said thats a 6% increase enough to put a smile of Linus's face.

Percentages are not a golden standard, they only make sense when you know the sample size. Very large samples mean very small levels of significance.

If we assume the researchers used a survey, we don't know anything about n (the number or people interviewed), since the article doesn't mention it.
If we assume the researchers took the numbers the manufacturers reported, for example in their quartely income reports, we know the size of the numbers reported.

However, while you're right that 0.1% of A LOT may well be a large amount of money, that doesn't make it a significant amount of money.

Presumably you'd want to use market share numbers to predict future income. If your market share has been declining for years, probability is it will decline some more. If all of a sudden your sales drops 30%, you'd better have some pretty good explanation to account for it. But it your sales drop 0.1%? Assuming your sales staff only works 200 days of the year, that's a drop of 20% of a day's work! I'd hardly call that significant.

What you should remember here is that the marketshare/sales is NOT n here. It's the quantity measured. The number of observations, or n, is only 1; namely the last quarterly statement (or projection) of sales.

Quoting insignificant numbers could get them seriously fried.

Of course it wouldn't. But they would also quote a confidence interval, which is not mentioned in this article. Unless it's raw data (such as sales) in which case they may or may not quote an error of measurement (remeber your science classes?). It's the interpretation that matters. If they make sweeping generalizations based on a 0.1% rise or fall of marketshare, like the people here on slasdot, THEN they'd get fired. Unless of course they're talking about a very, very small company which only grosses 0.05-0.2% of the market.

Let's put it this way; if the price of a barrel of oil rises 0.1%, is this significant? If you happen to own a huge amount of oil, or need to buy it, it translates into a huge amount of money. But does it mean you should be worried about the oil price in general, or longer term political stability in the Middle East? Or do you just chalk it up to day-to-day fluctuation in the price of oil?

What would you say to a 0.1% raise?

Re:Light on details..

[pfafrich]

However, while you're right that 0.1% of A LOT may well be a large amount of money, that doesn't make it a significant amount of money.

I ment to refer to statistical significance. i.e trying to gague if the numbers have meaning or are just noise.

Quoting insignificant numbers could get them seriously fried.

Of course it wouldn't. But they would also quote a confidence interval, which is not mentioned in this article.

I was trying to posit that there is a implict confidence interval sugested by the number of digits they quote. If they are statisticans worth their sort they will not quote 1.7% when the confidence interval is +/- 0.5%.

Re:noise, heat and damage....

[RMH101]

With respect, "Balls". I've built countless (well, OK, over 50 anyway) AMD Athlon systems and this just isn't true - it's FUD.
If yours have been overheating like this then you've installed it incorrectly, simple as that. The current retail (read, cheap) heatsink/fan combos AMD ship with are already quiet - and plenty of aftermarket quieter ones are available if you want near-silent.
I've had 1700's overclocked to 2200 speeds running in a normal mini tower with only a single case fan to ventilate the case and they typically hit mid-fifties *at the most* under load, well within normal specs. They also work fine up into the 80s if you really want to push them.

If you want to get really paranoid about heat, make sure your case is well vented and stick a zalman flower passive cooler on it.

different CPUs, different appliances

[KixXaSs]

"the little guys are gaining ground" well my next processor will be one of those "little guys". I especially like the fact that -for example- the VIA C3 generates LESS much heat than amds or intels, which is a good thing for silent computing. For day-to-day work those CPUs should be enough. Maybe more ppl think like me and thats why the smaller chip producers gain ground. :) just my .2 cent

"Microprocessor Market"?

[arekusu]

Wait, what market are we talking about?

Oh, right: "Mercury's numbers include so-called x86 processors shipped for inclusion in desktops, notebooks, servers and Xboxes."

So, these numbers don't tell us anything about the chips in Macs, Suns, SGIs, mainframes, Crays, Playstations, Palms, VCRs, cars, vaccuum cleaners, or toaster ovens. Just that Wintel stuff.

Alternatives

[maroberts]

So what alternatives are there to Intel? I'm obviously aware of AMD, but what other contenders are there?

I'd be particularly interested in anything which can provide approximately Athlon XP1800 performance with low heat output and comparable cost, since I'd like to build a PVR which is as silent as possible.

Obviously low noise fans are needed, but I suppose the other alternative is to water cool it.

Re:Alternatives

[BetaJim]

For a PVR applications checkout the VIA epia 800 mini-itx motherboards. They use an x86 clone that runs at 800MHz, not Athlon XP1800 performance but that may not matter too much.

Also, Casetronics makes some really nice cases for mini-itx motherboards. Thought I would mention mini-itx as the small size would seem to be perfect for a PVR box.

Re:Alternatives

[DirkDaring]

Hey Einstein, ever thought that people do buy the fastest CPUs out and then overclock those? Guess what? You can overclock them farther with a water cooled system.

And thanks for that critical update on water transmitting electricity. I'll alert CNN.

Not just good for silent computing.

[Moderation abuser]

Good for sweaty laps and changes of underwear.

How is 0.1% significant?

[Junior J. Junior III]

Ok, these are, technically, gains in marketshare for AMD and Transmeta, but they're so small that they are statistically insignificant, aren't they? Why is this article not saying that marketshare is more or less stagnant?

Re:How is 0.1% significant?

[avandesande]

What's significant is that these companies have survived one of the worst tech retractions in memory. Not to mention that AMD was selling old non-competitive technology. I think at this point there is no where to go but up.

Re:How is 0.1% significant?

[praksys]

but they're so small that they are statistically insignificant, aren't they?

No, because the numbers given are not statistical estimates based on a sample. Measures of statistical significance only apply to results that are obtained by sampling a population and then using statistical methods to draw conclusions about the population as a whole. In this case the figures are based on the total sales reported by various companies. No sampling was involved.

Of course you might argue that 0.1% of a given market is insignificant rather than statistically insignificant (i.e. the differnece doesn't matter much rather than there is no difference as far as we can tell).

Re:How is 0.1% significant?

[nathanh]

Ok, these are, technically, gains in marketshare for AMD and Transmeta, but they're so small that they are statistically insignificant, aren't they?

I don't think marketshare figures are statistics. They are derived from sales figures. Statistics implies a sample; that's where the error comes from. There's no error if you're going off 100% of the data.

Audio/video editing

[wowbagger]

If you do any audio/video editing, 64bits is a godsend.

Consider something relatively simple: transcoding a DV file into an MPEG4 file. For a medium length file you are talking 2-6GB of data.

Now, for a 32 bit program, the programmer must write his code to either a) process the file in a stream, with little or no memory (which means multiple passes over the file with a log file to record frame size data from pass to pass) or must write his code to work through a small window into the file, loading and reloading that window as needed. Neither approach is really friendly to the file system buffer cache.

In a 64 bit addressing system, the programmer can simply mmap() the file into his process memory space, and let the OS's VM system handle faulting the pieces of the file in and out. As a result, the OS's buffer cache logic can better manage what parts of the file are cached. Also, from the programmer's perspective the code gets much simpler (and simpler code is better!) - if he wants to access 2 parts of the file at once (for interframe compression, say), he just has 2 pointers. If he wants to seek forward, he increments a pointer. Simple. Easy.

And lest you say "But that's not something that Joe Average does" - consider the current crop of DV camcorders, DVD burners, and video editing software. Joe Average might not do this yet, but Joe (Average+2*sigma) does, and the threshold is moving downward.

I expect that when 64 bit Macs and 64 bit MacOS become available, the video editing software on the Mac will become the platinum/iridium standard for the industry.

Re:Audio/video editing

[MtViewGuy]

I think people are starting to realize that audio/video editing has extremely high demands on CPU time.

This is going to become even more important by 2010 because I actually expect people by then to be burning high-capacity optical discs with HDTV data (720p/1080i uncompressed video) on home machines, and gawd will THAT need a huge amount of CPU processing power.

Re:Audio/video editing

[Anonymous Coward]

Joe Average might not do this yet, but Joe (Average+2*sigma) does

Whoa, Nelly. You're going beyond the eigth grade math that most Slashdot readers completed last spring. Careful!

"Market share" favors big-bucks Intel processors

[shoppa]

Because "Market share" is by total dollars sold, and not by numbers of processors sold, Intel gets a very real boost in these figures.

OTOH the low-end sellers (like Via and Transmeta who target set-top and embedded devices) end up underrepresented because their processors are so cheap (or in some cases not even sold at retail).

Now clearly, this is a business report so only those who make big bucks count there. I'm just pointing out that the methodology, by design, ignores trends towards lower-cost pervasive computing.

Re:noise, heat and damage....

[Slack3r78]

my current personal system == Athlon 2600 with the retail HSF. Despite living in the south and being in a room where the A/C doesn't circulate well, this thing only runs in the mid 50s. The small builder I work for here deals exclusively in AMD systems (read: no P4s) and I can't remember a system ever coming back due to overheating problems. Like another poster in the thread said, if you're having major heating problems and you're not overclocking, there's something wrong with the way you've installed the parts.

So, by this information Apple has 0% Market share

[adzoox]

Okay, first of all, skewed stats come out all the time that Apple only has 3-4% market share. When that is quarterly sales of a MUCH larger pie than 10 years ago when market share was in the 20's. Actual SALES volume of Apple Computers has remained relatively flat to increased. Actual MARKET share of Apple (installed base) hovers at around 11%. --- Do you honestly think on 3% of the USA is buying 8.3 million iTunes songs?

So buy this report IBM & Motorola have a 0% market share because the total adds up to 100. Moto and IBM make LOTS of CPU's for computers OTHER than Apple as well. This is another statistic probably paid for and sponsored by Intel just as the Billionth processor news was.

Re:So, by this information Apple has 0% Market sha

[shoppa]

The view of this (and other reports) is towards the "big fish in the big pond" - in other words, Intel. Anything not Intel-related is simply not on their radar.

It sucks, but that's the way it is.

In total units sold, by far the biggest selling microprocessors are 8051 derivatives, there are literally billions sold every year. But these aren't 80x86 compatible so they don't even know how to classify these sales.

Hint

[mattdm]

read the *subject* of this story on slashdot.

Anyone wanna take a guess?

[splerdu]

How long till "classic x86 DOS" shows up when we search for "emulator" and "romz"? I miss prince of persia...

Re:Anyone wanna take a guess?

[LocalHero]

Hey

Check out
http://dosbox.sourceforge.net/
Its just wounderfull. I played railroad tycoon for hours when i found it

Precise sales figures anyone?

[PurpleWizard]

It might not be noise but based off actual units shipped. Tracked through records. If that is the normal way of doing it there is no statistical noise.
Besides results of much finer accuracy than that are accepted in some fields these days like subatomic physics. No one bats an eye lid at the precision of measurements there!

Intel Itanium is not really a success.

[MtViewGuy]

I think introducing some radically different architecture will never work out (intel kind of proved that), amd is going the right direction innovating inside the box.

You can say that again. What plagued the Itanium CPU was that in order to take full advantage of the CPU you had to essentially write code from scratch, which is an extremely expensive investment, to say the least. It didn't help that the Itanium CPU pricing is somewhere out in the stratospshere, too. =( Small wonder why it took quite a while before the first Linux distributions that support Itanium native mode finally shipped.

With the Athlon 64 CPU, not only can you run current legacy x86 code unmodified, but it's a pretty straightforward step to modify current x86 code to support x86-64 instructions. This is Linux is already running in x86-64 native mode, and don't be surprised that Microsoft will likely have x86-64-native versions of Windows XP Home/Professional and Windows 2003 Server shipping before the end of 2003.

Transmeta

[LimeColoredSloth]

...Transmeta and other manufacturers went from 1.7% to 1.8% in a single year.

In other news, CPUs do not exist outside US. Seriously, wasn't this supposed to be big in Japan?

no time for champagne -- break out the water!

[Stephen Samuel]

For Transmeta, that 0.1% increase in market share is a 5% increase in sales. Granted it's only significant because their market share is so small, but they definitely have more reason to celebrate than AMD does.

Re:noise, heat and damage....

[Merlin_80000]

actually, I have on my desk 4 AMD Thunderbird (950+Mhz) CPUs all dead from heat and all were properly installed with the fans still spinning, one of them was from my personal workstation. I don't know about the XP or later series, but from what i've seen, there's at least SOME credibility to the heat damage argument, also, the famous tom's hardware videos (i'm sure if you look, you'll find them) demonstrate pretty well that amd has a flawed thermal management system compared to the pentium. (even though running a CPU at all deserves the loss of said CPU, dying fans happen every day, and that really just doesn't deserve the loss of a whole CPU.)

Re:gcc for benchmarking is stupid

[dpilot]

You make good points about optimization.

But gcc is still what most of us use. Kind of a different application of, "'something that works' is the enemy of 'excellent'" that so often gets applied to X86 and Windows.

Re:"Market share" favors big-bucks Intel processor

[mercuryresearch]

The market share is computed on units, not dollars. Intel doesn't get any more of a boost than AMD.

The methodology doesn't ignore any trends -- that's why it's done in units. As mentioned in a previous posting the one-tenth of a percent gain in the "Other" segment was VIA, which is definitely benefiting from the lower-cost computing trend.

Re:So, by this information Apple has 0% Market sha

[mercuryresearch]

The statistics relate to what they are labeled as: x86 CPUs. This isn't a report on PC unit shipments, it's a report on x86 processors.

As an aside, the document these figures are from includes Apple processor shipments as well -- which have been roughly 800K-1.1 million units per quarter since 1995. But the statistics here are x86, and that't not what Apple uses.

I can also assure you that the statistics Mercury produces are far from bought and paid for by Intel. We've documented both Intel and AMD's rising and falling shares for the past 10 years, as well as those of VIA, Transmeta, and a number of now-defunct suppliers. It would take an imaginative conspiracy theory to believe that Intel and AMD coordinated transfer of "sponsorship" to coincide with share changes.

Re:AMD's so called "performance".

[FatherOfONe]

I personally don't care between the AMD and Intel, but if I was Intel I would be a little worried. The Opteron appears to be a good chip (we are getting a dual 244 (1.8GH)processor box in this week), and currently competes against the Xeon. Well from what I can tell it spanks a Xeon in 32 bit Linux server software. Now for us that means that we don't have to purchase a 4X Xeon box for Oracle but can use a 2X Opteron. That saves our company ~$40,000 in software cost!

To me the real question is how fast can AMD clock this thing? Will Intel respond with some good chip? (Xeon 3GH 1MB cache doesn't cut it). How good will AMD64 be for desktop apps? Will Doom3 support AMD64 and if so how much better will it run?

Do I think that Intel should panic? No!!! They can use their "MarketShare" to force motherboard vendors and OEM's not to support AMD, but that will only last so long. But if (and this is a big if) AMD64 is a great chip and can outperform anything Intel has on the desktop side, Intel should worry.

Gaining ground?

[greenhide]

Hmmm...

Looks to me like all these numbers say is that Intel market share dropped by 0.4% of its total over the last year. That's not much of a loss. AMD's market share went up by one tenth of a percent for a percentage increase of 0.6%. That's not much of a gain. Considering that AMD is supposed to be offering better chips at a more reasonable cost, it seems to me that it must be doing something wrong to have an overall growth that's so lousy. At this rate, it will take over a thousand years for Intel to get to the point where it has less than 50% market share.

I think that AMD makes good procesors -- we have quite a few computers in the office using AMD chips. However, I don't think that they're "gaining ground", and neither did the actual article, which states that AMD "ekes slight gain". The real news of the article is that processor sales in general are picking up, which is probably good news for everyone in the tech industry, right?

Awesome! Just another 66.8% to go...

[grimani]

.1% a year. Heh...

At this rate, AMD only needs another 668 years to get to where Intel is right now.

Not bad, at least we're making progress...'gaining ground', as they call it.

Too bad the snails in my backyard even gain ground faster.

Do-It-Yourself Kit

[MyHair]

$an "amd transmeta athlon"

This assumes you have an installed. Debian puts it in /usr/games.

I got 1,495,995 combinations! Unfortunately you have to weed through them to see what might make sense:

Rot Manhattan damsel
Damn anal thermostat
Matt marshaled no ant
Toad rant at helmsman
Tenth NASA marmot lad

Now to make sure AMD gets in there:

$an -c amd "amd transmeta athlon"

Re: AMD lost Manhattan
Last 10, AMD Marathon
AMD Earthman lost tan!
No Hamlet rants at AMD
AMD harlots met an ant

Darn, not enough "s"es to make Slashdot anagrams out of that phrase.

Re:Do-It-Yourself Kit

[caluml]

Gentoo!! Noooooooooo! You've let me down....
gentoo root # emerge an
Calculating dependencies
emerge: there are no masked or unmasked ebuilds to satisfy "an".

!!! Error calculating dependencies. Please correct.
gentoo root #

I will never be able to look my Debian using friends in the eye again... Please make this your top priority!

Re:Do-It-Yourself Kit

[MyHair]

It looks like an old abandonded project last updated in November 2000, but you can get the source from Debian's an package page. Should be easy to add to Gentoo. (Anything I don't know how to do must be easy, right?)

I found it by seraching Debian's packages for "anagram". It doesn't appear to be in Freshmeat.

x86 processors

[MyHair]

In that case, what about Via? I intuit that their admittedly tiny C3 market share has been increasing. I wonder how their numbers compare to Transmeta.

(Trying to pull up Cyrix to see if they still make anything x86, but the page isn't loading.)

One word - DRIVERS

[charnov]

One of the biggest problems of porting to another instruction set is that ALL drivers would have to be re-written to get the full potential of the hardware (that is the big deal with AMD64 and Windows 64bit edition). Not that 32 bit drivers do not work on a AMD64 chip, but that it would not work as well. Change that to a completely different instruction set, and you get big problems.

Just look at the Itanium: big, expensive, LOUSY to program for.

I think the PPC and AMD64 will merge sometime down the road, but only when IBM/AMD/Apple is really ready to go against Intel/Microsoft. Remember, neither AMD or IBM even has the fabrication CAPACITY to challenge Intel yet. That's the real reason AMD hasn't gained market share.

Mhz isn't everything

[MikeCapone]

You seem to think that the clock speed is a sure way to know a processor's performance; it isn't. If I remember correctly (chip geeks will correct me if I'm wrong), the 2Ghz G5 from Apple is faster than even the faster P4.

Athlon64 will be Crushed by PPC970, not Deerfield

[reporter]

Occasionally, the markets operate in a way that defies the observations of conventional pundits. Conventional wisdom says that the primary competitor of the Athlon64 will be the Deerfield (an Itanium chip). Both are 64-bit chips, and both target the same desktop market.

However IBM's recent entry, the PPC970, has radically altered the desktop landscape. The new Apple computers powered with the PPC970 are genuine workstations sold as desktops. The ARS Technica article indicates that the SPEC2000 performance for the PPC970 is 937 and 1051 for integer applications and floating-point applications, respectively. The Athlon64 is a weaker version of the server chip, the Opteron. The PPC970 has about the same performance as the Opteron. (reference: SPEC performance list)Hence, the PPC970 is sure to beat Athlon64 across a broad range of applications.

What is particularly interesting about the PPC970 is that it was designed and built largely without H-1B employees. Both IBM and HP have a policy of not hiring anyone who does not have American citizenship or permanent residence unless that applicant has a Ph.D. Clearly, American companies do not need H-1B employees to produce awesome products.

Duh!!

[maroberts]

I was thinking of buying a fast CPU and avoiding having a fan revving at 5000rpm to keep it cool, not overclocking.

Re:noise, heat and damage....

[RMH101]

AMD vary the heatsinks/fans quite a bit actually. Currently, anything over a 2.2 has been shipping with really quite nice retail heatsinks/fans - copper-cored, hologram on the fan and they really are pretty quiet...the old green plastic ones were a bit on the unsubtle side but current ones from the last six months are actually very good. there are some excellent aftermarket ones out there, though - personally for really quiet, i'd say either go passive if you can, or if not stick an 80mm fan on there with an 80-60mm adaptor. a larger fan is quieter for the same amount of air moved...

Re:not as significant

[turgid]

That's a long time we went struggling on with the segmented memory model, even though our hardware could do more. Hopefully the transition to 64-bit architectures will go more smoothly. Microsoft is really the key to the transition on the software side, since they have such a huge market share on the desktop.

It's funny you should say that, 64-bit processors started to come out about 10 years ago in workstations, and 64-bit UNIX soon followed. Microsoft even had a portable OS back then (NT 3.51) which ran on MIPS and Alpha, as well as intel, but only in 32-bit mode.

Microsoft os only now getting around to producing a 64-bit OS, having killed the nice portability they had built in, so they really limited their choice of processor architectures.

The reason the portability went away was that when NT went from 3.51 to 4.0 the HAL (Hardware Abstraction Layer) went away in the interest of speed. A lot of stuff went in the kernel that shouldn't, with stability problems as a result.

AMD Animation and Short Film 64-bit Contest

[AMDpro]

AMD's sponsoring a contest to promote animation and digital short film development for 64-bit. Two grand prize winners get an Athlon64 system, $6,400 and global visibility at AMD's launch events for Athlon64. More info at http://www.amd.com/us-en/0,,3715_9392,00.html?redi r=ANUS01