JITs, programmer shit
i know some of that can be because they try to merge different passes together for speed. the nanopass framework shows you don't *really* need to cram everything in to a single pass. i dunno if there is some clever wizard way to merge those without burdening the dev team (like, idunno, some way to define join points AOP style and let passes glue themselves together around those.)
apparently mono/coreclr run 2-4x faster than gdscript in godot.
i'm somewhat curious (if iceclr gets that far) if we just don't do that and instead leave it maintainable. the JIT doesn't need to be fast. we have caches for that
maybe i'm stupid and the people who maintain those runtimes for a living know more than me though probably
re: JITs, programmer shit
@Moon @icedquinn One pattern that I keep seeing over and over again is how people would first do their JIT compiler w/ something like LLVM because "we can tolerate longer compile times and it produces more optimized code anyway" yet would move away from it (or adds tiered compilation w/ LLVM being the last tier) eventually because it turns out to be too slow for their purposes or something...
So I suppose compile times still matter to some extent? 
usually you want a compiler to be very fast for prototyping and then you want it to make code that runs fast when you're finished with that.
llvm is okay at the second (but pulls in a massive c++ dependency) but not good at the first. i think beef uses a homebrew compiler for debug and llvm for release, for this reason.
people seem to be fine with Go's performance, and Go tends to side with the pareto efficient designs. so i would guess if it could match go then it's good enough. that being said i don't know anything else about the Go compiler so idk.
Graal gets pretty good performance too. not sure how chungus it is (i've only read the papers.)
bonifartius 𒂼𒄄
@icedquinn @Moon @koakuma the go compiler is pretty interesting, it also uses something like IL as it's assembler. i think it would be pretty interesting to see other languages targeting the go assembler.
> The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine. Some of the details map precisely to the machine, but some do not. This is because the compiler suite (see this description) needs no assembler pass in the usual pipeline. Instead, the compiler operates on a kind of semi-abstract instruction set, and instruction selection occurs partly after code generation. The assembler works on the semi-abstract form, so when you see an instruction like MOV what the toolchain actually generates for that operation might not be a move instruction at all, perhaps a clear or load. Or it might correspond exactly to the machine instruction with that name. In general, machine-specific operations tend to appear as themselves, while more general concepts like memory move and subroutine call and return are more abstract. The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined.
It sounds a lot like LLVM, if I'm not mistaken
@confusedelectron @icedquinn @Moon @koakuma iirc the go/plan9 compilers are pretty simple compared to other compilers http://doc.cat-v.org/plan_9/4th_edition/papers/compiler
