> Meanwhile in just about every other area that uses fp computation it's been the defacto standard for decades.
Not that strongly for more parallel things, quite similar to the situation with atomics on cuDNN. cuBLAS for example has a similar issue with multi-stream handling, though this can be overcome with a proper workspace allocation: https://docs.nvidia.com/cuda/cublas/index.html?highlight=Rep....
Still better than cuDNN where some operations just don't have a reproducible version though. The other fields are at least trying. DL doesn't seem to be.
"Haswell or newer" is a bit misleading here, because there were low-end Celerons and Pentiums shipped for years after the release of Haswell that lacked AVX2 and wouldn't be able to run software compiled for -march=haswell.
Oh, yeah. Looking at the code the comparison function is bad in a way that will hit issues with cmovs. The "else if" there is a nearly 100% predictable branch which follows a branch that's probably completely unpredictable. One optimization you get with -O3 is that branches not marked likely or unlikely can be turned into dataflow. The proper ordering for that code is to pull the equality check forward into an if statement and mark with "unlikely" if you're using -O3, and then return the ordering of the floating point comparison.
Since we're using Rust there's some decent syntactic sugar for this function you can use instead:
Fil-C works because you recompile the whole C userspace. Unsafe Rust doesn't do that... and for many practical purposes you probably want to touch the non-safe-version of the C userspace.
Still, it's all LLVM, so perhaps unsafe Rust for Fil-space can be a thing, a useful one for catching (what would be) UBs even [Fil-C defines everything, so no UBs, but I'm assuming you want to eventually run it outside of Fil-space].
Now I actually wonder if Fil-C has an escape hatch somewhere for syscalls that it does not understand etc. Well it doesn't do inline assembly, so I shouldn't expect much... I wonder how far one needs to extend the asm clobber syntax for it to remotely come close to working.
at the bottom of the turtle stack, there's a yolo-c libc that does some syscall stuff:
> libyoloc.so. This is a mostly unmodified [musl/glibc] libc, compiled with Yolo-C. The only changes are to expose some libc internal functionality that is useful for implementing libpizlo.so. Note that libpizlo.so only relies on this library for system calls and a few low level functions. In the future, it's possible that the Fil-C runtime would not have a libc in Yolo Land, but instead libpizlo.so would make syscalls directly.
but mostly you are using a fil-c compiled libc:
> libc.so. This is a modified musl libc compiled with Fil-C. Most of the modifications are about replacing inline assembly for system calls with calls to libpizlo.so's syscall API.
HTTPS is there, so you go down to that level only if you want to distrust any element of the public key infrastructure. Which, to be fair, there are plenty of reasons if you are paranoid -- they do tell you who's doing what in a shady way as they revoke, so there's a huge list of transgressions.
It is not only that directly; the domain name might be reassigned to someone else, resulting in a valid certificate which is different than the one you wanted. (If you have the hash of the file which you have verified independently then it is more secure (if the hash algorithm is secure enough), although HTTPS is not needed in that case, it can still be used if you wish to avoid spies knowing which file you accessed. You can also use the server's public key if you know what it should be, although this has different issues, such as someone compromising the server (or the key) and modifying the script.) (There is also knowing if the script is what you intended or not anyways (or if there is something unexpected due to the configuration on your computer); if that is your issue, you can read it (and perhaps verifying the character encoding) before executing it, whether or not you trust the server operator and the author of that script.)
> the domain name might be reassigned to someone else
If that happens its game over. As the article I linked noted, the attackers can change the installation instructions to anything they want - even for packages that are available in Linux distros.
AM404 really is the metabolite that keeps giving. The central nervous system system effects were fun too, acting on cannabinoid receptors and/or TRPV1 channels -- so either stony or spicy.
From my limited experience of metamizole it feels a bit stronger than paracetamol/acetaminophen. Neat little drug if your genetics can take it.
Tangential: China technically banned metamizole due to the agranulocytosis scare, but somehow small clinics always have fresh stocks of this stuff. And their stocks don't look like my metamizole for horses! It's pressed out of the usual magnesium stearate instead of whatever rock-hard thing they use for animal drugs in China.
Not a professional, but still use it like that. They also have a new smartblast thing, which works much faster (really, really like Google!) but only on highly similar proteins.
on one hand i can see how it's going to break stuff (and I see they've changed it! []). on the other hand... mind talking a bit more about how it did break things?
Let's call the old combine function C. How long can you combine things C(C(C(C(a, b), c), d), e)... until you get a collision? Experimentally, it averaged around 2^14 iterations and I had examples with 7. The issue was that I found this code deep in the bowels of a system controlling heavy machinery such that a collision potentially meant life altering consequences for someone.
I wasn't aware boost had changed it, but the solution I settled on was essentially identical to what boost came to here. There's some further issues with that system in that the mixing functions aren't ideal for all bitlengths T. The way they're using it here is safe, but it annoyed me enough to devise a class of mixing functions with provably max length periods for all sizes T (at the cost of some mixing quality). Haven't published that crate yet because I'm not sure who else would want it.
Not that strongly for more parallel things, quite similar to the situation with atomics on cuDNN. cuBLAS for example has a similar issue with multi-stream handling, though this can be overcome with a proper workspace allocation: https://docs.nvidia.com/cuda/cublas/index.html?highlight=Rep....
Still better than cuDNN where some operations just don't have a reproducible version though. The other fields are at least trying. DL doesn't seem to be.
On that note Intel added reproducible BLAS to oneMKL on CPU and GPU last year. https://www.intel.com/content/www/us/en/developer/archive/tr...