The scientific “unit” we call the decibel

The speed of cryptographic function such as ciphers and hashes are quoted in cycles per byte. This is because in the pure numeric code, without worrying about memory transfer speed, the speed of the crypto algorithm is directly proportional to the CPU clock speed. https://en.wikipedia.org/wiki/Encryption_software#Performanc... . Random example: https://bench.cr.yp.to/results-hash/amd64-hertz.html

> if the actual CPU speed is 838,860,800Hz, how many bytes does it process in 1 second?

If the CPU is 800 MiHz (never heard of that term, lol), then it processes 800 MiB in 1 second. Stated differently, 839 MHz --> 839 MB.

> Remarkable circular reasoning

No, I'm pointed out that the industry has already splintered into two. Your "16 GB" of RAM is a different measure than "16 GB" of HDD or SSD.

> It is thus not a part of metric system so SI has zero business regulating information storage.

If a byte is not derived from fundamental SI units, then it should not take on SI prefixes.

Otherwise, if it takes on prefixes, it should respect the SI definition and not abusively have its own contradictory definition.

> On the other hand you can't buy a computer that does not address memory in anything other than powers of two.

So what? I can use that same logic to argue that all RAM sizes should be quoted in base-2, so I'm buying 1_0000_0000_0000_0000 (base-2) bytes of RAM, right? Clearly base-10 notation is a poor fit, so why not go all the way to base-2?

> Nor you could ever buy a 1000 million bytes RAM chip

It is certainly feasible. You can just cut a bunch of rows at the end. I know how binary decoder gates work.

Also, if you have a computer and put in a 4 GiB stick of RAM and a 2 GiB stick, then you have 6 GiB of addressable memory, which is clearly not a power of 2.

That's called throughput, and denomination for it absolutely doesn't matter. You can measure it in megabytes as well as in MarketingMegabytes.

> If the CPU is 800 MiHz (never heard of that term, lol), then it processes 800 MiB in 1 second.

Plot twist, your 800MHz CPU oscillator would never run at 800,000,000Hz sharp for any substantial stretch of time. And clock specs are typically rounded numbers. That's why this whole example is ridiculous.

> No, I'm pointed out that the industry has already splintered into two.

No shit it did. My point is that it did it for no advantage at all. You could measure storage megabytes in same normal sane megabytes as before, just couldn't lie about it to the customers.

> If a byte is not derived from fundamental SI units, then it should not take on SI prefixes.

Kilo is a Greek prefix, not SI prefix. You can split hairs that it should mean sharp thosuand but it does not exist in terms of computer architecture. Kibi however is completely made up shit used by noone else and it sounds like a wannabe cartoon character.

> It is certainly feasible.

It is not feasible, that's why they aren't ever gonna be made.

> Also, if you have a computer and put in a 4 GiB stick of RAM and a 2 GiB stick, then you have 6 GiB of addressable memory, which is clearly not a power of 2.

It is not a power of 10 either, you should really think this through.

> So with just 2× = 3.01dB we already know (...) 8, to fairly good precision. (...) (The most imprecise of these is 8: 10⁰·⁹ is about 7.94, which is an error of about -0.7% when the right answer was 8.)

This is slightly mixed up. It's true that approximating 8× as 9dB gives you an 0.7% error. But I was talking about 3.01dB, and approximating 8× as 9.03dB gives 7.998×, only about 0.02% low.

The errors for the logarithms of the 10 digits thus approximated are:

  >>> print('\n'.join([f'  {10*p:.2f}: {100*(10**p-i-1)/(i+1):+.3f}%' for i, p in enumerate([0, .301, .477, .602, .699, .778, .845, .903, .954])]))
  0.00: +0.000%
  3.01: -0.007%
  4.77: -0.028%
  6.02: -0.014%
  6.99: +0.007%
  7.78: -0.035%
  8.45: -0.023%
  9.03: -0.021%
  9.54: -0.056%