Slashdot Mirror
Intel Medfield SoC Specs Leak
MrSeb writes "Specifications and benchmarks of Intel's 32nm Medfield platform — Chipzilla's latest iteration of Atom and first real system-on-a-chip oriented for smartphones and tablets — have leaked. The tablet reference platform is reported to be a 1.6GHz x86 CPU coupled with 1GB of DDR2 RAM, Wi-Fi, Bluetooth, and FM radios, and an as-yet-unknown GPU. The smartphone version will probably be clocked a bit slower, but otherwise the same. Benchmark-wise, Medfield seems to beat the ARM competition from Samsung, Qualcomm, and Nvidia — and, perhaps most importantly, it's also in line with ARM power consumption, with an idle TDP of around 2 watts and load around 3W."
It beats the current crop of dual core ARM processors (Exynos, snapdragon s3 and Tegra 2) in one benchmark that "leaked".
Nothing fishy about that at all.
The Atom's have always had a reasonable core power consumption... but the external chipsets that ruin the system power consumption figure. Will be curious to see what the total system consumption is going to be with these new one, maybe time to look towards a nice replacement for my Asus eeebox B202's for the desktop.
Awesome, with smartphones these days containing 6 watt-hour batteries you'll get 3 hours standby time! Thats nearly as much an an iPhone 4S
That just doesn't cut it. Based on that, I'd assume the mobile version of the chip to consume at least 1W at idle loads. That _still_ doesn't cut it.
I think the tablet will be interesting.
Help stamp out iliturcy.
Its a feature!
2W idle + 3W active?!!!
Not in line with power consumption of any ARM board I've played with-- more like 4-6 times active consumption and an order of magnitude+ higher idle.
But, if they can pull decent marketing of a portable hand warmer that doubles as a phone for a couple hours a day between charges, maybe they have a winner.
come on, when talking about comparing embedded SoC's is it really fair to say a new die shrunk version of another architecture best another using a much larger die size?
So here we have Intel putting their low cost product on their high cost process and claiming a victory? I don't buy it but since Intel is going to be selling these things at deep discounts, I might buy a product or two. I don't think in the long run they can continue this game but it's fun to see them attempting it.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
> The tablet reference platform is reported to be a 1.6GHz x86 CPU coupled with 1GB of DDR2 RAM,
For tablets / netbooks, you better be able to add more RAM. My current tablet came with 2GB, but supports up to 4, which is what I have it at now (cheap upgrade). RAM often makes more difference to system responsiveness than CPU speed. 1GB is fine for phones but just isn't much for tablets and netbooks.
think of all those amplitudes not being modulated.
this is a terrible, terrible loss for America.
teh37737one's point, if i may, was that this 'leak' was actually a 'plant', a PR move by Intel to get people posting ridiculous speculative nonsense, like, exactly the stuff you posted in your comment.
"if this is realistic, intel has an awesome CPU" etc etc etc.
Does anyone care if its realistic? Intel sure doesn't, it just wants people to speculate that it might be realistic, and then talk about Intel, and how awesome Intel is.
But of course, it might be a load of crap... when the actual numbers come out, who knows what they will say? And when real programs hit the thing, who knows what it will do?
That's why Intel is 'leaking' it. On purpose. So they can have 'plausible deniability'. They can churn the rumor mill, get their product mentioned in the 24 hour ADHD cycle of tech news, get people posting on slashdot, etc, but Intel itself never has to sully it's good name by engaging in outright pushing of vapor-ware.
If only the guys at Duke Nukem had been smart enough to 'leak' stuff 'anonymously' to the press, instead of giving out press releases...
Of course, another way to look at it is this: It's yet another example of the corporate philosophical suite that is drowning our civilization in garbage and awful values. Never say anything directly, never take responsibility for your words or actions, never be straight with people, and hide everything you are doing in layers and layers of techno jargon, babble, and nonsense.
It looks like CaffeineMark 3 is single threaded. At least the online version is anyway.
How can you compare a 1.6ghz presumably single core against dual core cpus on a single thread benchmark?
I just compared my laptop which is 2.2ghz dual core with my desktop, 3ghz single core. laptop gets 16,000, desktop gets 24,000. Laptop was at 50% cpu, desktop was at 100%.
I was hoping someone would know ?
These days 32nm is their main process. They use 45nm still but not for a ton of stuff. Almost all their chips have moved to it. Heck they have 22nm online now and chips will be coming out rather soon for it (full retail availability in April).
Once of Intel's advantages is that they invest massive R&D in fabrication and thus are usually a node ahead of everyone else. They don't outsource fabbing the chips and they pour billions in to keeping on top of new fabrication tech.
So while 32nm is new to many places (or in some cases 28nm, places like TSMC skipped the 32nm node and instead did the 28nm half node) Intel has been doing 32nm for almost 2 years now (first commercial chips were out in January 2010).
It's bloated. It had its time. I LOVED writing in assembly on my 80286, the rich instruction set made quick work of even the most complex of paddle ball games...
However, that was when I was still a child. Now I'm grown, it's time to put away childish things. It's time to actually be platform independent and cross platform, like all of my C software is. It's time to get even better performance and power consumption with a leaner or newer instruction set while shrinking the die.
Please, just let all those legacy instruction's microcode go. You can't write truly cross platform code in assembly. It's time to INNOVATE AGAIN. Perhaps create an instruction set that lets you get more out of your MFG process; Maybe one that's cross platform (like ARM is). Let software emulation provide legacy support. Let's get software vendors used to releasing source code, or compiling for multiple architectures and platforms. Let's look at THAT problem and solve it with perhaps a new type of linker that turns object code into the proper machine code for the system during installation (sort of like how Android does). DO ANYTHING other than the same old: Same Inefficient Design made more efficient via shrinking.
Intel, it's time to let x86 go.
Wake me when Intel releases a product I want. This part is going to be obsolete by the time the next iPad comes out.
What Intel needs to figure out is how to put 8GB of ram, x86-64, quadcores and then make it use 1 watt. Bonus is to figure out how to turn OFF the unused RAM by coming with a process that doesn't need to be refreshed. Then we'll see a chip that is competative to ARM design.
Intel's failure is that they aren't reducing TDP in any of their chips, rather it keeps increasing, this unfortunately has the problem of hitting the wall. Already you can only put 8 CPU's in a 15A rack. The TDP needs to come down for real, not with marketing.
I don't know what Intel is shooting for here. If they are shooting for the Tablet, it will be obsolete shortly with those specs. Current desktops are 8GB ram 64bit and quadcore as standard. Putting anything out there that is less, even for a "tablet" is just admitting they can't put a desktop experience in a tablet. This is where Apple figured out the right thing to do... pick a better power conserving CPU and then don't try to put the desktop on the tablet. Sure it is essentially the same OS, but by not putting the MacOS UI on it and instead coming up with something more stripped down that doesn't rely on any other unused libraries (think about why Windows is bloated... the same OS is used for the Server and Desktops.) And no development tools on the device it sellf (See *nix land)
Microsoft's entire screwup dates back to trying to integrate MSIE into the system too rigidly. Had they not tied it down to the OS and instead broke it accross componets that could be swapped out, we might not be were we are today with 2.5 competing alternatives. So the Server OS (NT) got spitpolished up and became Windows 2000, XP, Vista and 7, heading clear in the opposite direction of a lightweight GUI on top of DOS that ended in WindowsME. Meanwhile Microsoft botched WindowsCE/Mobile/Phone, several times. CE should have started out as a stripped down NT (as in figuring out how much to strip out of NT to make it work on embedded devices.) Instead Microsoft had to duplicate efforts countless times, ending with everyone dumping their PDA's (the predecessor to the Tablet.)
We have already seen Microsoft fail at the Tablet environment already, and we've seen why (OEM's produce throwaway expensive crap) Exactly what is happening on Android. Android's future is Windows Mobile 5's past already. The OEM's need to shape up and produce better hardware with the same user experience on the same OS. We've seen this game before with the CDi, 3DO, WindowsCE/Mobile, and even Palm. The OEM's produce inferior hardware and nobody wants to develop for it (except for some hardcore nerds) , the end users end up stuck with the bloatware that comes with the phones and tablet and never buy anything from the market because their brand new device doesn't run the current version of the OS.
Only would a mobile phone company have the gall to force it's users to throw away their product and purchase a new one within the warranty period to get the latest software. This is what the WindowsMobile OEM's were doing before. I've been burned there, I'm not getting burned again with Android. When I see a OEM support their tablet for 6 years (like a game console) I'll consider that brand as good. Till then, screw them all and let the grandmas use them for portable throwaway web browsers.
Typical ARM-based SoC have idle power around 50-200mW, 2W ain't going to cut it.
Intel will need to bend the law of physics before their power hungry chips can match the the energy efficiency of ARM SoCs, but if anyone can do it it'll be Intel. Intel took x86 to workstations and supercomputers killing many RISC processors in the process. It'll be fun to see them pull it off again against ARM.
GENERATION 25: The first time you see this, copy it into your sig on any forum and add 1 to the generation.
Recent track record... Yeah, sure...
http://www.pcper.com/reviews/Graphics-Cards/Larrabee-canceled-Intel-concedes-discrete-graphics-NVIDIA-AMDfor-now
There's a few others like this one. This includes the GMA stuff where they claimed the Xy000 series of GMA's were capable of playing games, etc. They're better than their last passes at IGPs, but compared to AMD's lineup in that same space, they're below sub-par. Chipzilla rolls out stuff like this all the time. Been doing it for years now.
Larrabee.
Sandy Bridge (at it's beginnings...).
GMA X-series.
Pentium 4's NetBurst.
iAPX 432.
There's a past track record that implies your faith in this is a bit misplaced at this time.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
We still use Imperial units in the US. And do you remember the shortage of competent Cobol programmers back when Y2K was the big worry?
The world does indeed move on, but the past stays with us for a long while. A low power x86 SOC is still a useful and a wonderful thing.
My first thought when I read the article was "Cool! You'll be able to get a notepad to run WINE and native Windows XP now!" I can see TONS of uses for this, even with the lousy power specs. Industrial/business types don't like to let go of legacy systems. I just know I'm going to get some work someday that this chip will be the perfect fit for. I'm thrilled. Excellent work Intel.
Is ARM better? In this marketspace, absolutely. It's the best forward thinking decision you could make. But not everyone looks forward or is willing to spend cash on rewriting some legacy system. This chip fits a need perfectly.
Weaselmancer
rediculous.
Somebody will also remember how Larrabee was meant to smother the market of video cards, the rumors that Sony was to build the PS4 upon it, etc. Result in reality: Larrabee shelved.
It's easy for Intel to beat ARM in performance benchmarks - they have been doing this since the beginning. The point is, that they have to beat ARM in power efficiency, and it looks like Medfield isn't quite there yet.
If this thing can compete on performance with ARM chips, it's only because Intel can make miracles happen in silicon. Of course, we might never know what would happen if Intel used their latest process technology to print ARM chips like Apple's A6 or whatever the next generation will be. But it would be very good.
I wonder if this means Meego will finally get the last push it needs to be allowed onto the market. The chips, I could not care less about.
I Think Not. Really, this shouldn't need to be said, but apparently the submitter is clueless here. You can't presume proof before you have it, thanks. That means no claims about benchmarks without the benchmark numbers (and all the details, dammit, the numbers are useless enough as it is) in hand. Say the specs make you expect it will out-perform the competition, fine. But putting it like this is vaguely handwaving with extreme presumption. Techies really ought to know better than deploying marketeers' weasel word salad, thanks.
So...how's the performance per watt if we compare these recent ARM and Intel offerings?
I was also thinking that the Atoms probably have more all sorts of acceleration units. I'm not sure how important would those be on a tablet or a phone though. Anyway, there was an interesting discussion pondering if it would be possible to run Folding@Home on a phone. It ended by realizing that the ARMs wouldn't have the same kind of FPU power.
Admittedly, _released_ versions of Windows 7 and Windows Vista didn't support any RISC chips. The days of NT shipping with install discs for multiple architectures are long gone.
But the the most recent versions of the Windows family still supports RISC chips, just on a different code branch (Windows CE/Mobile/Pocket PC/Whatever they're calling it these days). Microsoft had planned on re-unifying the branches with Windows 7 but that goal got pushed back to Windows 8.
Perhaps everyone is too stoned from Christmas but 28nm stamping is already approved with GlobalFoundries, TSMC and Samsung.
http://arm.com/about/newsroom/globalfoundries-and-arm-deliver-optimized-soc-solution-based-on-arm-cortex-a-series-processors.php
http://www.tsmc.com/tsmcdotcom/PRListingNewsArchivesAction.do?action=detail&newsid=6181&language=E
http://www.samsung.com/global/business/semiconductor/newsView.do?news_id=1254
Intel took x86 to workstations and supercomputers killing many RISC processors in the process. It'll be fun to see them pull it off again against ARM.
No, it wouldn't. RISC is a superior instruction set. x86 only beat RISC because it was really the only game in town if you want to run Windows, which every non-mac user did. At the time, the desktop was king and made Intel lots and lots of money, which they used to beef up their server offerings. Now we are stuck with x86 with RISC being used only in "closed" architectures like smart phones, consoles and big-iron servers.
I like competition. I'd rather see ARM make gobs of money of designing chips that everyone can improve on than Intel make gobs and more gobs of money selling desktop, server and mobile chips that only they may design, produce and sell.
The final processor line that Intel makes will be the one they are producing when they become the only game in town.
I fully agree. Not only is RISC superior to CISC, it's even turned out to be more optimal than VLIW. After all, remember all the hype about VLIW when Intel & HP first started working on the Itanium? It turned out that that the dynamic analysis part of RISC CPUs that Itanium was going to move into the Compiler, such as branch prediction, register renaming, etc, was just a small portion of the Si, so not much was really saved in terms of real estate there. In the meantime, the much ballyhooed VLIW compilers were all but impossible to write, so that in the end, the advantages of Itanium were minimal. Besides, a lot of the advantages that EPIC really brought, such as large scale parallelism, was implemented successfully in the last Alpha 21364 processor, as well as later POWER processors. In short, there was nothing that VLIW could do well enough to give it the sort of advantage over RISC that RISC had over CISC, or most specifically, the x86 platforms.
However, Intel did manage to knock off RISC by successfully pushing the Itanium vaporware and causing Compaq & HP to end the Alpha & PA-RISC CPUs and migrate to the Itanium. Two of the best CPUs that the industry had were thereby lost. Aside from that, Microsoft played its role in destroying the potential of RISC by systematically ignoring the RISC versions of NT: if Microsoft had ported every, or even the most used Windows applications of Microsoft to the Alpha, or the MIPS, all the companies that based themselves on that - Carrerra, Aspen, Microway, DeskStation, NeTpower, et al would have been pretty successful computer vendors. That is the reason that Intel could catch up w/ RISC - Microsoft did not bother to make RISC versions of NT as successful as Wintel.
Given Intel's fiasco w/ the Itanium, I doubt that they'll dare venture into new adventures w/ new CPU platforms anytime soon. Even X-Scale was not such a success, was it?
Advances in both chip design and software has largely diminished the traditional advantages to RISC design.
For example, one of the longstanding argument for RISC chips was that because the instruction set was simpler (in terms of the computations, not necessarily in terms of having fewer instructions), it was easier to ramp up clocks speeds. So you had DEC Alphas running rings around x86 chips simply because the DEC kit was running at 500Mhz when Intel was barely able to crack 100Mhz. But advances in chip design have largely leveled the playing field here. Clock speeds are similar between CISC and RISC chips these days.
Another one of the advantages in RISC design was the ability to keep the pipeline full. But with improvements in branch prediction, out of order operations, and speculative execution, modern CISC designs are almost always able to keep the pipeline full of instructions.
Not to mention, Intel was able to adapt a good bit of RISC theory in its chips designs. The guts of the modern x86 family are fundamentally different than the days of yore. The x86 instruction set is largely an artificial interface that Intel chips break down into an almost entirely different instruction set internally.
And then there also the improvements in compiler design. Modern compilers are much better at optimization than they were in 80s and 90s. But this leads to the point you make in your second paragraph. That was effectively the argument for VLIW processors. Yet Itanic didn't seem to pan out so well. It would seem that compilers and programmers just aren't clever enough to make VLIW work well (where working well means better performance than non-VLIW chips doing the same computations). As it turns out, the things that can make a compiler smarter can mostly be applied to compilers for both RISC and CISC chips.
Once C became popular, however, this changed. A few of the reasons were
This was just the basic underpinnings of the 'RISC is better' school of thought. Over time, RISC itself developed several techniques, and schools of its own. You had super-scalar processors, that increased the number of registers, pipelines and other hardware in the CPU as a result of saving on the microcode - examples of this were the SPARC and POWER CPUs. You also had super-pipelined processors, that diced the various stages of a pipeline even finer, to enable the CPU to run @ higher frequencies - examples being the initial MIPS I & II processors (up to the R4x00 series) and the Alpha 21064s. Over time, superpipelined processors became more superscalar - like the Alpha 21164, while the MIPS switched to superscalar from MIPS III (R5000 onwards), while superscalar processors became more superpipelined in the quest to bump up their frequencies.
While Intel didn't eliminate microcode itself, it adapted a lot of concepts from the RISC camp, such as multiple registers, pipelines and even superpipelining (Intel called it hyperpipelining). Some companies, like NexGen created RISC processors which had x86 instructions fed in and decoded into internal RISC instructions that got executed. AMD's Athlon - made by the same DEC team that did Alpha after they left DEC for AMD - was their first CPU that didn't have any Intel underpinnings to it, but was a RISC CPU internally, and x86 outside. That was the first time that AMD got an independent CPU design team that weren't just copycats of the x86. And that was the year their fortunes changed.
To make a long story short, the reason RISC had advantages over CISC was due to the preponderance of higher level languages, whereby if a compiler was simply tuned to use certain instructions in an instruction set, and if that processor ensured that those instructions were the ones supported well in terms of performance, then the apps would fly. This marked a shift in the role of compilers in RISC processing as opposed to CISC processing. This concept worked so well that some companies, and ultimately HP decided to take the argument further, using a concept called VLIW (Very Long Instruction Word). The concept here was to have several independent instructions in a program running in parallel, so that you essentially had a multiprocessor within a CPU, and in addition to the usual things that a RISC compiler did - like register renaming, branch prediction and speculative execution.
Only problem - unlike the CISC to RISC, RISC to VLIW hit a point of diminishing returns, as I pointed out in my post yesterday below. Much of the real estate that would be saved by a VLIW was minimal, but the complexity of the compilers was really high. VLIW has been used by some companies and has been found to be fine for some applicati
These power and performance numbers finally match what Intel promised to deliver with Atom in 2008, and it took ARM and AMD kicking Atom squaw in the competitive nuts to get them to deliver. This does not bode well for Chipzilla.