Go 1.1 Function Calls

https://docs.google.com/document/d/1bMwCey-gmqZVTpRax-ESeVuZGmjwbocYs1iHplK-cjo/pub

by obilgic • 13 years ago

120 28 13 years ago

docs.google.com

staunch• 13 years ago

Russ Cox is a g'damn genius. You can spend hours being fascinated by his code and writing: http://research.swtch.com/

Not only that, he's really helpful on the Golang Google group in answering questions to all programmers, new & old. What really hooked me onto Go was both the helpfulness of the Google group as well as the nice people on #gonuts.

chimeracoder• 13 years ago

What really hooked me onto Go was both the helpfulness of the Google group as well as the nice people on #gonuts

Same here, which is why I like to idle in the channel when possible (and occasionally answer questions when I can).

People often underestimate how much impact the community behind a language has. The Go community has been one of the friendliest, and also one of the most willing to share its knowledge.

FYI, it's #go-nuts, just in case anybody reading this is inspired to check it out.

bobsh• 13 years ago

Is it just me, or is he really using the equivalent of Forth's CREATE DOES> ...?

js2• 13 years ago

OT: if Google thinks you have an account (based on a cookie I guess) it requires you to login to access this document. So you either need to login or delete the cookie or enable incognito/private mode to access the document.

Why doesn't google treat non-logged in users the same as those w/o an account?

faddotio• 13 years ago

No it doesn't. Visit it in an Incognito window if you don't believe me.

It's asking for your password because you apparently do have a Google account and it wants to verify your identity before it lets you access things that are tied to your account.

furyofantares• 13 years ago

I don't understand how that's different than what the parent was saying

jlgreco2• 13 years ago

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.)

enneff• 13 years ago

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 there. (Of course there are many ways to approach this, this is merely my hypothesis.)

safetydank2• 13 years ago

Ios disallows dynamic code generation at runtime - what other environments could Go target with these restrictions?

twotwotwo2• 13 years ago

RSC's saying that 1.1's new calling convention removed the need for dynamic code generation.

mortdeus2• 13 years ago

Native Client, Android, ummm, pretty much any environment that is encapsulated in a sandbox.

safetydank2• 13 years ago

Ah yes, Native Client. I assume Android allows it since it runs V8.

malkia• 13 years ago

I think Windows 8.0 or 8.1 Store application do not allow it.

saurik• 13 years ago

iOS actually doesn't have a restriction as strict as this: you can take a page of memory and map it again without issue. This is the technique used by imp_implementationWithBlock, and current versions of libffi can generate closures based on the technique.

http://landonf.bikemonkey.org/2011/04/index.html

twotwotwo2• 13 years ago

Not much to look at, but you can easily play with bound instance methods like the r.Read example in the doc at the playground: http://play.golang.org/p/lnfidH3usx

micro_cam• 13 years ago

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).

apgwoz• 13 years ago

Wait. This is pretty much just "closure conversion," which is a standard, and widely known technique. Did I not read carefully enough?

barrkel• 13 years ago

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.

kisielk• 13 years ago

There'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.

andrewcooke• 13 years ago

is 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?

gsg• 13 years ago

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.)

Go 1.1 Function Calls

Related Stories