9-bit bytes could easily make the common case ~12.5% slower everywhere. Most integers and chars fit in 8 bits no problem.
We'd be better off with 9-bit bytes
191–200 of 359 posts
Re: We'd be better off with 9-bit bytes
#192Earlier quoted context omitted.
Plato argued that 7! was the ideal number of citizens in a city because it was a highly factorable number. Being able to cut numbers up is an time-tested favorite. That's why there are 360 degrees.
Wonder why we don’t have 720 degrees… (6!)
Maybe because 360 is already divisible by 6, so 720 is not much of an upgrade over 5!. 7! On the other hand adds another prime factor to it.
Re: We'd be better off with 9-bit bytes
#193Earlier quoted context omitted.
Plato argued that 7! was the ideal number of citizens in a city because it was a highly factorable number. Being able to cut numbers up is an time-tested favorite. That's why there are 360 degrees.
And many of the conversions between metric and imperial align with the Fibonacci sequence on any order of magnitude. 130km/h is roughly 80mph simply because the fibo sequence has 8 and 13. Obviously not an emergent property but shows how these things were designed.
1 mile = 1,000 [double] paces of 0.8m each = 1,600m
1m = 1e-10 times half-meridian from the North Pole to the equator, via Paris for a croissant, apparently.
So kind of a coincindence... But a very neat one. Meanwhile, ratio of adjacent Fibonacci numbers converves to some expression involving sqrt(5) which is approx 1.6
Re: We'd be better off with 9-bit bytes
#194It would also make Base64 a bit simpler (pun intended), at the cost of a little more overhead (50% instead of 33%).
> a little more overhead (50% instead of 33%)
a little?
Re: We'd be better off with 9-bit bytes
#195I often wondered why not make the word 10 bits, so that unsigned char is 0..1023 (basically 1,000). I guess hardware considerations make sense.
Re: We'd be better off with 9-bit bytes
#196Perhaps the reason modern programs use so much memory vs what I remember from the Windows XP era is precisely because we went to 64 bits. Imagine how many pointers are used in the average program. When we switched over to 64 bits, the memory used by all those pointers instantly doubled. It's clear that 32 bits wasn't enough, but maybe some intermediate number between 32 and 64 would have added sufficient capacity wit…
Because of aligned reads any pointer size between 32-bit and 64-bit would end up using 64-bits anyway.
Re: We'd be better off with 9-bit bytes
#197Earlier quoted context omitted.
[flagged]
What do you think they missed? What they said seems accurate: You're putting a lot of faith in ChatGPT that doesn't seem warranted.
It's not an argument for longer roads or can kicking? The thesis is stated at the top: with 9 bit bytes we'd avoid a couple of bad numerological coincidence (like that the number of Chinese characters is vague but plausibly around 50k, or the population of the earth is small integer billions). By avoiding the coincidences we'd avoid certain problems entirely. Unicode is growing but we're not discovering another Chinese! Not will world population ever hit 130B, at least as it looks now.
If you think there's some equally bad coincidence go ahead and tell me but no one has yet. I think I do a good job of that in the post. (Also it's amazing you and maybe everyone else assume I know nothing except what ChatGPT told me? There are no ads on the website, it's got my name face and job on it, etc. I stand by what I wrote.)
Re: We'd be better off with 9-bit bytes
#198Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
I mean the post is silly, why not just say 10 bit bytes lol, shit then bits/bytes could be metric lol
Re: We'd be better off with 9-bit bytes
#199Because we have 8 bit bytes we are familiar with the famous or obvious cases multiples-of-8-bits ran out, and those cases sound a lot better with 12.5% extra bits. What's harder to see in this kind of thought experiment is what the famously obvious cases multiples-of-9-bits ran out would have been. The article starts to think about some of these towards the end, but it's hard as it's not immediately obvious how many…
Author here. Actually I doubt we'd have picked 27-bit addresses. That's about 134M addresses; that's less than the US population (it's about the number of households today?) and Europe was also relevant when IPv4 was being designed. In any case, if we had chosen 27-bit addresses, we'd have hit exhaustion just a bit before the big telecom boom that built out most of the internet infrastructure that holds back transiti…
why not 10 bit bytes and 40 bit addresses and nice 2 based metric based measures :)
Re: We'd be better off with 9-bit bytes
#200Non-power-of-2 sizes are awkward from a hardware perspective. A lot of designs for e.g. optimized multipliers depend on the operands being divisible into halves; that doesn't work with units of 9 bits. It's also nice to be able to describe a bit position using a fixed number of bits (e.g. 0-7 in 3 bits, 0-31 in 5 bits, 0-63 in 6 bits), e.g. to represent a number of bitwise shift operations, or to select a bit from a…
The Nintendo 64 RDP(graphics/memory controller) used 9 bit bytes. This was done for graphics reasons, native antialiasing if I understand it. The cpu can't use it. it still only sees 8-bit bytes. https://www.youtube.com/watch?v=DotEVFFv-tk (Kaze Emanuar - The Nintendo 64 has more RAM than you think) To summarize the relevant part of the video. The RDP wants to store pixel color in 18 bits 5 bits red 5 bits blue 5 bit…
> a common optimizing operation for most architectures is to trade calculation for memory(unroll loops, lookup tables...)
That really depends. A cache miss adds eons of latency thus is far worse than doing a few extra cycles of work but depending on the workload the reorder buffer might manage to negate the negative impact entirely. Memory bandwidth as a whole is also incredibly scarce relative to CPU clock cycles.
The only time it's a sure win is if you trade instruction count for data in registers or L1 cache hits but those are themselves very scarce resources.