Changes requested to goals doc

[jonmeow]

Just tracking a few changes to the goals #51 requested by @josh11b

(not making these up-front due to decision in progress)

[jonmeow]

193: overarching goal can be decomposed into a few specific aspects.

josh11b: Do we want to say anything about "reasonably fast by default" or "favors constructs that can be compiled to efficient code" or something like that? It was the sort of statement I just assumed was in the goals until I reread this section. The way this is written now, we could create a slow language as long as it was predictable and had an inline assembly escape hatch that was painful to use and hence rarely used.

jonmeow: TODO in https://github.com/carbon-language/carbon-lang/issues/106

Note though, I don't think this is an issue right now due to "leave no room for a lower level language" -- inline ASM is still breaking the "rules and structure of Carbon". Arguably it may be unavoidable, but I think the implications should address most of your concern, could maybe just be more explicit.

364: to understand.

josh11b: "... and the resulting performance more predictable"?

jonmeow: Adding as a TODO; https://github.com/carbon-language/carbon-lang/issues/106

424: scalability options for build systems of large software.

josh11b: Do we want to say anything about development vs. release builds here? If the overall goal is fast development, separate compilation would mostly apply to development builds. For the same reason, incremental build and link performance may be as or even more important than separate compilation.

jonmeow: I'll think this over, it definitely seems too much for this change. https://github.com/carbon-language/carbon-lang/issues/106

439: is good but insufficient. Both SIMD and SPMD must be directly addressable in

josh11b: I found it a bit unclear what point these two sentences about SIMD and SPMD were after. Are SIMD & SPMD supposed to be an exhaustive list of ways of implementing parallel constructs? Is this specifying that there should be at least three ways of writing parallel code (SIMD, SPMD, and something higher level that compiles to one of the other in some mysterious black box way)? Is it saying there is some relationship between SIMD/SPMD and the native programming models of platforms we want to target?

jonmeow: TODO work on phrasing; https://github.com/carbon-language/carbon-lang/issues/106

442: OS/environment distinctions such as desktop versus mobile versus bare metal.

josh11b: Add "embedded" here? I'm thinking of examples like game developers writing software for game consoles, which doesn't really fit in any of the three categories.

jonmeow: TODO work on phrasing; https://github.com/carbon-language/carbon-lang/issues/106

584: and having reasonable test coverage that passes under sanitizers.

josh11b: Wording nit: tests are the thing that pass under sanitizers, not coverage

jonmeow: TODO work on phrasing; https://github.com/carbon-language/carbon-lang/issues/106

[chandlerc]

Another one to capture here is a formatting quirk w.r.t. the emdash used with the John Carmack quote. Applying the hyphenation rule from the style guide here seems odd as this isn't a hyphen.

[jonmeow]

"... and the resulting performance more predictable"?

I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

[jonmeow]

"Add "embedded" here?"

Around 442, embedded could be added, as could microcontrollers, etc. I think we need to let the success criteria address this -- we shouldn't aim to have this duplicate that. Also, a 4-way "versus" I think becomes really just quite difficult to read. To whit, rephrasing a bit, and dropping "bare metal" rather than adding "embedded"

[josh11b]

"... and the resulting performance more predictable"?

I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually.

[jonmeow]

"... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually.

I agree, and think that my changes to the performance section do that.

[josh11b]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for?

On Wed, Jul 22, 2020 at 4:10 PM Jon Meow notifications@github.com wrote:

"... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability.

I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually.

I agree, and think that my changes to the performance section do that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/carbon-language/carbon-lang/issues/106#issuecomment-662742144, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ .

-- Josh

[jonmeow]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for? … On Wed, Jul 22, 2020 at 4:10 PM Jon Meow @.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ . -- Josh

"Idiomatic code should have good performance."

[josh11b]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for? … On Wed, Jul 22, 2020 at 4:10 PM Jon Meow @.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ . -- Josh

"Idiomatic code should have good performance."

That does not capture what I was trying to convey. Yes, idiomatic code should have good performance. And yes, it says performance should be predictable. I had requested something additional conveying, in the simple implementation section, that a simple implementation is part of our strategy from for achieving the goal of predictable performance. Right now nothing in the doc captures that link.

[jonmeow]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for? … On Wed, Jul 22, 2020 at 4:10 PM Jon Meow @.***> wrote: "... and the resulting performance more predictable"? I'm skipping this one: after adding the paragraph to the performance goal, I think it's not necessary, especially in the "Code that is easy to read, understand, and write" section. The relevant sentence/paragraph from 364 is currently focused on understandability. I think this document would still benefit from some statement establishing a link between simple implementation and predictable performance, beyond stating we want them individually. I agree, and think that my changes to the performance section do that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADUNHVZPJCHIHP7LCUZZA53R45WXZANCNFSM4OVBAFAQ . -- Josh

"Idiomatic code should have good performance."

That does not capture what I was trying to convey. Yes, idiomatic code should have good performance. And yes, it says performance should be predictable. I had requested something additional conveying, in the simple implementation section, that a simple implementation is part of our strategy from for achieving the goal of predictable performance. Right now nothing in the doc captures that link.

To explain my point of view:

• Performance goal says idiomatic code should be performant without creating a readability trade-off.
• Understanding goal says Carbon should have excellent ergonomics. (or perhaps you're referring to "clearly and simply specified"? but I think that bullet is heading off in a different direction about undefined behavior)

Idiomatic carbon code should thus be performant, and have excellent ergonomics. But I really do think that the text under performance should be saying what you want, and I've adjusted it a little further.

Anyways, I'm shifting the PR to RFC, also adding another paragraph about docs that I now feel is missing. It may be helpful to shift comment there, and if you have specific edits to suggest, that may help too.

[jonmeow]

RFC

[chandlerc]

I must be missing some change, I don't see anything like that. Could you give me a quote to search for?

"Idiomatic code should have good performance."

That does not capture what I was trying to convey. Yes, idiomatic code should have good performance. And yes, it says performance should be predictable. I had requested something additional conveying, in the simple implementation section, that a simple implementation is part of our strategy from for achieving the goal of predictable performance. Right now nothing in the doc captures that link.

To explain my point of view:

• Performance goal says idiomatic code should be performant without creating a readability trade-off.
• Understanding goal says Carbon should have excellent ergonomics. (or perhaps you're referring to "clearly and simply specified"? but I think that bullet is heading off in a different direction about undefined behavior)

Idiomatic carbon code should thus be performant, and have excellent ergonomics. But I really do think that the text under performance should be saying what you want, and I've adjusted it a little further.

I don't think this is what @josh11b is talking about here really...

To illustrate, I think @josh11b is suggesting something along the lines of https://github.com/carbon-language/carbon-lang/pull/126

However, I'm not sure this is necessary, and it feels somewhat awkward and forced. I feel like the overall point might be better made with a principle rather than an adjustment of the goals, where we actually talk about the underlying desire: to not make performance contingent on complex, and thus unpredictable compiler optimizations. An example that might be used as an extreme but especially well analyzed case is making all methods virtual in Java and relying on the HotSpot optimization techniques (profiling, speculation, and deoptimization) to ensure this does not create a performance overhead. There is lots of research to support the idea that these optimization techniques can eliminate the cost of unnecessary virtual dispatch abstraction points, but there is also a lot to show that they are extremely complex and can be very difficult to predict in a performance constrained environment.

[chandlerc]

Just a quick note - not suggesting we run #126 through the whole proposal process. If that's the approach we want can likely fold it together with other wording improvements. I just couldn't make a suggested edit to unchanged lines in the review of #120 for example.