Slashdot Mirror


Intel Details Upcoming Gulftown Six-Core Processor

MojoKid writes "With the International Solid-State Circuits Conference less than a week away, Intel has released additional details on its upcoming hexa-core desktop CPU, next gen mobile, and dual-core Westmere processors. Much of the dual-core data was revealed last month when Intel unveiled their Clarkdale architecture. However, when Intel set its internal goals for what its calling Westmere 6C, the company aimed to boost both core and cache count by 50 percent without increasing the processor's thermal envelope. Westmere 6C (codename Gulftown) is a native six-core chip. Intel has crammed 1.17 billion transistors into a die that's approximately 240mm sq. The new chip carries 12MB up L3 (up from Nehalem's 8MB) and a TDP of 130W at 3.33GHz. In addition, Intel has built in AES encryption instruction decode support as well as a number of improvements to Gulftown's power consumption, especially in idle sleep states."

43 of 219 comments (clear)

  1. Re:Are most programmes multi-processor? by Anonymous Coward · · Score: 2, Insightful

    MultiTasking

  2. Re:Are most programmes multi-processor? by Anonymous Coward · · Score: 5, Funny

    Cores are like girls in 'hot sluts gone wild' scenes - after a certain point you might hardly notice if there's even more of them, but you'd never say "no" to an increase.

  3. Grand Central Dispatch by TheStonepedo · · Score: 2, Interesting

    Perhaps a jump in number of cores will convince people outside the Apple and FreeBSD camps to port Grand Central Dispatch.
    Letting the kernel team handle the hairier parts of multi-threaded design should make it easy for barely-optimized software to use powerful hardware.
    Could its Apache license work with the #1 OS family?

    --
    I'll be your candy shop of infinite deliciousity if you'll be my discotheque of endless rump-shaking.
    1. Re:Grand Central Dispatch by TheRaven64 · · Score: 5, Informative

      Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers). On Darwin, Apple used the kqueue() mechanism that was ported from FreeBSD, so it's quite easy to port the code to FreeBSD (just #ifdef the bits that deal with Mach messages appearing on the queue). Kqueue is also ported to NetBSD and OpenBSD, so porting it to these systems will be easy too.

      Solaris and Windows both have completion ports, which provide the same functionality but with different interfaces. Porting to Solaris would require replacing the kqueue stuff with completion port stuff. Porting to Windows would ideally also require replacing the pthread stuff with win32 thread calls. Even Symbian has a nice event delivery framework that could be used, although I'm not sure what the pthread implementation is like in the Symbian POSIX layer.

      Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event. This also makes it harder to write low-power Linux apps, because your app can't spend so long sleeping and so the kernel can't spend so much time with the CPU in standby mode.

      If you don't need the event input stuff (which, to be honest, you do; it's really nice), you can use toydispatch, which is a reimplementation that I wrote of the core workqueue model using just portable pthread stuff.

      It also adds some pthread extensions for determining the optimal number of threads per workqueue (or workqueues per thread, depending on the number of cores and the load), but these are not required. The FreeBSD 8.0 port doesn't have them; they were added with FreeBSD 8.1.

      --
      I am TheRaven on Soylent News
    2. Re:Grand Central Dispatch by chaim79 · · Score: 2, Interesting

      Actually that isn't the case, I've been keeping an eye on the porting of GCD to other OSs and there are build options for with and without blocks (the non-standard C extension).

      As of right now I think the status is that FreeBSD (and other BSDs) can compile GCD with or without block support, Solaris is 90% there (again with and without blocks), and Linux is about 70% there (can compile and parts work, but not all of it).

      --
      DEMETRIUS: Villain, what hast thou done?
      AARON: Villain, I have done thy mother.
      Shakespeare invents 'your mom'
    3. Re:Grand Central Dispatch by mandolin · · Score: 2, Interesting

      Porting libdispatch requires a generic event delivery framework, where the userspace process can wait for a variety of different types of event (signals, I/O, timers). ... Linux is the odd system out. All different types of kernel events are delivered to userspace via different mechanisms, so it's really hairy trying to block waiting until the next kernel event.

      I don't understand this. It's true Linux does not have kqueue. (as I recall Linus thought it was "ugly" ... whatever) But in theory (because I haven't actually used them), to achieve the same effect under Linux, you would use timerfd() + signalfd() + (your normal i/o fds like sockets etc.) ... and then epoll_wait()/poll()/select() on all of the fds you were interested in. In this way, one thread could wait for multiple different types of events, including timers and signals.

      Would you please point out the flaws w/the above that make it impossible or impractical to achieve the functionality needed by Grand Dispatch? I would be enlightened -- thanks in advance.

    4. Re:Grand Central Dispatch by TheRaven64 · · Score: 2, Informative

      Subversion repository. Note that it's designed specifically to do stuff in the background for libobjc2. It only implements a tiny subset of the libdispatch functionality, and not as efficiently (one thread per workqueue, for example). It's not intended to replace libdispatch, just to let me use some of the libdispatch APIs in code that has to be portable. The 'toy' in the name is not self-deprecation, it's an accurate assessment.

      Oh, and you get better results if you search for 'toydispatch' not 'linux toydispatch' (it's nothing to do with Linux, although it should run there).

      --
      I am TheRaven on Soylent News
  4. Re:Are most programmes multi-processor? by goldaryn · · Score: 4, Funny

    Cores are like girls in 'hot sluts gone wild' scenes - after a certain point you might hardly notice if there's even more of them, but you'd never say "no" to an increase.

    But my "operating system" can only deal with one hand- I mean core- at once!

  5. Re:Are most programmes multi-processor? by SmilingBoy · · Score: 5, Interesting

    Wrong question. When was the last time my computer was running a single thread that could use 100% CPU for more than a few milliseconds. Answer: All the time. For example whenever I open Slashdot with Firefox. I rather have less cores at higher speed than more cores.

  6. Re:240mm square? by goldaryn · · Score: 3, Insightful

    1.17 billion transistors into a die that's approximately 240mm sq

    That's a big chip.

    240 mm sq, that's 15.49mm x 15.49mm

  7. Re:Are most programmes multi-processor? by pointbeing · · Score: 3, Informative

    Can most programmes really be written to take advantage of so many cores?

    Yup.

    Got a Core i7-920 running at 3.2GHz at home - OS is 64-bit Kubuntu 9.10.

    Yesterday I had five two-hour videos I wanted to render to DVD5 format - four were .avi and one was .mp4.

    Launched five instances of DeVeDe to render the video and create the DVD file structure and did all five at the same time - then left for work. Took an hour and twelve minutes and the machine didn't melt, explode or let any of the magic smoke out of the box.

    Even if an application isn't multithreaded the OS is - so even running a single task a multicore processor will give you a performance boost.

    A Core i7 has four cores that'll run two threads each - presents as eight processor cores to the OS. I have no problem using them all ;-)

    --
    we see things not as as they are, but as we are.
    -- anais nin
  8. Re:Are most programmes multi-processor? by TheRaven64 · · Score: 4, Interesting

    Most programs can't be written to take full advantage of even one core. Most of the things that you do on a computer will run happily on a 1GHz CPU and still not bring usage over 50% more than occasionally. Most of the things that will tax a modern CPU can be made parallel, so will scale quite well to a number of cores. Even if your processor intensive task isn't using multiple cores, you still benefit a bit from being able to move everything else onto another core. With the recent Intel chips you also have 'Turbo Boost' (horrible name) which underclocks some cores while overclocking others, giving one core a speed boost for that CPU-eating single-threaded app while keeping the power usage and heat generation output. To prevent hotspots on the die, you can move the process around between the cores, giving each a boost for a little while.

    --
    I am TheRaven on Soylent News
  9. Re:240mm square? by IBBoard · · Score: 2, Informative

    Isn't it 240mm sq = 240mm x 240mm (as in (240mm) squared) and 240 sq mm is 240 x 1mm x 1mm (as in 240 x (square mms))? It's always an awkward one to represent and be clear on.

  10. the best fucking CPU that ever existed by TubeSteak · · Score: 2, Funny

    Just so you know, I made this joke almost two years ago:
    http://hardware.slashdot.org/comments.pl?sid=465898&cid=22548916

    They could have gone to 3 cores, like the competition. That seems like the logical thing to do, but they said "Fuck it, we're going to six". What part of this don't you understand? If two cores is good, and four cores is better, obviously six cores would make them the best fucking CPU that ever existed.

    http://www.theonion.com/content/node/33930 [theonion.com]
    /I'm just waiting for the day Intel says "this one goes to 11"

    It's the CPU joke that will never die.

    --
    [Fuck Beta]
    o0t!
  11. Re:first by Anonymous Coward · · Score: 2, Funny

    first

    looks like you need more cores

  12. Re:Are most programmes multi-processor? by stilldead · · Score: 2, Insightful

    Let me rephrase this. As soon as you think virtualization and not just one OS this makes beautiful sense. There, I fixed that myself.

    --
    You are lucky, Ed Gruberman. Few novices experience so much of Ti Kwan Leep so soon.
  13. Intel announces 6 cores, 6 months after AMD.. yawn by Gr8Apes · · Score: 2, Interesting

    So I skimmed TFA (gasp!) and it appears that Intel is finally following AMDs lead by keeping thermal envelopes constant.

    I note that this is still a effectively 2 CPUs with 3 cores each, but that's better than legacy Intel approaches, which would have been 3 sets of dual cores.

    It will be interesting to see how independent performance benchmarks play out between the new processors that are coming out.

    --
    The cesspool just got a check and balance.
  14. Obligatory by Mattskimo · · Score: 2, Insightful

    blah blah Beowulf blah blah

  15. Re:Are most programmes multi-processor? by pointbeing · · Score: 4, Funny

    If you left for work, would it have really made any difference to you if it took five times as long?

    Well, yeah. I wouldn't have been able to brag about it ;-)

    --
    we see things not as as they are, but as we are.
    -- anais nin
  16. Re:Are most programmes multi-processor? by physburn · · Score: 2, Informative
    Most programs are very much not written to take advantage of multi-cores. Even advanced 3D games which might find the extra compute power useful, often can't deal with extra cores. E.g. I had to set the affinity of Borderlands to 1 CPU only to stop it crashing. Multithreaded programming is slowly getting easier as libraries to help it, become available. Java is particularly easy for this, have a look at java.util.concurrent, with i've just started using on the serverside. But most programs are miles behind in the move to being able to work with multiprocessors. Right now 6 cores will have very little to offer the desktop, on the server side however, i'm sure the extra core will have use, but only if the server is particularly loaded with transactions, something with rarely happens.

    ---

    Multithreaded Programming Feed @ Feed Distiller

  17. Re:DRM Support by FlyingBishop · · Score: 2, Insightful

    This is a server processor. They did it for advanced encryption. The only way this would make more powerful DRM is if there were some sort of key embedded in the CPU (and this is not that.)

    This is for encryption, which unlike DRM is actually more than security theatre (when used properly.)

  18. Re:Are most programmes multi-processor? by kjart · · Score: 2, Informative

    Having a second core was handy for people who like to play world of warcraft in one window and surf web pages in the other (considering how much CPU modern web pages eat for some reason. yay flash?).

    Having two more cores beyond that is fairly useless for the vast majority of even power users except for very specific apps that even they are running a very small percentage of the overall time they are using their computers.

    Not that I particularly disagree with your conclusions overall, but wow can actually be set to run on multiple cores and does get a performance benefit for doing so.

  19. Re:Are most programmes multi-processor? by war4peace · · Score: 3, Insightful

    Maybe GTA 4 is a very specific app for you.To me, GTA 4 is an important application :)
    And that game, my friend, requires a quad-core CPU. Which I don't have at the moment, and even with my Intel E6550 overclocked from 2.66 to 3.6 GHz the game runs at 25-35 FPS at 1680x1050, with both cores at 100%.
    I used to have the same approach (multicore is dumb) but now it's a thing of the past.
    There are more and more apps and games out there who take advantage of multicore, not to mention that operating systems (such as Windows 7) are better at allocationg sepaarte cores for single-core applications to balance the load.
    Therefore, while I don't dismiss the need of having a multicore CPU, in the end it's all about balancing your investment against the benefits. If you need a 6-core CPU and it doesn't cost a kidney and a lung, then get it. Regardless of your decision as a customer, there's always a good thing in this sort of advancements: new stuff pushes down prices for older stuff :)

    --
    ...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
  20. Re:DRM Support by sakdoctor · · Score: 4, Informative

    What?

    AES acceleration will be useful for VPNs, serving SSL websites, VoIP, full disk encryption ... and so on.

  21. To much cores, to little use... by null8 · · Score: 2, Interesting

    Instead of churning out cores they schould tweak the x86 isa to use multiple cores efficently. 1/2-word Atomic compare and swap is not enough, you cannot make atomic lockless doubly linked lists with that. No wonder something as interesting as http://valerieaurora.org/synthesis/SynthesisOS/ is not possible on x86 without major hacks.

    1. Re:To much cores, to little use... by TheThiefMaster · · Score: 2, Informative

      1/2-word?
      I'm pretty sure that there are instructions for atomic compare and swap of pointer-sized values, at least.

    2. Re:To much cores, to little use... by master_p · · Score: 2, Informative

      Isn't the xchg instruction atomic for all sizes (8/16/32/64 bits)?

  22. Re:Are most programmes multi-processor? by sznupi · · Score: 2, Informative

    Ah, so you don't realize that the cheapest Celeron nowadays is a dualcore 2.5 GHz, essentially a Core 2 Duo with 1 MiB of L2 (irrelevant, encoder will fit and the video is a stream of data) and 800 MHz FSB (irrelevant, mostly limited by the speed of computation, not by sustained transfer of the video stream). It would be done probably in around half of the time you were at work.

    If you were at home with a Celeron you could also do day-to-day stuff (yes, it would take even longer - but is that really that important in the case of a rare batch job which in every scenario is too long to be a "smooth" workflow?)

    --
    One that hath name thou can not otter
  23. Re:Are most programmes multi-processor? by Anonymous Coward · · Score: 3, Interesting

    Wrong question. When was the last time my computer was running a single thread that could use 100% CPU for more than a few milliseconds. Answer: All the time. For example whenever I open Slashdot with Firefox. I rather have less cores at higher speed than more cores.

    Really? So one thread wasn't reading the network traffic, one wasn't parsing the markup, and a third putting things up on the screen? At the same time the page wasn't being saved to your browser cache, while your e-mail program was querying the server for new mail, and cron was checking to see if there were jobs to run this minute? If you're on Windows, all of these activities were probably scanned by anti-virus.

    There's a lot going on in a modern system:
    $ ps -ef | wc -l
    146

  24. Re:Are most programmes multi-processor? by Big+Smirk · · Score: 2, Interesting

    Around here, the programmers never met a thread they didn't like. Add a requirement like - "display dialog box to confirm shutdown" and suddenly the thread count in the application jumps by 4...

    Could things be done more efficiently? No, because that would require thinking and thermodynamically it is cheaper just to spawn another thread.

    --
    TODO: create/find/steal funny sig.
  25. Codenamed codename? by CoffeeDregs · · Score: 2, Insightful

    >Westmere 6C (codename Gulftown)

        Really? I fricking hate codenamed codenames...

  26. Re:Are most programmes multi-processor? by Big+Smirk · · Score: 2, Informative

    Real time games are a bad example because in general the trouble with threads is you have to sync them up. The entire program becomes give feedback, gather input, calculate stuff, give feedback. You generally need to make sure the calculate stuff parts starts and stops with some predictability.

    Some games seem to run their AI in separate threads. These seems to be a reasonable compromise. So when the game does 'gather input' it asks the AI subsection where it wants to go at that instant.

    However, its judging by the stability of games like Fallout3, its unclear if either the programmers know how to deal with threads or the underyling OS is ready for intense real time updates.

    --
    TODO: create/find/steal funny sig.
  27. Re:on-board AES? by 0123456 · · Score: 4, Informative

    Why put AES on-board?

    They're not: they're putting extra instructions on-board which help implement AES more efficiently. They may also allow you to implement other algorithms more efficiently, though I haven't looked at them in enough detail to be sure.

    I thought AES was relatively fast as encryption algorithms go.

    That still doesn't make it fast at an absolute level. Particularly when you're doing full-disk encryption with user account encryption on top and IPSEC on all your network connections.

  28. Re:Are most programmes multi-processor? by petermgreen · · Score: 2, Informative

    Around here, the programmers never met a thread they didn't like. Add a requirement like - "display dialog box to confirm shutdown" and suddenly the thread count in the application jumps by 4...
    Lemme guess these programs are also buggy crash prone peices of shit?

    having more than one thread doing UI stuff has always struck me as more trouble than it's worth (you need loads of extra locks and a lot of thinking about what does and doesn't constitute a consistent state). Indeed some common gui libraries (swing for example) aren't built to support multiple threads accessing thier components for just this reason.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  29. Re:Are most programmes multi-processor? by Guspaz · · Score: 2, Interesting

    Examples of things that benefit from more than two cores:

    - Modern web browsers such as Chrome
    --- Multi-process architecture means that Flash sucks up a CPU all to itself, while various other tabs/domains are in different processes. Javascript-heavy web-apps or the user of other flash like plugins can easily make 3+ cores worthwhile
    - Most modern games
    --- Games are very CPU intensive. Most modern engines do a very good job of taking advantage of multiple cores. Some games even require 2+ cores in order to get any decent performance; MassEffect 2 (Unreal Engine 3) is unplayable on single-core processors
    - Video encoding
    --- GPU-accelerated (CUDA, OpenCL, etc) encoding is not yet useful, and isn't likely to be so any time soon. Existing hardware accelerated encoders are extremely limited in flexibility, and are usually of very poor quality (in terms of output).
    - Multitasking
    --- You scoff at it, but if I've got some demanding application running and I try to do something else at the same time (such as pause a game, alt-tab out of it, try to watch a video), CPU load starts to add up.

    Most peoples' needs can be met with the low end dual-core processors with hyperthreading such as the i3 or i5 series, but these days it's not just anybody who can take advantage of a quad core CPU. Pretty much all gamers, for example.

  30. Re:Are most programmes multi-processor? by Tim+C · · Score: 3, Informative

    Most of the things that you do on a computer will run happily on a 1GHz CPU and still not bring usage over 50% more than occasionally

    Speak for yourself.

  31. Re:Who cares... by Microlith · · Score: 2, Informative

    Sure, but neither the Oracle or IBM chips will be available for less than several grand, and never in consumer level equipment (I can't exactly order one off Newegg.) And there's no telling how long it will be until the AMD chip trickles down from Opteron class to Phenom class, while it will probably be short order for the Core i9 to appear in stores.

    I suspect that AMD will drop the 6-core version as an X6 pretty soon, but it will likely be outperformed (possibly significantly) by the Gulftown.

  32. Re:Transistor count by wtfbill · · Score: 2, Informative

    No, I bet his caffeine content is fine. The 68K transistors would refer to the 68000 procs from Motorola which were 16- or 32-bit depending on configuration. Some of them could be switched at boot time by holding one of the pins high or low (I forget which...where are those old data sheets I have on those?) Of course the 65xx series and the 6800 series were 8-bit, however, they didn't have close to 68K transistors. But GP is right on, 68K transistors for a 32-bit architecture.

  33. Re:Transistor count by sznupi · · Score: 2, Interesting

    And yet, latest ARM cores are much closer to that 68k transistors from 1980, while not being nearly that far behind i7 in performance as the relation between numbers of transistors would suggest.

    Perhaps ARM found the sweet spot.

    --
    One that hath name thou can not otter
  34. Re:Are most programmes multi-processor? by Snufu · · Score: 2, Insightful

    less cores at higher speed

    And I want a pony.

    The move to multiple cores was driven primarily by Moore's law approaching fundamental physical realities in trying to further shrink conventional CMOS transistors. I'm sure manufacturers would have loved to stay with single cores and bump up clock speed every financial quarter rather than upset the industry's technological architecture.

    Solid State Physics 1, Corporate Financial Officers 0.

  35. Re:Are most programmes multi-processor? by seventyfive75 · · Score: 2, Insightful

    LMAO. My videocard alone has more ram than my xbox 360 and PS3 combined. Maybe we will start comparing F-22's and messerschmitts soon. Perhaps we can look at how the Ferrari California stacks up to the new Honda Fit.

  36. 24 isn't enough by toastar · · Score: 2, Interesting

    24 x86 cores just doesn't compare to 1 Fermi with 512 striped down vector processors

  37. Re:on-board AES? by wirelessbuzzers · · Score: 3, Informative

    Why put AES on-board?

    They're not: they're putting extra instructions on-board which help implement AES more efficiently. They may also allow you to implement other algorithms more efficiently, though I haven't looked at them in enough detail to be sure.

    The instructions perform a single round of AES (which has 10-14 rounds depending on key size), either encrypting or decrypting. Certain other algorithms such as Lex, Camellia, Fugue and Grostl use AES S-boxes in their core, and can probably benefit from these instructions. However, they will not achieve nearly so much a speedup as AES.

    The AES instructions themselves will approximately double the speed of sequential AES computations. This is very unimpressive; VIA's AES instructions are much faster. They will also make it resistant to cache-timing attacks without losing speed, which is unimpressive because you can already do this on Penryn and Nehalem. The low speed results from the AES instructions having latency 6; if you can use a parallel mode (GCM, OCB, PMAC, or CBC-decrypt, for example) then the performance should be 10-12x the fastest current libraries. Hopefully, this will cause people to stop using CBC mode, but perhaps I'm too optimistic.

    Intel also added an instruction called PCLMULQDQ which does polynomial multiplication over F_2. If it's fast (I can't find timing numbers, but hopefully it's something like latency 2 and throughput 1) then it will be very useful for cryptography in general, speeding up certain operations by an order of magnitude or more. This is more exciting to me than the AES stuff, because it might enable faster, simpler elliptic-curve crypto and similarly simpler message authentication codes. Unfortunately, these operations are still slow on other processors, so cryptographers will be hesitant to use them until similar instructions become standard. If the guy you're communicating with has to do 10x the work so that you can do half the work... well, I guess it's still a win if you're the server.

    I thought AES was relatively fast as encryption algorithms go.

    That still doesn't make it fast at an absolute level. Particularly when you're doing full-disk encryption with user account encryption on top and IPSEC on all your network connections.

    AES is fast for a block cipher, but modern stream ciphers such as Salsa20/12, Rabbit, HC and SOSEMANUK are about 3-4x faster. (In other words, they are still faster than AES in a sequential mode on Westmere.) AES is still competitive, though, if you can use OCB mode to encrypt and integrity-protect the data at the same time.

    The fastest previous Intel processor with cutting-edge libraries in the most favorable mode could probably encrypt or decrypt 500MB/s/core at 3-3.5GHz. This is fast enough for most purposes, but in real life with ordinary libraries you'd probably get a third of that. So this will significantly improve disk and network encryption if they use a favorable cipher mode.

    Cred: I am a cryptographer, and I wrote what is currently the fastest sequential AES library for Penryn and Nehalem processors. But the calculations above are back-of-the-envelope, so don't depend on them.

    --
    I hereby place the above post in the public domain.