Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Intel Businesses Technology

Intel Reveals the Future of the CPU-GPU War 231

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."
This discussion has been archived. No new comments can be posted.

Intel Reveals the Future of the CPU-GPU War

Comments Filter:
  • Great! (Score:3, Informative)

    by Short Circuit ( 52384 ) * <mikemol@gmail.com> on Wednesday April 11, 2007 @07:15PM (#18696287) Homepage Journal
    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.
  • Re:yay (Score:3, Informative)

    by ewhac ( 5844 ) on Wednesday April 11, 2007 @07:33PM (#18696475) Homepage Journal
    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

  • Re:Sure there is (Score:4, Informative)

    by Fnord ( 1756 ) <joe@sadusk.com> on Wednesday April 11, 2007 @08:28PM (#18696985) Homepage
    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...
  • Re:Great! (Score:5, Informative)

    by strstrep ( 879828 ) on Wednesday April 11, 2007 @09:08PM (#18697255)
    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.
  • Re:Great! (Score:2, Informative)

    by strstrep ( 879828 ) on Wednesday April 11, 2007 @11:46PM (#18698151)
    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.
  • by *weasel ( 174362 ) on Thursday April 12, 2007 @09:01AM (#18701019)

    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.

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse

Working...