Biggles 266 said:What this is good for is legacy applications. Older, or at least current, games which aren't multithreaded will benefit. Lots of old, but still usable, custom business software will benefit. Loads of stuff that currently depend upon a single thread will benefit.
Will it though? Business software and older games are hardly taxing for current CPUs. Current games may have a slight benefit but by the time AMD release this then we'll have moved onto other games - potentially multi-threaded ones.
Even programs that are currently multithreaded will benefit; you can have a program that spawns 20 threads, but if 19 of them barely do anything and only one uses lots of CPU times, then you will still find that a multiple-core machine will not be used to its full potential. This will be because the operating system assigns a thread to a core; but if only one core does most of the work then the program will still benefit from split over two cores.
You have to remember that they're are other threads (mainly O/S threads) that play apart in this and the OS scheduler will handle the balance of the threads. Easiest example is the main thread on one core and O/S Threads, background tasks and the other 19 threads on a seperate core. If the OS has multiple cores available then it'll handle the loading of those cores so that half the cpu isn't twiddling it's thumbs (and the Windows / Linux schedulers do a pretty good job of this task).
The thing is, it is incredibly difficult to write code that is really well threaded. Sure, you can write code that spawns extra threads here and there, and that is a good thing. But synchronisation issues are very much at the forefront of any coder who is doing concurrent programming.
Yes it is difficult to write threaded code, but not impossible - it's something which comes from experience as a programmer. This is the way things are going so they better start looking at multi-threaded development because it does have great benefits and is becoming a vital skill. As you've said, concurrency between threads and sync'ing threads is an issue in programming but it's not an issue to which we don't have a solution. We know how to sync' threads in various languages - it's just utilising it to it's full potential which is the current problem.
The other problem is how many cores too take advantage of? Two is a safe bet, but what about in the next year or two when four cores becomes more popular? Adding extra threads does create overheads - this anti-HT idea would give the benefits of adding extra threads but without the overheads that comes with it.
Developers shouldn't write for a specific number of cores. In order for a program to be truely scalable, it should have as many threads as it takes without going overboard. If a program can utilise 100 threads effectively then it should be written to spawn 100 threads (Apache is something that comes to mind - I think Apache spawns a thread of each persistant connection to it). I remember when HT came out and quite a few programs 'updated' their software to use this when all they basically did was make it dual-threaded - this won't scale well on Quad proc/core systems. Multi-threaded programs are mostly about scalability and hence shouldn't be written for a specific number of cores / procs.
Adding more threads creates very little overheads unless they are poorly coded. In actual fact, in single proc systems it makes scheduling and multi-tasking a bit more efficient (but not by much) and in SMP enviroments it's used quite efficiently. Even if a thread doesn't do all that much, it still allows the scheduler to arrange threads as efficiently as possible and provide good load balance over all processors and cores.