That is, if you're Linus Torvalds.

we're a small team and we work with pretty tight feature branches, so that would rarely be an issue for us

If you're a kernel developer, you wake up, there are 20 new patches/pull requests since last night, waiting in your inbox, for you to review, apply, test. You'll spend most of your morning checking if they conflict with each other and rebuilding to test things. Probably the source control management takes half of your morning.

yeah, for sure, and I think that also describes a lot of how git is designed

doing that in SVN would be torture

https://www.youtube.com/watch?v=FnGCDLhaxKU

I'm watching this. Quite interesting, on how LLVM does some optimizations.

"Const methods and const references play no role in the LLVM optimizer."

this guy's talks are typically pretty good

Trying to help out on a node project and it's using "knex" to build DB queries. I have no idea why anyone would use this, the code is literally longer and more complex than just a raw sql query. It doesn't even completely abstract database types like a proper ORM would.

seriously why is the JS world so full of shit

Because JS programmers.

JS web apps are the reason humanity deserves nuclear annihilation

radical Islam > JS

I should become an imam and declare a jihad on using unmaintained node packages in production software

https://youtu.be/s4wnuiCwTGU

Best followup talk.

I'll watch that in a bit, that looks good

LLVM can do up to 3 inline optimizations, and he still doesn't know why.

... huh

runtime overhead limit?

no

huh

He can manually control the optimizer passes to convince the compiler to do a 4th inlining.

The optimizer is derived from something I assume

Clang is a front-end for LLVM.

ah

He's not a LLVM programmer, although Clang is their most important front-end.

I mean, he's not responsible for LLVM itself.

back when I did embedded stuff we would mess with the runtime to create different runmodes, and we did stuff like made generic unrolled loops for rasterizing and we'd put them straight into the runtime

so basically to do a draw cycle we'd use a DMI call to switch runmode

for some reason that came to mind just now but thiking about it there's absolutely no way that's how clang is doing any sort of optimizaiton

*incomplete thought - the crt had a size limit so in my head optimized code + limit to 3 connected to that

none of this is making any sense is it

I should probaly take a break soon

Clang doesn't optimize. It just spits out correct IR to LLVM.

Well, according to the previous talk, Clang only tries to remove dead code.

makes sense

He talks about how LLVM does bottom-up passes, while GCC does top-down. Both with fallback heuristics that try to work the other way around in special cases.

You're making me want to get into a big C++ project again. I haven't done a big C++ project in probably ~2 years now

i have a love/hate relationship with C++, but its the thing i use the most.