Thank you so much. It was so understandable :)

awesome keyboard😁

I forgot where exactly but I did use ExitStack when developing aiosmtpd

one of the points that sticks out to me is that sometimes it reports a time, sometimes its 0, where the actual time is actually a fraction of a second when it is measured. This smells of SMT/Hyperthreading taking away execution time and then suddenly popping everything into the foreground for your particular thread. Maybe try disabling SMT and see if things change?

"it's still in production" industry standards bite again

Oh man. For internal calls to user-facing APIs that may invoke a warning, I've been doing things like `warnings.catch_warnings` and re-emitting warnings to correct the stack level. This seems a lot more convenient.

I don’t think a lot of people would understand why the new code is written that specific way, I rather do the if outside and conditionally enter the context with a plainer looking code and 2 duplicate returns

Very clever, thanks for sharing

Define a function that works on pre-opened file descriptors and manage opening outside? Why switch between very different and fragilely stateful types - I mean it's simple for me to say that once I see the important difference between the two :)

One of the only in python videos 😂

The number of times I've seen or left PR comments to the tune of: "This is some clever code. Can't find the bug, but I know it's there somewhere" is more than one. That's too many. xD

surprised to hear about perpetual issue of conditional contexts - isn't this what nullcontext is for? i've used it successfully to conditionally manage seek-offsets and temporary-filters for db cursor management. smth like this? i dont like doing two checks for file=None, but maybe there's another implementation and in any case definitely think nullcontext should be mentioned! import sys from contextlib import nullcontext def read_first(file: str | None = None) -> str: cm = open if file is not None else nullcontext with cm(file) as stream: stream = stream or sys.stdin return next(iter(stream)) edit: def read_first(file: str = None) -> str: file, cm = (file, open) if file else (sys.stdin, nullcontext) with cm(file) as stream: return next(iter(stream))

ohh neat trick

thank you!

Anthony, you are the best. Please keep up with such content!

The performance counters in most VM software are simulated. At the moment the VM should simulate a virtual timer interrupt, it may not be running because your OS is running another thread. This can cause a backlog of timer interrupts, causing the guest OS to perceive substantially less time passage than the host, which can cause many weird behaviors, including duplicate values returned from monotonic clocks on operations you'd expect to take longer (e.g. Python code). Some VM software allows to pass through the host performance counters, look for the option "virtualize performance counters" or similar, although it requires hardware support. However, when using this option, you are now also perfing the VM software in addition to your Python code, so times would be artificially inflated, the best way to get accurate timing information is to use bare-metal dedicated hardware with nothing else running and a single CPU. Also, it's not much of an issue in Python, but you can observe monotonic clocks returning duplicate values when operations actually take less than the clock resolution amount of time to pass. E.g. if you try to benchmark malloc in C, which can in nice cases take ~20ns, you will find the same issue of duplicate monotonic clock values not because of some weird error but because not enough time has passed to increase the perf counter since the last call (it might take 200ns). The way we typically get accurate measurements of events that take less than clock resolution time is using statistics, e.g. by running the operation millions of times then dividing the time taken by a million. More advanced statistics are required when you can't simply run the operation in a loop, e.g. if you are perfing "execute trade on stock market", in which case you can still collect millions of samples of adjacent clock values just not in a loop and a proportion of them happened to be between counter increments, from which you can estimate the real time taken.

For a simple case like this, I think I would use "context = open(file) if file else contextlib.nullcontext(sys.stdin)"

ExitStack is magic. I'm yet to encounter something so elegant in any of the few languages that I write alongside Python--TS, Go, Elixir, etc.

"All Code Sucks" is a lot of fun! One-liners are so tempting. There's always that itch inside to make the solution fancy and perfect and smart, but maybe writing simple and straightforward code is better after all. :D

That's a dirty bug!

This is something I should have learned when I was just starting. Thanks as always, Anthony!

when you figure this stuff out, can you come fix my computer? It also has several nonsensical issues that I can't even explain.

Ah, yes. It's a classic problem with the inverse reactive current used in unilateral phase detractors and synchronization of cardinal gram-meters. See, the power used to be generated by the relative motion of conductors and fluxors, but in your VM, it is likely generated by the modial interaction of magneto-reluctance and capacitive deractance. I would check the base plate of prefamulated amulyte that is surmounted by a maleable logarithmic casing and make sure the 2 sperving barings run a direct line with the parametric fan. The Rockwell Retro Encabulator YT video goes into deep detail on this.

Would you be willing to change hypervisor? Can you try creating the VM (or converting your disk image to a vhd) with Hyper-V and see if it has the same behavior? Hyper-V is a type-1 hypervisor and will probably give a much better experience overall... not to mention is included with Windows. As a stab in the dark... some of the weirdest issues I've experienced have often been related to a disk partition being full. Double check all your partitions are mapped appropriately and have free space. Dynamically expanding storage can also do weird things because the machine basically stops very briefly when that occurs, which causes weird behavior sometimes.

don't cite me on this, but for the time being: just omit the outliers.

Someone already mentioned the time stamp counter but maybe try removing and checking the cmos battery?

there is no algorithm that can solve --warn-unreachable. it's the halting problem

You can write a simple C program which store time to array in a loop as fast as possible and then plot it to see if there are some stairs, spikes or whatever. It can give you better understanding what is happening. You can also experiment with using clock_realtime and clock_monotonic.

manual linux kernel replacement might fix it (just use the same version as installed first, then upgrade to something newer) that fixed it on an arm based system for me (a single core 400 MHz crappy softfp one, but hey, maybe) But that would have been a problem from the first boot. Firmware Update for BIOS/CPU would be better to try (mostly fixes the fixable things above). If its just in specific software idk, reinstall that software and things it depends on? custom build systemd : D (the last one was a joke, systemd is not so fun to replace, or at least it was when it became standard a decade ago) run a live cd and check times from there. If it is messed up still it might be the internal highprecission counter from the cpu it self is somewhat broken/buggy. Barely recoverable depending on the actual cause, CMOS/BIOS reset might fix that, another CPU (a crappy celeron-esque will do) can even help. there are wild suggestions online: Vaporizing the PC might do : D Would not reccomend checking that. Took me days on a laptop to figure this one out. And I could not fix it. My PC turned so slow it got to 50MHz tops for some reasons and I gave up. Usually this means your CPU is slowly turning insane. I am just taking wild guesses...

I'd try booting a live USB to see if it happens bear metal Additionally, I'd try a different hypervisor like VMWare or MS Hyper-V

I mean... First try it outside of a VM, and then try a different OS (windows can run in trial mode for 30-90 days)

Looks like KZbin deleted my original comment (likely due to it containing the commands I used), so I am commenting again. FWIW, I cannot reproduce the 0 ns thing. My CPU is Ryzen 3900X. I tried to reproduce it in a VM (Virtualbox with the same CPU settings; with Ubuntu 18.04, Lubuntu 20.04, Ubuntu 24.04 and PopOS 22.04) and on bare metal (Debian 12). Hope this data point would be useful in figuring it out. If I had to guess the source of the problem, it would be in the part of either the NT kernel or the firmware, which is responsible for reading the real-time clock. You could try to narrow it down by testing on the host, while it is running Linux (a live usb should suffice).

Not sure exactly how `time` is implemented under the hood. I would try another language to see if this behavior is reproducible across different implementations

Wrong approach! Figure out how it dies things in zero nanoseconds and leave those fancy quantum machines in the dust! You’ll make a fortune!

Could it be that the process is migrated to different CCD with different timer?

AMD issue... I think.

This feels like either a hypervisor and/or hardware virtualization bug or an intentional decision. Since you are on Windows I would try running a tool called InSpectre and disabling side channel mitigations there. If that alone doesn't work I'd comb through your host BIOS settings and Virtualbox settings for anything related to performance counters, hardware timers, or side channel attack mitigations and start flipping switches and checking. My (kind of a stretch) theory is that the system is adding noise to system time counters to mitigate side channel attacks - this was notably employed in response to Meltdown and Spectre but there have been other side channel attacks discovered since then that may have warranted heavier handed mitigations especially in virtualization. The implementation of this mitigation will be different on Intel and AMD which could be why you can't reproduce this on Intel.

just dropped another X files episode 😅

TempleOS never had this issue, just saying

What if change the best-of script to a bash loop so it's at least not related to python at all and see if it's reproduced

Yeah try set the vm to use directly the host cpu. And try also kvm.

I know exactly what the problem is! Is what I would say, if I would know what the problem is. However, I have no idea.

Is it plugged in?

I've seen failing clocks give the same value more than once so time is not stopping it's just repeating the time. This can cause drift, if no drift it's being stupid but the clock itself is working.

Really hope this is not going to be one of those weird Intel issues

Have you tried under different hypervisors? I believe virtualbox does some amount of CPU result caching which could potentially explain this.

Did you try to pin the cores to a single physical core (or package) or numa zone? What’s the host? I think perfcountere are per cpu - so is that a dual socket?

Maybe try disabling the "Extended features"

It's cause you have that malware python installed. =)

Does it happen on a newly created VM? No idea if this is even a thing, but wonder if there's something host-specific baked in from the prior machine you built this image on?