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."

23 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 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
    4. 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.

  2. 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 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!
    5. 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.

    6. 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
    7. 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...

    8. 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.
  3. 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.

  4. 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!
  5. 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.

  6. 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".

  7. 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
  8. 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

  9. 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.

  10. 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?"