Intel Demos Phone and Tablet In New Mobile Chip Push
holy_calamity writes "Intel is making another assault on the mobile processor market, showing off a prototype phone and a tablet using its newest mobile processor Medfield. The company claims that products based on the chips will appear in the first half of next year. There's reason to believe that Intel might get somewhere this time. Its chipsets traditionally comprise three separate chips, a design that guzzles power. Medfield introduces an all-in-one chip, mirroring the power efficient design of the ARM-based chips that run smart phones and tablets in the market today."
Surely, it is no longer the "Intel Inside" mantra we had become so used to seeing and hearing in the late 90s and early 2000s. Agree?
I think it is known as System on Chip, SoC.
Why can' they expand the market for powerful desktop/business computers, instead of trying to push their inefficiency into people pockets?
... I eagerly scan the article to see if the predictions here were true: http://www.tealdragon.net/humor/startrek/power.htm
"It's that miserable 80986 with the 512K bit bus multiplexed down to one pin."
That's so Intel...
Work like no one is watching. Dance like you've never been hurt. Make love like you don't need the money.
That's a bit of a cheap shot. Increased component integration has been a driving force for longer than Intel has been a company, and Intel has been as much of a driving force as anybody else. In fact Intel should excel at system-on-a-chip, since it's all about getting lots of transistors on a small piece of silicon, something they happen to be pretty good at.
and
So it looks like a bit of incremental leapfrog (if that), not some kind of breakthrough. Meh.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
Faster than the current top 3. Hmm not really surprising since you are demoing something 6 months out. What does ARM, or Apple have coming up in 6 months? Still good to see Intel come out with a much stronger offering.
Since Intel and Samsung are the driving forces behind Tizen, a new "open" Linux project for phones and tablets, maybe we will see Tizen running on this processor next year? When I say "open" I mean as in door; full access without jail breaking. Although the details about Tizen are still murky, at best.
Or maybe Mer, the folks who are picking up where Meego left off, could use this. But they need to get a hardware manufacturer on board.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
If it's Windows 8, penetration may be in the single digits. In the tablet marketplace, Microsoft, and by extension Intel based processors, are not major players. It's not just the power consumption. I've heard a rumor that Android would be ported to X86, but how will that work, I wonder? Would there be a separate marketplace? Development requirements to compile and test on two different architectures?
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
That's the question on everyone's mind now.
That's a bit of a cheap shot. Increased component integration has been a driving force for longer than Intel has been a company, and Intel has been as much of a driving force as anybody else. In fact Intel should excel at system-on-a-chip, since it's all about getting lots of transistors on a small piece of silicon, something they happen to be pretty good at.
Except that full system-on-a-chip designs, including X86 versions courtesy of AMD's Geode, have been around quite a while, but Intel has seemed hesitant to actually do it.
Though I will point out that it's cyclical... at some point, people will start saying "Hey, why don't we make that bit there modular, so we can upgrade is separately without having to redesign the rest of the chip?".
If you have ever touched the Android SDK, you learn very quickly that doing development on a desktop is rather painful. The main reason is their dev test environment completely emulates an ARM processor (on top of your desktop x86 system), which is extremely CPU intensive. If we get android running x86 (there are already a number of people out there working towards this), we can then do our testing in an x86 based simulator, which will be much easier on desktop system.
Its not what it is, its something else.
When someone shows it has battery life comparable to the current dual-core ARM A9 SoCs, then they will have something to talk about. Until then, it's just a PR pipedream.
make imaginary.friends COUNT=100 VISIBLE=false
Does the 8051 count? *tongue in cheek*
though it's interesting that Intel hasn't done much in the way of SoC until recently - they've traditionally kept the CPU quite separate from support chips. from a fab perspective, this makes a certain amount of sense, since the cpu needs transistors that perform quite differently (voltage, drive, frequency, etc) and the limited SoC integration present in, say, sandybridge, is mixed in performance (good memory and pcie controllers, mediocre gpu).
the real question with intel mid SoCs is whether they can drive down power to ARM levels. my smartphone has a 6.11 W-hour battery, and it better last (idle) for at least two days, or one day with reasonable activity. idle-on-net needs to be 1W...
Dalvik compiler for x86 and get it to be as fast as they can.
Should be do-able, since they have experts in compiler
technology, AND can drop in an instruction here or there
if it looks as if it will really speed things up. This is hinted
at in the article.
How many times Intel has tried to compete against Risc?
First, ðere was ðe iAPX 432. I never saw any use of it.
Ðen ðere was ðe i80860, today remembered for being ðe demonstration vehicle to Microsoft OS/2 3.0 NT.
Next try, ðe i80960, was actually succeßful — in printers, network and I/O controllers.
Ðen we had Merced, later named Itanium, AKA Itanic, ðe biggest flop around.
Intel actually ditched perfectly fine StrongARM and Alpha architectures it bought from Hewlett Packard because, as Digital Equipment Corporation’s inheritance, Intel got a bad case of ‘Not Invented Here’ syndrome over ðem.
Forgive me, but colour me sceptic ðis time around.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
The prevailing difference is it isn't an ARM chip. It is an x86 chip, meaning off-the-shelf x86 programs and OSes should run on it. Getting an x86 processor below the performance/power threshold of an ARM chip (while keeping it small enough to fit in a phone) is a pretty major breakthrough.
Michelle from quick iphone unlock
> It's true that Intel hasn't achieved great success with it's own RISC designs, but what about the times that Intel competed using its CISC designs against:
[]
> It's also worth noting that all of the modern ARM-based SoCs that Medfield will compete against are CISC designs, not RISC, so I guess my list doesn't even matter :-/
Yes, but all ðese were hampered in ðe desktop by ðe prevalence of binary, proprietary software. While binary, proprietary software also dominates ðe mobile market, it is compiled against iOS and Android, where it is Intel, not Risc, which fights an uphill battle.
Ðat, and talking about a proceß-derived advantage in a not yet ðere product is easy. Most probably ARM (and MIPS) will be already ðere if and when Intel hits ðe shelves.
Now, how is ARM Cisc? Last time I checked, it stood for Advanced Risc Machines has technology subverted the acronym?
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
How many times Intel has tried to compete against Risc?
First, ðere was ðe iAPX 432. I never saw any use of it.
Ðen ðere was ðe i80860, today remembered for being ðe demonstration vehicle to Microsoft OS/2 3.0 NT.
Next try, ðe i80960, was actually succeßful — in printers, network and I/O controllers.
Ðen we had Merced, later named Itanium, AKA Itanic, ðe biggest flop around.
Intel actually ditched perfectly fine StrongARM and Alpha architectures it bought from Hewlett Packard because, as Digital Equipment Corporation’s inheritance, Intel got a bad case of ‘Not Invented Here’ syndrome over ðem.
Forgive me, but colour me sceptic ðis time around.
LOL. Didn't you hear? Intel won the last round of the RISC vs. CISC wars with a knockout blow. See: Xeon.
I just want to see if I understand this correctly. You're suggesting that the world's biggest and most powerful processor company who has shown repetitively that they can produce the processors capable of the greatest performance per watt for general purpose computing shouldn't be able to produce an efficient processor as well?
I'm just wondering... do you really believe that the inefficiency you're talking about is related to an instruction set? Really? It's actually like saying that people are less efficient if they speak Mandarin as opposed to English though maybe more efficient if they speak Spanish. There are obviously advantages and disadvantages of each instruction set, but in truth, all a processor is is a device capable of processing a list of instructions.
Now, to compare it to something more intelligent... if you can cope with intelligence... I hope so.
It is possible to write directions to the your house for someone. Assuming that you have a starting point, you can provide instructions with multiple levels of detail. You can put a great deal of effort into every minute detail and even over compensate. On option you have is :
"Try every single road in this town until you find a blue house with a purple roof and a green football flag on the lawn".
The alternative would be
"Take this road to this road. You'll recognize this road because of the gas station at the corner on your left side. Turn right at this intersection." and so forth.
Which is more efficient? It doesn't matter what language or instruction set you write it in... what matters is the quality of the instructions you provide.
Desktop operating systems which are generally what's run on x86 processors tend to be written by people who know they have access to what feels like unlimited CPU power. The operating systems focus entirely on user experience and not specifically on efficiency. If an OS is designed to be efficient and usable, then there's much to be gained. At this point in time, we're limited to pathetic half breeds like versions of linux that are so covered in band-aids to make it run on small devices you almost want to cry, Symbian which wasn't functional, but was power efficient. Windows CE which was the same... a few others and soon a version of Windows 8 that will be similar to how Linux has been bastardized to run on small devices.
Android has had some of the greatest work done on it to make it more efficient. To compensate for the obvious short-comings in the Linux kernel, Android implements itself on top of something similar to Java which in effect makes it more power efficient. It's not that Java itself or Java programmers are more efficient. It's that by having a virtual machine layer that performs more "traffic control" on the system, power efficiency can be more easily achieved. This would be true for an MSIL or LLVM virtual machine as well. The extra layer makes it so that the virtual machine can do things like shut down or decrease the priority of a given virtual processor as a software function and makes it so that software developers don't have to instrument their apps to achieve it.
The next really big difference between Android/IOS and a desktop OS is simple. All the applications written for these OSes are designed to be run on telephones or "power efficient devices". You could in theory put these operating systems on any processor and their power performance will be quite good.
So... while I'd like to hear from you why you think Intel can't do power efficient, I doubt you'd have much to offer other than stupid buzzy wordy kinda snips.
Try learning something
Now, how is ARM Cisc? Last time I checked, it stood for Advanced Risc Machines has technology subverted the acronym?
ARM chips since ARMv7 have supported the Thumb-2 instruction set, which has 32-bit instructions with CISC features like making an optional left shift available to most instruction, and allowing each comparison to be followed by up to four conditional statements. It's what most JIT and my compilers target now, IIRC.
While binary, proprietary software also dominates the mobile market, it is compiled against iOS and Android, where it is Intel, not Risc, which fights an uphill battle.
It's absolutely true that it's Intel whom must the uphill battle here. The fact that many Android applications are compiled to DEX, and the emergence of HTML5 runtimes offer some relief. I still think that despite Intel's dominance of the desktop market, it faced an uphill fight in the server arena as well, where it was competing against OSes which generally did not (yet) run on IA, using Linux and Windows.
ARM chips since ARMv7 have supported the Thumb-2 instruction set, which has 32-bit instructions with CISC features like making an optional left shift available to most instruction, and allowing each comparison to be followed by up to four conditional statements. It's what most JIT and my compilers target now, IIRC.
Ðat is quite different from being a Cisc proceßor in ðe mobile market, being able to choose some Cisc instructions wiðout carrying ðe full Cisc legacy is an advantage. And ARM has chosen ðe Thumb 2 instructions not to go back to Cisc, but to achieve a code density which is a furðer advantage over anything Intel can do wiðout throwing out its only real competitive advantage, which is ðat people are familiar with ðe x86 instruction set. Not ðat it buys Intel much in a market ðat will not use any legacy binaries, nor hand code much aßembly.
It's absolutely true that it's Intel whom must the uphill battle here. The fact that many Android applications are compiled to DEX, and the emergence of HTML5 runtimes offer some relief. I still think that despite Intel's dominance of the desktop market, it faced an uphill fight in the server arena as well, where it was competing against OSes which generally did not (yet) run on IA, using Linux and Windows.
Not ðe same situation at all. In servers, Intel has only really displaced Unix and Risc where MS Windows reached, or where x86 systems could be deployed wiðout ðe full feature set expected from Risc. In any case, Intel was carried by its traditional OSs. Now, it must adapt to new OSs, as even MS Windows Phone is quite a different beast from its desktop version, and all but irrelevant anyways.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin