If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

^^This.^^ Thread-spawning on Linux is at least as easy as on Windows, if not more so. API's such as Intel's Threading Building Blocks make coding multi-threaded programs that spawn any (finite) number of threads very straghtforward, hiding an awfully large portion of the bookkeeping. Intel (Cilk) and Microsoft (AMP) both have working C++ extensions that codify massive-multi-threading as part of the language. The HPC big-boys -- the ones who spawn the thousands of threads modelling everything from weather to climate to nukes to in-vivo protein conformations on the Really Big Iron, code mostly in Fortran and C++. I think it premature to hope either will somehow be "displaced" within our lifetimes. Continue to evolve, yes.

That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.

If this is true, either standardisation committee is insane or compiler devs are incompetent.
I guess it is rather lack of interest.

Why would you prefer to roll your eyes and guess wrong rather than go ahead and look at the relevant pages? The issues are very well documented and are not due to issues with standards body or developers.

That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.

Never said they could. You are perhaps trying to create an argument where none exists?

Why would you prefer to roll your eyes and guess wrong rather than go ahead and look at the relevant pages? The issues are very well documented and are not due to issues with standards body or developers.

That multi-tread model that some of you describe doesn't exist. For example, a video encoding program can have 1000 threads for a movie. That's because a movie has a key-frame every 6 second and the next frames are depend on that frame. So 6000 seconds=1000 maximum possible threads. Cannot have 2000 threads even if "God" wants to. An office program cannot have more than two threads for the same reason. You have a program with if/else, first goes the one and only then the other. You have two equations, you cannot run them in parallel because the outcome of the first is a variable of the second, so you must have the first finished. Programming language has nothing to do with paralelization. And those helpers cannot do magically the job.

I don't see why you would be limited to 1 tread per key-frame. It should be possible to work on multiple parts of a frame simultaneously, you could for example spawn a tread per block, with a block size of 16x16 that would give you 8160 treads per key-frame. Probably not optimal in some ways but a lot more then 1.