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

[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.

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.

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???

[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.

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...

[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.

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

[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

[turgid]

When will this end?

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

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

[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

[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

[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

[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

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

[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

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?

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.

In Other News

[TrancePhreak]

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

Wow Transmeta's popularity is through the roof!!

[Stubtify]

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

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: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.

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?

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.

"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.

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.