News for hackers. Stuff that matters.
Re:Parallel STL by malkia on Friday May 08, 2015 @08:28PM (#9514896)
Spot on. There either needs to be some kind of OS level control (Grand Central), or tweaks through the environment, like OpenMP - where you set in advance how much threads are to be used by the process.

I think Microsoft's PPL had something where it would've cooperated with the OS, but things did not worked out as expected and it wasn't delivered. Or I could be completely wrong, some links here:

https://msdn.microsoft.com/en-us/library/ee207192.aspx

https://msdn.microsoft.com/en-us/library/dd984036.aspx

Re:Parallel STL by jfbastien on Friday May 08, 2015 @09:34PM (#9515067)
You're thinking of C++'s "executor", which is currently being discussed for addition to the standard. The parallel STL will use the executors once they're added to a technical specification. There's agreement on how integration this will work, and that it's the right thing to do, but executors don't have a fully agreed-upon API yet.

We (the C++ standards committee) discussed these things further this week :-)

Re:Parallel STL by malkia on Friday May 08, 2015 @09:40PM (#9515082)
Ah, thanks for correcting me. I've read about it year or more ago, a short article and I couldn't find it.
Re:Parallel STL by jfbastien on Friday May 08, 2015 @09:54PM (#9515133)
There are a lot of papers to follow, unfortunately. Listed here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/ http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/

You'll want to follow mostly Mysen's and Kohlhoff's proposals on executors.

Re:Parallel STL by jevinskie on Friday May 08, 2015 @08:59PM (#9514972)
I was going to suggest GCD as well. IIRC it's FreeBSD implementation is great and it's Linux port is adequate. But yes, queues, producers, consumers, and OS level parallelism is the way to go!