Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Intel Core 2 'Penryn' and Linux

Posted by CowboyNeal on Thu Nov 15, 2007 09:43 PM
from the two-great-tastes dept.
Intel Software Linux Technology
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."
+ -
story

Related Stories

Submission: Intel Core 2 "Penryn" and Linux by LHoAugustus (574819)
[+] Hardware: Details of New Intel Dunnington and Nehalem Architectures Leaked 147 comments
Daily Tech is reporting that details about Intel's new processor models were leaked over the weekend. Both the six core Dunnington and Nehalem architectures were featured in this leak. "Dunnington includes 16MB of L3 cache shared by all six processors. Each pair of cores can also access 3MB of local L2 cache. The end result is a design very similar to the AMD Barcelona quad-core processor; however, each Barcelona core contains 512KB L2 cache, whereas Dunnington cores share L2 cache in pairs. [...] Nehalem is everything Penryn is -- 45nm, SSE4, quad-core -- and then some. For starters, Intel will abandon the front-side bus model in favor of QuickPath Interconnect; a serial bus similar to HyperTransport."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Intel Core 2 'Penryn' and Linux 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Perspective (Score:5, Insightful)

    by explosivejared (1186049) <hagan.jared@g m a i l .com> on Thursday November 15 2007, @09:51PM (#21373865)
    "There are some new instructions that could be more convenient to use in some special cases (like the new pmin/pmax instructions). But these will have no real performance benefit."

    "So we do not plan on adding SSE4 optimizations. We may use SSE4 instructions in the future for convenience once SSE4 has become really widely supported. But I personally don't see that anytime soon..."

    I think that puts the hype over penryn into perspective. There are some nice improvements energy leaks and such, but it's nothing revolutionary.

    • Re:Perspective (Score:5, Interesting)

      by SpeedyDX (1014595) <speedyphoenix@@@gmail...com> on Thursday November 15 2007, @10:32PM (#21374157)
      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.

      • Re: (Score:3, Informative)

        by DaveWick79 (939388)
        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.

      • Re:Perspective (Score:5, Informative)

        by wik (10258) on Thursday November 15 2007, @11:02PM (#21374377) Homepage Journal
        The name you are thinking of is the "tick-tock model."

      • Re: (Score:2, Informative)

        by asm2750 (1124425)
        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 consu

        • Re:Perspective (Score:4, Insightful)

          by DaveWick79 (939388) on Thursday November 15 2007, @11:46PM (#21374725)
          I believe that by the time Quad core becomes mainstream, i.e. every piece of junk computer at Buy More has them, that 64 bit apps will also be the mainstream. By 2010 every computer sold will come with a 64bit OS, that will emulate for 32 bit programs but all the new software being developed will be transitioning to 64 bit.
          Can CPU performance hit a threshold? Sure it can. But maybe by then they will be integrating specialty processors for video encoding/decoding, data encryption, or for file system/flash write optimization, onto the CPU die. At some point nothing more will be required for corporate america to run word processors and spreadsheets, and tech spending and development will shift to smaller, virtual reality type applications rather than the traditional desktop. I think we have already reached the point where the desktop computer fulfills the needs of the typical office worker. The focus shifts to management & security over raw performance.
        • 'cause, you know, four cores should be enough for everybody. ;-)
      • Take a look at this old image of the Intel roadmap [imageshack.us].

        Also, Intel has a tech page [intel.com] where they describe this 2 year cycle.

      • I am impressed with Intel's 45nm Core 2 shink improvements, already, at 5-10% boost per clock. And this is just their first Penryns. Intel has really turned things around, AMD has some catching up to do.. 2008 will be interesting.
    • There are some nice improvements energy leaks and such, but it's nothing revolutionary.

      That's true for sufficiently brain-dead definitions of "revolutionary." Hafnium based High-K transistors are revolutionary. Instruction throughput isn't everything. Manufacturing technology needs breakthroughs too. Or did you see no point in the continuous shrinkage from 100 microns down to where we are now?
    • That isn't at all surprising, I remember AMD's 3dnow, and cyrix's extensions, and how they were supposed to revolutionize things. In the end, neither did very well, and didn't ever actually live up to the hype.

      I remember when Unreal was released, it had software rendering via 3dnow, and it was far from satisfactory, and not just in resolution, turning that down still led to problems.

    • I think that puts the hype over penryn into perspective. There are some nice improvements energy leaks and such, but it's nothing revolutionary.

      Improvements in fabrication technology have nothing to do with improvements in the ISA, beyond the extent to which the ISA relies on the performance provided by the process. The process improvements in Penryn are revolutionary. 45nm on hafnium gates with a whole slew of other process changes needed to make that work is something that five years ago wasn't even believed possible - I recall gloom-and-doom predictions that the brick wall was at 65 nm.

      Practically, Penryn may be an incremental step, but the pro

      • Hard drives could also be improved. If you had intelligent drives, you could place the filesystem layer in an uploadable module and have that entirely offloaded to the drive. Just have the data DMAed directly to and from the drive, rather than shifted around all over the place, reformatted a dozen times and then DMAed down

        Uhh what? Just a couple of lines above you said CPUs were overpowered, and now you want the filesystem code to run on the hard drive ? Specialized hardware maybe faster but which filesystem are you gonna have running on your hard disk? NTFS? ext3? ZFS? Reiserfs?

  • If video encoding/decoding is the bottleneck... (Score:5, Interesting)

    by compumike (454538) on Thursday November 15 2007, @09:51PM (#21373869) Homepage
    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. [slashdot.org]

    --
    Educational microcontroller kits for the digital generation. [nerdkits.com]

    • Re:If video encoding/decoding is the bottleneck... (Score:5, Insightful)

      by 644bd346996 (1012333) on Thursday November 15 2007, @09:59PM (#21373911)
      The place for hardware decoders is on the graphics card. Hence the reason why Linux needs to use the CPU.
      • One could argue that the place for graphics cards is on the CPU. What else are you going to do with all that extra silicon real estate?

        • Re: (Score:3, Interesting)

          by 644bd346996 (1012333)
          Some workloads benefit from vector processors, and some don't. For now, it is best economically to keep vector co-processors separate from CPUs, and use the advances in chip tech to lower power consumption and add more cores to the CPU.

          For example, many server workloads are handled best by a chip like Sun's UltraSparc T1, which doesn't have any floating point capabilities worth mentioning. People running that kind of server wouldn't buy a Xeon or Opteron that had a 600M-transistor vector processor. It's a h
          • In that case, it is much more economical if you can upgrade the vector processor without throwing away a perfectly good CPU.

            Is it? How much does that slot, bus, southbridge, etc., cost? CPUs are cheap! Certainly cheaper than most graphics cards. And the proximity to L1/L2 cache and computational units might make for some interesting synergy.
            • Every two years or so, when you goto upgrade, there is a new socket design or some limitation with the existing north bridge/south bridge chipsets that require you to buy a new main board anyways. So some of the components you listed might be spent already.

              With PCI express and the bandwidth it can handle, it might be the best option to put it either on a separate daughter card or allow a separate video card to be installed and dedicated specifically to this. Either way, processor, daughter cards, or video c

      • The place for hardware decoders is on the graphics card. Hence the reason why Linux needs to use the CPU.

        Why? If you're going to be displaying the video on screen, then yeah, it makes sense to have it on the graphics card. But why can't we just have a general-purpose codec card? What if I don't want to display video, I just want to encode/decode it? Surely this is such a fundamental need that it deserves its own chip. If they can fit an encoder into a 1-pound handheld digital camcorder, why can't they p

    • Re:If video encoding/decoding is the bottleneck... (Score:5, Informative)

      by Vellmont (569020) on Thursday November 15 2007, @10:14PM (#21374005)

        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.

      • Re: (Score:2, Insightful)

        by jibjibjib (889679)
        How many people really care about encoding video? 5% of the market? Less?

        I don't know why you seem to think video encoding is some sort of niche technical application that no one uses. A huge number of people record video on digital cameras and want to email it or upload it without taking too long. Many people now use Skype and other VOIP software supporting real-time video communication. Many people rip DVDs. Many people (although not a huge number) have "media center" PCs which can record video from TV

      • Re: (Score:2, Interesting)

        by xorbe (249648)
        > Cram? Chip designers get more and more transistors to use every year. I don't believe there's any "cramming" involved.

        Someone is definitely not a mainstream CPU designer! It never all fits... ask any floor-planner.

      • x86 not CISC?! (Score:5, Interesting)

        by porpnorber (851345) on Friday November 16 2007, @03:21AM (#21375881)

        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!

        • Thanks for the explanation. I've been wondering why, in late 2007, everything I see is still optimized for i686 (or even i586). I upgraded from Core to Core2, and couldn't figure out why I didn't need to recompile everything to take full advantage; that's when I noticed that Tiger was still using a gcc that didn't even have Core!

          It sounds like Penryn has a bunch of slightly-neat features that we'll start taking advantage of sometime in 2025.

          • I'm afraid I find this a little hard to interpret. It's a traditional thing to have flamewars about the 'point' of RISC (simply because - we're back in history here - the argument of H&P was 'measure twice, cut once' and RISC - an object, a project and a design schema - was just an application of that philosophy at a particular point in the technology curve), but the idea of RISC was most specifically to tune the visible ISA to the needs of a compiler back end (along with the execution engine, technolog

          • Intel wins in the market partly because it rides on Microsoft's coat tails (why Microsoft wins in the market is another long story, of course), and partly because it has fabrication technology that is actually sufficiently better than the competition to dominate most negative effects of architectural decisions. That in turn is because of economies of scale, and I understand was originally bootstrapped through their memory business, rather than by CPUs as such. And if it wins so utterly in the market, then i

      • Hardware decoding on hardware is already a reality, and has been for some time.

        As opposed to hardware decoding on software?

        Or redundant redundancies of redundancy?

    • If you are really interested in encoding video, I would think that you would have a specialized chip. My TV Tuner has a specialized chip for encoding mpeg 2, which means it can encode 12 mbit/s mpeg2 without putting any noticeable load on my processor. I'm sure it wouldn't be too difficult to build a chip specifically to encode video into MPEG 4.

  • More Useless Options (Score:5, Insightful)

    by hattable (981637) <hattable@gmail.com> on Thursday November 15 2007, @09:59PM (#21373913) Journal

    "So we do not plan on adding SSE4 optimizations. We may use SSE4 instructions in the future for convenience once SSE4 has become really widely supported. But I personally don't see that anytime soon..."

    This just reminds me of CONFIG_ACPI_SLEEP. About 2 times a month I am staring at this option wondering if I will ever get to use it. Some things just are not worth developer time to implement.
  • Am I the only one who read Penryn as penguin?

  • Remember MMX ? (Score:4, Informative)

    by 1888bards (679572) on Thursday November 15 2007, @10:07PM (#21373969)
    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.

  • Being an Early Adopter Sucks (Score:3, Insightful)

    by ocirs (1180669) on Thursday November 15 2007, @10:19PM (#21374041) Homepage
    These guys are pretty much saying that they don't really intent to optimize the code for penryn because very few processors will have SSE4, and even then they don't expect much performance improvement. I'm still waiting for decent 64-bit drivers for half of my hardware........ most early adopters pay a premium for features that aren't really utilized at first, and by the time the software catches up the hardware is dirt cheap. However penryn(except for the extreme edition) is an exception since it is priced at a point where it is worth it to pay the extra buck or two for the extra features that are not going to have much impact till years later when the software catches up. I'm really looking forward to Nehalem though, the architecture update is going to bring significant improvement in performance without much to do with software optimization.
    • What hardware do you have that doesn't have 64 bit drivers?
      • What hardware do you have that doesn't have 64 bit drivers?

        Adobe Flash and Opera.

        OK, it's not hardware or even drivers, but it's enough to make me regret installing 64-bit Ubuntu.

          • 32-bit opera installs just fine on 64-bit ubuntu. Flash works just fine in 64-bit firefox on 64-bit ubuntu. Java requires a little work but it is till doable under 64-bit firefox. Gutsy will even ask if you want to install flash when you visit a site that uses it (and installs it successfully, I might add).

            I'm still running swiftfire or swiftfox or whatever that allowed it. I haven't tried Opera since upgrading to 7.10, but just googling "opera 64-bit ubuntu 7.10" Take this [trentrichardson.com] site for exampe:

            Be aware before you install the 64bit version that you will not be able to install Flash, Opera, Wine, Komodo Edit, or any of the new cool Adobe Air products. Boy this is got me where it hurts being a web developer. Now none the less, most of these can be installed by following the tutorials for installing on a 64bit machine, but what I would really love to see in future versions is by default, Ubuntu have the capability of installing and running 32 and 64 bit versions of software. Now I've got no clue how one would begin creating such a work of art, but Apple did it, and I have full faith in the Ubuntu community.

            There are no t

  • Apple's change to LLVM (Score:5, Interesting)

    by tyrione (134248) on Thursday November 15 2007, @11:56PM (#21374799) Homepage
    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.

      • Re:LLVM == Hot Air (Score:5, Informative)

        by pavon (30274) on Friday November 16 2007, @01:23PM (#21381595)
        Apple used LLVM to improve the performance of software-fallbacks for OpenGL extensions by a hundred fold [arstechnica.com] 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.

        • Apple used LLVM to improve the performance of software-fallbacks for OpenGL extensions by a hundred fold [arstechnica.com] 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.

          If a new compiler frontend/backend/whatever improved the performance of those routines 100x, it's because the original routines were horribly inefficient. That is a simple fact and it is still true even when Apple is involved.

          • If a new compiler frontend/backend/whatever improved the performance of those routines 100x, it's because the original routines were horribly inefficient. That is a simple fact and it is still true even when Apple is involved.

            Apple is driving the costs behind LLVM. They are accelerating it's development goals and no GCC was not capable of providing the improvements to OpenGL and Quartz that Apple needed.

            Apple buys CUPS and makes sure it remains the same licensing while paying the salaries of its develo

  • All that matters is, does it run Linux?

    It does, end of discussion. Everything else is simply about applications.

    • Unless the bus and ram start running faster than the cpu, cache will have place in the design. And when die space is as cheap as it is for Intel now, why NOT use it for more cache?

    • Who gives a shit? (Score:5, Insightful)

      by Sycraft-fu (314770) on Friday November 16 2007, @08:29AM (#21377675)
      Seriously, I get tired of the AMD fanboy "Well if Intel did this they wouldn't have to do that," or "Intel is cheating by doing processors this way instead of that way." So understand this: None of that shit matters. The only thing that matters to the end user is performance for the dollars. That's it. You can bitch and scream all you like about how doing things a different way is theoretically better, what matter is actual, real performance. In that category, the Core 2 is very good. It's a damn fast chip for a good price. That's all it needs to be. I don't care about pissing matches over how it is done, only that in the end it works well for the things I do. Doesn't matter if there's a theoretical situation it's bad at, if that's not one I encounter, I don't care.

      Also as for bus speed, you might note that the real limiting factor is RAM speed. It is pricey to get faster RAM, and that's ultimately where you've got to go for non-cached data. You can build as fast a bus as you like, if you are waiting on the RAM it gains you little.
    • My 1,2 Ghz (C7) Epia Board runs a 28Mbyte/s file server over Gigabit LAN - with transparent AES decryption (dm-crypt).... :)
      • For most uses of md5 and sha1 in modern applications it makes very little difference that it's possible to manufacture collisions. That said, I'd really like to know what kind of applications requires enough md5 and sha1 generation steps that it causing enough load to be worth dedicated instructions.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.