3 ms·
Size reduction usually follows but not necessarily. That is easily measured is an irrelevance. The claim that its a decently predictive proxy I can't buy at the
by _a_a_a_ 2y ago
Size reduction usually follows but not necessarily. That is easily measured is an irrelevance. The claim that its a decently predictive proxy I can't buy at the moment, can you try justifying that? Some very terse code can be very hard to understand without (comprehensive) commenting eg. https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overview_of_the_code https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
Maybe you're right. I've had a drink, I'll think over it in the morning, thanks.
- jholman 2y agoIf you don't care about performance, we can make that code a lot shorter. float Q_rsqrt(float number) { return 1 / sqrt(number); } The "fast inverse square root" is absolutely 100% all about performance. For it to make sense to use as a counter-example, you need to show alternate code that still meets the contract (the contract being: be as fast as this code), that is longer, and clearer.
- _a_a_a_ 2y agoI was saying that shorter code is not necessarily more readable. But what you're talking about is optimisation and I'm fine with that, uglier code for higher speed (or whatever). But is that refactoring? I don't think so. I may have led you a bit down the garden path here.