I mean this is sort of true in that windows is constantly introducing trash, but I've run into all kinds of nonsense:
1. Amd HDMI 2.1 fiasco and adapter workarounds -> debugged the adapter compared to the displayport spec pdf, emailed the company, got a firmware update, patched my kernel. Fixed! This one is going away for good with FRL support upstream soon.
2. Game stops responding to controller input after playing for a bit. Debugged, turns out the service for doing something fancy with shaders has shared fate with the steam input process. It launches a zillion threads and OOMs from virtual memory exhaustion which takes out steam input; fixed by adding a wrapper script for steam that reduces thread stack sizes to the windows default size.
3. Xbox elite series 2 controller back buttons not supported in 2.4ghz wireless mode; reverse engineered the USB packets, contributed support to out of tree xone driver.
4. Flydigi controller software not supported on Linux; find random GitHub project that reversed their hidraw protocol. It's got bugs, so fix them and use it.
5. Terrible banding in Silksong. Set up gamescope to apply dithering; this breaks steam input, figure out all sorts of incantations with LD_PRELOAD
But all of these are very much off the beaten path problems, lots of people have fun with normal controllers, no VRR, etc. My steam deck has been just perfect with zero effort, and I assume that's because I'm not treating the system configuration like a puzzle game.
I got a measurable improvement from eliminating a null pointer check within the last week. Billions of devices have arm little cores, and the extra branch predictor pressure and frontend bandwidth from those instructions can be significant.
A standard way to eliminate those is to invoke undefined behavior if some condition is not met;
if (a == NULL) {
__builtin_unreachable();
}
Which then allows elimination of the null check in later code, possibly after inlining some function.
Wouldn't that make a compiler that emitted bounds checks violate the standard, since it would not be emitting the actual memory operations if you deref out of bounds?
Once you are addressing arbitrary values you are firmly in the realm of "anything happening" in practice, but you've now given up optimization opportunities. As has been repeatedly demonstrated over the years, once memory safety breaks it is practically impossible to make any guarantees about program behavior.
The Synaptics VMM7100-based adapters only support VRR on older firmware versions with bugs.
The Chrontel CH7218 is the most reliable but still also suffers blackouts during VRR.
ParadeTech PS196 adapters advertise VRR support but their DPCD does not correctly communicate that it is supported. So even if you add the chip to the VRR PCON list in the amdgpu driver, it still won't see VRR as supported.
And while some of these advertise themselves as displayport 2.0, all of them only support bandwidth of 25.96gbps on the displayport side, requiring DSC for 4k 120hz 10bit color, even though they support 48gbps on the HDMI output.
Yeah arm little cores are a very different story - they aren't superscalar out of order architectures, they can dispatch up to two operations per cycle.
Big cores are more like that dispatching 8 or more operations per cycle, but they're also more expensive, larger, etc.
The first implementation I encountered was a linear search, starting at the last-found field. Empirically it performed better to do a binary search with early exit and branchless bounds selection, I think due to branch predictor pressure. The data representation could be changed but it's tricky, as there are other traversals that want to go in sorted order, and there are lots of places that pass just one pointer for fields. But I agree any further improvement will probably have to come from that.
SIMD is tricky even with SoA because there is significant latency going between the general registers and the vector units, plus arm little cores can be configured to share a vector unit with another core.
Yeah namespaces and public/private would be quite nice, but C doesn't have them, so they get hacked on via macros and prefixing. The syntax was not the hard part of working or analyzing this code, though.
1. Check for dense list O(1)
2. Check upper bound
3. Constant trip count binary search
The constant trip count is great for the branch predictor, and the core loop is pretty tightly optimized for the target hardware, avoiding multiplies. Every attempt to get more clever made the loop worse and did not pay for itself. It's hard because it's an array-of-structs format with a size of 12, and mostly pretty small N.
I had fun exploiting this to detect the falling convention used by some code at runtime - there were two different options depending on OS version; one passed a jnienv* as the first param, the other did not. So if I called it with 0, I could tell which was being used based on whether the first argument was NULL or not. Only used for specific architectures with a defined ABI that behaved this way, of course.
>Maintaining both MV2 & MV3 support isn’t easily sustainable long term when you factor in the need to prioritize other features.
There is no feature Firefox provides that is more differentiating than ublock origin. As long as pages load and security issues are patched it is the reason to choose Firefox as a browser. What would they prioritize over it?
If you can trigger address sanitizer from input outside the program, and the program may interact with untrusted input, isn't that always worth reporting and fixing?
>With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax.
This is because the kotlin compiler is not written in the way people write fast compilers. It has almost no backend to speak of (if you are targeting the jvm), and yet it can be slower at compilation than gcc and clang when optimizing.
Modern fast compilers follow a sort of emerging pattern where AST nodes are identified by integers, and stored in a standard traversal order in a flat array. This makes extremely efficient use of cache when performing repeated operations on the AST. The Carbon, Zig, and Jai compiler frontends are all written this way. The kotlin compiler is written in a more object oriented and functional style that involves a lot more pointer chasing and far less data-dense structures.
Then, if run on a non-graal environment, you also have to pay for the interpreter and JIT warmup, which for short-lived tasks represents nontrivial overhead.
But unlike header inclusion or templates, which are language level features that have major effects on compilation time, I don't think kotlin the language is inherently slow to compile.
The default Gboard keyboard has settings for always showing the number row, or only showing it when entering a password. There is also a setting for the "suggestion strip" under "corrections & suggestions". You can also drag to resize the keyboard itself in the Gboard menu, to scale the height.
Now, whether your users will do that to play your game is a different story, but the options exist.
Not OP, but used Arch for a while in 2011, and at some point doing an update moved /bin to /usr/bin or something like that and gave me an unbootable system. This was massive inconvenience and it took me many hours to un-hose that system, and I switched to Ubuntu. The Ubuntu became terrible with snaps and other user hostile software, so I switched to PopOS, then I got frustrated with out of date software and Cosmic being incomplete, and am now on Arch with KDE.
Back then I used Arch because I thought it would be cool and it's what Linux wizards use. Now Arch has gotten older, I've gotten older, and now I'm using Arch again because I've become (more of a) Linux wizard.
https://github.com/protocolbuffers/protobuf/commit/9f29f02a3...