Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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 12:54:33 -0500
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vtm6lv$78l6$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>
 <vtkrm6$30c7e$2@dont-email.me> <vtm4l7$54nr$1@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 19:57:20 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6afe4eb49cb32733d87df4c1be72a36f";
	logging-data="238246"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18MNcRZyaRoCEWvEuXuzrhdzw9+21fKr5M="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UrfZJhES2i0JSzpslLpjFPLV9HA=
Content-Language: en-US
In-Reply-To: <vtm4l7$54nr$1@dont-email.me>
Bytes: 5336

On 4/15/2025 12:22 PM, David Brown wrote:
> On 15/04/2025 07:40, BGB wrote:
>> 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.
> 
> Quantum mechanics, the current theory, is not complete.  Physicists are 
> aware of many limitations.  So while Plank time is the smallest 
> meaningful time interval as far as we currently know, and we know of no 
> reason to suspect that smaller times would be meaningful, it would be 
> presumptuous to assume that we will never know of smaller time intervals.
> 
>>
>> Practically, picoseconds are likely the smallest unit of time that 
>> people could practically measure or hope to make much use of.
> 
> The fastest laser pulses so far are timed at 12 attosecond accuracies - 
> 100,000 as accurate as a picosecond.  Some subatomic particle lifetimes 
> are measured in rontoseconds - 10 ^ -27 seconds.  Picoseconds are 
> certainly fast enough for most people, but certainly not remotely fast 
> enough for high-speed or high-energy physics.
> 
>>
>> 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 (*).
>>
> Physicists have measured times a thousand millionth of a femtosecond. It 
> is not easy, of course, but not impossible.
> 

I am not saying that the smaller times don't exist, but that there is no 
point in wasting bits encoding times more accurate than can be used by a 
computer running at a few GHz, with clock speeds that will likely never 
exceed a few GHz.

This sets the practical limit mostly in nanosecond territory.


But, for many uses, even nanosecond is overkill. Like, even if a 
clock-cycle is less than 1ns, random things like L1 cache misses, etc, 
will throw in enough noise to make the lower end of the nanosecond range 
effectively unusable.

And, things like context switches are more in the area of around a 
microsecond or so. So, the only way one is going to have controlled 
delays smaller than this is using delay-loops or NOP slides.

But, also not much point in having clock times much smaller than what 
the CPU could effectively act on. And, program logic decisions are 
unlikely to be able to be much more accurate than around 100ns or so 
(say, several hundred clock cycles).

....

You could express time as a 64-bit value in nanoseconds, and, it would 
roll over in a few centuries.


Meanwhile, a microsecond is big enough for computers to effectively 
operate based on them, small enough to be accurate for most real-world 
tasks.

Granted, one could have a "double" value holding the time in seconds, 
but this is its own thing (and, outside of 3D games or similar, more 
common to represent time values as integers, *).

*: And, we don't use "float", as this isn't even sufficient even really 
for games (if you are much over an hour or so from the epoch, then you 
no longer even have millisecond accuracy...).

....