I got something like a 30% speed up switching go 1.0 to go 1.1 with some code that used a closure.
It is number crunching code (random forests) but go 1.1 is faster then gccgo as well (though i haven't tried the latest version of that).
Go 1.1 Function Calls
21–30 of 34 posts
Re: Go 1.1 Function Calls
#22Wait. This is pretty much just "closure conversion," which is a standard, and widely known technique. Did I not read carefully enough?
Re: Go 1.1 Function Calls
#23There's a list of various Go design documents maintained on the Go wiki:
https://code.google.com/p/go-wiki/wiki/DesignDocuments
There are a lot of interesting reads in there.
Re: Go 1.1 Function Calls
#24Wait. This is pretty much just "closure conversion," which is a standard, and widely known technique. Did I not read carefully enough?
[deleted]
Re: Go 1.1 Function Calls
#25Re: Go 1.1 Function Calls
#26Re: Go 1.1 Function Calls
#27Wait. This is pretty much just "closure conversion," which is a standard, and widely known technique. Did I not read carefully enough?
In the abstract, sure; but what it was doing before was also "closure conversion". The interesting bit is in the specific implementation details.
Closures need the combination of code and data. There are multiple implementation strategies to pair the two together though. Delphi, for example, has implemented method pointers for a very long time as a pair of pointers, one code and one data.
When I added anonymous method support, that wouldn't fly because it doesn't handle account memory management (Delphi is not garbage collected). So I implemented a different form, using COM-style interfaces, where the code pointer is the first method after QI, Addref and Release. Since Delphi had auto-refcounting support for COM pointers, this solved the dynamic closure allocation problem; and since it was language independent, it solved the C++ interop problem.
Re: Go 1.1 Function Calls
#28is 10 possible combinations of function and call a good thing? it seems odd to me. are other languages like that? having such a large number(?) seems to imply that the language has lots of special cases. which is worrying, isn't it? wouldn't it be better (all other things being equal) to have a smaller number of ways that function calls work?
Re: Go 1.1 Function Calls
#29Earlier quoted context omitted.
> Why doesn't google treat non-logged in users the same as those w/o an account? I wager what they actually want to do is treat those without an account the same as those who are not logged in, but realize they can't get away with that quite yet. (That is to say, I suspect that they would like to turn away all users without accounts.)
That's a baseless assertion. I'd assume (and I have no insider knowledge) that it's because Google assumes if you have a Google account that you probably want to be logged into it when using Google products. Otherwise it would suck if you tried to do something that requires an account and were told "log in" and then had to refresh the page, potentially losing state. The up-front login avoids some usability issues the…
With some insider knowledge: Because this document is commentable for (some) Googlers, though you don't see the comments on the /pub version that is accessible externally. Docs would rather force you to verify your state (Logged in or anonymous) than having some things 'not work' because you're expecting permissions from login cookies you don't have.
Re: Go 1.1 Function Calls
#30is 10 possible combinations of function and call a good thing? it seems odd to me. are other languages like that? having such a large number(?) seems to imply that the language has lots of special cases. which is worrying, isn't it? wouldn't it be better (all other things being equal) to have a smaller number of ways that function calls work?
It's fine since all the detailed goop is at the implementation level. Programmers need not care.
Making a distinction between known and unknown calls in the implementation is not only a good thing, but in a language with first-class functions it is all but inevitable because the performance win is so large. (The majority of calls are known, and known calls can be compiled significantly more efficiently than any general purpose call machinery.)