Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel Reveals the Future of the CPU-GPU War

Posted by CowboyNeal on from the state-of-the-chip dept.

Arun Demeure writes "Beyond3D has once again obtained new information on Intel's plans to compete against NVIDIA and AMD's graphics processors, in what the Chief Architect of the project presents as a 'battle for control of the computing platform.' He describes a new computing architecture based on the many-core paradigm with super-wide execution units, and the reasoning behind some of the design choices. Looks like computer scientists and software programmers everywhere will have to adapt to these new concepts, as there will be no silver bullet to achieve high efficiency on new and exotic architectures."

45 of 231 comments (clear)

  1. Great! by Short+Circuit · · Score: 3, Informative

    As I recall, AMD's Athlon beat out the competing Intel processor in per-clock performance, partially as a result of having a more superscalar architecture. It's nice to see that, with the NetBurst architecture dead, Intel's finally taking an approach that's expandable and extensible.

    The CPU wars have finally gotten interesting again. I'm going to go grab some popcorn.

    --
    tasks(723) drafts(105) languages(484) examples(29106)
    1. Re:Great! by JordanL · · Score: 4, Interesting

      So when Intel decides that it's time to implement new architectures and force new methods of coding it's an awesome thing, but when Sony does it people tell them to stop trying to be different... I know people will cry about the console market being different, but the principals of the decisions are the same. If people cried about the Cell I expect them to cry about Intel's new direction. And this had to be said... I have Karma to burn.

      --
      FanFictionRecs.net
    2. Re:Great! by nuzak · · Score: 3, Funny

      Intel doesn't go around telling us that their design will push 17 hojillion gigazoxels, with more computing power than Deep Blue, HAL, and I AM put together, in order to render better-than-real detail in realtime while simultaneouslly giving you a handjob and ordering flowers for your gf.

      --
      Done with slashdot, done with nerds, getting a life.
    3. Re:Great! by Short+Circuit · · Score: 2, Interesting

      I thought Sony's processor design was awesome, and I still do.

      --
      tasks(723) drafts(105) languages(484) examples(29106)
    4. Re:Great! by JordanL · · Score: 4, Interesting

      Speaking as someone who wrote reports on the Cell as early as 2004, it was mostly the people who thought Sony was the devil himself who hyped it up.

      Easiest way to make sure a product doesn't meet expectations is to raise expectations.

      --
      FanFictionRecs.net
    5. Re:Great! by strstrep · · Score: 5, Informative

      It's a good design, it just doesn't seem like a good design for a video game system. It's a general purpose CPU attached to several CPUs that essentially are DSPs. DSP programming is very weird, and you need to at least understand how the device works on the instruction level for optimal performance. A lot of DSP code is still written in assembly (or at the very least hand-optimized after compilation).

      It's very expensive to have DSP code written, when compared to normal CPU code, and video game manufacturers have been complaining that the cost of making a game is too high. Also, most of the complexity in a video game nowadays is handled by the GPU, not the CPU. Now the cell would be great for lots of parallel signal processing, or some other similar task, and I bet it could be used to create a great video game, it would just be prohibitively expensive.

      The cell is a great solution to a problem. However, that problem isn't video games. A fast traditional CPU, possibly with multiple cores, attached to a massively pipelined GPU would probably work better for video games.

    6. Re:Great! by jmorris42 · · Score: 2, Insightful

      > So when Intel decides that it's time to implement new architectures and force new methods of coding it's an awesome thing, ....

      Except when it ain't. Lemme see, entire new programming model..... haven't we heard this song before? Something about HP & Intel going down on the Itanic? Ok, Intel survived the experience but HP is pretty much out of the processor game and barely hanging in otherwise.

      Yes it would be great if we could finally escape the legacy baggage of x86, but it ain't going to happen anytime soon. The pain isn't there yet that would convince people to migrate.

      --
      Democrat delenda est
    7. Re:Great! by strstrep · · Score: 2, Informative

      You typically write code that runs on the main CPU. This program supplies the GPU with data such as vertices, triangles, textures, etc.. For special effects, you can write shader programs for the GPU that modify how the GPU renders specific things. However, most of the code that's running on the GPU is already written for you... at the transistor level.

      All a DSP does is do lots of arithmetic operations and memory moves quickly. For example, in a single instruction, the DSP could run an addition and shift operation, move some data from memory to registers, and move some data from registers to memory. Also, DSPs (and the SPU in the cell) tend to perform (relatively) terribly when they run into a conditional statement. Thus, the type of programs that you end up writing for DSPs don't just need special attention when programming; you have to write a whole different kind of program for them than you're used to.

    8. Re:Great! by Fred_A · · Score: 2, Funny

      I know people will cry about the console market being different, but the principals of the decisions are the same.
      No, it's quite different, the console market is indeed different since it's more like high school. In the PC market we don't have principals, we have managers.
      --

      May contain traces of nut.
      Made from the freshest electrons.
  2. yay by Anonymous Coward · · Score: 2, Interesting

    Maybe they will ditch the shiatty 950 graphics chip, that is all too common in notebook computers

    1. Re:yay by ewhac · · Score: 2, Informative
      The 945/950 GMCH is common in notebooks because it's easy to implement (Intel's already done almost all the work for you), it's fairly low-power and, most important of all, it's cheap.

      Schwab

      --
      Editor, A1-AAA AmeriCaptions
    2. Re:yay by Anonymous Coward · · Score: 5, Insightful

      Funny, I wouldn't consider a mobo without because Intel are working towards an open source driver. I'm sick of binary drivers and unfathomable nvidia error messages. At least Nvidia expend some effort, ATI are a complete joke. Even on windows ATI palm you off with some sub-standard media player and some ridiculous .NET application that runs in the taskbar (What fucking planet are those morons on?)

      So you can bash intel graphics all you like but for F/OSS users they could end up as the only game in town. We're not usually playing the latest first person shooters, performance only need be "good enough".

  3. Sure there is by Watson+Ladd · · Score: 5, Insightful

    Abandon C and Fortran. Functional programing makes multithreading easy and programs can be written for parallel execution with ease. And as an added benefit, goodbye buffer overflows and double frees!

    --
    Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
    1. Re:Sure there is by QuantumG · · Score: 4, Insightful

      Cool, with that kind of benefit, I'm sure you can point to some significant applications that have been written in a functional language which have been written for parallel execution.

      This kind of pisses me off. People who are functional programming ethusists are always telling other people that they should be using functional languages but they never write anything significant in these languages.

      --
      How we know is more important than what we know.
    2. Re:Sure there is by ewhac · · Score: 5, Insightful
      Cool! Show me an example of how to write a spinning OpenGL sphere with procedurally-generated textures and reacts interactively to keyboard/mouse input in Haskell, and I'll take a serious whack at making a go of it.

      Extra credit if you can do transaction-level device control over USB.

      Schwab

      --
      Editor, A1-AAA AmeriCaptions
    3. Re:Sure there is by beelsebob · · Score: 3, Interesting

      Actually... Looking at Haskell, and clean in the debian language shootout, both are beating C# in terms of memory usage, and CPU usage.

    4. Re:Sure there is by beelsebob · · Score: 2, Interesting

      How about google search? That a big enough exmpe for you? It's written using a functional library called Map reduce.

    5. Re:Sure there is by Goalie_Ca · · Score: 3, Interesting

      Tim Sweeny of Epic has a pdf floating around. Basically a game can be divided into 3 groups. Shading (using shader language), numeric computations (functional) and then game state/logic. He quoted 500 Gflops for shading, 5 gflops for numerics, and 0.5 for game state/logic. Shading is a solved problem as far as concurrency is concerned. THe numeric computation uses the most cpu, that is mostly small numerical jobs for things like checking collisions and can be parallelized and done functionally. The game static/logic and scripting were said to be best done in c++/scripting. That is the part you won't really thread but you could use STM if needed.

      --

      ----
      Go canucks, habs, and sens!
    6. Re:Sure there is by beelsebob · · Score: 2, Interesting
      Can you show me any open source project where massive parallelism is being exploited? I'm not sure I can think of any.

      In the mean time, you were given a nice example -- ATC systems and telephone exchanges, and in the mean time, you can have a research paper about map reduce -- if you don't belive me, belive the peer reviewed research.

    7. Re:Sure there is by QuantumG · · Score: 2, Insightful

      No, dude, he's asking you to solve real problems using your functional language which you claim to be so much better at solving real problems. And, as usual, the response from the functional programming crowd is to point at supposed case studies that no-one can verify or to point at contrived benchmarks.

      --
      How we know is more important than what we know.
    8. Re:Sure there is by Bill+Barth · · Score: 2, Insightful

      If you read the paper you linked to below, you'll find that Google's Mapreduce language is implemented as a C++ library. Specifically, check out Appendix A of thier paper.

      --
      Yes...I am a rocket scientist.
    9. Re:Sure there is by beelsebob · · Score: 2, Insightful

      Actually, no... That's exactly the point here. These chips are so comlex to think about that a human can't possibly juggle it all in their head. A good human will *never* be as good as a compiler for these chips, and good functional languge compiler for these chips will almost always be better than a good procedural language compiler.

    10. Re:Sure there is by AstrumPreliator · · Score: 5, Insightful

      I couldn't find anything related to procedurally-generated textures, not that I really looked. I could find a few games written in Haskell though. I mean they're not as advanced as a spinning sphere or anything like that...

      Frag which was done for an undergrad dissertation using yampa and haskell to make an FPS.
      Haskell Doom which is pretty obvious.
      A few more examples.

      I dunno if that satisfies your requirements or not. Though I don't quite get how this is relevant to the GP's post. This seems like more of a gripe with Haskell than anything. But if I've missed something, please elaborate.

    11. Re:Sure there is by ewhac · · Score: 4, Insightful

      Functional languages will let us utilize multiple cores without the headaches and performance is acceptable, to claim otherwise is plain short-sighted.

      I've done some rudimentary reading on functional programming languages -- mostly Haskell and LISP (which is sorta FP) -- and I believe you when cite all the claimed benefits. The architecture of the languages certainly enables it.

      However, every time I've tried to get a handle on Haskell, all the examples presented tend to be abstract. In other words, they contrive a problem that Haskell is fairly well-suited to solving, and then write a solution in Haskell, using data structures and representations entirely internal to Haskell. "Poof! Elegance!" Well, um...

      I'm a gaming, graphics, and device driver geek, and so my explorations of new stuff tend to lean heavily in that direction. I'm interested in more "concrete" expressions of software operation. Could Haskell offer new or interesting possibilities in network packet filtering? Perhaps, but first you have to read reams of text on how to bludgeon the language into reading and writing raw bits.

      The other issue with FP is that they tend to treat all problems as a collection of simultaneous equations -- things that can be evaluated at any time in any order. There's a huge class of computing problems that can't be described that way. You can't unprint a page on the line printer. There are facilities for sequencing/synchronizing operations (Haskell's monads, for instance), but I get the impression that FP's elegance starts to fall apart when you start using them.

      Understand that my exposure to FP in general and Haskell in particular is less than perfunctory, and am very likely misunderstanding a great deal. I'd like to learn and understand more about FP, but so far I haven't encountered the "Ah-hah!" example yet.

      Schwab

      --
      Editor, A1-AAA AmeriCaptions
    12. Re:Sure there is by Bill+Barth · · Score: 2, Interesting
      Yes, but if you look at the code in Appendix A, it's written in C++. Yes, it calls a the MapReduce library which is functional in style, but the user still must write their code in an essenitally procedure language. Yes, the library hides a lot from the user, but so what? They still have to write their code in C++! The OP exhorted us to "abandon C and Fortan," but you're touting a C++ class library as an example of a win for functional languages. I assume you can see why we might object!

      Of course Google's programmers can write cool parallel programs with this powerful library, but it's not a functional programming library! It's a C++ library that borrows some map and reduce ideas from functional languages.

      I'd rephrase the objection to the OP as: "Show me the climate simulator in Haskell. Show me the ML hypersonic flow code for computing reentry flow over the shuttle."

      --
      Yes...I am a rocket scientist.
    13. Re:Sure there is by Fnord · · Score: 3, Informative

      A perl6 *interpreter* was written in haskell, and it's considered a non-performance oriented reference implementation, purely for exploring the perl6 syntax. No one has ever doubted that interpreters and compilers are easier to do in functional languages. One of the things you learn first when you take a class in lisp is a recursive descent parser. But the version of perl6 that's expected to acutally perform? Parrot is written in C. The fact that its no where near done is a completely different matter...

    14. Re:Sure there is by Bill+Barth · · Score: 3, Insightful
      There's no MapReduce compiler. The programmer writes C++. So, at best, the programmer is the functional language compiler, and he has to translate his MapReduce code into C++.

      Again, no one disagrees with your idea that writing in a functional style is a good idea for parallel programming, but the OP said that we should give up on two specific languages and pick up a functional one. Clearly a program in a functional style can be written in C++ (which is a superset of C89, more or less, which is one of the two languages mentioned by the OP). The challege to the OP was to show the world a massively parallel program of significance written in a functional language, not one written directly in a procedural language but in a functioal style. You showed us the latter, we'd still like to see the former.

      --
      Yes...I am a rocket scientist.
    15. Re:Sure there is by alphamugwump · · Score: 2, Interesting

      What makes you think a compiler will be able to do it better than a human?

      When people write games, they do all kinds of crazy stunts to ensure they have as few multiplications as possible. Can you really trust a compiler to get the code right for that tight inner loop? Figuring out parallelism might be hard, but game programming has always been hard.

      Also, you avoided mentioning memory. It doesn't matter if Haskell uses marginally less memory if it's in the wrong place when you need it. Is that texture in RAM, VRAM, or swap? That sort of thing makes a big difference in terms of performance. And games must maintain a certain framerate. Sometimes it's completely unacceptable to use swap, even if the time gets made up later.

      I'm not against functional languages, it's just a question of using the right tool for the job. You use high level languages for high level tasks, and low level languages for low level tasks. If you're writing a compiler or an AI or a raytracer, where realtime performance it not an issue, sure, functional languages are great. But games have always been married to the hardware, and I don't see how that could change any time soon.

    16. Re:Sure there is by Anonymous Coward · · Score: 2, Insightful

      If you actually read that paper, you will notice from the code snippet at the end that map reduce is a C++ library. So it kind of proves the exact opposite of what you intended: people are doing great stuff with the languages that you are saying should be dropped.

    17. Re:Sure there is by stephentyrone · · Score: 2, Interesting

      Functional programming makes multithreading easy, but multithreading != vectorization, and vectorization is the bulk of what is needed to take advantage of this type of processsor. I'm yet to encounter a language as suited to talking about vector code as Fortran is, sad as that may be.

    18. Re:Sure there is by slamb · · Score: 2, Interesting

      Tim Sweeny of Epic has a pdf floating around.
      The PDF in question is The Next Mainstream Programming Language: A Game Developer's Perspective. It's a good read, though I wish there were a paper version rather than just a PowerPoint presentation.
  4. Cell by Gary+W.+Longsine · · Score: 2, Insightful

    The direction looks similar to the direction the IBM Power-based Cell architecture is going.

    --
    If you mod me down, I shall become more powerful than you could possibly imagine.
  5. Astroturf by Anonymous Coward · · Score: 5, Insightful

    Arun Demeure writes "Beyond3D has once again obtained new information...

    If you are going to submit your own articles to Slashdot, at least have the decency to admit this instead of talking about yourself in the third-person.

  6. future of computing? by jcgf · · Score: 2, Interesting

    I'm just waiting till they come out with a complete single chip PC (I know there are examples but they aren't spectacularly performing). Just enough PCB for some external connectors and some voltage regulation.

  7. We need a new architecture by jhfry · · Score: 5, Interesting

    I don't know what it is, or how it will be different from x86, but progress can't keep continuing if we don't look for better methods of doing things.

    It cannot be argued that x86 is best architecture ever made, we all know it's not... but it is the one with the most research. We need the top companies in the industry, Intel, AMD, MS, etc. to sit down and design an entirely new specification going forward.

    New processor architecture, a new form factor, a new power supply, etc...

    Google has demonstrated that a single voltage PSU is more efficient, and completely do able. There is little reason that we still use internal cards to add functionality to our systems, couldn't these be more like cartridges so you don't need to open the case?

    Why not do away with most of the legacy technology in one swoop and update the entire industry to a new standard.

    PS, I know why, money, too much investment in the old to be worth creating the new. But I can dream can't I?

    --
    Sometimes the best solution is to stop wasting time looking for an easy solution.
    1. Re:We need a new architecture by Pharmboy · · Score: 5, Insightful

      Itanium?

      --
      Tequila: It's not just for breakfast anymore!
  8. Similiar to what sun is doing with Niagara by mozumder · · Score: 3, Interesting

    Basically put in dozens of slow low IPC, but area-efficient, processors per CPU. Later on, throw in some MMX/VLIW style instructions to optimize certain classes of algorthims.

    The first Niagara CPUs were terrible at floating point math, so they were only good for web-servers. The next generation I hear are supposed to be better at FPU ops.

  9. Re:Not a troll -- Meta-Mod unfair by Blahbooboo3 · · Score: 2

    Uh, turn off all the cutesy graphics and Vista would be fine. Windows classic theme removes all the GUI candy and the 950 is fine...

  10. Intel against NVIDIA/ATI/AMD? OSS? by WhiteWolf666 · · Score: 5, Insightful

    If intel keeps supporting its equipment with excellent OSS support, I'll happily switch to an all-intel platform, even at a significant premium.

    NVIDIA's Linux drivers are pretty good, but ATI/AMD's are god awful, and both NVIDIA's & AMD/ATI's are much more difficult to use than Intels.

    I'd love to see an Intel GPU/CPU platform that was performance competitive with ATI/AMD or NVIDIA's offerings.

    --
    WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
  11. Good for linux by cwraig · · Score: 3, Insightful

    If Intel start making graphics card with more power to compete with nvidia and ati there they will find a lot of Linux support as they are the only ones which currently have open source drivers http://intellinuxgraphics.org/ I'm all for supporting Intel move into graphics cards as long as they continue to help produce good linux drivers

  12. Great expectations! by Anonymous Coward · · Score: 2, Funny

    "Easiest way to make sure a product doesn't meet expectations is to raise expectations."

    Sex with geeks is great!

  13. It's an old argument by Bozdune · · Score: 3, Insightful

    Functional languages are nicely parallelizable because they don't have side effects. Unfortunately, real life is full of side effects. So, a pure functional language has to "hack" the side effect by passing it around everywhere as a closure. That gets old really, really quickly. Which is why useful functional languages contain constructs with side-effects (not without accompanying hand-wringing from purists).

    Back in the 70's, people like Jack Dennis used to promise the DARPA that they could parallelize the old Fortran code used to do complex military simulations by converting the Fortran code to a pure functional language. It would be wonderful! Well, they couldn't, and it wasn't.

    The above notwithstanding, IF you can coerce a problem into a form in which a functional language can be effectively employed, the benefits can be huge. The code tends to be more elegant and more readable; algorithms that would be difficult to write in an applicative language like C become easy; data structure manipulation is trivial; and so on. Arguments that functional languages are "slow" have been debunked. Arguments that functional languages must be interpreted are wrong.

    And, all the syntactic nonsense of C++ and the rest of the "object oriented" languages can be (mercifully) shed. Pure functional languages are object oriented by nature. However, functional languages do have their own idiosyncracies, such as the infamous Lisp "quote", and implementation-dependent funarg problems. So there are cobwebs still.

    To sum up: If you have a hard algorithmic problem to solve, a functional language will probably be a better choice, even if you end up re-coding the algorithm in an applicative language later. If you have a device driver to write, though, roll up your sleeves and get out the C manual. But first: make sure to put a debug wrapper around your mallocs (and pad your malloc blocks with patterns on both sides) so you can trap double-frees, underwrites, and overwrites. It will pay many dividends.

  14. Re:Not quite by Coryoth · · Score: 2, Interesting

    You do have a point. I wrote the Concurrency chapter in The Java Tutorial, struggled for 15 pages just to discuss the basics of the topic, and ran out of time to cover more than half of what I should have. Most of what I wrote was about keeping your threads consistent, statewise. Ideally I would like to see Java take up something like this as a means to handle concurrency. It is simple, easy to understand, easy to reason about concurrent code, and doesn't require stepping very far outside standard stateful OO programming methods. Whether that will actually happen is, of course, another question, but something along those lines does offer a good way forward.
    --
    Craft Beer Programming T-shirts
  15. Re:Not quite by chudnall · · Score: 2, Funny

    Dude, you think C and Fortran are the main alternatives to functional languages?
    Dude, you have the Abstract Math gene.


    Dude, you have the dude gene. Help is available. The first step is to admit you have a problem...
    --
    Disclaimer: Evolution comes with NO WARRANTY, except for the IMPLIED WARRANTY of FITNESS FOR A PARTICULAR PURPOSE.
  16. Ken Kutaragi thinks Sony is the devil? by *weasel · · Score: 3, Informative

    it was mostly the people who thought Sony was the devil himself who hyped it up


    No, mostly, it was Ken Kutaragi.

    Having an extensive history of reporting on Sony, I'm sure you remember he did the exact same thing when hyping the PS2's emotion engine.

    --
    // "Can't clowns and pirates just -try- to get along?"