eholk

I used the Nano pass framework for my language when I was in grad school and loved it. I forget the exact count but I think we had 40 or 50 passes. Generally each pass either did some analysis that would be consumed by a later pass or it rewrote some higher level concept or feature in terms of more primitive operations.

Nanopass had a DSL for describing what forms you delete from each intermediate language and which forms you add. Each pass was generally pretty small then, usually just replacing one form with some set of other forms.

Be cause each pass was really small it was pretty easy to reorder them. Sometimes we figured out if we moved one optimization sooner then later passes worked better. Or we realized some analysis was useful somewhere else so we rearranged the passes again. The pass ordering made it really clear which analysis results are valid at each point in the compilation process.

I took it as meaning "perspectives of people in the Rust Project about AI."

You know, that's exactly how I learned to program.

I started up QBasic knowing nothing other than that it seemed like a thing for programming computers and programming seemed like a cool thing to do.

I typed in random words, and eventually I typed "screen". When I pushed enter, QBasic capitalized it, so it seemed important. I hit F1 and read the help. It made no sense, but the example ran and had other capitalized words so I could repeat the process.

Eventually I started making really terrible text-based Final Fantasy knock-offs.

When we were teenagers, one of my friends lit a guitar pick on fire. It was a lot more exciting than we expected! We thought it'd just shrivel up and melt, but instead it was like the pick was made of solid rocket fuel.

Bjarne Stroustrup is 74, so he probably counts as a senior too at this point, although surely more technically literate than the stereotypes.

Still, I'm in my early 40s and I find myself baffled when I help my mom with her iPhone. I've been an Android guy ever since that was an option.

For what it's worth, I've read both Bostrom's Superintelligence and AI 2027. Reading Superintelligence was interesting and for me really drove home how hard setting aligned goals for an AI is, but the timelines seemed far enough out that it wasn't likely to be something that would matter in my lifetime.

AI 2027 was much more impactful on me. It probably helps that I read it the same week I started playing with agent mode on GitHub Copilot. Seeing what AI can already do, especially compared to six months ago, and then seeing their projections made AI seem like something much more worth paying attention to.

Yeah, getting from here to being killed by rogue AI nanobots in less than five years still seems pretty far fetched to me. But, each of the steps in their scenario didn't seem completely outside the realm of possiblity.

So for me personally, my 80% confidence interval includes both things stagnating pretty much where they are now, but also something more like AI 2027. I suspect we'll be fine, but AGI seems like a real enough possibility that it's worth working on a contingency plan.

This was back when Internet Explorer was at version 7. Some Mozilla folks told me they used to get questions like "when are you going to upgrade to Internet 7 like Microsoft?"

If I remember right, after Firefox 4 they skipped a few versions and started the train model, while also trying to de-emphasize the version number in marketing.

If you're using Windows, in my experience Thunderbird is essentially unusable until you add a Windows Defender exclusion for your Thunderbird profile.

Would that mean Indiana goes back to the way they were before they started doing Daylight Savings Time?

Firefox adopted rapid version numbers basically because the rest of the browsers did. For years Firefox was on 3.something, and they'd get questions from people saying things like "Microsoft is already on Internet 7, when are you going to support Internet 7?" If I recall right, Firefox skipped versions 5 and 6, and starting with 7 they decided to use a rapid version number scheme and deemphasize version numbers in their marketing.

The names are still there internally. Android 10 was Quince Start, and Android 11 is Red Velvet Cake.

https://www.xda-developers.com/android-11-red-velvet-cake/

I'd be really interested to see a comparison of the relative risks between skin cancer and vitamin D deficiency.

A lot of what I've read lately suggests we're discovering a lot of benefits of vitamin D that were previously unknown, and some evidence that the recommended vitamin D levels should be higher than they are.

For a generation or so we've told people the sun is dangerous because of skin cancer, and obviously skin cancer is really bad. But I wonder if we have a case of need to weight risks that are high cost, low probability (skin cancer) compared with low cost, high probability (low vitamins D complications). What is the overall effect of these two things?

I think originally Roman numerals didn't have shorthands like IV instead of IIII. In that case, to add Roman numerals, you just write the letters all together, sort them, and combine smaller digits into larger digits as necessary.

Typically the way systems do this is by translating small sections of straightline code, and patching the exits as they are translated. So you start by saying translate the block at address 0x1234. That code may go until a jump to address 0x4567. When translating that jump, they instead make a call to the runtime system which says "where is the translated code starting at address 0x4567?" If the code doesn't exist, it goes ahead and translates that block and patches the originally jump to skip the runtime system next time around.

This means early on in the program's run you spend a lot of time translating code, but it pretty quickly stabilizes and you spend most of your time in already translated code.

Of course, if your program is self modifying then the system needs to do some more work to invalidate the translation cache when the underlying code is modified.

I see it as a way of focusing the discussion. The numbers we could plug into it are mostly all wild guesses, but the exercise of plugging in different numbers can still be instructive.

For example, we now know there are a huge number of planets out there, and even planets in the habitable zone. Yet we haven't found any extraterrestrial life, so that suggests maybe the other factors are smaller than we initially would have guessed.

...some Google employee has already refactored the code around the bug. Then you have to be fast enough to get your updated patch applied before someone else has reorganized the code again...

For what it's worth, this is how it work's if you're a Google employee too.

- IRs need to be intuitive to the people who work on the compiler. Sea of nodes is more challenging to think about than SSA over CFG.

I worked on V8 for awhile, which uses a sea of nodes representation. This point really resonates with me. I and many of my teammates never completely developed an intuition for the different edges in the graph. There was a lot of trial and error involved.

I remember reading this paper and thinking "wow! this is the solution to all the problems I never knew I had." The generality and simplicity of a single graph that does everything is appealing. But in practice, I think you'd most often be better with SSA over CFG.

Sorry I didn't set this up initially, but here's a super barebones playground: https://google.github.io/schism/playground.html

Keep in mind there's barely any error checking, so it may or may not work for you. I hope to improve this over time, and am happy to accept patches to do that as well.

I hadn't seen those before. Thanks for the link, they look pretty interesting!

I haven't documented the choice of R6RS anywhere, so here is as good of place as any.

The main reason was familiarity. R6RS is the Scheme I know best. I learned on R5RS and moved on the R6 when it was the new hotness. I vaguely was aware of R7 (I have friends that were on the standards committee), but didn't really know much more than that it had happened.

There's a technical reason for choosing R6RS as well though. To me the defining characteristic of R6RS is the library system. In my mind, this has a pretty clear mapping to WebAssembly modules. Scheme libraries import some set of identifiers and export another set. WebAssembly modules are the same way, so I basically set it up so that Scheme exports and imports map directly only WebAssembly exports and imports.

I'd definitely be open to supporting other Scheme versions in the future.

Responding to pjmlp, a cool project I saw recently that's related to the ones you mentioned is Unikernels [1]. They noticed that a challenge faced by a lot of those projects is hardware support--each OS has to ship with a huge set of drivers to be widely usable. They sidestep this by targeting a VM, which exposes a single hardware interface no matter what it's running on.

[1] http://anil.recoil.org/papers/2013-asplos-mirage.pdf

To be fair, Rust probably would have needed this for some other reason in the future. I see this more as making Rust a more complete language.

I've done most of my development on a Mac, but I keep finding many bugs in Apple's OpenCL implementation. Intel's seems to follow the standard most closely, which is useful for keeping me honest.

It's basically defunctionalization. It's hard to get access to function pointers on the GPU to do "real" higher order functions.

It's not, although I don't think it should be too hard to port. I haven't done it yet because I don't have ready access to a Windows machine with an OpenCL-capable GPU.

Lately I've been more focused on getting the features running and less on performance, so I haven't completely explored the impact of using these structures.

I'd be interested to hear more about what you're doing. Do you have any links you could share?

I really should update the user guide, since the language has changed a lot in the last year.

I have an earlier post that discusses a couple of the optimizations that Harlan does: http://blog.theincredibleholk.org/blog/2013/06/10/some-simpl...

To me the win for Harlan over CUDA is its region system, which lets you work with more intricate pointer structures in the GPU. For example, there is an interpreter for the Lambda Calculus as one of the test cases, which would be much harder to do in straight CUDA: https://github.com/eholk/harlan/blob/master/test/lambda3.kfc

Very soon, Harlan will have support for higher order procedures, which is also not available in CUDA.

We did start out with a miniKanren type inferencer and region inferencer, but I replaced it a couple months back with a unified type and region inferencer. Region inference is definitely an interesting challenge for miniKanren, since a lot of the constraints it introduces are soft. There are many legal region assignments, but deciding the best one requires some heuristics.

The experiment has several variants of each program. In some cases the names make sense, and in other cases they are just random words. One of the goals is to measure how much choosing good names matters.

Some of the initial analysis Mike has done shows that programmers spend the majority of their time looking at identifiers. I think this supports your point.