There's a bunch of C-like successor languages that say they want to eliminate undefined behavior. I've never been able to figure out how they intend to deal with reads and writes to memory since a lot of these languages take what I would call the "naive" machine-centric view of memory which is hard to reconcile with source-level semantics for variables, etc. You can't really rename all of this stuff as "implementation-defined" and get out of jail for free.
(some behavior in C is undefined by virtue of the language standard not saying anything about it)
Yes, there is the truly weird category of UB which pertains to translation time, not execution time, and it seems completely unnecessary, but I assume that's not what was meant here.
(prompted by discussion of detecting bitwise and-not earlier in GCC's optimization pipeline)
My ideal compiler IR would not have and/or/xor as distinct bitwise ops, just generic ternlog and probably the corresponding two-operand function ("bilog"?) too.
Perhaps my ideal CPU would also have a ternlog opcode instead of an incomplete zoo of bitwise ops.
mul-add is another useful three-input instruction (although unlike ternlog it's macro-fusible from separate mul+add). If one made a CPU geared towards such three-input instructions, I wonder what other combined ops would be there (clmul+xor? shift+or?) and what the trade-offs are.
PSA for people writing Arm SIMD code in C or C++: unlike x86, where you can cast any pointer to __m128* and be able to dereference it regardless of the dynamic type of the pointed-to memory, that is not the case on Arm: Neon types do not carry the may_alias attribute and standard type compatibility rules apply. Compare the differences between 'f' and 'g' on the first pic, and Arm codegen on the second pic.
Digging through old stuff, here's a fairly extreme example of branch predictor training effects in a benchmark of Robin Hood linear probing vs conventional linear probing. Look at the branch misses for 1 vs 1000 outer loop iterations for RH (and the impact on wall clock time): https://gist.github.com/pervognsen/e818251d52f725db7c67e562577a12f6
In 'less', you can interactively add command-line arguments without leaving the pager by pressing '-': you can press '-S' to flip wrapping/chopping of long lines, and '-j11' to spawn 10 wor^W^W^W see extra ten lines of context above the match when searching!
Are these all the special sections that run code on program init/exit? Did I miss any?
.section .preinit_array; .quad fun
.section .init, "ax"; callq fun
.section .init_array; .quad fun
.section .ctors, "aw"; .quad fun
.section .dtors, "aw"; .quad fun
.section .fini_array; .quad fun
.section .fini, "ax"; callq fun
One of the arguments against immediate mode UI is that it will drain your battery. I think that's bollocks!
Here is my "proof of life" test to measure power draw. Preliminary result is that Dear ImGui consumes less power than YouTube. That feels like a fairbar to compare against
I'll of course take some much more rigorous measurements and tests over longer periods of time. This is just the first time I have actual data.
@wolfpld@forrestthewoods@castano I am well aware of the joke that goes like "to learn how to do <X> on Linux, loudly claim 'Linux cannot do <X>! WTF!' and wait to be corrected", and I am not sure what you were looking for when both perf and turbostat can work with RAPL sensors, but I'm curious how you solved it in the end.
shower thought re. rgb 565 vs. theoretical 555|1 (common least significant bit for each component): it introduces higher "distortion" for darker colors (i.e. the closest encodable to dark purple { 1, 0, 1 }/64 is dark grey { 1, 1, 1 }/64), but our vision loses color sensitivity in low-light conditions anyway, so that probably would have been a better fit
this has to be one of my all-time favorite bug-finding techniques: in your widely deployed software, at very low probability, you put a new heap allocation next to a protected page. performance is unaffected and the bugs that you find are those that actually matter to users in practice.
With xz backdoor opening an RCE pathway, have you thought "hey, it would be nice if the sshd sub-process doing the key/cert parsing would not be able to fork/exec anything?" Ideally the only thing it should be able to do is read/write to already-open fds and die a peaceful death, right?
Now, this particular backdoor was embedded deep enough that it might be able to workaround such privilege separation, but in general dropping privs for risky computations is an important part of defence-in-depth
And that reminds me of another scenario where we parse untrusted certificates: WPA2-Enterprise authentication. Venerable wpa_supplicant does have some privilege-separation code (which I believe is rarely enabled on Linux), but what iwd does is completely incomprehensible to me: they pass certs from the access point straight to the kernel keyring subsystem, using the kernel as a fancy SSL library. Any weakness in the involved kernel code is thus open for exploitation by rogue access points.
I still can't figure out the intended use-case for AMD's IBS (instruction-based sampling). You select a period N, and then for each N'th instruction you get info about that particular instruction (in which caches it missed, was a branch, was it mispredicted, ...). Which seems... completely unworkable for rare events? If I want to sample on mispredicted branches, and they account for 1% of all instructions, I'll have to discard 99% of IBS data, and my effective sampling period is 0.01 of nominal?
Fun fact: there are at least five distinct choices for type T (not counting typedefs) such that a C compiler targeting a POSIX system cannot optimize out the call to 'aux' in
Apparently #Gentoo's sys-apps/sandbox (which ensures ebuilds don't make a mess outside of their build "sandbox") had a huge performance regression which caused webkit-gtk build times to go from 9 minutes to 1 hour.
After collecting a ton of data, applying patches, reverting patches, etc, I filed https://bugs.gentoo.org/910273 and it seems we have a fix.
