Subj : Re: Thoughts about threads in C++ To : comp.programming.threads From : Marcin 'Qrczak' Kowalczyk Date : Fri Apr 29 2005 05:20 pm Maciej Sobczak writes: > My gut feeling is that by acknowledging the existence of concurrency > at the level of language control statements, you give the *compiler* > the insight into what will be executed in paraller. If the concurrent > blocks of statements are relatively simple, the compiler might opt to > skip the OS-level threading and prefer to directly push the > instructions into separate pipelines of the multicore CPU (if that is > possible). The same is possible if concurrency is done by library functions. Modern compilers already treat various standard functions specially, e.g. memcpy or mathematical functions. > By following the traditional approach where the concurrent statements > are hiddent behind a pointer to function, you basically prevent the > compiler from having this depth of insight and any further > optimization options are therefore limited. If the function is defined in the same compilation unit, the compiler can see what code it will execute. > The difference is conceptually similar to that between std::sort (in > C++) and qsort (in C). The former is way easier to optimize by code > inlining just because the comparison operation is not isolated behind > the pointer to function. std::sort uses a universal machinery of instantiating templates. In principle qsort could be optimized to yield as good code as std::sort, but since this would be a complex optimization specific to qsort, compiler vendors don't bother - the advantages are smaller than the cost. This doesn't apply to threads. No matter how they are exposed, the compiler would have to do non-trivial optimizations specific to threads. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/ .