4 ms·

> They are mostly programmed in managed languages, where the respective runtimes and OS collaborate, in order to distribute the computing across all available c

by fl7305 3y ago

> They are mostly programmed in managed languages, where the respective runtimes and OS collaborate, in order to distribute the computing across all available cores in the best way possible, with little intervention required from the developers side. I was under the impression that distributing workloads across many CPU cores (or HW threads) is done at the process and thread level by the OS? That gives managed and unmanaged languages the same benefits. Managed languages provide higher level primitives that makes it easier to create a multi-threaded application. But isn't that still manually coded in the mainstream managed languages? I'm thinking of inherently CPU-intensive custom workloads. UI rendering and IO operations become automatically distributed with little intervention. Or am I missing something, where there is "little intervention required from the developers side" to create multi-threaded apps?

pjmlp 3y ago
You are missing the part that ART, Swift/Objective-C runtime, and stuff like Gran Central Dispatch also take part in the decision process. So the schedulers can decide in a more transparent way what runs where, specially on Android side, where the on-device JIT/AOT compilers are part of the loop. Additionally, there is more effort on having the toolchains explore SIMD capabilities, where on C and C++ level one is expected to write that code explicilty. Yes, auto-vectorization isn't as good as writing the code explicitly, however the latter implies that only a niche set of developers actually care to write any of it. Hence why frameworks like Accelerate exist, even if a JIT isn't part of the picture, the framework takes the best path depending on available hardware. Likewise higher level managed frameworks offer a better distribution between the parallel processing taking part across CPU, GPU or NPU, which again on classical UNIX/Win32 in C and C++, have to be explicility programmed for. Such higher level frameworks can of course also be provided in such languages, e.g. CUDA and SYCL, howver then we start discussing about programmer culture to adopt such kind of tooling in classical LOB applications.
- fl7305 3y ago
  > ART, Swift/Objective-C runtime, and stuff like Grand Central Dispatch I don't know these, but from a quick googling it still looks like explicit multi-threading? Albeit with higher level primitives than in older languages, but still explicit? > auto-vectorization I'm not sure I see a hard dividing line between older languages and managed ones as far as auto-vectorization? Sure, a higher-level language might make it easier for the compiler since it knows more about potential side effects, but simple and local C code doesn't have any side effects either. > with little intervention required from the developers side > Hence why frameworks like Accelerate exist, even if a JIT isn't part of the picture Accelerate looks nice, but it still looks like it has to be called explicitly in the user code? > Likewise higher level managed frameworks offer a better distribution between the parallel processing taking part across CPU, GPU or NPU, which again on classical UNIX/Win32 in C and C++, have to be explicility programmed for. I'm not sure I understand, can you give more explicit examples? My point here isn't that managed languages don't give big benefits over C. I prefer Python and C# when those can be used. It's more that I don't see "automatic parallel processing" as a solved problem? Sure, we get better and better primitives for multi-threading, and there are more and more high-level parallel libraries like you mentioned. But for most cases, the programmer still has to explicitly design the application to take advantage of multiple cores.

by fl7305 3y ago

pjmlp 3y ago

You are missing the part that ART, Swift/Objective-C runtime, and stuff like Gran Central Dispatch also take part in the decision process. So the schedulers can decide in a more transparent way what runs where, specially on Android side, where the on-device JIT/AOT compilers are part of the loop. Additionally, there is more effort on having the toolchains explore SIMD capabilities, where on C and C++ level one is expected to write that code explicilty. Yes, auto-vectorization isn't as good as writing the code explicitly, however the latter implies that only a niche set of developers actually care to write any of it. Hence why frameworks like Accelerate exist, even if a JIT isn't part of the picture, the framework takes the best path depending on available hardware. Likewise higher level managed frameworks offer a better distribution between the parallel processing taking part across CPU, GPU or NPU, which again on classical UNIX/Win32 in C and C++, have to be explicility programmed for. Such higher level frameworks can of course also be provided in such languages, e.g. CUDA and SYCL, howver then we start discussing about programmer culture to adopt such kind of tooling in classical LOB applications.

fl7305 3y ago
> ART, Swift/Objective-C runtime, and stuff like Grand Central Dispatch I don't know these, but from a quick googling it still looks like explicit multi-threading? Albeit with higher level primitives than in older languages, but still explicit? > auto-vectorization I'm not sure I see a hard dividing line between older languages and managed ones as far as auto-vectorization? Sure, a higher-level language might make it easier for the compiler since it knows more about potential side effects, but simple and local C code doesn't have any side effects either. > with little intervention required from the developers side > Hence why frameworks like Accelerate exist, even if a JIT isn't part of the picture Accelerate looks nice, but it still looks like it has to be called explicitly in the user code? > Likewise higher level managed frameworks offer a better distribution between the parallel processing taking part across CPU, GPU or NPU, which again on classical UNIX/Win32 in C and C++, have to be explicility programmed for. I'm not sure I understand, can you give more explicit examples? My point here isn't that managed languages don't give big benefits over C. I prefer Python and C# when those can be used. It's more that I don't see "automatic parallel processing" as a solved problem? Sure, we get better and better primitives for multi-threading, and there are more and more high-level parallel libraries like you mentioned. But for most cases, the programmer still has to explicitly design the application to take advantage of multiple cores.