@koronkebitch most definitely, I think we need a lot care approaching stipend amount vs cost of living when advertising positions. When I joined northwestern, we were advertised as having one of the highest stipends in the nation (or some similar statement with more nuance/gymnastics), but that didn't account for the high cost of living. After unionizing we're at a decent place (a person without dependents can live well with no roommates [and maybe put some money away if they budget strictly]). But if you just look at the dollar difference between northwestern and most places it'd seem big. It'd be nice if we could get finer grained CoL numbers for folks in different situations (dependents, roommates, medical needs, etc) so that prospectives could get a better view of what life would be like.
PhD Candidate at Northwestern University, I study how we can improve static analysis and optimization of memory operations with new compiler intermediate representations.
@koronkebitch I was going to recommend https://csstipendrankings.org/ as a useful quick reference resource for students (which I share when students reach out/during our visit day), but I just realized they only have info for schools in the USA. Maybe a concerted effort to crowd source info for Canada could help? (Typical caveat that I don't see a need to make this stuff a ranking, but a single source of info is helpful imo)
I've been getting custom (out-of-tree) passes to work at LTO with LLVM's new pass manager (I hope they never rename it).
I couldn't find a good description of this solution anywhere online so I wrote it up:
https://gist.github.com/tommymcm/1c65f9ed5f169bdc8ee1f4d1268558bb
Hopefully someone finds it useful.
I have a similar workflow working now for Rust/Cargo.
If folks are interested in that I can take some time to write it up as well, otherwise I'll do it when I feel like it.
@tekknolagi and I have put together our camera-ready version of our PLDI 2025 paper, "Partial Evaluation, Whole-Program Compilation": https://cfallin.org/pubs/pldi2025_weval.pdf
This paper is on weval, which I worked on for two years and previously wrote up on my blog (https://cfallin.org/blog/2024/08/28/weval/). In brief, it's a way to get a compiler from an interpreter "for free". Unlike past Futamura-like systems we're aware of, this one works on existing industrial interpreters (SpiderMonkey).
Enjoy! Looking forward to Seoul...
I'm looking forward to presenting our work on "Saving Energy with Per-Variable Bitwidth Speculation" at ASPLOS'25!
This work makes more efficient use of the register file by speculating on the bitwidth of program variables, enabling us to pack multiple subword values in a single register.
We do this with a compiler-architecture co-design, combining speculation in software with a hardware mechanism for detecting misspeculation. With minor extensions to the LLVM IR and CFG Linearization, we are able to perform this fine-grained speculation with virtually no performance overhead on speculative code paths.
You can find the preprint here: https://mcmichen.cc/files/BITSPEC_ASPLOS_2025.pdf
Looking forward to seeing folks in Rotterdam! Just in time for the tulips, I hear.
@wilbowma csconferences.org
@dev have you or someone you know used typst for any papers? I had heard a comment (in passing) that someone had issues generating a camera ready pdf (for acm iirc). It seems really nice but I'm afraid of putting any time into it until I know that I can use it for more than personal documents.
@wilbowma when I was learning and implementing range analysis, this paper was the most useful resource for me:
https://homepages.dcc.ufmg.br/~fernando/publications/papers/SBLP2011_douglas.pdf
@cfbolz thanks for sharing! Definitely some fun stuff going on in the world of mojo. I remember seeing a blurb about these library defined optimizations being enable by some combination of progressive lowering and elaboration in their past blurbs. I especially love how simple optimizations like this become when you have ownership in the type information (like you said, they dont elaborate much but that's what I've gathered from the slides). It's a nightmare trying to raise that kind of thing from something like LLVM IR. Looking forward to the day when they make their compiler toolchain publicly available and we can start playing around.
Very excited to announce that our paper,
Getting a Handle on Unmanaged Memory
by @wanninger @tommy, Simone Campanoni, and Peter Dinda
has been accepted to ASPLOS 2024!
A preprint is available here: https://nickw.io/pub/asplos24-alaska
This work enables a runtime to transparently and automatically relocate heap objects in *unmanaged* languages like C or C++ with no changes to the source code.
We do this using a level of indirection well known in the managed languages world: the handle. We present an LLVM compiler transformation that automatically translates these handles whenever they are used. This indirection allows us to relocate objects freely, which enables heap defragmentation in unmodified C programs like Redis and Memcached.
Looking forward to seeing folks in La Jolla!
@cfbolz To my knowledge there was no recording. If I am able to scrounge one up I'll be sure to pass it along!
In the meanwhile, here are the slides for the CGO'24 talk: http://mcmichen.cc/files/MEMOIR_CGO24_TALK.pdf
I also have a longer slide deck that I have given to a few universities and workshops now, which has more details and visuals: http://mcmichen.cc/files/MEMOIR_LONG_TALK.pdf
Of course, slide decks only go so far--as there's no one there to, you know, talk--so if you need more details feel free to reach me on here. I will try to keep the latter slide deck up to date as I make various changes and (hopefully) improvements to it overtime.
@regehr Oh hey, that's me! I'm very excited about the doors we're opening with this direction and I've been overjoyed at the reception we've gotten so far! I'm more than happy to give more details to folks here that may be interested.
A little late on this one, but I was very grateful for the opportunity to present my work on "Representing Data Collections in an SSA Form" with MEMOIR at CGO'24! Had a ton of great conversations about using, representing and compiling data collections at the conference, I am very happy to be a part of such a lively community.
The paper is available here: http://mcmichen.cc/files/MEMOIR_CGO_2024.pdf
The compiler is open source: https://github.com/arcana-lab/memoir
And we have documentation: http://mcmichen.cc/memoir-docs/
We are planning on building upon and supporting MEMOIR well into the future.
Very happy to release MPL v0.5, which implements automatic parallelism management, from our POPL'24 paper.
This release makes it possible to write very fine-grained parallel code with good performance in practice!
@mattpd @lritter @cfbolz Yes, I had looked into ClangIR and some other MLIR dialects when setting out on the engineering for the project. We ended up not using any for a few reasons:
(1) our lab has a lot of engineering put behind LLVM already and we saw staying within that substrate to be the least friction for future research
(2) we wanted to avoid building on top of a language-specific compiler and end up making decisions that would limit the bulk of our engineering to that language.
I think that for any production quality approach we would want to move MEMOIR into an (existing/new) MLIR dialect, but I am not at all an expert on that infrastructure.
If you'd like to chat about paths forward for putting MEMOIR/MEMOIR-esque ideas into ClangIR I'd be more than happy to chat!
@cfbolz @lritter I'd say that Sarkar and Knobe SAS'98 is the most easily digestible description I have found ( https://www.cs.rice.edu/~vs3/PDF//sas1998.pdf ).
@lritter Thanks for sharing the spec. I think what you're getting at is the partial compilation problem, i.e., we are compiling part of a program and the variables we are using are getting passed into a separate black-box module. We describe how we handle this compilation environment in the beginning of Section 5 with ARG/RET PHIs. Long story short, they cause your analysis to be conservative and limit your transformations. For the case that you're talking about this would be limiting when you try to concretize an abstract type, i.e., sequence => linked list. We don't encounter the issue at the moment because our compiler implementation lowers all sequences to `std::vector` and all associative arrays to `std::unordered_map`. This issue of language interop is a part of the reason why we chose to implement memoir as an extension of LLVM.
@lritter @cfbolz Are you talking about the general issue of passing these collection variables into a C function? If so, the paper doesn't talk much at all about that but our compiler implementation deals with it. The way that we represent our collections in the LLVM IR is as a C pointer, so we simply analyze how those pointers are created and used by our own functions. I can elaborate on this more if that's what you're referring to.
If that isn't what you're referring to, could you elaborate on the issue a bit more?
@lritter @cfbolz Hey! Author of the paper here. I'm more than happy to answer any questions y'all have.
To hopefully clear up _why_ we distinguish between indexed and key-value collections: during an insert/remove, the only change to the index space of a key-value collection is to the referenced key (it now either exists or doesnt, in isolation from others), whereas with indexed collections the index of multiple elements is updated (pushed in the case of an insert occuring ahead of it in the sequence or squished back together following a removal to element(s) ahead of it in the sequence).
I'm sorry about the lack of prior work explanation, we were very restrained with the space in this paper so we had to gesture back to it more than I would have liked. I'm hoping to have some time in the near-ish future to put out a technical report with those details fleshed out in writing, or at least a couple of blog posts on the topic. If there are portions that you think could use the most attention please let me know so that I can have an idea on where to start.