Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Tue, 15 Apr 2025 00:40:48 -0500
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <vtkrm6$30c7e$2@dont-email.me>
References: <87y0wjaysg.fsf@gmail.com> <vsj1m8$1f8h2$1@dont-email.me>
 <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me>
 <vsjg6t$20pdb$1@dont-email.me> <vsjgjn$1v1n4$1@dont-email.me>
 <vsjk4k$24q5m$1@dont-email.me> <vsjlcp$230a5$1@dont-email.me>
 <vsni1v$291i3$5@dont-email.me>
 <slrnvv82gk.2aciv.candycanearter07@candydeb.host.invalid>
 <vt1a7f$i5jd$1@dont-email.me> <vti36r$g4nu$2@dont-email.me>
 <slrnvvqhmc.2eh69.candycanearter07@candydeb.host.invalid>
 <vtjknt$1sp26$1@dont-email.me> <vtk2f9$295ku$2@dont-email.me>
 <vtka7u$2ddeu$1@dont-email.me> <vtkmhm$2u0tr$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 15 Apr 2025 07:43:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6afe4eb49cb32733d87df4c1be72a36f";
	logging-data="3158254"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+AGLxTG3/VAnjKw40kMbwkjBlLtLKaKus="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Yz2+fFwfwvW22GQWNpbrpl0GXh4=
Content-Language: en-US
In-Reply-To: <vtkmhm$2u0tr$3@dont-email.me>
Bytes: 4628

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.

....