jeffbee

4 ms·

1.
by jeffbee 5d ago
At my employer in 1999 we were maintaining home-grown binary modification to the Solaris kernel so that TCP segment send and receive were not O(N^2) where N was the number of addresses on the interface :-/ It was, as far as I could tel
2.
by jeffbee 5d ago
Right before they fell face-first into the grave, they did finally ship the v20z, which was a completely reasonable way to run Solaris x86. Its management board ran Linux on PowerPC, for irony purposes.
3.
by jeffbee 5d ago
Counterpoint: it actually sucked. Entire universities lost a day's work when their editors were all fatally stuck in an rpc.lockd bug.
4.
by jeffbee 8d ago
Sure, also true that the per-CPU scheme co-evolved with the proliferation of services with thread-per-request architectures having way more TIDs than cores.
5.
by jeffbee 8d ago
Can we stop acting like selective quoting from discovered materials gives us an unbiased and factual representation of the truth? The plaintiff is always trying to cherry-pick and distort elements from discovered material. And this is exa
6.
by jeffbee 8d ago
> on other platforms, I am not so sure tcmalloc only works on Linux.
7.
by jeffbee 8d ago
Exactly. You want memory arenas that are hot in this CPU's caches. If your thread moves, its per-thread caches are now elsewhere. Original TCMalloc was developed in the days of 2-4 core servers. Current TCMalloc was an evolution in t
8.
by jeffbee 8d ago
No, but production ceased pretty recently and Waymo still has an inventory of them with zero miles.
9.
by jeffbee 8d ago
How much experience do you have with LLMs exactly? It would be consistent with my experience if Claude stuck in a line of python that just emits a JSON literal with no justification, potentially buried in a large program where an untrained
10.
by jeffbee 8d ago
> 2. Whenever a service retries but has to give up, the error it sends to its callers should never be retried. There has to be some agreement that that HTTP code will never be retried. This prevents the multiplicative factor of retry on
11.
by jeffbee 8d ago
Just limiting your retry budget to 1% of normal rates using a client-local token bucket with no distributed coordination will eliminate the possibility of long-lived retry storms.
12.
by jeffbee 9d ago
RISC was not a distant dream in 1994 LMAO.
13.
by jeffbee 9d ago
WiFi is a little faster I guess? In the primitive days people used the EyeFi.
14.
by jeffbee 9d ago
Mainstream DSLRs with dual card slots came out 22 years ago.
15.
by jeffbee 10d ago
Older versions also do that.
16.
by jeffbee 11d ago
Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.
17.
by jeffbee 11d ago
Java is almost always significantly faster than Go because the Go runtime does a poor job of exploiting large memory page, doesn't support text-on-huge-pages, and barely supports profile-guided optimization. With HotSpot you get all of
18.
by jeffbee 11d ago
Sure. You get the pointer, you lock the mutex, 99.99% of the time that is uncontended, then you set all the metrics and release it.
19.
by jeffbee 11d ago
This would have different answers depending on if it ran on a machine with a more closely-shared cache, right? For example on an Intel efficiency core cluster where 4 cores share an L2.
20.
by jeffbee 11d ago
If you have a per-cpu metric there would not be a reason to use atomic instructions to mutate it.
21.
by jeffbee 11d ago
Reading the clock every time you jump into a closure is in fact incredibly wasteful, and is exacerbated by chopping work up into tiny chunks for questionable reasons.
22.
by jeffbee 11d ago
The difference is nobody in the C++ community believes that a dominant asynchronous executor library exists, and there is not a pervasive belief that it would be helpful.
23.
by jeffbee 12d ago
I'm just reporting from the trenches here. I think you are suggesting that everyone is aware of and capable of using state-of-the-art (from 20 years ago) tracing schemes like XRay[1], when in reality they are not. Most projects would b
24.
by jeffbee 12d ago
I can get an LLM to trace my incomprehensible Tokio application which was also written by an LLM, which is why I don't understand its behavior. Truly the future we were promised.
25.
by jeffbee 12d ago
The low cost of eBPF tracing is another myth.
26.
by jeffbee 12d ago
Also a great way to make sure that your app spends most of its time in observability overhead. For example even the latency histogram that the OP mentions is wildly expensive.
27.
by jeffbee 12d ago
All of the significant server applications I have encountered in the industry have suffered from the same problem, which surprised their authors but seemed obvious to me: the application was spending the majority of its CPU time doing meta-
28.
by jeffbee 12d ago
Reporting bugs before Ubuntu releases has never worked for me. They always land a bunch of major changes after the supposed "freeze" then they ignore all feedback because of the freeze. It's infuriating.
29.
by jeffbee 13d ago
Android Auto and Android Automotive are not the same thing.
30.
by jeffbee 13d ago
Lol no. For almost the entire 20th century, until 1992, Filipinos could just join the Navy or Coast Guard at foreign recruiting posts, without even being American residents, then get fast-tracked for citizenship.

More ›