fix: _cycles_per_sec might crash due to overflow by reordering of rdtsc#12
Conversation
tisonkun
left a comment
There was a problem hiding this comment.
Generally, in a good direction. Comments inline.
| #[cfg(all(target_arch = "x86", not(target_feature = "sse2")))] | ||
| use core::sync::atomic::compiler_fence; | ||
| #[cfg(all(target_arch = "x86", not(target_feature = "sse2")))] | ||
| use core::sync::atomic::Ordering; |
There was a problem hiding this comment.
nit: move this import to the block use it below. And I remember we prefer use std:: since this crate requires std.
There was a problem hiding this comment.
Addressed. The original code is generated by LLM with full qualified path, so I told LLM to import the function or method instead.
- Use
useimports instead of fully qualified paths. For example, importstd::sync::atomic::compiler_fenceand usecompiler_fence(...)rather thanstd::sync::atomic::compiler_fence(...).
Now I added another convention:
- Scope
useimports insidecfgblocks rather than at module top level when they are only needed there
tisonkun
left a comment
There was a problem hiding this comment.
Pushed a new commit for tidy code. LGTM.
|
@BewareMyPower Do you have a bench report after introducing this fence like #11 (comment)? |
I assume you mentioned this PR. The current workflow already run the bench, see https://github.com/fast/fastant/actions/runs/25777647841/job/75713505393 Here is a Python script that parses the raw outputs:
The change in this PR does not matter because it only affects the warm-up phase. The fence introduced in
On the hot path,
|
fixes #5