dzaima

52 ms·

811.
by dzaima 4y ago
You usually wouldn't need to push&pop all registers, just ones that you want to preserve across the call. Regardless, yeah, non-volatile aka callee-saved registers are extremely important for good performance of code that calls fun
812.
by dzaima 4y ago
not dynamically chosen though, at least in the case of earlyoom; whether to prefer killing the browser, or a random long-running process that has built up a couple gigabytes of RAM usage (or even just a bunch of small processes I don't
813.
by dzaima 4y ago
Right, it wouldn't help when one process wants more memory but you want an unrelated one to get killed, but the question here was about a browser killing one of its own tabs instead of the main browser process dying. (though, for what
814.
by dzaima 4y ago
If allocation predictably fails, you don't need an OS-level OOM killer to kill least-recently-used - you could just do said killing manually on failed allocation yourself. And you'd be able to do so in a much more controlled manne
815.
by dzaima 4y ago
The compiler could do those things too (-Wsign-compare is a thing; nothing for signed index though), but that won't change the existing code that uses "for (int ..." (incl. 637K C source files on github), and those warnings c
816.
by dzaima 4y ago
If you do "for (int i = 0; i < len; i++) data[i] = 0;" and len happens to be above 2^31, is your intent to write 2 billion zeroes, and then write 2 billion zeroes behind the data pointer, and repeatedly do that forever (never m
817.
by dzaima 4y ago
The operation being done based on the result matters - returning 0 or 1 can be done branchlessly, so it's worth making the whole operation branchless. However, if the operation requires a branch one way or another, both gcc and clang d
818.
by dzaima 4y ago
Mentioning 2^N variants on this specific proposal is probably the worst place to do so - Zca, Zcf, Zcd are all subsets of the 'c' extension, and Zcmp is incompatible with the 'c' extension, which severely cuts down the c
819.
by dzaima 4y ago
The syntax/"Special glyphs" page shows glyphs that specifically aren't builtins (i.e. functions & modifiers, which include your regular +-÷×, among many others). As for why use glyphs - setting up the keyboard &
820.
by dzaima 4y ago
Most of the time, though, you run applications that aren't frozen. Sure, having resizing do something in that case is useful, but you don't want those black bars to appear for the fraction of time between moving your mouse & t
821.
by dzaima 4y ago
The discussion[0] pretty explicitly says that support isn't planned, so it's not just that there is a lack of developers. Either way, I would assume that the effort needed to add server-side decorations to GNOME would be way less
822.
by dzaima 4y ago
I think it's important to take context in mind here - this isn't how linus responds to every suboptimal patch. If you already say "this patch is bad" for many patches with average levels of bad, repeating that same thing
823.
by dzaima 4y ago
I've given a go at making a GDB GUI (not published anywhere currently). It's at a stage where it looks pretty nice, and is usable for a decent number of basic things, but GDB/MI is such a pain to work with (the existing comma
824.
by dzaima 4y ago
Besides the people already saying the performance difference is much larger, the memory savings are quite important too, and I'd argue the complexity isn't that bad either. Sure, NaN-boxing isn't completely trivial, but it&#x
825.
by dzaima 4y ago
In fact, today already there are CPUs that support larger address spaces. But OSes should be smart and only provide pointers with the top 16 bits free while the application fits - even if some programs in the future end up using >256TB o
826.
by dzaima 4y ago
For what it's worth, clang[0] compiles to the vpminu[bwd] + vpcmpeq[bwd] version even from manually written intrinsics of the addition-based version, and has since clang 7. Though, interestingly enough, it fails to cancel out a followi
827.
by dzaima 4y ago
If that were the case, the plan should've been to revert if things do break, i.e. revert an improper action when you find it's based on false premises. But that's not what we see here.
828.
by dzaima 4y ago
> why not allow the ISA to query[1] if an L1 access is currently viable (enabling dispatch to different static schedules)? For tight loops loading one or two things per iteration, maybe it'd be worth it; most other things, though, w
829.
by dzaima 4y ago
right; at which point the subset of jvm you're using is a subset of any other IR/VM, the 'j' in 'jvm' being only useful as an implementation/runtime.
830.
by dzaima 4y ago
the JVM bytecode does not have any memory address type. Just various width integers & floats, and references to managed heap objects. Arbitrary pointers would have to be done with 'long's one way or another.
831.
by dzaima 4y ago
might you have used a signed hash value instead of unsigned? (or just one that never sets the top bit) (0xffffffff*101)>>32 is 100, which is the expected maximum.
832.
by dzaima 4y ago
Unfortunately, being slow is just not acceptable in a decent portion of scenarios. Web developers won't start writing 5x faster sites, and cloud providers won't like needing 5x more hardware to serve the same amount of virtual CPU
833.
by dzaima 4y ago
The fact that you should avoid allocation when possible has absolutely nothing to do with how fast allocation should be when you need it. And code not written with performance in mind should still be as fast as reasonably possible by defaul
834.
by dzaima 4y ago
I don't see a reason for the stdlib to be considered in a different way from the base language is all I'm saying. For most C programmers, the distinction between the stdlib and the base language isn't even a consideration. Th
835.
by dzaima 4y ago
Except that I'd guess that there is no "good" case in the case for MSVCRT's malloc. You shouldn't assume malloc is free, but you should also be able to assume it won't be horrifyingly slow. Just as much as you
836.
by dzaima 4y ago
C isn't that hard; you certainly have to approach things in a pretty different way, and it does have a slower curve to productivity, but once you get past the hurdle of having less abstraction (i.e. mostly by just not making pointles
837.
by dzaima 4y ago
Between a jump table and a scalar loop, the loop will screw with the branch predictor more. A jump table has the potential to be faster by doing SIMD, at the cost of taking more icache.
838.
by dzaima 4y ago
There's only one SIMD loop - a 128-bit one. There's a 64-bit SIMD segment for handling handling when the tail has ≥8 items (which is gonna be a pretty decent speedup for 8≤n≤15 byte inputs). If you're gonna operate on only ve
839.
by dzaima 4y ago
-O2 doesn't have any usage of SIMD/vectorization though. Of course it'd be simpler.
840.
by dzaima 4y ago
Here's an AVX-2 implementation that assumes it can read up to 31 bytes past the end of the input: https://godbolt.org/z/r33h75j5h (yes, that's autogenerated C) Requires -fno-unroll-loops as otherwise clang ge

More ›