Live data from Hacker News

Mid-stack inlining in the Go compiler

docs.google.com

71–76 of 76 posts

Re: Mid-stack inlining in the Go compiler

#71
post #68

Earlier quoted context omitted.

If you're going to be pedantic, you might at least be strictly correct. There is no existing term that would distinguish it from Go's prior state, so there is no misuse nor "useless invention". Even if there were and you were correct, this would still be pedantry at its finest.

> ...would still be pedantry at its finest. Why would correct use of terminology be "pedantry at its finest"? What people are concerned about is intellectual dishonesty. The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go. Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter…

> Why would correct use of terminology be "pedantry at its finest"?

Because you're debating terminology when the wrong term caused no one confusion, thereby detracting from the actual conversation.

> What people are concerned about is intellectual dishonesty.

There's no cause for this concern.

> The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go.

Sure it does; see slides 3-6.

> Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter?

Perhaps the author omitted it from his deck because it's impractical to cover the whole breadth of inlining in a deck that's already 35 slides long. Perhaps he simply didn't think to include it. There are a lot of likely explanations for why this wasn't included besides nefarious motives. You sound paranoid.

Re: Mid-stack inlining in the Go compiler

#72
post #65

Earlier quoted context omitted.

"Conventionally inclining includes ...?" What does it include? You've conveniently managed to skip over the crucial part with ellipses. Calls in the middle of stacks perhaps? You people have too much time on your hands to go and pick at the wording people use in their presentations.

> You people have too much time on your hands to go and pick at the wording people use in their presentations. What kind of argument is that?

I'm saying that this is an incredibly inane, nitpicky, superficial conversation that has nothing to do with the technical content of the presentation.

Re: Mid-stack inlining in the Go compiler

#73
post #71

Earlier quoted context omitted.

> ...would still be pedantry at its finest. Why would correct use of terminology be "pedantry at its finest"? What people are concerned about is intellectual dishonesty. The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced for Go. Do other languages not have this kind of inlining? Does comparing and contrasting other implementations just not matter…

> Why would correct use of terminology be "pedantry at its finest"? Because you're debating terminology when the wrong term caused no one confusion, thereby detracting from the actual conversation. > What people are concerned about is intellectual dishonesty. There's no cause for this concern. > The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced…

> There's no cause for this concern.

Well, why do you think we are bringing it up, then? Due to some nefarious motive?

Re: Mid-stack inlining in the Go compiler

#74
post #72

Earlier quoted context omitted.

> You people have too much time on your hands to go and pick at the wording people use in their presentations. What kind of argument is that?

I'm saying that this is an incredibly inane, nitpicky, superficial conversation that has nothing to do with the technical content of the presentation.

You are saying it; but you aren't really backing it up with anything.

Re: Mid-stack inlining in the Go compiler

#75
post #71

Earlier quoted context omitted.

> Why would correct use of terminology be "pedantry at its finest"? Because you're debating terminology when the wrong term caused no one confusion, thereby detracting from the actual conversation. > What people are concerned about is intellectual dishonesty. There's no cause for this concern. > The presentation does not go to much effort to show, for example, why the term "mid-stack inlining" needs to be introduced…

> There's no cause for this concern. Well, why do you think we are bringing it up, then? Due to some nefarious motive?

My take: it's because of an unnecessarily cynical worldview coupled with a misunderstanding about the intended audience of the presentation.

Re: Mid-stack inlining in the Go compiler

#76

Earlier quoted context omitted.

I strongly doubt this. It doesn't say this in the preso, and ... 1. The compiler is a lot slower, which is usually from code growth and not debugging info growth. If the compiler is that much slower from debugging info growth, they have larger issues :) 2. Usually people do not include debug info sizes in binary sizes, because DWARF/et al info can be stripped and put alongside the binary (IE it doesn't even have to b…

It does say this. One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining.

"If I'm understanding the increase is mostly due to the "debugging" info that is added, not necessarily due to more code. " vs " One of the last slides says 4% of the additional size came from adding more debugging information, excluding anything to do with the new inlining"

So no, it doesn't say that it's "mostly due", it says ~25% is due to debugging information.

Post reply on HN