almostgotcaught

> Anyone can act as though their position is righteous enough, and their opponent's is pernicious enough, that an exception should be made in this case.

"Both sides are the same"

> If someone else's comment is wrong, respond with an opposing argument. If their comment is inflammatory or in some other way in breach of the guidelines, flag it, and/or report it to us via email.

My man - there are well known dog whistles and revisionist accounts of the slave trade in this very comment chain ... And yet the only one that gets flagged is mine. And even so based on what grounds - a flippant remark about Wikipedia being free? Forgive me if I don't take your commitment to "healthy" discourse seriously.

[flagged]

You're missing that it's a dog whistle - we should not be nice. Look at this person's adjacent comments here.

[flagged]

[flagged]

> "Emancipation Day" does give the outsider a clue.

shall we also rename shabbat and yom kippur and purim so that "outsiders" can have a clue?

people are so tone deaf sometimes - it's not for you - it's for the people whose ancestors were freed on this day.

> the word itself gives you nothing to help you understand

neither does any other word that you don't bother to look up in dictionary or encyclopedia.

It's the same thing - both nanobind and cffi compile the binding. The fact that nanobind let's you expose cpp doesn't prevent you from only exposing c. And IMHO nanobind is better because you don't need to learn another language to use it (ie you don't need to learn cffi's DSL).

The call overhead of using ctypes vs nanobind/pybind is enormous

https://news.ycombinator.com/item?id=31378277

Even if the number reported there is off, it's not far off because ctypes just calls out to libffi which is known to be the slowest way to do ffi.

You're "talking your book".

This is giving tinfoil hat vibes - I would guess style detection has such a high false positive rate as to be near useless. Also there's nothing stopping people from publishing reviewer comments today and letting the Internet run wild with "style detection" (or doing it themselves).

Sure - I agree that LLVM is mostly reasonable - I'm just saying I don't think has to do with the design of the IR itself and is primarily because of convention/code quality/stewardship. Like to ask my question more precisely: can you give me an example of an IR design that didn't "isolate ugliness"?

Edit: I'm being rate limited so here's what I wanted to post in response:

You kept talking about LLVM and I just assumed LLVM IR but this thing (different rules before and after regalloc) is exactly the case for LLVM's MIR (even going so far as no longer being SSA after a certain part of the pipeline). And in fact I have a PR hanging out right now for adding a legalization for GISel (which also operates on MIR) that crashes in exactly the way you say it shouldn't - I run my legalizer and it's fine and dandy and then somewhere down the line (another legalizer) there's a null dereference. So I guess LLVM isn't reasonable everywhere! And also I should take a think about the differences between LLVMIR and MIR.

> SLP vectorizer will affect the performance upside of passes before/after it. It won't affect their correctness.

maybe. it's late so i can't think of a counter-example off the top of my head where someone downstream of SLP somehow took something for granted and then it blew up in their faces. even if it is somehow magically not true for SLP, it's definitely true for other sequences of passes, where subsequent passes depend on prior passes.

> if you reorder the phases then the compiler crashes and burns. Some of these compiler are in production, sadly. I've heard some crazy horror stories. And it's all too easy to find yourself in that situation if you're not careful.

i mean i have witnessed this in a prod MLIR compiler i have personally worked on - it's exactly what i had in mind above. did it crash because it tried to deref some pointer to some attribute/node/whatever? no that's true - it crashed via llvm::report_fatal_error (or assert) - but it crashed nonetheless.

> It is the case that if you do a flow-insensitive analysis of variables over SSA, it will be equivalent to a flow-sensitive analysis of variables, because of the static single assignment property.

you're saying the same thing i'm saying - the question/issue arises from value numbering and naming. see "engineering a compiler" page ~400 where they discuss the benefits of SSA for value numbering: https://imgur.com/a/bPabq7D

> I don't think dense vs sparse analysis is the same thing as the use of the word "sparse" in the post.

it is - the allusion/claim in the post is that SSA is sparse because you don't need to keep track of facts/metadata for all variables at all program points. that's because of the same thing: SSA uniquely locates/identifies values and therefore you can uniquely map between SSA ids and metadata. so you don't need to have a table of stuff that's updated at every program point (like you do in dense analysis), just along control-flow/operand/result edges.

> A good IR means that the only contract between compiler passes is the IR itself.

this is like impossible (or at least np-hard). phase ordering exists and will always exist - SLP vectorizer will dramatically affect passes after it and sometimes even passes before it!

> Writing a cool new pass that obeys the IR’s laws is not going to break the other passes.

I don't really get how you can fail to obey the IR's laws other than just emitting unparseable IR? alternatively if you like have uses without defs or flip-flopping types, the verifier needs to catch that after the guilty pass and just bail (not put the onus on the subsequent passes to fix).

Anyway IMHO (even though no one asked me), IR needs to have enough structure/info that you can quickly reproduce whatever metadata you need for XYZ arbitrary analysis. Meaning it should represent all of the useful/necessary things (don't make me infer non-negativity structurally if I can just annotate) and it should propagate those things across rewrites.

> If your static analysis is over SSA, then generally the static analysis is easier and (potentially) storing facts is easier. This is due to this property called sparseness. Where a static analysis over non-SSA programs has to store facts about all variables at all program points, an analysis over SSA need only store facts about all variables, independent of context.

Not sure what this has to do with SSA or not? Maybe you're saying if you don't have SSA then value numbering requires extra book-keeping to keep track of the names? that's true but the book-keeping only kicks when a name is updated, not at every program point.

> If we want to keep our information sparse, though, we have to add a new definition to the IR.

I mean this isn't like a law of nature, it's just a design point - a question of whether the facts have to be serializable for some reason. If they don't (and in general, I can't think of a reason they would have to be), you can just keep things in-memory in general and do either sparse or dense analysis on an as-needed basis. To wit MLIR, an SSA IR, handily supports both sparse and dense dataflow analysis:

https://github.com/llvm/llvm-project/blob/main/mlir/include/...

https://github.com/llvm/llvm-project/blob/main/mlir/include/...

Note, both analyses propagate lattices which support meet and join.

> Anyway, SSA only stores type information about instructions and does not encode information that we might later learn in the IR. With basic SSA, there’s not a good way to encode refinements…

This is true of course but I struggle to think of a reasonable semantic that would enable you to refine/change/alter the type of a value that wasn't an operation. The conditional example is specious but could be rectified if it were modeled correctly: the conditional is an operation which has operands and two regions, each with a basic block with basic block args and it's the types of the bb args that can show as "refined". MLIR's scf.if isn't "isolated from above" and its bbs don't have args but it could have both such things and such an operation would model what you want precisely and in the IR/types themselves.

> The amount of effort required to design and implement such a device makes it difficult for a single company to invest in, but many interested users of it could band together to create a viable open source implementation.

There are lots of companies that have their own high-performance accelerator cores (though not general purpose). Multiple generations. Eg every FAANG (except Netflix, that I know of).

There are exactly zero such OSS cores.

So I think you have this exactly backwards.

I'll never figure out why people post this kind of stuff here (and then it gets upvoted). there's literally nothing "hacker" related or even novel about these notes - it's just bog standard stochastic process. like these are just notes for some grad class or something. invariably someone will pop in and respond to my complaint saying "well actually I used everything in these notes for a project 10 years ago". ok. it strikes me, strongly, as just weird virtue signaling.

Your Func thing is better than std::function the same way a hammer is better than a drill press... ie it's not better because it's not the same thing at all. Yes the hammer can do some of the same things, at a lower complexity, but it can't do all the same things.

What I'm trying to say is being better than x means you can do all the same things as x better. Your thing is not better, it is just different.

I don't know why people think it's such a deeply shrouded secret - it's ~10k a seat for a core-limited license.

You really don't understand that what is advertised on a "people" page can be different from what the person actually does?

FYI if you worked at FB you could pull up his WP and see he does absolutely nothing all day except link to arxiv.

> Sometimes software development is largely "done"

Lol absolutely not

Lol where are people getting such ideas. First of all there are probably like 10 QC people graduating a year in the whole world (okay maybe 20). Second of all y'all people have no idea how far off usable QC is. It's like 50 years at best.

No one is going to ask this on an interview. Used to be matmul. These days it's FA.

> runtime

Are you talking about your libc equivalent or MAX?

As someone said below - you'd never write just a transpose kernel - it'll be fused into something else.

There's also the slack but you gotta know someone to get on that ;)

Weird take - how exactly could literature improve "in depth and characterization"? What new "technology" has been made available to authors that enables them to create deeper characters?

lol hot off the presses

Lol that's like asking what's the difference between the empire state building and the shed in my backyard: one is the runtime that the company that owns/makes the GPUs has been building for 10 years and the other is a (good) solo project.

> reversable or traditional computing

o.O ...

No man I'm saying a very simple and non-controversial thing: just because someone does a tut, has an elementary understanding, knows the basics, doesn't mean I'm going to let them build/maintain/own mission critical systems.

It's not that deep.