51–60 of 76 posts
Earlier quoted context omitted.
I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?
The point is "inlining" already refers to this kind of inlining. The already-present form is more limited than the typical use of the term.
Earlier quoted context omitted.
If I'm understanding the increase is mostly due to the "debugging" info that is added, not necessarily due to more code.
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…
Earlier quoted context omitted.
The point is, as usual, Go is trying to catch up to what everyone else has had for years. The use of non-standard terminology here is suspicious, raising the question that the Go people are trying to hide the fact that they are playing catch-up.
Comments like these are so depressing. Someone does a bunch of work to improve the Go compiler and writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it), and gives it all away for free. This is textbook open source citizenry, which should be applauded. But instead, you come along and criticize them for being too specific with their terms (!!) and als…
Perhaps Ericson2314's gripe is that it's being posted (and upvoted) on HN, rather than just a Go-specific forum (e.g. reddit.com/r/golang), and by implication it's intended to be read by a more general audience.
Earlier quoted context omitted.
I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?
> What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler? There isn't a standard term, because virtually all inliners always did what Go is now doing. It's pretty basic functionality.
Earlier quoted context omitted.
I don't think anyone is pretending that Go is a decades-old language. What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler?
> What is the standard term for this kind of inlining which would distinguish it from the inlining already present in the compiler? There isn't a standard term, because virtually all inliners always did what Go is now doing. It's pretty basic functionality.
Earlier quoted context omitted.
"So it records the calling convention, architecture flags, alignment, and other ABI pieces etc?" No. At the moment it records the AST in the object file, because the inliner works at the Go AST level. In the future it may instead record the SSA representation (which would obviously give better cost estimates; the current heuristics are really extremely simple). "FWIW: Writing out the info is usually not the hard part…
> The DAG-ness means it's always available when compiling the call site, even if it's a cross-package call. It means you don't have to do it at link time. Why is it any harder to do at link time? (I've implemented this in a production compiler, and choosing whether to do it at compile time or link time was a trivial decision.)
Every good production C++ compiler has had some form of link time optimization for many years.
IBM's, for example, has been happily cross-optimizing between C++, java, fortran, PL/IX, etc without any issues, going on at least 15, maybe 25+ years now (I know it's 15 for sure, i suspect it's closer to 25).
Earlier quoted context omitted.
Comments like these are so depressing. Someone does a bunch of work to improve the Go compiler and writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it), and gives it all away for free. This is textbook open source citizenry, which should be applauded. But instead, you come along and criticize them for being too specific with their terms (!!) and als…
> writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it Perhaps Ericson2314's gripe is that it's being posted (and upvoted) on HN, rather than just a Go-specific forum (e.g. reddit.com/r/golang), and by implication it's intended to be read by a more general audience.
Earlier quoted context omitted.
The point is "inlining" already refers to this kind of inlining. The already-present form is more limited than the typical use of the term.
Then what word would you have used in this presentation, given no established word existed?
Earlier quoted context omitted.
The point is, as usual, Go is trying to catch up to what everyone else has had for years. The use of non-standard terminology here is suspicious, raising the question that the Go people are trying to hide the fact that they are playing catch-up.
Comments like these are so depressing. Someone does a bunch of work to improve the Go compiler and writes a presentation to share their approach (primarily so that other people working on Go can understand and extend it), and gives it all away for free. This is textbook open source citizenry, which should be applauded. But instead, you come along and criticize them for being too specific with their terms (!!) and als…
Earlier quoted context omitted.
The presentation makes a distinction between mid-stack and leaf inlining, and apparently it was only done on leaf calls before because this is less confusing in backtraces.
The point is, as usual, Go is trying to catch up to what everyone else has had for years. The use of non-standard terminology here is suspicious, raising the question that the Go people are trying to hide the fact that they are playing catch-up.
As far as programming languages go, Go is very new. Of course, there will be a number of areas that still need to be optimized or fully fleshed out. I think the Go compiler has only been written in Go for about a year. I'm sure you you find this pretty lame as well.