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."
In the article, the authors of XviD and FFMPEG, aren't too optimistic about speedups. If video encoding/decoding is the bottleneck, then why not start building motherboards with a dedicated chip specialized for this kind of work, instead of trying to cram extra instructions into an already bloated CISC CPU? Doesn't make sense to me.
Also, an earlier comment that may be useful in this discussion: Why smaller feature sizes (45nm) mean faster clock times.
--
Educational microcontroller kits for the digital generation.
Isn't that their strategy when they use a finer fab process anyway? I remember reading an article (possibly linked from a previous /. submission) about how they had a 2-step development process. When they switch to a finer fab process, they only have incremental, conservative upgrades. Then with the 2nd step, they use the same fab process, but introduce more aggressive instruction sets/upgrades/etc.
I couldn't find the article with a quick Google, but I'm sure someone will dig it up.
makes a lot more sense with these latest processors. Sure the SSE 4 instructions won't be that immediately useful to Linux. They sure as hell will be for OS X Leopard.
x86 has a hella complex instruction set, and it's decoded in hardware, not software. On a computer. So: it's a CISC. A matter of English, sorry, not religion. Sure the execution method is not the ancient textbook in-order single-level fully microcoded strategy - but it wasn't on a VAX, either, so you can't weasel out of it that way. ;)
Of course, the problem isn't with being a CISC, anyway. Complex instruction sets can save on external fetch bandwidth, and they can be fun, too! It was true 25 years ago, and it's still true now. CISC was never criticised as inherently bad, just as a poor engineering tradeoff, or perhaps a philosophy resulting in such poor tradeoffs.
The real point is twofold, and this: first, that the resources, however small, expended on emulating (no longer very thoroughly) the ancient 8086 are clearly ill-spent. While this may have come about incrementally, it could all by now be done in software for less. And second, while don't write assembly code any more, we do still need machines as compiler targets; and a compiler either wants an ISA that is simple enough to model in detail (the classic RISC theory) and/or orthogonal enough to exploit thoroughly (the CISC theory). Intel (and AMD, too, of course; the 64 bit mode is baffling in its baroque design) gives us neither; x86 is simply not a plausible compiler target. It never was, and it's getting worse and worse. And that is precisely why new instructions are not taken up rapidly: we can't just add three lines to the table in the compiler and have it work, as we should be able to do; we can't just automatically generate and ship fat binaries that exploit new capabilities where they provide for faster code, as must be possible for these instruction set increments to be worthwhile.
Consider, for example, a hypothetical machine in which there are a number of identical, wide registers, each of which can be split into lanes of any power of two width; and an orthogonal set of cleanly encoded instructions that apply to those registers. CISCy, yes, but also a nice target that we can write a clean, flexible, extensible compiler back end for. Why can't we have that, instead? (Even as a frikkin' mode if back compatibility is all and silicon is free, as you appear to argue!)
It shouldn't be a question of arguing how hard it is or isn't for the Intel engineers to add new clever cruft to the old dumb cruft, but one of what it takes to deploy a feature end-to-end, from high level language source to operations executed, and how to streamline that process.
So, sure, give us successive extensions to the general-purpose hardware, but give them to us in a form that can actually be used, not merely as techno-marketroids' checklist features!
Since 2002 we've been hearing about LLVM. It sounds as something generally "vaguely very cool TM", so when you download it it's a bunch of "optimization strategies framework, etc, etc". Still nothing practical though. When you can compile the kernel with LLVM, it works and it is not 50 times slower than gcc, wake me up. It seems that in the best case scenario LLVM would require at least 7 more years of heavy development before it gets there, if ever at all. If you want to invest in hot airs and arrange your future decissions on the existance of this hypeware, fine. Yawn.
Yeah, at a certain point you run up against the uncertaintly principle, but I don't think that is supposed to be anything near an issue until the later half of this century. The first limit that processors are going to hit is frequency - an electron can only move three feet during a cycle on a three gigahertz processor. While that's plenty, there are going to be problems to be resolved whenever data can't be transferred from memory in the space of a single cycle. This is unrelated to the relative speed of the memory, as I'm talking about the speed of the wires rather than the latency of various components.
To support what you say, Microsoft said that Vista and Windows 2008 Server where supposed to be the last OS to be available in 32-bit versions.
"You superiour intellect is no match for our puny weapons" - The Simpsons