I mean, theoretically it's possible. A super basic example would be if the data is known at compile time, it could be auto-parallelized, e.g.
int buf_size = 10000000;
auto vec = make_large_array(buf_size);
for (const auto& val : vec)
{
do_expensive_thing(val);
}
this could clearly be parallelised. In a C++ world that doesn't exist, we can see that it's valid.
If I replace it with
int buf_size = 10000000;
cin >> buf_size;
auto vec = make_large_array(buf_size);
for (const auto& val : vec)
{
do_expensive_thing(val);
}
the compiler could generate some code that looks like:
if buf_size >= SOME_LARGE_THRESHOLD {
DO_IN_PARALLEL
} else {
DO_SERIAL
}
With some background logic for managing threads, etc. In a C++-style world where "control" is important it likely wouldn't fly, but if this was python...
arr_size = 10000000
buf = [None] * arr_size
for x in buf:
do_expensive_thing(x)
You’re fixated on the very specific examples in our existing tools and saying that this wouldn’t work. Numpy could have a switch inside an operation decides whether to auto parallelise or not, for example. It’s possible but nobody is doing it. Maybe for good reasons, maybe for bad.
I’m doing no such thing. I’m providing an example of why verifiable industry trends and current technical state of the art are the way they are.
You providing examples of why it totally-doesn’t-need-to-be-that-way are rather tangential, aren’t they? Especially when they aren’t addressing the underlying point.
If I replace it with int buf_size = 10000000; cin >> buf_size; auto vec = make_large_array(buf_size); for (const auto& val : vec) { do_expensive_thing(val); }
the compiler could generate some code that looks like: if buf_size >= SOME_LARGE_THRESHOLD { DO_IN_PARALLEL } else { DO_SERIAL }
With some background logic for managing threads, etc. In a C++-style world where "control" is important it likely wouldn't fly, but if this was python...
could be parallelised at compile time.