Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go and Assembly

doxsey.net

Post reply on HN
Print view View original

51–60 of 127 posts

Re: Go and Assembly

#51

Post by cdoxsey »

papsosouid wrote: post #46
car54whereareu wrote: post #41

Earlier quoted context omitted.

Actually if you import "net" go links to libc.so and some others.

Ah, if the original bulletpoints for go are wrong then ghc may be more comparable than I figured. Can you statically link go binaries? As in, if I am using a go postgresql binding, can I build a binary with libpq (the postgresql C library) linked in statically, so it can be deployed on servers with no postgresql libraries installed?

From what I understand cgo doesn't currently support static linking like this.

Re: Go and Assembly

#52

Post by georgemcbay »

dualogy wrote: post #38
Xeoncross wrote: post #4

That is pretty neat. I'm glad he mentioned that the Go compiler will not inline functions written in assembly, but it will inline small Go functions.

Yeah but the list of restrictions preventing inlining is pretty exhaustive...

This is true currently but both the inlining and the garbage collector have improved tremendously over the past year and should continue to get better.

I do wish Go supported an explicit inline modifier that worked like haxe's though (unlike the C/C++ one which is more of a suggestion).

Re: Go and Assembly

#53

Post by damien »

So what does that middle dot actually do before the function names? It doesn't seem to be mentioned in the linked documentation of the Plan 9 assembler, and if I have to use a character that I can't easily type with my keyboard, I'd like to at least know what it actually does. :)

Also, doesn't doing this limit your code to using gc toolchain (since the generic Go function has to get called from the arch-specific asm code which uses that Plan 9 dialect)? Does this mean that the Go standard library can't be compiled with gccgo for example?

Re: Go and Assembly

#54

Post by stephencanon »

dualogy wrote: post #12
cdoxsey wrote: post #8

Earlier quoted context omitted.

In this case there is a 386 implementation: http://golang.org/src/pkg/math/remainder_386.s The other two call the go version: http://golang.org/src/pkg/math/remainder.go

Yeah that was kinda my point ;)) so basically 386 users get some highly specialized hand-tuned asm optimization whereas arm and amd64 merely get a commoner's gc treatment -- or am I missing something? ;)

Several things:

- The fprem1 instruction is actually a long microcode sequence and is quite slow; 26-50 cycles on SNB according to Agner Fog. Several iterations of that loop are necessary for a complete reduction of some operands.

- There is no analogous instruction on arm (or really, any platform that isn't x86), anyway.

- If you're using the floating-point remainder operation in a performance-sensitive context, You're Doing It Wrong. Programmers have gotten so used to this that there is little value in optimizing remainder; it is rarely used in situations where the optimization would matter.

Re: Go and Assembly

#55

Post by pcwalton »

georgemcbay wrote: post #52
dualogy wrote: post #38

Earlier quoted context omitted.

Yeah but the list of restrictions preventing inlining is pretty exhaustive...

This is true currently but both the inlining and the garbage collector have improved tremendously over the past year and should continue to get better. I do wish Go supported an explicit inline modifier that worked like haxe's though (unlike the C/C++ one which is more of a suggestion).

Most C dialects (for example, GCC and Clang) provide some form of explicit inline qualifier that forces inlining, for example "attribute((always_inline))".

Re: Go and Assembly

#56

Post by geoka9 »

charlieflowers wrote: post #44

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too). I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful. I don't know i…

I think the only thing missing is a REPL as part of the tool chain. ipython and scala shell are so useful, especially when you're learning or just testing things out.

Re: Go and Assembly

#57

Post by jholman »

TylerE wrote: post #18
dlisboa wrote: post #15

Earlier quoted context omitted.

Java, Python, Ruby, Lua, Haskell. All names which the programming language is one of the last things a search engine would normally associate, but by sheer number of hits you end up finding stuff. When they were invented these names weren't good either. The discussion about Go's name is indeed useless.

There's a crucial difference. Those are longer words. Many search engines either ignore, or outright throw an error on, search terms shorter than 3/4 characters.

"Many search engines"?

How many search engines do you use? And which of them ignore or error on 2-letter words?

I just tried this on the only four search engines I can even think of that seemed like they MIGHT matter: google, bing, ddg, and stackoverflow's site-specific. All four obviously respected the two-letter word "go" (although for my searches only Google and SO returned results I found useful).

Re: Go and Assembly

#58

Post by jholman »

songgao wrote: post #24
freehunter wrote: post #2

And herein lies the problem with Go. Seriously, try searching for articles about Go on HN. People always say "well the name isn't a problem, because you just search for it with "golang" instead!" but no one writes golang unless they're pointing out how to search for it . If I was trying to get back to this article a month from now and I searched for "go", would I find it? Probably not, unless I remembered the article…

According to golang FAQ, the origin of the name is that, “Ogle” would be a good name for a Go debugger. [1] I just came up the idea: why didn't they name the language "Goo", and leave "Gle" to the debugger? It would be more common for people to refer to the language itself than to its debugger. [1] http://golang.org/doc/faq#What_is_the_origin_of_the_name

I think you should consider the possibility that the FAQ is joking.

Also, if you're suggesting "gle" as a debugger name, you're missing the joke. "ogle" is a verb meaning, approximately, "to look at", so it's a good name for a debugger. "gle" is not.

(Except that "ogle" is not actually a good name for a corporate-sponsored debugger, because "ogle" has sexual connotations. Which is why you should assume that this is a joke.)

Re: Go and Assembly

#59

Post by charlieflowers »

jlgreco wrote: post #49
felixge wrote: post #47

Earlier quoted context omitted.

Go supports panic/recover which is very similar to exceptions. Instead of wrapping a try...catch block around something, you get to handle exceptions every time they are about to cause a function to be exited. This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value. tl;dr: Go has exceptions, they are just a little different (IMO…

I think the real value of panic/recover over try/catch is the vastly improved idiomatic usage. Only to be used in exceptional cases, and never to cross package boundaries. I just find that so much more pleasant.

Hmmm, interesting. The "defer" approach is a different spin on things. But yes, panic/recover does look like it would address my concerns. I never did like exceptions across package boundaries much, but inside a cohesive module I want to use them instead of a bunch of code that checks return values for error codes.

Re: Go and Assembly

#60

Post by tptacek »

felixge wrote: post #47
charlieflowers wrote: post #44

Now this is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too). I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful. I don't know i…

Go supports panic/recover which is very similar to exceptions. Instead of wrapping a try...catch block around something, you get to handle exceptions every time they are about to cause a function to be exited. This means you can't continue to execute the function, but you do get a chance of handling the exception / turning it into a regular return value. tl;dr: Go has exceptions, they are just a little different (IMO…

Panic and recover are non-idiomatic; using them the way you would exceptions in Python is (stylewise, I mean) a little like using setjmp and longjmp for flow control in a C progam.

In the Go standard library source code, "panic" has pretty much the role 'assert(!"error message")' has in C.

The reality is that Go does not have exceptions the way Python does. If you're writing idiomatic Go, you're manually checking errors.

Post reply on HN