Slashdot Mirror
Intel Core 2 'Penryn' and Linux
An anonymous reader writes "Linux Hardware has posted a look at the new Intel "Penryn" processor and how the new processor will work with Linux. Intel recently released the new "Penryn" Core 2 processor with many new features. So what are these features and how will they equate into benefits to Linux users? The article covers all the high points of the new "Penryn" core and talks to a couple Linux projects about end-user performance of the chip."
Driver problems on a processor compatible with current motherboards?
I seem to remember Intel doing this when they release the 'first' MMX instructions in the pentiums, that time they had actually doubled the L1 cache from 16k to 32k in the new pentiums, but they somehow managed to convince/fool everyone that the performance was as a result of MMX. Very sneaky/clever.
instead of trying to cram extra instructions
Cram? Chip designers get more and more transistors to use every year. I don't believe there's any "cramming" involved.
into an already bloated CISC CPU?
You're about 15 years out of date. The x86 isn't exactly a CISC CPU, it's a complex instruction set that decodes into a simpler one internally. Only the intel engineers know how they added the SSE4 instructions, but based on the comments of the encode/decode guys, these new instructions sound a lot like the old instructions. It's not too hard to imagine that they didn't have to change much silicon around, and maybe got to re-use some old internal stuff and just interpret the new instructions differently.
Anyway, so why not just have a dedicated piece of silicon for this exact purpose? Partly because it'd be more expensive (you'd have to basically implement a lot of the stuff already on CPU like cache, etc), but also because it's just too specific. How many people really care about encoding video? 5% of the market? Less?
Hardware decoding on hardware is already a reality, and has been for some time. GPUs have implemented this feature for at least 10 years. But of course it's generally not a feature that has dedicated silicon, it's integrated into the GPU. If this is the first you've heard of it, it's not surprising. The other problem with non-CPU specific accelerations is they don't ever really become standard, as there's no standard instruction set for GPUs, and ever a GPU maker may just drop that feature in the next line of cards.
In short, specialized means specialized. Specialized things don't tend to survive very well.
AccountKiller
I don't have a reference for this either, but this is the message that Intel regularly conveys to the channel. You can see the usage of this release strategy starting with the later Pentium 4 CPUs and it has continued through the various renditions of the Core series processors.
The name you are thinking of is the "tick-tock model."
/ \
\ / ASCII ribbon campaign for peace
x
/ \
Like an earlier post said, its called the "Tick-Tock" strategy. One upgrade you improve architecture, and then the next upgrade you make the fab process smaller. Its not a bad idea, but two questions to ask is this: Could Intel hit a dead end because 16nm is the last point in the ITRS roadmap nulling this strategy in around 2013? Because once you go even smaller, you are essentially start having gates the size of atoms. And second, once quad core becomes more common will there really be any reason for consumer level products to go beyond that, given the fact very few programs take advantage of 64bit and processor parallelism?
Apple used LLVM to improve the performance of software-fallbacks for OpenGL extensions by a hundred fold in Leopard, and the big part of that was because it was good at optimizing high-level routines depending on the low-level features of the chip, such as Altivec/SSE2 32bit/64bit, PPC/x86 etc. So it stands to reason that, to the extent that SSE4 is usefull, LLVM will make good use of it, just like it did for other extensions.
That sounds pretty practical to me.