4 Comments
- geminitojanus, on 10/11/2007, -0/+3"do I run that instruction on the graphics core or the math co-processor?"
That's the job of the programmer, and the programmer's progeny --the operating system--, to know where instructions are best run. The challenge is scheduling; I've got 10 applications and 80 cores, which cores should I dedicate to which task? It's not necessarily a hard problem, or one we haven't solved before, it's just getting more complicated as now we're trying to graft an old CPU design into a new format; like trying to take eight cars and make a semi truck.
Sadly the article is just as bad as all of the other news articles on Terascale, and don't describe at all how these challenges are going to be met. The Terascale project is less about how to build the next super-multicore beast and more about how to make a lot of processors talk to each other at the same time. Technologies like bonding memory directly to the core (using TSVs as the article points out, or silicon lasers), technologies like instruction-switched processor networks (yes, like ethernet on a chip), how to deal with heat generation, bus contention, all of these things that need to be solved by the time we're trying to push 16- and 24- core processors on people.
Lastly, we don't need to change the way we're programming, much. Threading works. Processes work. What we've done in the past is figured out how to run 10 programs on one processor, all we're doing now is relearning how to run 10 processes on 10 processors (through a tiny memory corridor). Your average joe-blow program couldn't peg a CPU if it tried, and most programs that do have already found ways of spreading their operations across multiple cores. People need to stop thinking that higher level programmers need to change anything; it's a fallacy propagated by people who aren't familiar enough in the field to make that call. They see multi-core processors as the next, hot thing and they don't understand that their program doesn't actually *need* that kind of power, and they complain that they can't use it effectively. [They used to say the same thing about lots and lots of memory, insert favorite BG quote here].
So yeah, while the Operating System engineers are going to have quite a few nailbiting years coming up, most of us can go on writing what we're writing. The real bottleneck we're running up on is how to get to memory faster, and that's really what programmers should be thinking about. - universal12, on 10/11/2007, -2/+1Intel is a very innovative company. They are the future!
- swordedge, on 10/11/2007, -2/+1The article said Intel was working on ways to mask what the complexity of the chip from developers. This is VITAL. Programmers have trouble enough wrapping their minds around proper multitasking, never mind 64 cores of different types. Make it so that the programmer does NOT need to say, "do I run that instruction on the graphics core or the math co-processor?"
For the non programmers, multitasking means that programmers have to do ten times the work. Tasks that the program does get spun off into their own threads. The programmer doesn't know ahead of time when these task will finish so they use things like an event manager. Doing this also makes data management way more complicated. It's like many users trying to update your data base at the same time. This inner workings of this chip make that look simple.


What is Digg?
Check out the new & improved