I think AMD is going to have the 5770 and 5750 live on as their lower-midrange cards while these will become the upper-midrange cards. The top of the line (single die) cards will then be named 69XX. Not sure what they are going to do with the dual die cards (perhaps bring back the X2 naming convention).
It makes sense for AMD to hold off on updating their lower end offerings since consumers are less demanding at this price point.
I don't loathe C++ as much as some people, but I am not much of a fan either.
To me C++ (and Java) is too much of a middle road between lower level languages (like C) and higher level languages (Python, Perl, etc). I prefer to write the bulk of my code in a high level language like Python, profile the code, and then rewrite performance critical sections in C (which is relatively easy to integrate with Python). This gives a good balance between performance, development speed, and maintainability.
You are fundamentally wrong for many reasons:
1) Highly data-parallel problems (like graphics) are always going to be solved faster on a GPU-like architecture.
2) GPUs are gaining processing power at a higher rate than CPUs.
3) Power/heat/cost for the number of CPUs needed to match the processing power of a GPU-based solution is always going to be worse.
The mentality of one size fits all for processor architectures is what is actually dying.
Slashdot Mirror
I think AMD is going to have the 5770 and 5750 live on as their lower-midrange cards while these will become the upper-midrange cards. The top of the line (single die) cards will then be named 69XX. Not sure what they are going to do with the dual die cards (perhaps bring back the X2 naming convention).
It makes sense for AMD to hold off on updating their lower end offerings since consumers are less demanding at this price point.
I don't loathe C++ as much as some people, but I am not much of a fan either. To me C++ (and Java) is too much of a middle road between lower level languages (like C) and higher level languages (Python, Perl, etc). I prefer to write the bulk of my code in a high level language like Python, profile the code, and then rewrite performance critical sections in C (which is relatively easy to integrate with Python). This gives a good balance between performance, development speed, and maintainability.
You are fundamentally wrong for many reasons: 1) Highly data-parallel problems (like graphics) are always going to be solved faster on a GPU-like architecture. 2) GPUs are gaining processing power at a higher rate than CPUs. 3) Power/heat/cost for the number of CPUs needed to match the processing power of a GPU-based solution is always going to be worse. The mentality of one size fits all for processor architectures is what is actually dying.