mpu

We just released a tiny (~3kloc) Python library that implements state-of-the-art inference algorithms on GPU and provides performance similar to vLLM. We believe it's a great learning vehicle for inference techniques and the code is quite easy to hack on!

Hi, thanks for the information, but LLVM still does not provide ABI compatibility. If you reduce the struct to 3 i32, it is passed in edi, esi, and edx on my machine. However according to the ABI it should be packed in rdi and rsi.

Checkout the QBE transcription and what it will compile to http://c9x.me/paste/mGOO (there is a bit of register shuffling because hinting in regalloc is not very mature yet, but note that SSA form for the input is not required!).

I actually decided to take more time to answer your comment more throughly than others. Also, I TA'd twice the class from where you linked the article below, so I know about it :).

It's only a goal I set to myself, if we can do better, heck let's do it! Keeping the code short, on the other hand, is really something I care about.

I think the extra load/stores clutter the IL.

Also, QBE does not really "alternate" SSA/non-SSA, SSA form is built once at the beginning of the compilation pipeline and preserved later.

I don't understand what you mean by "fully pruned programs". Maybe you want to refer to pruned SSA form. And then, here is my point: with LLVM, either you build SSA yourself or you use allocas. QBE offers a convenient third option.

Cool, thank you guys!

At least, I can try!

And also, we are seeing more and more certified C programs: see the DeepSpec NSF expedition grant, the Verified Software Toolchain, and the CertiKOS project for examples. I work with these guys.

I take this as a compliment. It means my design choice was totally valid, and maybe even a good one.

Then maybe I did not express myself in the best terms. QBE definitely supports stack slots and their registerization! Minic, a small C frontend shipped with QBE makes use of them.

The difference is that LLVM forces you to use them even when you know your locals do not escape (i.e. your source language is Pascal), QBE doesn't.

So, LLVM makes you use stack slots for two independent problems: 1. Compiling languages like C where locals can escape, and 2. Avoiding to construct SSA form in the frontend. In QBE, you use stack slots (alloc4, alloc8) to solve 1, but to solve 2, you can simply emit non-ssa form and QBE will fixup things for you.

It's an alternative if you fit in the use case. I did not try to clone LLVM.

It's much much smaller (I think libfirm is over 100kloc, QBE is about 6k).

But the major difference is the IL: I use a human-readable and easily-printable text IL. This means that you don't need a graph-viewing tool to read the IL (it's just text) and that you can modify the IL between two passes super easily. This simple IL is a blessing when debugging a compiler.

I think QBE also has better support for the x64 ABI.

Finally, it is much less advanced (less optimizations, less tested) than libfirm and supports only x64 as a target.

This is a sketchy comparison.

Thank you for your words. It is often called NIH, but eh, I learned a lot! And I think that I made some modest improvements over LLVM, you can check them out in my comparison at http://c9x.me/compile/doc/llvm.html

12,000 links is probably too much.

Hurray, no floating points!

So you rewrote the whole thing.

You're wrong about the arrays, the standard guarantees that zeroing the bytes of an object of integer type will give a 0 value to the integer. Pointers are a different matter though.

Bullshit, on x64 all 32 or 64 bit base arithmetic operations have the exact same cost, except the 64 bit version is one byte longer because of a REX prefix. This is why 32 bits is the natural int size for x64.

Bc and dc do exact arithmetic.

Anybody who wrote a medium-sized project in C is aware of such a trick. And also of the load of problems that comes with it! (They are not really pointers anymore.) Please stop trying to make C look like javascript, just create a new language from scratch, the pile of syntax tricks you're playing with is bound to collapse.

That's what Cello is about I think.

Isn't it possible to talk about variance as soon as you have a type constructor (function from types to types)? In this case [].

Edit: I don't know go, but if slices give write access, I think the automatic conversion the author wants would be unsound.

Thank you, I fixed that. In my head I knew a REX prefix was necessary and thought it was sufficient, but i386 has shortcuts to load an immediate into a register that are not available in 64 bits version!

Thanks for mentioning that.

Nope, except for the fun, the assembly part does not add much to the matter. The essence is how to design, describe and analyze algorithms, so it is largely orthogonal to the language you use.

Pretty good point. That's how I felt.

Additionally, this setting is probably too close to usual situations you get in school where there is little to no interaction and negative answers from the teacher are seen as failures by students. (Speaking about education in my country only.)

But what a type! I would be much more inclined to annotate effectful code instead.

I find it hilarious that all the examples he gives in the beginning have weird semantics only because of LAZINESS, mixing effects with laziness gives nonsense, give a cbv semantics to the language and you get the intended behavior (intended even by HIM who is arguing for laziness). Unbelievable.

Edit: in my comment, oppose pureness (that is put forward in his rant) to laziness (what he unintentionally is arguing against).

Agreed.

Why does it have to be in the cloud? Can't you guys provide a player in html css whatever and the recording program to generate data files for the player so we can use your technology everywhere and are not tied to this website and its hosting policies?

/rant

Good job on the 3-SAT encoding, it was very clear.

Lots of code in there is deprecated. Don't use it.