Re: "A diagram of C23 basic types"

On 4/14/2025 11:15 PM, Lawrence D'Oliveiro wrote:

On Mon, 14 Apr 2025 19:43:04 -0500, BGB wrote:
 

On 4/14/2025 5:33 PM, Lawrence D'Oliveiro wrote:

>
I figured that it would be hard to find an epoch less arbitrary than
the Big Bang ...

>
But, we don't really need it.
>
If so, could probably extend to 128 bits, maybe go to nanoseconds or
picoseconds.

 The reason why I chose the Planck interval as the time unit is that
quantum physics says that’s the smallest possible time interval that makes
any physical sense. So there shouldn’t be any need to measure time more
accurately than that.

Practically, picoseconds are likely the smallest unit of time that people could practically measure or hope to make much use of.
While femtoseconds exist, given in that unit of time light can only travel a very short distance, and likely no practical clock could be built (for similar reasons), not worth bothering with (*).
Planck units are so small as to be essentially useless for any practical measurement.
*: Like, say, not really worth trying to make a clock for a pulse that is so short that the clock-pulse couldn't even make it to the other side of the silicon die (even if it were made really tiny).
Like, to be useful, one needs something where at least light could move, say, a few inches or so; which is more in nanoseconds territory.
Well, and similarly, for an electronic device running on a global clock pulse, can't reasonably run it much faster than the time it would take for that pulse to fully cross the device.
Well, unless maybe someone got creative and started designing the chip's logic to operate based around light-speed propagation delays rather than around clock-edges. Say, the chip is shaped like a ring or disk and is almost purely combinatorial logic, with a "clock-pulse" based more around how quickly it takes signals to make the full circuit around the die (likely for logic running at high-GHz speeds or similar and at very low power).
...
For current use (in computers), much smaller than nanoseconds is likely in "wishful thinking" territory in terms of being able to make much effective use of it.
Even the comparably large microsecond is still pretty accurate for most things (short of measuring times for electrical signals or similar, you don't usually need much smaller than this).
Well, and having a realistic "nanosleep()" that is anywhere near the requested delay on nanosecond scales is likely, itself, wishful thinking. Like, say, "usleep()" is probably fine, at least one can have hope that the OS scheduler can get in the right area (vs, say, well you have more precision but realistically it isn't going to happen).
Like, you are about as likely to get nanosecond precision on sleep as one is to be able to sleep a specific number of clock-cycles (+/- a few clock cycles).
Like, even with NOP slides one is likely to be hard-pressed to get delays this accurate.
...