x86 CPUs from AMD & Intel current/future releases.

[casperes1996]

The other thing about OpenMP that is a little odd these days is the model of making synchronous code parallel, constrained by the design that the code should behave fundamentally the same if OpenMP is disabled at compile time (just on a single thread). The end result is that you will block the calling thread (i.e. main) when using OpenMP which is a bad situation to be in on Apple platforms. Say hello to the pinwheel of death.

Never used OpenMP, but in theory you could spin up your own background thread that deals with OpenMP and have a simple run loop in the main thread that just goes "Are there new things from the OpenMP multi-threading thread that I should respond to? No? I'll loop back around then" or something - At least I would imagine it'd be possible to make that sort of thing work, but of course this still comes at complexity costs

Regarding LibDispatch (GCD) on Windows - How does Swift Concurrency work on Windows?

 

[Nycturne]

Regarding LibDispatch (GCD) on Windows - How does Swift Concurrency work on Windows?

It's possible it got ported while I wasn't looking. Windows was a gleam in some bored engineer's eye last time I paid super-close attention.

I'm honestly surprised Concurrency uses libdispatch. I expected the Swift team to try to limit their dependence on the library with Concurrency, much as they are trying to back slowly away from some of the early "Just port Darwin's libraries to Linux" approach now that you have things like swift-nio for networking that are truly cross-plat but also not Apple's platform APIs.

Never used OpenMP, but in theory you could spin up your own background thread that deals with OpenMP and have a simple run loop in the main thread that just goes "Are there new things from the OpenMP multi-threading thread that I should respond to? No? I'll loop back around then" or something - At least I would imagine it'd be possible to make that sort of thing work, but of course this still comes at complexity costs

You could in principle, but that's getting into "Yo Dawg" territory to me. So now I'm managing threads so I can let OpenMP manage my threads.

 

[Andropov]

It's been a long time since I even looked at OpenMP that I forgot it relied on compiler directives.

Never used OpenMP, but in theory you could spin up your own background thread that deals with OpenMP and have a simple run loop in the main thread that just goes "Are there new things from the OpenMP multi-threading thread that I should respond to? No? I'll loop back around then" or something - At least I would imagine it'd be possible to make that sort of thing work, but of course this still comes at complexity costs

You could in principle, but that's getting into "Yo Dawg" territory to me. So now I'm managing threads so I can let OpenMP manage my threads.

I started (then dropped) a MSc in high performance computing just a couple years ago and they were teaching OpenMP including task creation for asynchronous purposes (so not the simple thread - fork - join model). I can't overstate how deranged the decision to base a multithreading API around compiler directives felt at the time, coming from a world where Swift Concurrency already existed. It's the opposite of what you want: the true and tested parts of the compiler know nothing about the concurrency details of what you're attempting to implement. No type safety, no exploiting existing compiler capabilities to attempt to have the compiler detect issues on your code. Just a custom syntax bolted on top of your program hidden in comments.

 

[casperes1996]

I'm honestly surprised Concurrency uses libdispatch. I expected the Swift team to try to limit their dependence on the library with Concurrency, much as they are trying to back slowly away from some of the early "Just port Darwin's libraries to Linux" approach now that you have things like swift-nio for networking that are truly cross-plat but also not Apple's platform APIs.

I think it's just step 1. I think their perspective was that it was easier to build concurrency on top of LibDispatch to begin with (pretty sure it already had been ported to Linux before Swift Concurrency?) than build a new system for it from scratch - and that they'll refactor it out later. Like SwiftUI separating more from UIKit lately - I could frankly see SwiftUI becoming cross platform mapping to GTK or Qt one day or something. I don't think it will happen, but I also wouldn't be shocked - Like a 15% chance of it happening or so.

You could in principle, but that's getting into "Yo Dawg" territory to me. So now I'm managing threads so I can let OpenMP manage my threads.

I don't know. It does sound like a janky way of doing it, but on the other hand your thread management could be über simple, with just a non-blocking main thread checking for data from the OpenMP workers so you only manage two effective threads. - But I dunno; It's certainly not ideal no matter what

 

[Nycturne]

I think it's just step 1. I think their perspective was that it was easier to build concurrency on top of LibDispatch to begin with (pretty sure it already had been ported to Linux before Swift Concurrency?) than build a new system for it from scratch - and that they'll refactor it out later. Like SwiftUI separating more from UIKit lately - I could frankly see SwiftUI becoming cross platform mapping to GTK or Qt one day or something. I don't think it will happen, but I also wouldn't be shocked - Like a 15% chance of it happening or so.

libdispatch was one of the libraries available from day 1 (or at least very early), along with Foundation and CoreFoundation, yes.

Concurrency according to the Swift devs only uses libdispatch for managing the thread pool, so the coupling is already quite light. I'm just surprised they went this far without simply cutting the cord at that point. It's a bit like going through the effort of making a sandwich and then deciding you are too tired to eat it. (All this said, Swift does support custom executors already, so implementers can replace libdispatch on different platforms: https://github.com/apple/swift/pull/39518)

SwiftUI the library? No. SwiftUI the DSL? Maybe. I already see people implementing SwiftUI-like libraries for other platforms.

I don't know. It does sound like a janky way of doing it, but on the other hand your thread management could be über simple, with just a non-blocking main thread checking for data from the OpenMP workers so you only manage two effective threads. - But I dunno; It's certainly not ideal no matter what

And the infrastructure to communicate between them, don't forget that. Another area that tends to be where people get things wrong with multithreading.

I started (then dropped) a MSc in high performance computing just a couple years ago and they were teaching OpenMP including task creation for asynchronous purposes (so not the simple thread - fork - join model). I can't overstate how deranged the decision to base a multithreading API around compiler directives felt at the time, coming from a world where Swift Concurrency already existed. It's the opposite of what you want: the true and tested parts of the compiler know nothing about the concurrency details of what you're attempting to implement. No type safety, no exploiting existing compiler capabilities to attempt to have the compiler detect issues on your code. Just a custom syntax bolted on top of your program hidden in comments.

It makes sense to me in the context of when it was developed and the goals. But a lot has changed in the last 20+ years in terms of thinking around concurrency.

 

[Andropov]

It makes sense to me in the context of when it was developed and the goals. But a lot has changed in the last 20+ years in terms of thinking around concurrency.

Yes. Sorry I didn't make that clear in my post. I see where they were coming from, and it totally made sense (back then) as an easy way to parallelize C/C++ programs for certain applications (ie scientific programs) where all you want is for the compiler to execute a loop in parallel. But once they added tasks and more complex stuff I think they should have realized that they were trying to do too much with an approach that was never designed for that.

 

[casperes1996]

And the infrastructure to communicate between them, don't forget that. Another area that tends to be where people get things wrong with multithreading.

My first thought here was "Well we can create channels, atomic flags […] - Then I stopped and thought "Yeah fair play, fairly high complexity"