rsc

14 ms·

31.
by rsc 2y ago
One small correction: we were doing bisect over compiler optimizations a decade ago, but bisect over call trees only happened in the past year or so. For the hash table case, deciding the function per-table as you suggest is probably good e
32.
by rsc 2y ago
If we add it to the standard library it will be for runtime uses (identify the call stack for which swapping in the new implementation or behavior breaks the test). It is pretty simple. You call 'godebug.New' in a global init to g
33.
by rsc 2y ago
Anyone working on libraries that are used by large programs can use them, like in the sort and timer cases described toward the end of the paper. When you work on libraries used by other larger programs you inevitably break them accidentall
34.
by rsc 2y ago
Yes, I believe LLVM has a flag for "run only the first N optimization passes" that gets used with binary search this way. A global optimization fuel that worked at finer granularity would be even more precise but you'd have t
35.
by rsc 2y ago
Indeed. Something like this is what I intend to do when I get some time.
36.
by rsc 2y ago
What you are describing sounds like comparing traces of two supposed-to-be-identical programs to see where they first diverge. That's not what this is describing. There is no trace at all, nor any decision about what to trace or what n
37.
by rsc 2y ago
Thanks for that link. I've changed the link beneath the Cinder mention to that page instead of the GitHub page.
38.
Hash-based bisect debugging in compilers and runtimes(research.swtch.com)
254 points by rsc 2y ago|45 comments
39.
by rsc 2y ago
Idempotent is a somewhat confusing word choice here. "Verifiable builds" seems more a accurate description of what they want. (See also https://go.dev/blog/rebuild .)
40.
by rsc 2y ago
I can't speak to what has happened with Buildifier, but in general you are right. It has to be a hard rule that if you change the format rules, you have to reformat everything to match. If that means it's too hard to change the fo
41.
by rsc 2y ago
Not git, but yes, it did mess up the blame lines. Luckily most people don't care about the attribution on BUILD files. But I did get the occasional email for years afterward about "hey looks like you added this build target, can y
42.
by rsc 2y ago
This One Trick Will Add 80 Minutes To Your Day
43.
by rsc 2y ago
No, because Go compiles to binaries, like C/C++ but unlike Java or Python. Only the buildifier binary needed to be installed on everyone's machine. (I think Go was already installed on every Google developer machine at that point
44.
by rsc 2y ago
(Rosie is a code janitor program at Google that takes a change that affects files all across the tree and automatically cuts it into individual changes that can be mailed out to the individual teams as CLs/PRs for their approval.) Rosi
45.
by rsc 2y ago
If you're using Go with Bazel, gazelle is available outside Google: https://github.com/bazelbuild/bazel-gazelle Enabling tools like these was exactly the point of the enforced formatting. It worked extremely well.
46.
by rsc 2y ago
At that point you could even use different languages. Maybe you like programs that look like Lisp and I don't. There was a project at Microsoft Research in the late 1990s/early 2000s that did exactly this - storing ASTs in source
47.
by rsc 2y ago
My notes say it was 193k at the start. The final dashboard when we stopped said "216,626 / 216,890 = 99.8%; 264 to go". The other correction I would make is that this post does not mention Nilton Volpato, who had written an e
48.
by rsc 2y ago
If you do it that way, then what should be a 1-line BUILD file change turns into something that changes every line. It distracts from the actual purpose of the future change. Many directories aren't touched for long periods of time. A
49.
by rsc 2y ago
Thanks for posting the update here. I was going to point out that 0.5ns for anything is almost always a sign of benchmarks being optimized away. But even if those numbers had been accurate, it is important to think about how they compare to
50.
by rsc 2y ago
From the article: The messages show the Chinese citizen and the collective members reacting in real-time to the vulnerability being detected. “I don’t understand. Which idiot discovered this?” the Chinese citizen claiming responsibility ask
51.
Xz attack attributed to Chinese official's son, claims another exists(thenightly.com.au)
17 points by rsc 2y ago|4 comments
52.
by rsc 2y ago
Sure, like the one in https://9fans.github.io/plan9port/ . :-)
53.
by rsc 2y ago
Not if you use a modern language that enables TCP_NODELAY by default, like Go. :-)
54.
by rsc 2y ago
> I'm kind of surprised that it's slower on AMD Ryzen - it looks like only the Pro series have a an actual co-processor. Weird decision on AMD's part to implement AES-NI without HW acceleration on some CPUs instead of just
55.
by rsc 2y ago
For benchmarking ChaCha8, I ran: go test -bench=Block internal/chacha8rand For benchmarking AES-GCM, I edited src/crypto/cipher/benchmark_test.go:51 to add 256 to the length list, and then I ran: go test -
56.
by rsc 2y ago
OpenBSD had a similar problem with people calling arc4random and getting RC4 randomness, but they just changed it to use ChaCha20 anyway and backronymed it to "a replacement call for random". https://man.openbsd.org&#x2
57.
by rsc 2y ago
Filippo and I dug into this a bit more, and it is possible that VSCode auto-complete (which also adds imports for the auto-completed things) is the culprit here. Apologies if that's what happened to you. We will look into fixing that.
58.
by rsc 2y ago
It's a good question. We probably could have designed something based on AES-GCM instead, but it would have had more limited impact. ChaCha8 is still very fast even without direct hardware acceleration. The 32-bit benchmarks at the end
59.
by rsc 2y ago
That publication doesn't seem to mention the "lagged" part, or maybe I missed it. I am aware of https://www.leviathansecurity.com/blog/attacking-gos-lagged-... which also refers to it as a lagged Fibonac
60.
by rsc 2y ago
Ouch, apologies for that. We changed goimports to prefer crypto/rand back in 2016, so I'm not entirely sure what happened during your refactoring. Perhaps code that used other math/rand-only APIs ended up in the same file. h

More ›