[go-nuts] Re: Go 1.9 Beta 2 is released
It is certainly a micro-benchmark. I just wanted to ask in case it was
expected since I use golang on ARM based embedded systems a lot and they
tend to be sensitive to binary size. In the tests, my binary is stripped
(-ldflags="-w -s"), so I wouldn't think the size difference is related to
the changes that were made to add additional DWARF info, etc. When I
checked the cross compiled Linux ARM 7 sizes for the hello world program,
they are also up in go1.9 beta.
go version go1.8.3 darwin/amd64
$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"
dozer2:test Parker$ ls -l
total 1824
-rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
-rwxr-xr-x 1 Parker staff 928608 Jun 30 06:37 test
go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"
$ ls -l
total 2176
-rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
-rwxr-xr-x 1 Parker staff 1107256 Jun 30 06:36 test
Checking the hello world HTTP server program:
package main
import (
"net/http"
)
func main() {
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello world!"))
})
panic(http.ListenAndServe(":8080", nil))
}
The size is also up a bit from go1.8 -> go1.9 on both darwin amd64 and
linux_arm (7), though a smaller percentage than the basic hello world.
go version go1.8.3 darwin/amd64
$ go build -ldflags="-w -s"
$ ls -l
total 8344
-rw-r--r-- 1 Parker staff 204 Jun 30 06:44 main.go
-rwxr-xr-x 1 Parker staff 4264852 Jun 30 06:47 test
$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"
$ ls -l
total 6344
-rw-r--r-- 1 Parker staff 204 Jun 30 06:44 main.go
-rwxr-xr-x 1 Parker staff 3242224 Jun 30 06:48 test
go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
$ go build -ldflags="-w -s"
$ ls -l
total 8880
-rw-r--r-- 1 Parker staff 204 Jun 30 06:44 main.go
-rwxr-xr-x 1 Parker staff 4538852 Jun 30 06:45 test
$ GOOS=linux GOARCH=arm GOARM=7 go build -ldflags="-w -s"
$ ls -l
total 6664
-rw-r--r-- 1 Parker staff 204 Jun 30 06:44 main.go
-rwxr-xr-x 1 Parker staff 3405040 Jun 30 06:46 test
I can check it out for bigger/more realistic programs as well.
~Parker
On Thursday, June 29, 2017 at 8:21:18 AM UTC-4, Alberto Donizetti wrote:
>
> But if you have other numbers please share them, it'll certainly interesing
> to see them.
>
> Il giorno giovedì 29 giugno 2017 13:38:18 UTC+2, Parker Evans ha scritto:
>>
>> Congratulations on the Beta 2 release, pretty excited to test it out.
>> Lots of interesting updates!
>>
>> I did notice one thing when I was playing around with Beta 1 and now Beta
>> 2 that I wanted to ask about. Is it expected that binary size would
>> increase in this release? A toy example that has been somewhat of a
>> benchmark in previous releases is the simple hello world program:
>>
>> package main
>>
>> import (
>>
>> "fmt"
>>
>> )
>>
>>
>> func main() {
>>
>>fmt.Println("Hello world!")
>>
>> }
>>
>> It seems like this program, when compiled with options to strip debugging
>> information has grown about 20% in size when compiled natively for macOS:
>>
>> go version go1.8.3 darwin/amd64
>>
>> $ go build -ldflags="-w -s"
>>
>> $ ls -l
>>
>> total 2320
>>
>> -rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
>>
>> -rwxr-xr-x 1 Parker staff 1181728 Jun 29 07:24 test
>>
>> go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
>>
>> $ go build -ldflags="-w -s"
>>
>> $ ls -l
>>
>> total 2792
>>
>> -rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
>>
>> -rwxr-xr-x 1 Parker staff 1424992 Jun 29 07:11 test
>>
>> Anyone have any insight on whether this is expected and if a similar
>> increase should be expected across the board in this release?
>>
>> Thanks,
>> Parker
>>
>> On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>>>
>>> Hello gophers,
>>>
>>> We have just released go1.9beta2, a beta version of Go 1.9.
>>> It is cut from the master branch at the revision tagged go1.9beta2.
>>>
>>> There are no known problems or regressions.
>>> Please try running production load tests and your unit tests with the
>>> new version.
>>> Your help testing these pre-release versions is invaluable.
>>>
>
[go-nuts] Re: Go 1.9 Beta 2 is released
Congratulations on the Beta 2 release, pretty excited to test it out. Lots
of interesting updates!
I did notice one thing when I was playing around with Beta 1 and now Beta 2
that I wanted to ask about. Is it expected that binary size would increase
in this release? A toy example that has been somewhat of a benchmark in
previous releases is the simple hello world program:
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello world!")
}
It seems like this program, when compiled with options to strip debugging
information has grown about 20% in size when compiled natively for macOS:
go version go1.8.3 darwin/amd64
$ go build -ldflags="-w -s"
$ ls -l
total 2320
-rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
-rwxr-xr-x 1 Parker staff 1181728 Jun 29 07:24 test
go version devel +eab99a8 Mon Jun 26 21:12:22 2017 + darwin/amd64
$ go build -ldflags="-w -s"
$ ls -l
total 2792
-rw-r--r-- 1 Parker staff 79 Jun 16 18:47 main.go
-rwxr-xr-x 1 Parker staff 1424992 Jun 29 07:11 test
Anyone have any insight on whether this is expected and if a similar
increase should be expected across the board in this release?
Thanks,
Parker
On Monday, June 26, 2017 at 6:11:46 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9beta2, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta2.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new
> version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta2
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta2
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta2
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 is available at:
> https://tip.golang.org/
>
> Cheers,
> Chris
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Dynamic linking against individual golang standard libraries
Alright, so I played around with this a bit. It would appear that I can actually get pretty far by just compiling the full standard library as shared and then compiling the individual packages one at a time in the proper order. What I am doing is captured in the program in this repository: https://github.com/ermergerd/go-dynlib However, I hit a couple snags before I got all of the packages compiling (thus some are commented out in the application). Specifically, I see the following linker panics when compiling log/syslog and crypto/ecdsa: 2016/12/02 22:05:56 Building package: log/syslog 2016/12/02 22:05:56 # /var/folders/5y/90kqcw0j72bgyj0kgxl1rnc4gn/T/go-build689781855/liblog-syslog.so panic: runtime error: index out of range goroutine 1 [running]: panic(0x19fa60, 0xc42000e130) /Users/Parker/go1.7/src/runtime/panic.go:500 +0x1a1 cmd/link/internal/ld.(*deadcodepass).flood(0xc42003bcd0) /Users/Parker/go1.7/src/cmd/link/internal/ld/deadcode.go:279 +0xe88 cmd/link/internal/ld.deadcode(0xc42048a000) /Users/Parker/go1.7/src/cmd/link/internal/ld/deadcode.go:60 +0xe1 cmd/link/internal/ld.Ldmain() /Users/Parker/go1.7/src/cmd/link/internal/ld/pobj.go:192 +0x1089 cmd/link/internal/arm.Main() /Users/Parker/go1.7/src/cmd/link/internal/arm/obj.go:45 +0x19 main.main() /Users/Parker/go1.7/src/cmd/link/main.go:30 +0x168 2016/12/02 22:06:05 Building package: crypto/ecdsa 2016/12/02 22:06:05 # /var/folders/5y/90kqcw0j72bgyj0kgxl1rnc4gn/T/go-build010152613/libcrypto-ecdsa.so panic: runtime error: index out of range goroutine 1 [running]: panic(0x19fa60, 0xc42000e130) /Users/Parker/go1.7/src/runtime/panic.go:500 +0x1a1 cmd/link/internal/ld.(*deadcodepass).flood(0xc4204afcd0) /Users/Parker/go1.7/src/cmd/link/internal/ld/deadcode.go:279 +0xe88 cmd/link/internal/ld.deadcode(0xc42049e000) /Users/Parker/go1.7/src/cmd/link/internal/ld/deadcode.go:60 +0xe1 cmd/link/internal/ld.Ldmain() /Users/Parker/go1.7/src/cmd/link/internal/ld/pobj.go:192 +0x1089 cmd/link/internal/arm.Main() /Users/Parker/go1.7/src/cmd/link/internal/arm/obj.go:45 +0x19 main.main() /Users/Parker/go1.7/src/cmd/link/main.go:30 +0x168 For reference, I am cross compiling the libraries to run on an ARM/Linux platform with the following command line: CC=arm-linux-gnueabihf-gcc GOOS=linux GOARCH=arm GOARM=7 CGO_ENABLED=1 ./go-dynlibs -ldflags="-w -s -extld=arm-linux-gnueabihf-gcc" Any thoughts on this method of doing things or the linker panics that I see for a couple of the packages? I was a little confused why I needed to compile the full libstd.so before I could make any progress with building the individual packages as buildmode shared/linkshared. Thanks, Parker On Tuesday, November 22, 2016 at 9:50:21 PM UTC-5, Parker Evans wrote: > > Alright, I will take a look. Thanks for the response. > > ~Parker > > On Monday, November 21, 2016 at 7:00:01 PM UTC-5, Ian Lance Taylor wrote: >> >> On Sun, Nov 20, 2016 at 1:22 PM, Parker Evans <pa...@cornell.edu> wrote: >> > >> > In order to do this kind of thing, do I need to manually figure out >> > dependencies and then setup appropriate linker flags? >> >> Yes, pretty much. >> >> It may help a bit to look at go/build/deps_test.go. >> >> Ian >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Dynamic linking against individual golang standard libraries
Alright, I will take a look. Thanks for the response. ~Parker On Monday, November 21, 2016 at 7:00:01 PM UTC-5, Ian Lance Taylor wrote: > > On Sun, Nov 20, 2016 at 1:22 PM, Parker Evans <pa...@cornell.edu > > wrote: > > > > In order to do this kind of thing, do I need to manually figure out > > dependencies and then setup appropriate linker flags? > > Yes, pretty much. > > It may help a bit to look at go/build/deps_test.go. > > Ian > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Dynamic linking against individual golang standard libraries
Hi, Question about using dynamic libraries on Linux. So I know that creating a shared .so for the golang standard library can be done via the following (or some appropriate cross compiling variant): go install -buildmode=shared -linkshared std When stripped of debugging information, this process results in a .so binary somewhere between 17MB and 26MB depending on version of golang and target architecture (amd64 vs. ARM for instance). Not too bad for the ENTIRE golang standard library but still pretty big for a shared library especially on an embedded system. One of the negatives for having such a large shared library on embedded Linux systems in addition to just the disk space is that you pay the penalty of the full shared library size in memory if at least one running application is using it (even if the application is only using a very small subset of the standard library packages). So I have been investigating ways to generate and use shared libraries for each of the standard library packages (or appropriate subsets). Is there a supported/easy way to do this? Does anyone have any suggestions? Going into the sync package for instance and building it using the shared build mode and -linkshared typically hangs in (cross-) compilation, whereas removing -linkshared will result in a shared library .so binary that is about 1.5MB in size. To use it, I would probably need to specify appropriate linker flags to link against it (as -linkshared seems like it might be expecting libstd.so). I am guessing that the build statically links in any go standard library dependencies that it uses (since I didn't specify -linkshared). In order to do this kind of thing, do I need to manually figure out dependencies and then setup appropriate linker flags? I realize this isn't too common a use case, but it could be very useful for controlling disk and memory usage in embedded systems using go. Any help would be greatly appreciated. Thanks, Parker -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Any reason make.bash does not allow you to pass asmflags?
I was recently playing around with the assembler and compiler -trimpath option to remove build machine prefixes from the built from source toolchain and I realized that make.bash allows you to pass gcflags via the GO_GCFLAGS environment variable but there is no equivalent GO_ASMFLAGS environment variable that allows you to pass -asmflags. As properly trimming all the paths involves passing the -trimpath option via -asmflags and -gcflags, this seems to be required. Is there another way to do this? Or would this be a good patch for future Go releases? Thanks, Parker -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
