deadrats wrote:1) the common programming language C is about 40 years old (from circa 1970) and does not have native support for threads, you need to use a threading library like pthreads or the win api and neither of those is all that easy to work with. if programming languages allowed programmers to do something like:
thread1{
commands go here};
thread2{
commands go here};
you would see much more multi-threaded code, however you have a chicken and the egg scenario, programming languages haven't traditionally offered programming constructs like that because cpu's didn't have many cores and cpu's didn't have many cores because programming languages didn't allow for easy multi-threading.
1) The inelegant expression or obtuseness of the APIs is not the primary problem when it comes to threading. The difficulty of using threads is not the limiting factor, rather, it is the difficulty of using threads
well. You are treating the entire concept of concurrent execution as little more than a programming language's high-level primitive, and that's ridiculous. Those are just tools. The relative ease of handling the tools has very little to do with the overall difficulty of the project you are attempting to finish with them.
2) The difficulty in using concurrent execution for single programs is coherent synchronization. Thread 1, thread 2, thread
n are all trying to accomplish result 1. Your multiplicity of threads is working towards a unity of result, and this means that your program is going to have to resolve them together somehow at some point. This problem is not even remotely trivial. Race hazards
suck and the methods needed to prevent them sap performance, increase development time, and require skill.
3) Your chicken & egg narrative is simply wrong. Hardware historically lacked SMP because it was prohibitively expensive. It wasn't until the gains from using transistors towards IPC began to level off that it made sense to start going after TPC. They reason you didn't see two original pentiums on the same die is because it was uneconomical to the point of being physically infeasible.
4) Your narrative about programming language is inaccurate. Procedural programming languages are
inherently uncomfortable with threading because of their paradigm; they are step-by-step depictions of the execution environment and threading completely confounds that. It's easy for you to invoke "thread 1 do this" and "thread 2 do that", but that's clearly just a description of two different programs you've merely called threads. The question isn't what they are doing separately,
but what they are separately doing together. Keeping that effort coherent means either leaving the procedural concept altogether or making it thread-safe, something you cannot invoke via a primitive. In reality, it usually takes an intensive amount of effort to make code thread-safe, and that's what most of those APIs you mention are about. Even then, they merely provide the tools to do it correctly, it's ultimately up to the programmer.
deadrats wrote:in fact if you ever go through a comp sci program, you won't take a class on multi-threaded programming until your third or fourth year, though that may be different in colleges like penn state that have switched to teaching all their comp sci classes in java as java has multi-threading built into the language.
Which is indicative of the fact that TLP isn't remotely simple. You have to be well-versed in all the basics before you can even begin.
As to using a new language like java, you're really asking a different question at that point.
deadrats wrote:you are however seeing the better programmers taking advantage of Open CL, Direct Computer and CUDA to leverage the multiple streaming cores within gpu's to allow for the calculation of physics and AI on the gpu (that's why many games only enable certain physics effects via PhsyX, because a gpu with it hundreds of cores is capable of handling all the collision calculations without choking while a cpu with just a handful of alu's would be brought to it's knees of it tried to perform hundreds of collision calculations per second.
Flappy flags and moar particle effects! Whooo! I'm glad I spent all that money on "better programmers."
I actually had forgotten about the luddites who haven't upgraded their operating system in a decade. However, I guess someone's got to still be providing the computing power for the botnets. 
