What I'd like to see is on-chip or even on-die FPGAs. Or, more realistically, a socketed FPGA that would go along with AMDs plans to allow coprocessors on dual boards. Since most tasks don't see much improvement from parallelization, being able customize a single fast FPGA to the tast could be more useful. Imagine an FPS reprogramming the FPGA to run their own particular brand of AI on it, etc.
"Imagine an FPS reprogramming the FPGA to run their own particular brand of AI on it, etc."
Not likely -- remember that pretty much all current OS's are multitasking. What happens when the FPS finishes its execution time and another application executes for a time -- does that second app get to reprogram the FPGA every time too? And back again?
Constant reconfiguration doesn't seem too efficient to me, not to mention the added software complexity.
For the story itself:
Five years is not going to be enough for this. We don't even have adequate tools to write such massively parallel programs with ease and designing/building such tools could well take that long (or longer). Even if we end up with compilers capable of automating much of the hassle (unlikely -- I'm expecting some app-level changes, maybe even specialist programming languages), debugging a highly parallel system can be an absolute nightmare.
You can't rely on the OS to take advantage of that many cores automatically either, as (at least at present) I'm sure they just move processes/threads onto different cores. If you just have one or two running applications this will not work so well unless the apps are designed specially, etc... You see this now with some older (faster) single-core processors still outperforming their dual-core brethren at some tasks.
Reader Comments (Page 1 of 1)
cmonkey @ Feb 11th 2007 8:03PM
What I'd like to see is on-chip or even on-die FPGAs. Or, more realistically, a socketed FPGA that would go along with AMDs plans to allow coprocessors on dual boards. Since most tasks don't see much improvement from parallelization, being able customize a single fast FPGA to the tast could be more useful. Imagine an FPS reprogramming the FPGA to run their own particular brand of AI on it, etc.
Pete @ Feb 11th 2007 8:36PM
"Imagine an FPS reprogramming the FPGA to run their own particular brand of AI on it, etc."
Not likely -- remember that pretty much all current OS's are multitasking. What happens when the FPS finishes its execution time and another application executes for a time -- does that second app get to reprogram the FPGA every time too? And back again?
Constant reconfiguration doesn't seem too efficient to me, not to mention the added software complexity.
For the story itself:
Five years is not going to be enough for this. We don't even have adequate tools to write such massively parallel programs with ease and designing/building such tools could well take that long (or longer). Even if we end up with compilers capable of automating much of the hassle (unlikely -- I'm expecting some app-level changes, maybe even specialist programming languages), debugging a highly parallel system can be an absolute nightmare.
You can't rely on the OS to take advantage of that many cores automatically either, as (at least at present) I'm sure they just move processes/threads onto different cores. If you just have one or two running applications this will not work so well unless the apps are designed specially, etc... You see this now with some older (faster) single-core processors still outperforming their dual-core brethren at some tasks.