Fix-Point commented on PR #17675: URL: https://github.com/apache/nuttx/pull/17675#issuecomment-3701391293
> @Fix-Point Great job ! You have clearly identified the unreasonable aspects in the original design, provided corresponding test cases and detailed explanations, and also offered solutions. However, please be mindful of your choice of words in certain places—try to avoid using terms like "incorrect" to prevent misunderstandings. We should focus on discussing technical details and avoid emotional language. In addition, as @wangchdo mentioned, you need to run more performance tests, especially in AMP scenarios. > > @wangchdo I see that you have made many valuable comments on this PR, which are also excellent. We don’t need to deliberately distinguish which solution is better or worse; we just need to see which one can resolve issues of stability and performance. Moreover, this PR did not revert your solution, but rather built upon it. Thank you very much. I have always wanted to discuss only the technical details, but @wangchdo started by accusing me of copying his idea. In fact, apart from some similarities in naming, my implementation is entirely different from his in terms of design and APIs. He has never apologized for baselessly accusing me of copying his idea, which has left me feeling deeply hurt. Of course, I admit that it was my mistake to abbreviate "functional incorrect" as "incorrect," and I apologize for any confusion this may have caused. To clarify, when I referred to "functional incorrect," I meant it in the context of "functional correctness", as defined by the principle that "an algorithm is correct with respect to a specification if it behaves as specified" https://en.wikipedia.org/wiki/Correctness_(computer_science). His implementation does not guarantee that a cancelled timer will never overwrite a new timer (degisn specification), which is why I described his implementation as "functional incorrect." Besides, I have already provided the performance results on `intel64:nsh`, which is `non-SMP` platform. > We conducted 1 million interface calls on the `intel64:nsh` (Intel Core i7 12700) platform and measured their average execution CPU cycles, as shown in the Figure 3 below. It can be observed that the overhead for starting and asynchronously canceling timers is significantly reduced compared to wdog. > - **The speedup of `hrtimer_start` compared to `wd_start` is 2.10x**. > - **The speedup of `hrtimer_start & cancel` compared to `wd_start & cancel` is 1.57x**. > Additionally, after enabling hrtimer, wdog processing is treated as an hrtimer timer, which lowers the overhead of the wdog interface. > - **`wd_start` achieved a speedup of 1.73x when hrtimer is enabled**. According to the test results, the **main CPU consumption of the APIs comes from reprogramming the hardware timer (consuming more than 1000 CPU cycles)**, rather than the reading and writing of several hrtimer variables. These overheads of hrtimer modification can be fully hidden by the pipeline. Lastly, I greatly appreciate some of the suggestions from @wangchdo . I sincerely hope that in the future, we can engage in genuine technical discussions to make NuttX faster and more reliable, rather than wasting time on meaningless arguments. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
