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.
@ProjectPhysX@fclc@fay59
that's not for real, right? it does not follow IEEE conventions (Inf should be next to 2.0, and 2.0 should be 1.5), and surely for fp4 you want a two-bit exponent so you have only one NaN of each sign:
0000 0.0
0001 0.5
0010 1.0
0011 1.5
0100 2.0
0101 3.0
0110 +Inf
0111 +NaN
I don't get why IHVs hide their tools within layers of security and identity validation steps, that then don't work as intended and prevent developers from using those tools. What are they trying to protect?
On the other hand, AMD's approach is so refreshing.
@castano So much this, but which facet of "AMD's approach" are you praising? I'm mostly observing from the perspective of compute workloads on Linux, where AMD consumers are too often left to their own devices.
@demofox Yes! Young and Van Vliet described a fast approximation for Gaussian filters via IIR. It is used in RawTherapee and uncovered a very peculiar bug in GCC!
(Young – Van Vliet gives separate IIRs for each dimension, so at least one of them is very SIMD-friendly)
I wish 'git push' had a less hardcore mode for -n.
It connects to the server using the push protocol, and stops short of actually uploading anything. So it uses the push URI instead of the pull one, if they're different.
This means it checks that the push URI actually works. Great!
But if the push URI needs awkward authentication (e.g. SSH key on a token) then I'd also like a mode where it uses the pull URI, so I can easily check 'is this command line asking for what I meant to ask for?'
@simontatham Here's a possible alternative. At work we have a repo created with 'git clone --mirror' from upstream. When I clone that repo for development, 'git push -n' from my worktree is a local operation, and I do 'git push upstream my-branch:remote-branch' when everything looks ok (after setting up the 'upstream' remote).
(if the upstream updated in the meantime, I have to 'git fetch' in the mirror repo, and 'git pull --rebase' in my tree)
There's a shared pool of on-chip memory on the shader core that can be dynamically split up to serve as register file, tile cache, shared memory, general buffer L1, or stack. Since it's dynamic even within the lifetime of a thread/wave, the registers can be allocated dynamically as the program needs them rather than needing registers to be statically-allocated up-front.
@aras@pervognsen@mjp for OoO CPU you mainly look at critical path length and throughput limits without regards to specific instruction schedule, which is way easier compared to in-order. It's not like you can add up instruction latencies for a pipelined in-order core to get a good estimate. @rygorous tweeted about this too iirc.
(I don't suppose there's an implied ";)" after your "?")
Does anybody know what the current usable state-of-the-art method of converting an unsigned integer multiply by constant is? I'd imagine it's not still a variant Bernstein.
