← Back to context

Comment by TacticalCoder

2 years ago

I find it interesting that all the answers using hardcoded values / if statements (or while) are all doing up to five comparisons.

It goes B, KiB, MiB, GiB, TiB, EiB and no more than that (in all the answers) so that can be solved with three if statements at most, no five.

I mean: if it's greater or equal to GiB, you know it won't be B, KiB or MiB. Dichotomy search for the win!

Not a single of the hardcoded solutions do it that way.

Now let's go up to ZiB and YiB: still only three if statements at most, vs up to seven for the hardcoded solutions.

I mention it because I'd personally definitely not go for the whole log/pow/floating-points if I had to write a solution myself (because I precisely know all too well the SNAFU potential).

I'd hardcode if statements... But while doing a dichotomy search. I must be an oddball.

P.S: no horse in this race, no hill to die on, and all the usual disclaimers

I would expect your binary search solution is possibly slower than just doing 6 checks because the latter is only going to take 1 branch. Branching is very slow. You want to keep code going in a straight line as much as possible.

  • Yup, know your hardware and know problem. Dichotomic search is wonderful when your data can't fit in RAM and it starts being more efficient to cut down on number of nodes traversed.

    for a problem space limited by your input size (signed 64 bit number) to a 6 entry dictionary? At best you may want to optimize some in-lining or compiler hints if your language supports it. maybe setup some batching operations if this is called hundreds of times a frame so you're not creating/desrtoying the stack frame everytime (even then, the compiler can probably optimize that).

    But otherwise, just throw that few dozen byte lookup table into the registers and let the hardware chew through it. Big N notations aren't needed for data at this scale.

It depends on the input distribution. If it’s very common to have smaller values then the linear search could be superior.

Your comment and mine are basically the same. This is what I call terrible engineering judgement. A random co-worker could review the simple solution without much effort. They could also see the corner cases clearly and verify the tests cover them. With this code, not so much. It seems like a lot of work to write slower, more complex, harder to test and harder to review code.