Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Fri, 18 Apr 2025 20:03:48 +0200
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <vtu464$3h7m3$1@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>
 <vtm6lv$78l6$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 18 Apr 2025 20:03:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fb867aa1c6623fe279687870b6e898c7";
	logging-data="3710659"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19RJkp0M63BJELMxzOIhgHFEJyZSfUOB5Q="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:hPgRrOSZQOqX0ghhOhlc2vz/pEY=
Content-Language: en-GB, nb-NO
In-Reply-To: <vtm6lv$78l6$2@dont-email.me>
Bytes: 5789

On 15/04/2025 19:54, BGB wrote:
> 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.
> 

The datasheets of some of the components we use measure timings in 
picoseconds - things like inter-channel skew on memory devices, 
rise/fall times, or delays on FPGA pins and internal parts can be given 
as a small number of picoseconds.

> 
> 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).
> 

I have parts of microcontroller designs reacting a lot faster than that. 
  You use hardware, or at least hardware assistance, rather than pure 
software.

> ...
> 
> 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.
> 

Basically, all you are saying is that different timing resolution and 
ranges are needed for different things, and 64-bit would not cover it 
all.  128-bit could cover pretty much everything outside specialist 
physics use, and 64-bit with appropriate scale is fine for most purposes.