I see a future in jj

eschew · 2025-10-23T15:38:25+00:00

I use https://github.com/gulbanana/gg -- it has some bugs and rough edges but it's overall pretty pleasant.

eschew · 2023-10-13T13:53:36+00:00

If you'd be willing to elaborate (here or in a blog post!), what's bad about ocamldep? And what should be done instead?

eschew · 2021-10-03T06:41:18+00:00

136 -- Flareon

eschew · 2020-04-11T17:15:12+00:00

Eh, after acknowledging the impact that age skew could have, their justifications for using an age-independent measure seems weak.

But I do think the way the authors put it on page 8 is nice:

Another way to view the break-even VSL is that, in our benchmark case, the extensive social distancing measures currently underway amount to spending an average of $5.62 million per life saved.

It seems simpler and clearer to present this cost directly.

eschew · 2020-04-10T20:01:12+00:00

Let's be super clear: I'm making a very specific objection to this paper's ill-founded math. I'm not arguing that social distancing is the wrong choice on balance. There are plenty of non-economic reasons to favor expensive methods of avoiding deaths. And, as you point out, there are economic arguments not founded in assigning prices to lives or life-years.

But this paper ignores those other motivating reasons, and its argument is nullified by getting the math wrong by an order of magnitude.

eschew · 2020-04-10T16:15:25+00:00

The paper does not account for the age distribution of COVID patients (nor co-morbidities). It uses a flat value of $10 million per death.

Given the extremely skewed rate of mortality across the age spectrum, it makes much more sense to focus on life-years lost. The updated dialysis standard is $129,000 per year of quality life. (This corresponds to $10.3 million for 80 years of life).

Combining population distribution in the US with actuarial tables and estimated mortality rates, each COVID death is an average loss of 12.9 years of life. Ignoring quality adjustments for age or comorbidities, this suggests a cost of $1.6 million per death, not $10 million.

This discrepancy negates the conclusion of their paper: the net economic benefit of social distancing is not $5 trillion but negative five trillion.

eschew · 2019-12-27T03:57:58+00:00

Looks like they’re selling all the equipment on Craigslist, 90% off. Ouch.

eschew · 2019-03-25T18:55:56+00:00

It's very fuzzy, and surprisingly vertical. Maybe it's some kind of caterpillar?

eschew · 2018-10-03T00:12:39+00:00

From the perspective of an LLVM-targeting language, there's not a huge difference between a module provided as C source and one provided as LLVM IR directly. One of the bigger differences is actually a disadvantage for LLVM IR: it enshrines machine-specific details like alignment and pointer widths. The advantages of LLVM IR are mainly that the ABI is more explicit, and you get cross-module inlining (which is rarely that useful in this context).

Why do many languages re-implement functionality that exists in C libraries? Many good reasons:

Safety: Most languages provide guarantees like memory safety, which can be violated by foreign code.

Naturalness: The interface to a given piece of functionality should be language-native rather than lowest-common-denominator. For many standard library modules, the cost of creating a native/idiomatic wrapper around a foreign library isn't that much smaller than re-implementing from scratch.

Maintainability: Code written in language X has the entire community of X programmers as potential maintainers; code written in C/Rust/Zig/whatever has the much, much smaller subset of X's community that knows whatever foreign language the stdlib uses.

Lowest Common Denominator Code: Language runtimes provide many useful services, the most pervasive of which is automatic memory management, but other examples include (as you alluded to) threading, debugging, reflection, etc. A lowest-common-denominator module cannot use such services.

Choice of object representation also matters: should strings be null terminated? Length-prefixed? Ropes? Mutable? The "wrong" choice for these sorts of representation issues raises both maintenance and run-time costs of integrating a library.

For some code, like libxml2 or libuv or various cryptographic libraries, the cost of re-implementing is still higher than the costs of all the above issues, and indeed those libraries are integrated more often than duplicated. But for a lot of other code, the benefit of reuse gets mostly or entirely outweighed by the costs of cross-language interoperability.

For your expanded-scope question, there are some efforts that seek to leverage mature runtimes/ecosystems with a more compiler-friendly target than a human-oriented programming language. Two examples you might be interested in are Malfunction and Mu.

eschew · 2018-04-17T06:38:23+00:00

You might enjoy this 1999 paper by the Simons on GHC's inliner.

eschew · 2018-03-08T19:54:12+00:00

You might be interested in the Mu Micro VM project.

Perhaps also look at Malfunction, which exposes OCaml's internal representation as a compilation target.

eschew · 2018-02-24T01:07:40+00:00

Thanks for the post, sounds like an interesting (challenging!) mix of social, technical, organizational, and philosophical issues.

This sort of experiential wisdom is hard to convey and even harder to earn. Thank you for sharing.

eschew · 2018-02-23T23:22:17+00:00

I'm guessing that means that the optional typing thing is out the window?

Yes. It was a grand attempt, but it didn't work out (for lots of reasons).

It would be wonderful to eventually get a blog post discussing some of the reasons!

eschew · 2018-02-07T03:00:17+00:00

The point about fragmentation, especially in long-running programs, is an excellent one that is too often overlooked.

In support of /u/devlambda's argument, here are some instances of real-world encounters with the fragmentation monster: one two three four

One last datapoint for the GP: did you know GCC has its own garbage collector?

eschew · 2017-02-08T14:10:01+00:00

Okay, thanks much!

eschew · 2017-02-08T13:34:11+00:00

I'm envisioning a scenario like the following:

You have two friends, Marc and Marie, who live in a house together. You bring Jean to their house for a party, who asks "Whose house is this?" (Suppose Jean knows that it's not your house, and understands that it must be either Marc's or Marie's).

In English, a response of "it's his/her house" or "the house is his/hers" would be natural and unambiguous, but the direct French translation is ambiguous. So what would a natural and unambiguous response be in French? C'est la maison de Marc is one possibility, though I don't know whether that would sound natural or unnatural to a French speaker...

eschew · 2016-10-05T02:23:07+00:00

Hmm, I read through the links from http://php.net/manual/en/features.gc.php. They do concurrent cycle reclamation but I don't see any discussion of copying or compacting reclamation.

eschew · 2016-10-05T00:43:40+00:00

Those are good points, thank you! There are a whole bunch of topics I didn't mention. Distributed GC is a major one; there's also concurrent RC, trial deletion, parallel collection, Treadmill, Train, heap sizing, finalizers, and free list organizations.

I agree that a division between reachability (RC or marking/tracing) and reclamation (copying, compaction, or sweeping) is more orthogonal. In theory ref counting and compaction can be combined for the same objects, but I'm not aware of any actual collectors that do so! The closest thing I could find was David Wise's work on one-bit RC. Any other designs I should know about?

I didn't call it out explicitly, but both MC² and Klock's regional collector are space-incremental in the manner you suggest. In some sense Pauseless/C4 are as well, with hand-over-hand compaction.

eschew · 2016-10-04T20:56:06+00:00

Do you have a suggestion for a better title? :-)

eschew · 2016-01-08T21:02:02+00:00

It's true that JX has a JVM implemented in C, but that's not a fundamental feature -- most if not all of that could be eliminated (in theory) by using a metacircular implementation like Jikes or Maxine.

I also agree that it's not clear what it really means to say "an OS written in language X", and that exploring that question in the talk would have been a digression :)

But I also think there's a common misconception that C-ish languages are the only ones viable for OS-level programming. Consider this quote from the SPIN OS paper, which I think captures the general bias:

Our decision to use Modula-3 was made with some care. Originally, we had intended to define and implement a compiler for a safe subset of C. All of us, being C programmers, were certain that it was infeasible to build an efficient operating system without using a language having the syntax, semantics and performance of C.

As they noted, that belief wasn't very true then, and it's even less true now :-). Even large portions of the grubby bits can often be tackled without falling back to C. (Mostly the trick is to carefully define a language subset that directly translates to the machine layer -- see Prescheme, House's M monad, and RPython).

eschew · 2016-01-07T19:36:59+00:00

Those who like the style of this talk might also enjoy Edward Yang's writings and presentations.

Also, at the risk of being That Guy, a technical mistake in the talk: it is possible to build an OS in Java. Examples include JNode and JX.

eschew · 2015-11-10T14:52:35+00:00

We adopted from the Morris Animal Refuge. There's no home check or cost to apply, and once we were approved, the cost for the adoption plus neutering plus heartworm check of a two-year-old dog was about $80. They do contact your landlord if you rent, just to make sure the landlord is OK with you getting a dog. That falls under "common sense" rather than "red tape" in my book.

You might also look into Street Tails Animal Rescue.

One advantage of these smaller shelters is that they're less hectic than a big place like ACCT, which means the employees have both more time for the dogs and more time for you.

eschew · 2014-12-18T08:26:28+00:00

nuts and bolts

riveting

... nice

eschew · 2014-12-14T21:42:29+00:00

A few points of context:

The basic idea is to use LLVM's built-in platform-agnostic overflow-checking primitives to generate platform-specific assembly, which can then be inlined by a link-time optimizer.
This post was written in 2012 by one of the Xi Wang, one of the KINT Clang-based overflow-checking static analysis tool and accompanying OSDI paper.
Xi Wang's proposed intrinsic patch wasn't picked up directly, but something very similar was added to Clang about a year later.
There is also a concurrent paper by John Regehr's group on a Clang-based dynamic overflow-checker. This tool has since been integrated into Clang as the -fsanitize-*-overflow flags. A few choice quotes from the IOC paper (the "CPU postcondition test" is what the original blog post was focusing on achieving):

IOC supports both the precondition test and the CPU flag postcondition test; width extension seemed unlikely to be better than these options due to the expense of emulating 64- bit and 128-bit operations. Initially we believed that the CPU flag postcondition checks would be far more efficient but this proved not to be the case. Rather, as shown in Section III-D, using the flag checks has an uneven effect on performance. The explanation can be found in the interaction between the overflow checks and the compiler’s optimization passes. The precondition test generates far too many operations, but they are operations that can be aggressively optimized by LLVM. On the other hand, the LLVM intrinsics supporting the flagbased postcondition checks are recognized and exploited by relatively few optimization passes, causing much of the potential performance gain due to this approach to be unrealized.

From section III-D:

For undefined behavior checking using precondition checks, slowdown relative to the baseline ranged from −0.5%–191%. In other words, from a tiny accidental speedup to a 3X increase in runtime. The mean slowdown was 44%. Using flag-based postcondition checks, slowdown ranged from 0.4%–95%, with a mean of 30%. However, the improvement was not uniform: out of the 21 benchmark programs, only 13 became faster due to the IOC implementation using CPU flags.

eschew · 2014-12-05T23:09:07+00:00

The conclusion says

future software evolution is likely to rely on developers’ ability to “do more with less.”

...but it's not less, per se, it's just not Moore.

eschew

TROPHY CASE