Search code examples
ctimercpuclockhigh-resolution-clock

Is picosecond timer possible?


Given

I want to make a device, that measures distance, based on the time electromagnetic wave passes from one point (computer\microcontroller) to other. I do not consider phase shift method for that.

I want centimeter precision (at least).

For that purpose, both computers should have clock with at least 33.3 ps period resolution.

If consider clock as a counter loop, that just increments uint64_t variable each time, I need that loop do each iteration 30 billions time per second with 33.3 ps pause.

Problem

In this question, commentators and user, who answered states, that CPU performance is limited by its sizes due to the fact, that information can't propagates faster, than speed of light. It makes sense.

Thoughts

However, there is the CPUs millions instructions per second table.

Let's consider, Intel Core i5-11600K: it has 6 cores and 346 350 MIPS at 4.92 GHz. Obviously, 345 billions instructions are for multithreading program (or even not?), however, per one core it should be 346/6 = 57 000 MIPS.

57 000 MIPS means 57 billions instructions per second per one core, and period equals about 17 ps.

Electromagnetic wave passes 5 mm per 17ps.

Threadreaper has 36 trillions instructions per core, which means 8 um wave propagation at all.

So, by that logic it all should not work, however works. What is the trick? Does picosecond timer yet possible?


Update

If You are going to use multithreading as an argument, please, in the table I provided above, look at Intel Core 2 Extreme X6800, that has only 2 cores and 27 000 MIPS, i.e. 13 500 MIPS per core, which is still pretty fast, and should be impossible (light will pass only 2.3 cm).


Solution

  • Have you ever visited a factory? Let's say a car factory.

    It passes through many different stages. Some workers are painting the bodywork, then it has to dry, then some other workers mount the wheels, some others add the seats, etc, etc.

    A Tesla (just use that example, because the data are public) takes 12 weeks to go through the entire process (it takes 12 weeks between the moment the fabrication is started and the moment the working car exist the factory).

    Yet, Tesla build 1000 cars per day

    It would be a mistake to say 1/(12*7)=0.0119 cars per day. Or, on the contrary to expect that if a factory build 1000 cars per day, that means that a car is build in 86.4 seconds.

    And that is not just because of threads, or parallelism. Likewise, with my examples, one could say "but a factory doesn't build 1000 cars a day, there are more than one Tesla factories". Indeed, there are 6 of them. So 6 threads if you will. Still, it would be a mistake to deduce that it takes 518 seconds (86.4×6) to build a Tesla, not 12 weeks. It is also because of the process itself: the worker who is painting the bodywork is painting the one of a second car, while another worker is mounting the wheels of the first car. It takes time for a car to propagate through the whole chain. The computation 86400/1000*6 would be valid only if one worker was working at the same time (nobody takes care of the wheels while the car is being painted, or while it dries).

    So, no, you can't deduce the length of an instruction from the number of instructions per second. No more that you can deduce the time it takes to build a Tesla (12 weeks) from the rate at which the factories produce them (1000/6 per day and factory).

    (I could have used many other analogy. For example, since you are mentioning a signal propagation: you may know that it takes hours for an electron, when you switch on the light, to goes from the switch you've just closed to the lightbulb. Yet some quintillions of them pass through the lightbuld per second :D