JoshuaRLi
Joined 10 years ago
Joined 10 years ago
Ahh, very well said!
> We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our program. This phenomenon occurs because the UNIX environment is loaded into memory before the call stack. Thus, changing the UNIX environment size changes the location of the call stack which in turn affects the alignment of local variables in various hardware structures.
From https://www.inf.usi.ch/faculty/hauswirth/publications/asplos....
Edit: Oh, I see it's been recommended in this thread already.
Not my area either, but a little surprised why a PCG-family non-CSPRNG algorithm wasn’t used: https://www.pcg-random.org/posts/a-quick-look-at-xoshiro256....
PCG XSL RR 128/64 (MCG) could be used for 64-bit values (albeit with period 2^126 compared to xoroshiro256’s 2^256 − 1) with 128 bits. Half the state size than xoshiro256, and the performance might be comparable (would need benchmarking). LCG version if you want to trade PRNG quality for even more speed.
Switched to iPhone SE a while ago because of this.
Then, go get -v will download your dependencies to GOPATH, and (re)generate go.mod, go.sum. For info on how to update dependencies, read `go help get`.
When using modules (presence of a valid go.mod file), GOPATH won't be used for resolving imports. So you don't have to actually work in GOPATH anymore, dependencies are just stored there.
I was planning on setting up my own recursive resolver one day (tm) but NextDNS really just makes everything so seamless + easy.
This is a major pain point for me - I'm trying to use both NextDNS and Tailscale on my iPhone SE 2016, and confirmed that they clash with each other. :(