As I mentioned earlier, part of my fall schedule is to give a repeat of this spring’s sold-out seminar: “High-Performance and Low-Latency C++” (October 9-11, London, UK).
I am still getting mails about whether there are alternative/additional European dates for this seminar. Unfortunately, the answer is still no, but since I’m getting inquiries about it let me repeat that part of the earlier post:
On October 9-11, I’ll be in London giving a one-time repeat of “High-Performance and Low-Latency C++” (course details page). This is the same as the public course I gave in Stockholm [in April]; because that course sold out, and I was coming to Europe again for Qt World Summit anyway, we decided to do a single repeat that same week, this time in London.
Notes: (1) Some of you have emailed me asking if there will be other dates/cities, and the answer is no, sorry, I do seminars very rarely and this is the last one I have time to do for the foreseeable future. So if you are interested then this is the one to attend. (2) Some of you have also emailed me to ask whether the seminar will be recorded, and the answer is again no, sorry, the organizers are not set up for that. However, you can find all of my past Effective Concurrency writing (on which parts of this course are based) freely available via this blog, just search for that phrase or use the category tag — there’s a book’s worth of free material written by me in individual-article form.
So, if you’re interested, I hope you’ll be able to attend this October, and I look forward to seeing many of you there.
Sutter’s Mill 
Are you aware of this portability issue with visual c++ and c++11 threads?
https://chrisgreendevelopmentblog.wordpress.com/2017/08/29/thread-pools-and-windows-processor-groups/
It basically breaks the promise of being able to write high performance threaded code portably in c++ on high end xeon systems. The most trivial parallelism implementation written using std::thread, when run under linux on the same box will use all cores, but compilation with visual c++ will result in an executable which uses a fraction of the available processing power.
I think not addressing it is a mistake. Sure, it was easy to work out a (non-portable) fix, but I never would have been aware of the problem were I not coding on such a machine. Large amounts of commercial and open source-software will be written without knowledge of this, resulting in apps that cannot take full advantage of parallelism on such boxes. It needs to be addressed in the STL implementation IMHO.
It’s easy to address, and a fix will not change the current behavior in any way, except when running on systems with really large numbers of cores.
I thought about writing a program to hook thread creation in compiled executables, but I don’t believe it would work well, because apps still won’t know how many threads to create, since std::thread::hardware_concurrency() will still return a result less than the number of cores/HT threads.
That’s a fantastic news!!