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.
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.
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
think of all those amplitudes not being modulated.
this is a terrible, terrible loss for America.
For sure, yes, it's a SoC, but I'm still going to wait for a complete "on the shelf" system to make an appearance before holding my hopes too high. Leaked releases are about as useful as "New solar cell technology yields 50% more efficiency" announcements.
What is interesting is that they only mention the elevated power consumption in relation to video playback (720p) which is something that'd likely be handed off to a dedicated section of silicon, not something done in the general purpose CPU core. Hopefully we can get some more comprehensive data soon so we can all stop speculating.
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%.
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).
Well, the limiting factor is quite certainly backwards compatibility.
The architecture itself very possibly cannot compete with ARM on low power... no matter what the "best chip designers and process" can bring to the table.
I think it's getting to be time to finally retire x86. It'll be hell to bring a new architecture to market... but what's the alternative? Microsoft is dying. Apple is starting to make their own chips.
They probably do have the best people and starting fresh they could very likely do amazing things.
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.
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.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
Every Windows release from the NT line since NT 3.1 has run on at least one RISC architecture.
Bloodthirsty bastard, aren't you? Killing off the competition is fun?
I haven't liked Intel very much since I read the first story of unethical business practices. Intel doesn't rank as highly on my shitlist as Microsoft, but they are on it.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
RISC isn't an instruction set - it's a design strategy.
RISC = reduced instruction set computing
CISC = complex instruction set computing
The idea of RISC (have a small highly regular/orthogal instruction set) goes back to the early days of computing when chip design and compiler design wasn't what it is today. The idea was that a small simple instruction would correspond to a simpler chip design that could be clocked faster than a CISC design while at the same time being easier to compile optimized code.
Nowadays advances in chip design and compiler code generation/optimization have essentially undone these benefits of RISC, but the remaining benefits are that RISC chips have small die sizes hence low power requirements, high production yields and low cost, and these are the real reasons ARM is so successful, not the fact that the instruction set is "better".
What RISC platform did XP, Vista and Windows 7 run on? XP had support for Itanium, but that's not a RISC platform. Vista and Win7 only support 32- and 64-bit x86. So.. It seems you are wrong in your statement.
- Henrik
- when the Shadows descend -
> 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
Modern ARM processors aren't pure RISC processors. Most ARM code is written in Thumb-2, which is a variable length instruction code just like x86. Back in the 90s when transistor budgets were tiny, RISC was a win. When you only have a hundred thousand gates to play with, you're best off spending them on a simple pipelined execution unit. The downsides of RISC has always been the increased size of the program code and reduced freedom to access data efficiently (ie with unaligned accesses, byte addressing and powerful address offset instructions). With modern transistor budgets it is worth spending some gates to make the processor understand a compact and powerful instruction set. That way you save more gates in the rest of the computer than you spend doing this (ie in the caches, databuses and RAMs).
As a result of all this, in some ways, ARM chips are evolving to look more and more like an Intel x86 design. I'm still a big fan of ARM though. Intel will have a long way to go to compete on price, even if they can compete on power.
The first x86 processor, the 8086, only had 29,000 transistors total, whereas this new chip uses over 34,000 times that many (a billion) just for DRAM, so how much complexity can x86 really be adding?
The 8086 was a 16-bit processor that could only address 1 MB of RAM (split up into 64k segments) with no support for virtual memory, didn't have any floating point hardware let alone stuff like SSE, and took an awfully large numbers of clock cycles to execute each instruction by modern standards. If you want something capable of actually running modern applications, you're looking at a lot more complexity.
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?
Everyone says this, but really, CISC is more efficient. CISC code is more compact than RISC code, which helps cache hit rates. Additionally, the most used opcodes tend to be the shortest.
Actually, this is the everyone-says-it-but-it's-wrong thing. At least, when the RISC in question is ARM. Most 32-bit ARM instructions are 16-bits in Thumb-2 (ARMv8 doesn't have a Thumb mode yet, so all 64-bit instructions are 32 bits). Even without using Thumb-2, I find I get about the same instruction density for both hand-written and compiler-generated assembly for ARM and x86, often with ARM code being 5-10% smaller.
For example, ARM code supports predicated instructions so a simple if statement can be just a single predicated instruction on ARM while it would need to be a branch on x86. ARM addressing modes are also very rich, which was the place where CISC usually won a lot over RISC. Things like computing the address of an array or structure element can be half a dozen instructions on a traditional RISC architecture, but just one on ARM (x86 is almost as good, but seems to have a lot of addressing modes for things you don't use and, until x86-64, miss a lot of ones that you did want).
But, more importantly, ARM instruction encodings are very simple. Decoding the opcode is just a mask, as is selecting the registers. This means that the die area used by the instruction decoder is much smaller. This is really important in low power applications, because execution units can employ all sorts of power saving techniques when they're not in use, but the instruction decoder is always on and always in use (except on the Xeons, where micro-ops are cached in loops, but the micro-op decoder in the Xeon is about as complex as the real instruction decoder in an ARM chip so that doesn't actually save anything relative to ARM).
I am TheRaven on Soylent News
Before a typical workstation class CPUs had evolved complex instruction sets. There had not been enough focus on measuring the frequency of use of the various features of the instruction set. When people started analyzing this (ie Patterson and Hennessy) they showed that the vast majority of software spent its time executing code from a tiny fraction of the instruction set. Obviously if you make those common instructions execute much faster, you can afford to remove the rarely used instructions and make the compiler generate a few simpler instructions in their place. Once these complex instructions were removed, it became easier to implement a well balanced instruction pipeline on a single chip. This was a big win. The ARM2 achieved 4 MIPS @ 8 MHz. Compared to a Motorola 68000 which was about 0.6 MIPS at 8 MHz. The chips were a similar cost in 1987. You could have got comparable performance from a 386 at that time, but it would have been much more expensive.
I'm not entirely sure why contemporary CISC designs failed to achieve good pipelining. I suspect that _correctly_ implementing a CISC instruction set back then was difficult even without considering performance. The digital design tools and methods of the time were very hard to use. Removing most of the instruction set freed up the digital designer's head so they could concentrate on performance.
By the 2000s though, it was perfectly possible to implement a pipelined CISC processor. One way to do this is to implement a RISC core with a front end that translates CISC instructions into RISC ones. This is what Intel did. The number of gates in the translation logic is significant, but nothing like as large as the number in the L1 and L2 caches that are integrated onto the die these days. The code density in x86 instructions is probably 25% better than a typical RISC instruction set. Therefore you can make the program caches 25% smaller. You probably save enough gates doing that as it cost to implement the translation logic. Another nice advantage of the translation layer is you can change the design of the RISC core whenever you like and no software needs to be ported to the new design.
My day job is R&D on the Kalimba DSP core used in various SOCs designed by Cambridge Silicon Radio. We've just added a translation layer front end to the core to implement a more CISC like instruction set. This improves code density by over 30% and therefore reduces the program ROM on the SOC by 30%. This reduces the overall cost of the SOC. And there's no performance penalty. For DSP like tasks our core is 2-10x higher performance per dollar and per watt than competing ARM designs.
My prediction is that ARM will hold on to the mobile market no matter how hard Intel try. Intel's fabs cost too much to run. TSMC do a much better job. I predict that ARM will gradually take the server and desktop market away from Intel.