chandlerc

chandlerc , 3 days ago

@meowray FWIW, strongly disagree here.

I think it is entirely possible to have quality, velocity, and open contribution.

I'm not saying there isn't a tradeoff, but I think the above three can be preserved sufficiently.

For example, in LLVM, I think the bigger challenge than quality is that people view "contribution" as much more about "sending a patch" and not "reviewing a patch. As a consequence, the project has lost community and cultural prioritization of code review as an active and necessary part of contribution.

Also, "open contribution" doesn't mean you have to accept contributions. I think a project can still have meaningfully open contribution while insisting contributors balance their contributions between patches and review, and where contributions that are extractive are rejected until the contributor figures out how to make them constructive.

IMO, criteria for sustaining both quality & velocity in OSS:

• Strong expectation of total community code review in balance to total new patches -- this means that long-time contributors (maintainers) must do more review than new patches.
• Strong expectation of patches from new contributors rapidly rising to the quality bar where they are efficient to review and non-extractive.
• Strong testing culture that ensures a large fraction of quality is mechanically ensured
• Excellent infrastructure use to provide efficient review and CI so tests are effective

I think LLVM struggles with the first and last of these. The last is improving recently though!

chandlerc , 6 months ago

@pervognsen This is a really nice insight, and not what I had guessed it to be from the term "extrinsically tagged sum types"... I wonder if there is a way to refer to this technique that more immediately cues the reader to the insight / design tradeoff, because it does seem really valuable to teach and entrench as the default way you want to look at this problem space.

chandlerc OP , 7 months ago

@pervognsen Yeah, the visual similarity was an easy reason to exclude them from any widely used part of the language.

The question we're coming up with is that we have a relatively niche use case (couple orders of magnitude below Kotlin's usage) where val makes a great deal of sense. But var does come up in that use case, but yet another order of magnitude (at least) less often than val would. At that point, the visual confusion seems much less worrisome. There aren't going to be confusing runs with a slight difference, etc.

But if it makes just reading the descriptions of the language hard / impossible / infuriating for Japanese native speakers, that maybe argues against having both keywords even in a niche use case.

chandlerc OP , 7 months ago

@pervognsen https://discuss.kotlinlang.org/t/var-and-val-are-you-kidding-me-give-me-con/15621/6 is also a good citation for the frustration this can cause when in a widely used part of the language. =/

chandlerc , 9 months ago

@thephd Given that %q was used, and %lp was used by CHERI I think I would suggest continuing down the %lp path. Model this as a length field for the p type. I'd re-use I as a reference to an instruction pointer with %Ip. Re-using I has the advantage of it already being in a length field so it shouldn't break much, but does mean re-using / aliasing the meaning when applied to pointer types. No worse than %lp though, and that seems to have worked out OK.

If that doesn't work for folks, could either use %fp if you can re-use a type character in the length field, or if not, %Cp (with C for "code") maybe?

chandlerc , 9 months ago

@thephd I was trying to type capital I which I think is a length modifier?

chandlerc , 10 months ago

@pervognsen FWIW, I remain firmly in the "CFG with use/def graph layered on top". Had several debates about this over the years with V8 team and others. Somewhat interesting to see all this coming back around. =]

chandlerc , 10 months ago

@zwarich @pervognsen I don't really buy it...

You can always just write the optimization on the use/def graph and get SoN behavior?

And as much as I agree about the compile time benefit potential you mention, the larger thing for me is the huge advantage of a source-code hint for the schedule. Like, yes, you can compute a schedule easily enough. But the degrees of freedom on that are huge. Letting source code paint the path out of that impossibly-large search space is an advantage that is hard to beat. And not just for actual program scheduling (which I'm not sure matters that much), but also for all the optimizations that must rely on scheduling in some way because we don't have a proper dependency based model for them.

chandlerc , 10 months ago

@moonchild @zwarich @pervognsen This seems to presuppose that clarity is in opposition to scheduling, but that isn't always the case...

For performance critical code, the scheduling often is a hugely important aspect to make clear.

The scheduling that is completely unconstrained (side-effect-free scheduling) is also the one that even a CFG compiler will nearly limitlessly fix for you, and so is essentially never requires sacrificing clarity. And CFG remains strictly superior: in SoN, you write clear code and get bad performance in a very rare case, but have zero recourse to fix. While in CFG, you write clear code and and get bad performance in a very rare case, and at least have a recourse to fix locally (at clarity cost) until the compiler bug is addressed and clarity can be restored.

The scheduling where the program source has to reflect it is the effectful schedule, and there changes are often semantically relevant and so not best (IMO) communicated out-of-band. Or if they are, we already have the tools for this in terms of factoring functions, and organizing the source code in a way that is clear and then assembling those components in a way that enacts the desired schedule.

chandlerc , 10 months ago

@moonchild @zwarich @pervognsen SoN literally throws out the source code and starts from scratch. The CFG preserves the CFG at each step to fall back on, but can still make purely dependency based optimizations.

Thats some of what I mean by saying that in many ways, this is about it being easy to have the best of both worlds.

Another way to see it is that SoN focuses on throwing information away. My whole point is to keep both sets of information, and use whichever one is most helpful for a specific case.

chandlerc , 10 months ago

@moonchild @zwarich @pervognsen A somewhat simplified example, but about the best to fit into a social media post...

Imagine a huge bunch of loads and stores. None alias, and so the SoN compiler is free to select any order of loads and stores it likes. How does it guess at a likely-locality-clustered order? No chance.

But turns out, humans can easily group loads and stores together that have locality. And if there is no other information (and there often is no other info), that default order is likely near-optimal. And even if it isn't near-optimal, now you can document that the source-order is the default lacking information to the contrary, and the author can arrange for it to be near-optimal.

You could build a side channel to carry this information. But you do have source order already, and in practice it turns out to be a very solid starting point. Why not use it (and document it)?

chandlerc , 10 months ago

@pervognsen @zwarich @moonchild That could work. Or the load/store widening in codegen.

But sadly, neither of those are super powerful. And you'd have to teach a decent amount of machinery about the extract being cheap. The problem I suspect is that they see loading a vector (or a large integer) and extracting the parts, and a bunch of cost models go "EEEEP!", not knowing that this unpacking is built into the HW. =/

chandlerc OP , 11 months ago

When I wrote this, I said "naming convention".

What I was trying to talk about were the subtleties, not the main issue of "how do you name things".

Like:

• Do you use abbreviations? means shorter / simpler names, but may be less discoverable than the full word.
• Do you separate different kinds of names into different conventions like snake_case vs. CamelCase? Which ones?

The stumbling point that motivated it: how do you handle acronyms and abbreviations with CamelCase?

Again, not suggesting there exists a "right" answer. But also it doesn't feel wrong to want to question when the answer you have doesn't quite fit.

chandlerc OP , 11 months ago

@pervognsen This was the source of ... an inordinate time loss today.

Some folks like JpegEncoder. But it appears that a decent number of the folks who are comfortable with that rule in general, start to dislike it and potentially strongly when confronted with a specific case that ends up unreadable.

Interesting examples that came up: Llvm, Ir, Lld

chandlerc , 1 year ago

@thephd So, uh, does that mean I shouldn't re-boost this? ;]

chandlerc OP , 1 year ago

@michaelc I tried, but simple examples just fall apart in different ways, especially with the standard library and all the complexity of EH required in the containers...

Here is roughly a best case scenario: https://cpp.compiler-explorer.com/z/zTxGMdKe5

Main loop is the same, but "grow" requires its own bespoke template unlike with push_back.

chandlerc OP , 1 year ago

@michaelc

The way I think about it is break it down into a few core things.

First, emplace-style APIs capture each arg as a reference, so we spill them to the stack and use up a reg for every argument address. Then rinse through 42+ layers of std::forward, and only then pass each to the constructor.

Second, to ensure no copy or move, emplace has a much more complex growth scenario.

Third, the construction can't be separated and maybe occur at a diff level of inlining.

chandlerc OP , 1 year ago

@pervognsen @zwarich My primary use case is actually a nearly-static PIE binary. So I don't have any COW pages to really care about, my problem is that the entire large binary image is being relocated to some dynamic offset, and all these pointers need to be updated before I even hit main... My understanding is even in a separate section that'll have to happen?

chandlerc OP , 1 year ago

@pervognsen @zwarich I think this is largely already the case? They're all in .data.rel.ro rather than .data.ro, separating the pages of non-relocated data from the relocated ones from what I understand?

Certainly, the data structures themselves intermingle tons, but that's not easily fixed...

chandlerc OP , 1 year ago

@shafik https://cpp.compiler-explorer.com/z/MWv1nxTWd

Clang and GCC are solid.

MSVC is fine from Visual Studio 16.8 onward, but fail starting at 16.7 it seems. =[

chandlerc , 1 year ago

@pervognsen Is an M1 running Linux useful? (very good stability of timings, etc, but maybe not what you're looking for...)

chandlerc , 1 year ago

@pervognsen Here we go:

Executed in 51.55 secs fish external  
 usr time 211.05 secs 1.01 millis 211.05 secs  
 sys time 9.43 secs 0.03 millis 9.43 secs  

chandlerc , 1 year ago

@pervognsen Heres the release build (assuming I got the -r flag right):

Executed in 113.17 secs fish external  
 usr time 830.80 secs 264.00 micros 830.80 secs  
 sys time 9.63 secs 775.00 micros 9.63 secs  

I'm waiting to see if there is an M4 Max or Ultra that comes out in a non-screen form factor around the time that Asahi has M4 support, otherwise I would have nabbed one already.

chandlerc , 1 year ago

@dougall @pervognsen I wonder if the fact that I'm running Asahi Linux (and performance power mgmt strategy) on the M1 is part of the difference...

chandlerc OP , 1 year ago

Already some fun observations...

For short files, 10% of Carbon's compile time is ... initializing LLVM's internal commandline flags ... that we don't use...

This is going to be fun.

chandlerc OP , 1 year ago

@dougall Yeah, GCC is doing exactly what i'd expect here.

The extra frustrating thing is that at least for x86 I know LLVM models the flags sufficiently to get this. I'm really baffled why it doesn't... Guess bug filing time...

chandlerc , 1 year ago

@zwarich My favorite strategy is technically before the parser because I find it really hard to do well there:

Detect during lexing, and then post-process the token stream, ideally using indent to guide fixes.

Some of this implemented, but not the indentation bit:
https://github.com/carbon-language/carbon-lang/blob/trunk/toolchain/lex/lex.cpp#L1464

There is a TODO, and we have the indent data, just need someone to write the code to peak at the indent and select good fixes until we run out, and then run the greedy algorithm to fix anything left.

chandlerc , 1 year ago

@pervognsen @SonnyBonds AFAIU, not quite standard conformant in the latest C++...

Because you're round-tripping through the underlying storage pointer and a raw offset, you don't have valid pointer provenance for the subobject. But you can fix that, because this is an important use case in important cases: std::launder(reinterpret_cast<float*>(reinterpret_cast<char*>(&obj) + offset))

chandlerc OP , 1 year ago

also @thephd , this provides details that mean you may see a "happy"[1] ending to this story after all.

[1]: happy exclusively in the sense of whether it is yet-another-mem-safety-fail-parade entry or not...