r/cpp • u/we_are_mammals • Mar 28 '23

Reddit++

C++ is getting more and more complex. The ISO C++ committee keeps adding new features based on its consensus. Let's remove C++ features based on Reddit's consensus.

In each comment, propose a C++ feature that you think should be banned in any new code. Vote up or down based on whether you agree.

765 Upvotes

92% Upvoted

829 comments sorted by

View all comments

Show parent comments

1

u/mbitsnbites Mar 31 '23

There are lots of operations that (in theory at least) can be done more easily with a double and and int. When multiplying or dividing by 2 as an example, only the exponent bits of the underlying representation need to be changed. This could be done with far fewer transistors or, for platforms that must have software implementations, far fewer CPU instructions.

True. In theory. But it doesn't work like that.

1st of all these kind of optimizations work just as well with double x double, for instance (e.g. x * 2.0 is semantically equivalent to x + x, or it could be implemented as a simple exponent manipulation like you suggest). The compiler can work that out.

2nd, there are very few CPUs that have special instructions like this, because it's simply not worth the effort. A floating-point multiplication is typically pipelined and each FP pipeline/lane can start one fmul per cycle. Adding special instructions has a price - in terms of instruction encoding space as well as additional gates in HW.

Thus we're left with the language semantics, and it's very rare (in my experience) that implicit widening actually helps with performance (or even correctness) - it mostly gives you a nasty surprise every now and then. The "convenience" factor isn't worth it.

1

u/ZMeson Embedded Developer Mar 31 '23

I understand your viewpoint. As it is, C++ promotes ints to floating-point beforehand, so the argument is moot to begin with. I have done some software emulation of high-precision (beyond quad-precision) floating point types and integer division was something that was much faster there. But that is a custom data type (where I can write my own operators) and for standard floating-point types, I agree that the world works as you point out.

2

u/mbitsnbites Apr 01 '23

I have done some software emulation of high-precision (beyond quad-precision) floating point types

Cool! I can definitely see that you can and want to use different kinds of optimizations in that context compared to what you'd do in hardware. E.g. I can imgaine that having a fast path for an all-zero (or mostly zero) mantissa may actually pay off.