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

[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

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

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?

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

[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

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

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

[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

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

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

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.

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

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.

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.

Hint

[mattdm]

read the *subject* of this story on slashdot.

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.