21–30 of 47 posts
Earlier quoted context omitted.
Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?
The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?
2) the map part is included in the accumulate lambda, so the map part cannot be parallelized either -> you'd have to split it out into a transform step (iirc)
Earlier quoted context omitted.
Both of them have to be completely rewritten to make use of multiprocessing, so what exactly is the advantage?
The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?
Earlier quoted context omitted.
The first one too? Isn't that the map-reduce fork-join golden example of multiprocessing?
`std::accumulate` is defined to have sequential semantics, so the analysis required to make it parallel is probably not that different than starting from the loop version. I guess you could have an alternate `accumulate_associative` that uses the same interface but assumes the reduction is associative and has unspecified evaluation order?
[flagged]
Trusting trust was based on old C. You don't get much more minimal than that.
Earlier quoted context omitted.
`std::accumulate` is defined to have sequential semantics, so the analysis required to make it parallel is probably not that different than starting from the loop version. I guess you could have an alternate `accumulate_associative` that uses the same interface but assumes the reduction is associative and has unspecified evaluation order?
C++ has std::reduce for that, which is std::accumulate except it's defined to operate without any specific ordering.
Trust the compiler - sure - but we can't change the whole program by using -ffast-math, unfortunately, so that particular one is out.
https://doc.rust-lang.org/std/primitive.f32.html#algebraic-o...
> Algebraic operators of the form a.algebraic_*(b) allow the compiler to optimize floating point operations using all the usual algebraic properties of real numbers – despite the fact that those properties do not hold on floating point numbers. This can give a great performance boost since it may unlock vectorization.
> The exact set of optimizations is unspecified but typically allows combining operations, rearranging series of operations based on mathematical properties, converting between division and reciprocal multiplication, and disregarding the sign of zero. This means that the results of elementary operations may have undefined precision, and “non-mathematical” values such as NaN, +/-Inf, or -0.0 may behave in unexpected ways, but these operations will never cause undefined behavior.
> Because of the unpredictable nature of compiler optimizations, the same inputs may produce different results even within a single program run. Unsafe code must not rely on any property of the return value for soundness. However, implementations will generally do their best to pick a reasonable tradeoff between performance and accuracy of the result.
I’ve seen some terrible horrid nonsense from them and even the best compilers don’t use a third of the opcodes our modern CPUs boast of. Nobody understands the big compilers any more either, they’re all too huge. And soon AI will be “improving” hem too. You want to see a beautiful compiler? Look at Plan 9’s compiler suite. A man could understand and even build on that.
> even the best compilers don’t use a third of the opcodes our modern CPUs boast of That’s not necessarily an indication of the weakness of compilers. It also could be an indication that hardware designers could leave out instructions. X86, in particular, will have lots of them for backwards compatibility reasons (extreme example: the old 80-bit x87 FP stack) There also are instructions that are expected to never get…
Every time I see "use ranges and algorithms!" examples, I am baffled that apparently, I am supposed to find inline double algorithm_call(std::span xs) noexcept { return std::accumulate( xs.begin(), xs.end(), 0.0, [](double acc, double volts) { auto mv = calibrated_mv(volts); auto err = residual(mv); return weighted_square(err) + acc; }); } more readable, concise, and easier on my eyes than inline double raw_loop(std:…
That's what abstraction is about.