Earlier quoted context omitted.
Factorio logic applies as always - powers of 2 for trains belts etc. makes evenly splitting resources trivial.
Unfortunately belt speed gain per tier is linear and 1:3 blue:yellow belt.
but we have green belts now!
We'd be better off with 9-bit bytes
291–300 of 359 posts
Re: We'd be better off with 9-bit bytes
#292Earlier 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.
360 degrees in a circle predates Plato by quite a lot (2000 years I think!). It comes from the Summarians more than 4000 years ago. They used a method of counting on fingers that goes up to 12 on one hand and 60 using both hands, so their numbering system was based on 60. 360 is 6 * 60 and also roughly how many days in a year. Later societies inherited that from them along with 60 minutes in and hour.
But why wasn't the handcounting inherited too?
It sounds useful to be able to count up until 60 on two hands.
Re: We'd be better off with 9-bit bytes
#293Earlier quoted context omitted.
Yeah but if the CPU can't use it then it's kinda like saying your computer has 1,000 cores, except they're in the GPU and can't run general-purpose branchy code In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. It doesn't address more than 4 GB of anything ever
> In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. Usually the size of general purpose registers is what defines the bitness of a CPU, not anything else (how much memory it can address, data bus width, etc). For instance, the 80386SX was considered a 32-bit CPU because its primary register set is 32-bit, despite the fact it had a 24-bit external address bus and a…
>Usually the size of general purpose registers is what defines the bitness of a CPU
The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Re: We'd be better off with 9-bit bytes
#294Non-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…
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.
I've always held opinion that ideal base for our day life computation is 12. It's close enough to 10, so most things would work just as well (like you just need to remember 2 more digits), but it's actually divisible by 3, 4, 6 which is a lot more useful than 5, compared to 10-base.
Re: We'd be better off with 9-bit bytes
#295Earlier quoted context omitted.
> That's why there are 360 degrees. Not that these are exclusive, but I thought it's a rounding of 365.25 days a year stemming from Egypt. 360 is a pretty useful number of degrees for a starry sky that changes ince a night.
I believe the 360 degrees is attributed to Babylonians, who were using the Sumerian base 60 number system (6*60=360)
It's attributed, but the Babylonians knew a year was about 360 days.
Re: We'd be better off with 9-bit bytes
#296Earlier quoted context omitted.
> In fact, it's not even useful to say it's a "64-bit system" just because it has some 64-bit registers. Usually the size of general purpose registers is what defines the bitness of a CPU, not anything else (how much memory it can address, data bus width, etc). For instance, the 80386SX was considered a 32-bit CPU because its primary register set is 32-bit, despite the fact it had a 24-bit external address bus and a…
>Usually the size of general purpose registers is what defines the bitness of a CPU The Motorola 68000 has 32-bit registers but it's usually considered a 16-bit CPU because it has 16-bit ALU and 16-bit data bus (both internal and external).
Motorola 68k is a curious case because it originally was supposed to be a 16bit cpu, not 32bit, and the 24bit addressing that ignored upper 8 bits didn't help the perception.
Ultimately, 68k being "16bit" is a marketing thing from home computers that upgraded from 8bit 6502 and the like to m68k but didn't use it fully.
Re: We'd be better off with 9-bit bytes
#297Because 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…
When 32 bits were chosen it was because it was deemed a temporary thing for an experimental protocol, so there was no need to invest into proposed 128bit addressing by IIRC Vint Cerf (or 160 bit addresses of ITU/ISO protocols).
After all, we were supposed to switch off IPv4 in 1990...
Re: We'd be better off with 9-bit bytes
#298Earlier quoted context omitted.
Brillant, that 36 bits would be three bytes. "DEC's 36-bit computers were primarily the PDP-6 and PDP-10 families, including the DECSYSTEM-10 and DECSYSTEM-20. These machines were known for their use in university settings and for pioneering work in time-sharing operating systems. The PDP-10, in particular, was a popular choice for research and development, especially in the field of artificial intelligence. " "Compu…
Personally I think 12/48/96 would be more practical than the current 8/32/64. 32 bits is almost trivially easy to overflow whereas 48 bits is almost always enough when working with integers. And 64 bits is often insufficient or at least uncomfortably tight when packing bits together. Whereas by the time you've blown past 96 you should really just bust out the arrays and eat any overhead. Similarly I feel that 24 bits…
The fixed point TI dsp chips always had a long int that was 48. Intel had 84 bit floating point registers before simd registers took over. And the pdp-11...
Powers of two aren't as ubiquitous as it seems. If anything, the hardware uses whatever sizes it wants and that gets abstracted from the rest of the world by compilers and libraries.
Re: We'd be better off with 9-bit bytes
#299Earlier quoted context omitted.
LLM dren also isn't going to provide anything on how wildly different the home computer revolution would have been with twice as big character ROMs; the personal computer revolution would have been with twice as big code pages 437, 850, and 1252 and an extra CGA attribute bit; the BBS era would have been with 9N1 telecommunications; ECMA-48 and ECMA-35 would have been with space for the C1 control characters with no…
> The knock-on effect of EBCDIC having room for accented characters would have been the U.S.A. not changing a lot of placenames when the federal government made the GNIS in the 1970s and 1980s, for example. I don't know about that, it had room for lots of accented characters with code pages. If that went unused, it probably would have also gone unused in the 9 bit version. > Actual intelligence is needed for this sor…
You don't want to switch code pages while processing the data unless you add extra fields to indicate code page, ISO 2022 style (or in fact old baudot shifts style)
Re: We'd be better off with 9-bit bytes
#300This article reminds me a lot of a conversation with an expert DBA recently. We were talking about performance improvements and he said that upgrading hardware is almost negligible. Upgrading from HDD to SSD gives you 10x boost. SSD to nvme maybe 4x. But optimizing queries and fixing indexes can give you 100x or 1000x improvements.
Of course, every little bit counts, so we still did upgrade the hardware, but (at least in our area), almost all speed improvements came from code optimization.
This article is talking about kicking the ipv4 can down down the road only 10 years and increasing process memory from 2G to 32G. Seems like such small fries when we could just double it and move on. If you brought the 2038 problem to Unix devs, I'm sure they would have said "thanks! We'll start with 64-bit" instead of "yes... Let's use an unaligned 36 bits so the problem is hidden slightly longer".