1,856 karma · joined September 24, 2014
If you're short on time: the paper reads a bit dry, but falls in the norm for academic writing. The github repo shows work over months on 2024 (leading up to the release of 3.13) and some rush on Dec 2025 to Jan 2026, probably to wrap things up on the release of this paper. All commits on the repo are from the author, but I didn't look through the code to inspect if there was some Copilot intervention.
[0] https://news.microsoft.com/apac/2020/03/17/windows-10-poweri...
Opening in a private window solved the issue, however I'm pretty sure I don't regularly read anything on this site (maybe never was an overstatement?).
Edit: this is the latency project I was thinking about https://danluu.com/input-lag/
Edit: Oh and cpldcpu linked the ComputeDRAM paper that explains how to do it with off the shelf parts.
If there's a memory dump to work on, a more in-depth analysis can be done with Volatility on running processes, but it usually falls back on the expert having good skills on that kind of search (malfind tends to drop a lot of false positives).
But at least the guides gave a baseline/starting point that seems to be better than what was described. It's very difficult to prove a negative, so I'd also be careful with the wording, eg: "evidence of a malware infection was not found with these methods" instead of "there's no malware here".
[1] https://www.swgde.org/?swp_form%5Bform_id%5D=1&swps=malware
Might want to check that. Also 4.something got SIFT as part of OpenCV (instead of living in the contrib module) because the patent expired and you can now use it for free.
As for blowing up with NN packages and such... I don't really use those parts, but if the NN module had easier support to run networks trained on popular frameworks I might've used it. Disclaimer: it's been quite a while since I last tried to use those parts, so maybe now the latest version has fantastic support and I'm talking nonsense.
So it was a bit better than the authors tests, but there's still room for improvement.
While what you say is correct, let's not forget that lead _is_ an elemental superconductor. With a Tc of 7K, it's only bested by niobium (9K) and diamond (11K) as an elemental superconductor.
Yes, cuprates and ceramics were ruling high-temperature SC so far, but it's not like lead was entirely unexpected in the superconducting world.
They're keeping the "30 years of experience" agent for the 2.0 version /s.
This is a good analysis, and I'm glad that there are some people like you giving these things a good deal of thought.
On the other hand, yes, everyday use (web, mail, video/media consumption) don't require today much more than 8 or 16GB of RAM. If we go a bit creative, a PC with Linux can run very smoothly on 4GB alone, and surely someone here can point to their one anecdote of a machine with 2 GB or even 1 GB sporting a nice desktop environment, or 128mb CLI-only machine.
Edit: also memory has to improve its bandwidth and data transfer rates to keep up with faster processors, so it could also improve over 10 years time without much focus on storage capacity. Or maybe they focus on latency instead, or a mix of all three. Point is that it's not a single metric to improve.
Admittedly we're on a reasonably easy situation: we just have to deploy models (some from scikit-learn, some from Keras, some from PyTorch) to various users who mainly run a specific version of python under Windows and Linux, with CPU and GPU support.
[0] https://github.com/faster-cpython/ideas/blob/main/FasterCPyt...
Now I'm quite fond of python, but largely I read this as the CUDA implementation having quite some room for improvement. Having almost no CUDA experience of my own, that is just a hunch, which I'm glad rfoo supports with (surely) a lot more experience than me.
Per my usual update schedule, I'm looking down the line to at least a Zen5(+?) upgrade in a few years time, so I hope they improve this kind of things in the future. However that's entirely up to OEMs deciding to make a good product, and a bit out of AMDs grasp.