News for hackers. Stuff that matters.
Re:Intel, Samsung, and TSMC Demo 3D-Stacked Transistors by pjmlp on Sunday December 17, 2023 @05:21AM (#38671827)
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.

Re:Intel, Samsung, and TSMC Demo 3D-Stacked Transistors by fl7305 on Sunday December 17, 2023 @06:52AM (#38672244)
> 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.