Slashdot Mirror
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.'"
0.1 of a percentage point? Whats the betting that is *well* inside the bounds of sampling error.
Nothing to see here, move along.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
Aren't the modern chips RISC underneath anyway? The underlying architecture hasn't stayed the same, it's just a compatibility interface. Yes?
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?
Trust the Computer. The Computer is your friend.
My guess, VIA
Seconded. Their C3 &c chips on the mini-itx boards are going from strength to strength
--
This sig is inoffensive.
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.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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
bite my glorious golden ass.
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.
/. elitism or anything you seem to imply, this is paraphrasing. RTFA:
Holy chill there batman. Take a look at the article, will you? This isn't editorializing or
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.
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 =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
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
bite my glorious golden ass.
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.
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.
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.
Yell & scream & rant & rave... it's no use... you need a shaaaave ~ Bugs Bunny
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
-Michael
$an "amd transmeta athlon"
/usr/games.
This assumes you have an installed. Debian puts it in
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.