> The only thing that matters is wall clock time so if cache layout is making a 300% difference to wall clock, focusing on instructions counts will mislead you on the most impactful optimization to make
It isn't surprising to me that instruction counts as a performance metric would have less variance than wall time. Did you know that the environment size can actually affect wall time?
> 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.
Have a look at https://github.com/zyedidia/micro, which has those keybindings by default. Mouse support too. Completely eliminated the text editing learning curve for me, and years later, I still use it happily.
Edit: Oh, I see it's been recommended in this thread already.
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.
Love how my old Galaxy S6 is stuck on ancient Android 7. And it's the verizon version too, so I can't unlock the bootloader. Perfectly capable device, what a shame.
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 switched from pointing various things to cloudflare to simply using NextDNS a while ago, and it's just excellent. The onboarding flow was way faster and easier than I thought it would be (fantastic setup documentation). Configurations are really great for customization at per-device granularity. Extremely slick and fast web UI. Great DNS latency + performance overall.
I was planning on setting up my own recursive resolver one day (tm) but NextDNS really just makes everything so seamless + easy.
> Even worse, iOS forces you to use a fake VPN to change DNS servers at all on cellular!
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. :(
Agree with all these points (also an iPhone SE 2016 user). One more point to consider is whether or not the iPhone SE 2016 will continue to get OS updates.
Yes. I've long been impressed with the single core performance and power efficiency of apple's mobile SoCs. Same-generation SoCs used on a variety of androids can't even compare. Google Maps for example was running like total shit on my old Galaxy S6, switched to iPhone SE (2016) and never looked back.
Really exciting times where an A9-based quality handset can be had for ~$60 on eBay. I expect prices will fall a bit further with this new SE model. And yes, the A9 is completely viable in 2020. Planning on holding onto it for as long as reasonably possible.
This looks pretty clean! The enhanced readability reminds me of Wikiwand.
If you're looking for a bit of feedback, the search doesn't seem to handle fast typing well. I tried searching for "Frank Chu" and it seems that if I type it really fast, I get either no results or Franks that aren't Frank Chu. If I type slower, Frank Chu shows up.
Shameless plug: I rewrote the "dotfile-relevant" featureset of GNU stow in plain python as a PoC of a simpler batch symlinker: https://github.com/joshuarli/sym-prototype
> the general public actually doesn’t care about privacy at all
It's not that people don't care; privacy is probably undervalued in the context of making privacy vs. convenience/utility decisions. (Digital) privacy's value isn't really tangible until it's actively used against you.
At least on linux, go's native resolver follows a sane subset of glibc conventions like parsing /etc/nsswitch.conf, /etc/resolv.conf, /etc/hosts [1]. As long as your dns configuration is defined there, you won't notice much of a difference between go programs using go's resolver and programs making glibc library calls for dns stuff.
Hi Dima - I'm assuming you're aware of dnscrypt-proxy and wrote nss-tls because you wanted a lighter weight implementation of a subset of dnscrypt-proxy's features on a specific platform (linux/glibc, for example this won't work on linux/musl afaik)? I use dnscrypt-proxy happily but was interested in nss-tls, yet couldn't find a rationale/comparison in the readme.