haberman

14 ms·

121.
by haberman 2y ago
For the first, the prediction was "in the next few years." If we take "a few" as three, that would bring us to 2024-10-02, which was earlier this month. It could still happen someday, but didn't in the time frame
122.
by haberman 2y ago
I've added claims from a wide gamut of people (some just random Internet users), but here are a few: 2021-10-02 (did not come true): "I would not be surprised if Apple completely closes off the Mac ARM64 platform for “security” in
123.
by haberman 2y ago
I consider https://longbets.org/ the public version of this. It's a little different in that it only publishes bets made directly on the site, but that also helps remove some of the ambiguity that otherwise would be in
124.
by haberman 2y ago
> And of course, the other real issue, especially in the U.S., is the capability of the power grids. In the Netherlands, which is an advanced economy, as in the U.S. and the U.K., we’ve already seen reports that the grids are functioning
125.
by haberman 2y ago
If the characterization is inaccurate, then say so. If not, this is just name calling and mind reading.
126.
by haberman 2y ago
FWIW he says your last point is false: https://x.com/MKBHD/status/1838583491413360781 > The Twitter account is from 2021 because it's a salvaged username from an inactive account. The app was built from sc
127.
by haberman 2y ago
> Non-goals: Drop-in replacement for CPython: Codon is not a drop-in replacement for CPython. There are some aspects of Python that are not suitable for static compilation — we don't support these in Codon. This is targeting a Pytho
128.
by haberman 2y ago
I agree with the article's diagnosis: the system is out of control, with no market forces are in place to keep costs in check. It's unsustainable for students to take on this level of debt. I'm not sure I agree with the solut
129.
by haberman 2y ago
> As for the level of public debt, it is indeed very high, but not unprecedented. It is close to that observed in France in 1789 (around one year's national income), and significantly lower than that seen in the United Kingdom after
130.
by haberman 2y ago
Agreed that these are remarkable and moving pieces. If anyone wants to hear some of these, I helped produce (and sang on) a recording of these several years ago, that I think turned out pretty well: https://www.youtube.com/p
131.
by haberman 2y ago
"Build is the first stage of execution" resonates with me too. It follows that build systems should be written in terms of real, encapsulated APIs that separate interface from implementation. Make-like build systems are like progr
132.
by haberman 2y ago
LuaJIT completely upended my view of what a JIT compiler could be. I always thought that JVM-like overheads were inevitable for high-performing JIT compilers. When I saw how small and low-overhead LuaJIT is, I was blown away. Here are some
133.
by haberman 2y ago
I have been happily using OrbStack for a while now, and I've had nothing but good experiences. The UI is polished and responsive, the containers have great performance and nice integration with the host, and overall the product seems
134.
by haberman 2y ago
If that’s the case, when can I expect C compilers to inline variable-length memcpy() the way they will inline fixed-length memcpy today?
135.
by haberman 2y ago
> A medium-sized Rust project can easily tip the scales at 2-300 crates, which is still rather more dependencies than anything I’ve looked at here, but that’s explained by the simple fact that using libraries in C is such a monumental pa
136.
by haberman 2y ago
Came here to ask this exact question. As I understand it, Observable Plot also seeks to be the "higher-level abstractions on top of D3" layer. The Vega docs address Vega vs D3 ( https://vega.github.io/vega/abou
137.
by haberman 2y ago
I always take this as inspiration that the performance quest is rarely over. LLD was specifically designed to be fast, as was Gold which came before it. But Mold blew them both away.
138.
by haberman 2y ago
The problem is not the 1 cycle latency, but the data dependency on both values. A correctly-predicted branch cuts the dependency on the value that is not used. I've definitely measured scenarios where cmov/branchless is slower th
139.
by haberman 2y ago
Since preserve_none is Clang-only and only available on recent compilers, it would introduce an ABI hazard between the core library and generated code. We don't want to cause crashes if you compile protobuf with one compiler and gener
140.
by haberman 2y ago
I certainly understand your caution. I don't have intimate expertise with the implementation of musttail in the backend -- when I implemented musttail in Clang, it was piggybacking on an existing attribute from the LLVM IR: https:&#x
141.
by haberman 2y ago
Mike Pall makes an argument that interpreters are especially susceptible to this problem, and I find it convincing, since it matches my experience: https://web.archive.org/web/20180331141631/http://articl
142.
by haberman 2y ago
> On the other hand, adding "real" tail calls to C would probably require changing the ABI (e.g. to "tailcc" or "fastcc -tailcallopt") But [[musttail]] does exactly this while respecting existing calling con
143.
by haberman 2y ago
Fallback paths most definitely have more state than what can be stored in registers. Fallback paths will do things like allocate memory, initialize new objects, perform complicated fallback logic, etc. These fallback paths will inevitably
144.
by haberman 2y ago
preserve_none is the new one. It can be applied to the functions performing tail calls to allow them use of the full register space. I even saw an enhancement recently that will make preserve_none allocate arguments in the registers that a
145.
by haberman 2y ago
Thanks for the pointer, I'll have to check this out. Can you elaborate on how "return goto" is easier to implement? [[musttail]] also ends the lifetime of local objects AFAICS. One thing I'll mention from a quick scan: &
146.
by haberman 2y ago
Sure, but that approach forces you to consider/research just how much CPU your I/O tasks may or may not require. What if I'm not sure? How CPU-intensive is open()? What about close()? What about read()? It would simplify
147.
by haberman 2y ago
Is it safe to say that a single thread using io_uring should be as fast or faster than N threads performing the same set of I/O tasks in a blocking manner? In other words, can you count on the kernel to use its own threads internally w
148.
by haberman 2y ago
I had exactly the same thought. I don’t know if that 20k number was supposed to inspire confidence, but for me it did the opposite. It would have inspired confidence if it was 300 lines of code. My impression is that the WebAssembly verifie
149.
by haberman 2y ago
Coincidentally I was just writing a bignum library from scratch two weeks ago. A few interesting things I learned: 1. Knuth volume 2 has an extensive discussion of the problem space. I've only gotten a chance to skim it so far, but it
150.
by haberman 2y ago
Is this really true? I would intuitively expect that register renaming would apply to eflags too, so that reads from flags don't truly need to be serialized despite nominally writing a bunch of things to the same register. EDIT: this

More ›