Linked by Thom Holwerda on Thu 29th Jan 2009 12:11 UTC
Thread beginning with comment 346086
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Atom is the Great Cure for Software Bloat
by bnolsen on Thu 29th Jan 2009 15:18
in reply to "RE: Atom is the Great Cure for Software Bloat"
Apparently atom doesn't scale. What hurts x86 massively multi core is the comparatively "vast" amount of silicon required just for the x86 decoder. That's why intel went back to hyper threading. They can get more (inefficient) execution units while not having to replicate yet another x86 decoder.
The arm guys should get off their butts since the arm instruction set is far superior for low power small die truly multi core operation.
Likely nvidia's only way to get back in the game short term is to find a way toteam up with freescale and put together something with a cortex a8. The other arm core nvidia is supporting can't play in the netbook arena.
RE[3]: Atom is the Great Cure for Software Bloat
by timofonic on Thu 29th Jan 2009 15:56
in reply to "RE[2]: Atom is the Great Cure for Software Bloat"
RE[3]: Atom is the Great Cure for Software Bloat
by _txf_ on Thu 29th Jan 2009 16:08
in reply to "RE[2]: Atom is the Great Cure for Software Bloat"
RE[3]: Atom is the Great Cure for Software Bloat
by christian on Fri 30th Jan 2009 13:05
in reply to "RE[2]: Atom is the Great Cure for Software Bloat"
Apparently atom doesn't scale. What hurts x86 massively multi core is the comparatively "vast" amount of silicon required just for the x86 decoder. That's why intel went back to hyper threading. They can get more (inefficient) execution units while not having to replicate yet another x86 decoder.
There is nothing inherently inefficient with hyper-threading. It allows you to have relatively simple pipelines, and avoid pipeline bubbles by having multiple execution streams. Sounds like a great idea to me, and allows you to ramp up execution units and still use them relatively efficiently.
I'd rather have a HT core with 4 execution units than 2 non-HT core with 2 execution units each.
While avoiding duplication of decoder units is good argument for HT in x86, HT also works very well for RISC instruction sets as well, as it is the pipeline bubbles that HT effectively removes.
SPARC T1 & T2 is a good demonstration of HT with simple pipelines.





Member since:
2005-07-11
The Atom is already multi-core, netbooks use the single core version. The desktop Atom implementations use the dual core version.