http://www.eetimes.com/showArticle.jhtm ... =206105179
Roundtable discussion regarding multicore. Which model do you want to code for?
I wish the idiots on /. would answer that question rather than do the prognosticating and armchair architecting they seem so fond of.
software vs. hardware
-
quantus
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
Currently, I agree with the heterogeneous guys. That's the fastest way to see significant improvement in the short term with multiple cores. As cores get smaller and smaller compared to the overall die size, I could see a shift back to more homogeneous cores since their scheduling overhead will be lower relatively.
I wonder if you could design a core that could either run as a separate processor, or could hook up with the processors nearby, turn off it's own data path control and essentially work in a vector processing form? I think that wouldn't be so hard to do. You may have to deal with a clock cycle skew between the master vector processor and slave computation processors, but that's not so bad since it's still pipeline-able. Now go design the ISA that would make this work!
Hrmmm, that'd almost be like a P2P'ish type architecture... You ask your peers to help you computer stuff by asking them to slave up to your data path control.
I wonder if you could design a core that could either run as a separate processor, or could hook up with the processors nearby, turn off it's own data path control and essentially work in a vector processing form? I think that wouldn't be so hard to do. You may have to deal with a clock cycle skew between the master vector processor and slave computation processors, but that's not so bad since it's still pipeline-able. Now go design the ISA that would make this work!
Hrmmm, that'd almost be like a P2P'ish type architecture... You ask your peers to help you computer stuff by asking them to slave up to your data path control.
-
quantus
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
The verification wouldn't be totally self-contained, true, but it already isn't with multi-core since you still need to check the cache coherency and other boundary logic. This would potentially expand the problem some because it may add another interface to the core. Perhaps it could use the interrupt mechanism already present to pass signals from chip to chip?
-
Jonathan
- Grand Pooh-Bah
- Posts: 6722
- Joined: Tue Sep 19, 2006 8:45 pm
- Location: Portland, OR
- Contact:
Just think of validation in terms of O(n) where n is the number of transistors. By scaling out in terms of cores, you can increase n dramatically without having much effect on validation, as long as the design was MP to begin with. With a single monolithic design, the validation problem grows polynomially (or perhaps exponentially if you're unlucky) with n.
Anyway, this doesn't answer the question. Do you want to code this hypothetical array of hetero cores using an API, like DirectX or CUDA? Do you want to use an explicitly parallel ISA (like EPIC but fancy)? Or do you want to program them using a convenient legacy ISA and programming model?
No right answer here, I'm just genuinely curious. Telling me you don't care about performance and reject my multiple cores is a valid answer, too.
Anyway, this doesn't answer the question. Do you want to code this hypothetical array of hetero cores using an API, like DirectX or CUDA? Do you want to use an explicitly parallel ISA (like EPIC but fancy)? Or do you want to program them using a convenient legacy ISA and programming model?
No right answer here, I'm just genuinely curious. Telling me you don't care about performance and reject my multiple cores is a valid answer, too.
-
quantus
- Tenth Dan Procrastinator
- Posts: 4891
- Joined: Fri Jul 18, 2003 3:09 am
- Location: San Jose, CA
I think the answer is both with APIs being for the mass market. The APIs will abstract away the need to know what is underneath so you can use homogeneous or heterogeneous cores. This is good for most people. Then you have a translation layer, like a driver/library that implements these special API calls on hardware. It seems that drivers are better than libraries, but I can't really comment on the differences between the two that support this supposition. Anyways, the people writing the API will be the ones who care about how to get the hardware to do the actions specified by the API.
API's will probably win just because, it's hard to go the other way of making smart compilers and such as you pointed out in the past. We need to make higher level abstractions to make the compiler's job easier and also make the programmer's job easier as well. They won't want to care that it's better to traverse an array in one direction rather than another. They just want it to be fast. That's one reason why we have iterators these days. It removes the implementation detail. We need higher level constructs. Time to market is king.
Homogeneous vs heterogeneous will only matter depending on the application. You can usually get better perf with custom hardware over general purpose. The same is true with heterogeneous over homogeneous. The metric may be expanded to perf/watt/$ or whatever, so the balance may shift in favor of general purpose as it has in the last decade or so.
My idea was more like if you have a sea of heterogeneous cores:
CCCC
CCCC
CCCC
CCCC
But you might need to do vector operations, so your cores are special in that they can ask neighboring cores to slave up to it by taking in messages to drive the execution units instead of doing their own fetch and decode, so you mght get something like the following:
CCCC
MSSS
CCCC
CCCC
or
CCCC
CCMS
CCSS
CCCC
if you needed a 4-wide vector processor. The M will do the fetch and decode for all the S's too. Rather than build in vector operation units to handle SSE, you just ask neighboring processors to help get a similar increase in throughput. Now your chip may even be simpler to verify because the cores don't have transistors dedicated to SSE stuff.
Oh, how is an ISA not and API?
API's will probably win just because, it's hard to go the other way of making smart compilers and such as you pointed out in the past. We need to make higher level abstractions to make the compiler's job easier and also make the programmer's job easier as well. They won't want to care that it's better to traverse an array in one direction rather than another. They just want it to be fast. That's one reason why we have iterators these days. It removes the implementation detail. We need higher level constructs. Time to market is king.
Homogeneous vs heterogeneous will only matter depending on the application. You can usually get better perf with custom hardware over general purpose. The same is true with heterogeneous over homogeneous. The metric may be expanded to perf/watt/$ or whatever, so the balance may shift in favor of general purpose as it has in the last decade or so.
My idea was more like if you have a sea of heterogeneous cores:
CCCC
CCCC
CCCC
CCCC
But you might need to do vector operations, so your cores are special in that they can ask neighboring cores to slave up to it by taking in messages to drive the execution units instead of doing their own fetch and decode, so you mght get something like the following:
CCCC
MSSS
CCCC
CCCC
or
CCCC
CCMS
CCSS
CCCC
if you needed a 4-wide vector processor. The M will do the fetch and decode for all the S's too. Rather than build in vector operation units to handle SSE, you just ask neighboring processors to help get a similar increase in throughput. Now your chip may even be simpler to verify because the cores don't have transistors dedicated to SSE stuff.
Oh, how is an ISA not and API?