My guess is nothing on the desktop. Hyperthreading & OOE should both be going away (as core counts rise). That's why it is curious that this chip only got rid of one, when they both use the same hardware on the chip.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Intel's Silverthorne (Ultra-Mobile Processor) Previewed
- Thread starter MacRumors
- Start date
- Sort by reaction score
My guess is nothing on the desktop. Hyperthreading & OOE should both be going away (as core counts rise). That's why it is curious that this chip only got rid of one, when they both use the same hardware on the chip.
I'm going to brush up on my OOOE and hyperthreading knowledge as well. From my skimming they both want to prevent stalls from slowing down the usage of execution components to complete a task.
http://www.google.com/search?q=hyperthread nehalem
It should trickle down from the Xeons just like on Core 2 and Netburst.
Yeah, rumoured by people who haven't got a single clue in the universe about what Silverthorne is competing with in the ARM camp. I've written it all before - too large a chipset, too power hungry still, not enough integration, ARM is well understood by Apple, ARM is good enough, etc.
An Apple tablet? Yes, maybe Silverthorne will be good there. Or a real Apple subnotebook. Or the next Apple TV hardware revision. Not the iPhone. Not the iPod Touch.
SMT (the real term for Intel's HyperThreading) works really well on in-order CPUs - lots of bubbles in the pipelines to fill.
See Sun's Niagara CPU for a rather extreme implementation. Niagara 2 will have 8 in-order cores with 8-way SMT and can do 64 threads simultaneously and achieve very good figures. Not so hot in single-threaded tasks though.
0.05W to 0.5W including cache, integrated 3D graphics (Imagination I expect, so that's a Dreamcast in your iPhone - it's PowerVR essentially but modernised - this is very simplified).
All this is also in a package that's a centimetre or two on a side - indeed I believe the iPhone CPU also has its 128MB of RAM in the package.
Primary power draws in the iPhone are probably the display and the wireless.
I think the iPhone has 3 ARM CPUs inside - the main processor (ARM11), the wireless (ARM9), and the baseband.
Yes, instructions from two or more threads can and do interfere
Actually, Amdahl has a valid point, and the tone of your response is inadequate. Just as data dependencies exist between different instructions in the same thread, so do they exist between separate threads. It is the fact that these data dependencies are much easier to resolve that makes hyper-threading easier to implement (and consequently require less die space as well): As each thread has its own register set, data dependencies in between threads necessarily involve memory addresses. So one easy solution is to make both thread pipelines perform all memory accesses through the same, synchronized cache. Actually, the cache does not even need to be fully synchronized, i.e. a read-modify-write operation does not necessarily have to lock the cache line until it completes. It is sufficient to synchronize the cache at so-called memory barriers (Intel usually calls them memory fences) but that is another and potentially long story so I'll leave it at that.
By the way, contrary to what your usage of the word "process" suggests, hyper-threading can be used to execute two threads of the same process as well. Processes are an OS-level concept anyway - the CPU does not care which threads (or "tasks" in conventional Intel parlance) belong to which process.
Actually, Amdahl has a valid point, and the tone of your response is inadequate. Just as data dependencies exist between different instructions in the same thread, so do they exist between separate threads. It is the fact that these data dependencies are much easier to resolve that makes hyper-threading easier to implement (and consequently require less die space as well): As each thread has its own register set, data dependencies in between threads necessarily involve memory addresses. So one easy solution is to make both thread pipelines perform all memory accesses through the same, synchronized cache. Actually, the cache does not even need to be fully synchronized, i.e. a read-modify-write operation does not necessarily have to lock the cache line until it completes. It is sufficient to synchronize the cache at so-called memory barriers (Intel usually calls them memory fences) but that is another and potentially long story so I'll leave it at that.
By the way, contrary to what your usage of the word "process" suggests, hyper-threading can be used to execute two threads of the same process as well. Processes are an OS-level concept anyway - the CPU does not care which threads (or "tasks" in conventional Intel parlance) belong to which process.
out of order execution was invented to prevent idle states on processor when cache misses occurr (the processor asks data to the memory controller and this is a longer path than their neighbourhood caches).
in OOE the instructions are stacked when waiting for that, and thus, new instructions with no direct implication can be processed through the pipeline.
theory on OOE drop:
well, in the new range of mobile devices the processor is very close to the memory chips, the memory is faster and the tipical behavour of these operating systems don't require too many context switches along time (saving and restoring registers when switching processes)
in OOE the instructions are stacked when waiting for that, and thus, new instructions with no direct implication can be processed through the pipeline.
theory on OOE drop:
well, in the new range of mobile devices the processor is very close to the memory chips, the memory is faster and the tipical behavour of these operating systems don't require too many context switches along time (saving and restoring registers when switching processes)
Somebody help me here, but didn't I hear something about Intel offering options of including WIFI, Graphics, & 3G built into these chips?
I can see them adding an additional product like that to serve more as the Next Gen Newton, but I don't think people want their phones any bigger. I would like them to make the iPhone thinner and smaller, as long as the screen stays the same size.
You're fine. I don't think it will see any hardware changes until the Holidays. The iPod Touch and iPhone are meant to last longer and be updated with software mostly until there are obvious hardware benefits coming.
So should we be expecting a new iPhone as early as April 08 or will we have to wait for the silverthorne processor?
Actually, HyperThreading was always a win on a single CPU (that is, a single core system). It would sometimes be quite a bit faster, more often a little bit faster, but never slower.
Hyperthreading on a dual-socket system, however - not so much a good thing. If you always had lots of threads computable, it would help (server-land).
If you had two computable threads on a dual-socket single-core system (two sockets, two HT chips, four logical CPUs), then HT could hurt if the OS scheduled the two threads on the same socket.
When that happened, it would be slower than if they had been scheduled one on each socket.
what's the over/under?
I wouldn't bet on seeing a new iPhone by April. We'll likely see more incremental software updates to go along with the first wave of SDK produced goodies. Also thinking of the s***storm that was kicked up when the price drop occurred, I'd hate to hear the noise if a new version of the iPhone was released before the early adopters were even one year into their contracts without the offer of a VERY attractive upgrade path. They won't hang back and let it get too stale, but I think Apple is going to tread somewhat lightly as far as iPhone revisions go . . . perhaps a little too lightly for people waiting on an updated iPhone.
I'm guessing we'll more likely see something in the second half of the year. Again, I'm only guessing.
I wouldn't bet on seeing a new iPhone by April. We'll likely see more incremental software updates to go along with the first wave of SDK produced goodies. Also thinking of the s***storm that was kicked up when the price drop occurred, I'd hate to hear the noise if a new version of the iPhone was released before the early adopters were even one year into their contracts without the offer of a VERY attractive upgrade path. They won't hang back and let it get too stale, but I think Apple is going to tread somewhat lightly as far as iPhone revisions go . . . perhaps a little too lightly for people waiting on an updated iPhone.
I'm guessing we'll more likely see something in the second half of the year. Again, I'm only guessing.
So in other words Apple would shoe horn in a fourth ARM if the power was needed before they would pop a sliverthorn in to the iPhone.
I thought the silverthorn was to replace the chip intel currently offer for UMPC or MIB applications and most of those are what 7inch and what 4 times the volume of the iPhone.
I think your right if apple use this it will be in something between and iPhone and a MacBook Air. Then again maybe it's not the processor that is the shortfall. What is the best resolution 7inch screen around?
You could see them waiting for till they can get 180, 200dpi.
They achieve the same result, but are very different in implementation and cost.
OOE is expensive in circuitry, as the processor has to decide what can and can't be out of order. This isn't exactly easy to build in fixed logic design. Easy in software, hard in EE.
Hyperthreading, on the other hand, is easy in implementation. The downside is that you now have to track two sets of registers on the die, but the upside is that by doing this, your insertion logic is very simple.
For both the PS3 and 360 CPUs, they had hyperthreading (under a different name), and lacked OOE... but suddenly freed up quite a bit of space on the die for specialized cores, more cores, etc.
It would never be slower /overall/, but with Hyperthreading turned on, and how it balanced between processes... it did some noticeable perf damage. Single-threaded apps like games took a performance hit because there was other code balanced onto the same core taking up cycles it would normally use.
Gamers tended to turn off Hyperthreading or get chips without it to prevent background processes from siphoning off performance from the single process.
Unless you desperately need one (read: don't have an iPod), I would wait until a 32GB model comes out. With the prices that USB flash drives are at, I'm really surprised that the iPhone and iPod Touch don't have more memory already. Don't they all use the same type of memory?
I will also tell you that cnet said the Touch's display is nowhere near the uber-high quality that the iPhone's is. Might be better to wait for the 2.0 version. First-gen products usually have plenty of bugs to work out. It took Apple until either the 4th or 5th generation to put the click-wheel on iPods.
I still have the 3rd gen iPod, which is the first iPod touch really. It has no moving parts (externally). Not even a click. Just a touch. I love it. Not sure why they went back to the wheel.
um, I think that Silverthorne consumes MORE power than the current iPhone-CPU does....
Not really. Like others have said, it never really lowered performance (I think I saw benchmarks that showed 2-3% reduction at most, but that might be statistical noise). At best, HT improved performance by 10-20%. And in many ways, HT makes more sense today, since multi-core CPU's are the norm, so more software is being written that is multithreaded, so the benefits might be more apparent. Now, the downside of Hyperthreading was that it increased power-consumptiosomewhat, but Intel might have that under control these days.
And, we must not forget the fact that hi-end processors routinely use Hyperthreading (well, that's Intel's brand-name for it, but still). Suns Niagara uses it, Itanium uses it etc.
I'm sorry, but your argument makes no sense. Yes, Apple has changed architectures in the past. So? How exactly is 68k a "dead-end"? How long did Apple use it? How is PPC a "dead-end"? They used it for a LONG time.
Yes, things change. But that does not mean that they things they used before is suddenly a "dead-end". Hell, Intel has for all intents and purposes moved from x86 to x86-64, does that mean that x86 was a "dead-end"? And even if current iPhone/iPod touch was the only device Apple ships that uses Arm, so what? How exactly would that change in CPU affect you?
And like I said: I don't think that Silverthorne is destined for the iPhone. It consumes more power, and the one benefit it has is that it uses x86. But in devices like iPhone, that feature is more or less useless. I'm thinking devices like AppleTV and maybe a device that sits between iPhone and a laptop.