FAQ

On Fri, Jan 9, 2015 at 7:17 AM, wrote:

Hello,

I’m thinking of using Go application in embedded system running in ARM.
The major point that blocks us from using it is

binaries too big and growing issue
<https://github.com/golang/go/issues/6853>

It is now marked for Go1.5. I see that it was earlier marked for go1.3 and
then 1.4 and is now moved.
It would be awesome if this issue is resolved with Go1.5 (or at least the
size is reduced significantly to an acceptable level).
That's pretty vague. The hello world binary actually got smaller in Go 1.3,
and a little bigger in Go 1.4, but Go 1.4's binaries are still smaller than
Go 1.2's binaries. In any event, I don't expect more than 2x ever.

How big are the binaries you want to run, and how big do you want them to
be? Just for comparison, godoc is 16 MB on my laptop. Most ARM systems can
run binaries that size just fine.

Russ

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Dave Cheney at Jan 9, 2015 at 11:45 pm
    Jothiram,

    I'm interested in Go on embedded ARM systems. What platforms are you targeting ?

    Dave
    On Sat, Jan 10, 2015 at 7:01 AM, Russ Cox wrote:
    On Fri, Jan 9, 2015 at 7:17 AM, wrote:

    Hello,

    I’m thinking of using Go application in embedded system running in ARM.
    The major point that blocks us from using it is

    binaries too big and growing issue

    It is now marked for Go1.5. I see that it was earlier marked for go1.3 and
    then 1.4 and is now moved.


    It would be awesome if this issue is resolved with Go1.5 (or at least the
    size is reduced significantly to an acceptable level).

    That's pretty vague. The hello world binary actually got smaller in Go 1.3,
    and a little bigger in Go 1.4, but Go 1.4's binaries are still smaller than
    Go 1.2's binaries. In any event, I don't expect more than 2x ever.

    How big are the binaries you want to run, and how big do you want them to
    be? Just for comparison, godoc is 16 MB on my laptop. Most ARM systems can
    run binaries that size just fine.

    Russ

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Jan 10, 2015 at 12:00 am
    if permanent storage is the issue (but not volatile memory), you can try
    use upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Caleb Spare at Jan 10, 2015 at 12:09 am
    Does upx work with Go binaries? (I've only heard of it on this thread:
    https://github.com/golang/go/issues/6853#issuecomment-66088639, which
    seems to indicate that it doesn't.)
    On Fri, Jan 9, 2015 at 4:00 PM, minux wrote:
    if permanent storage is the issue (but not volatile memory), you can try use
    upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Jan 10, 2015 at 12:11 am

    On Fri, Jan 9, 2015 at 7:09 PM, Caleb Spare wrote:

    Does upx work with Go binaries? (I've only heard of it on this thread:
    https://github.com/golang/go/issues/6853#issuecomment-66088639, which
    seems to indicate that it doesn't.)
    Not on linux/amd64, but works on linux/386 and linux/arm.
    And we're talking about linux/arm here.

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Kevin Gillette at Jan 10, 2015 at 2:49 am
    At least with 1.4, and the latest revision of goupx, it works with
    linux/amd64 again
    On Friday, January 9, 2015 at 5:11:51 PM UTC-7, minux wrote:


    On Fri, Jan 9, 2015 at 7:09 PM, Caleb Spare <ces...@gmail.com
    <javascript:>> wrote:
    Does upx work with Go binaries? (I've only heard of it on this thread:
    https://github.com/golang/go/issues/6853#issuecomment-66088639, which
    seems to indicate that it doesn't.)
    Not on linux/amd64, but works on linux/386 and linux/arm.
    And we're talking about linux/arm here.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jothiram Selvam at Jan 10, 2015 at 9:16 am
    @Russ: @Minux:

    We are developing a baseboard management firmware in which we have numerous
    binaries running. Our current storage is 64MB (with memory 128MB), some of
    our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic) web server using
    golang. Any binary size over a couple of MB would be difficult to justify .
    This implementation is supposed to ship by the end of this year. So I
    wanted to wait and see whether Go1.5 would help the case. I’m leaning more
    towards GO, as it is more easier to move from C development, compared to
    nodejs. Do you believe that choosing GO would be a wise and feasible
    decision.

    @Dave:

    Our baseboard management firmware directly runs on custom ARM SoCs.

    For building purposes we use Qemu -
    http://wiki.qemu.org/Main_Page
    http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

    Best Regards,
    Joe.

    On Sat, Jan 10, 2015 at 1:00 AM, minux wrote:

    if permanent storage is the issue (but not volatile memory), you can try
    use upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Jan 10, 2015 at 9:31 am

    On Sat, Jan 10, 2015 at 4:15 AM, Jothiram Selvam wrote:

    We are developing a baseboard management firmware in which we have
    numerous binaries running. Our current storage is 64MB (with memory 128MB),
    some of our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic)
    64MB of memory is probably too small for Go. Obviously this depends on how
    much
    memory you want to spare for Go applications, and how much concurrent
    traffic do you
    expect the Go application to handle.

    I believe Josh (CCed) has built some embedded ARM hardware powered by Go,
    perhaps
    he can comment more.

    web server using golang. Any binary size over a couple of MB would be
    difficult to justify . This implementation is supposed to ship by the end
    of this year. So I wanted to wait and see whether Go1.5 would help the
    case. I’m leaning more towards GO, as it is more easier to move from C
    development, compared to nodejs. Do you believe that choosing GO would be a
    wise and feasible decision.
    I build a basic http server, without any handlers, just bare
    net/http.ListenAndServe.

    The binary size for linux/arm (latest tip, with CGO_ENABLED=0), is 4848448
    bytes, after
    upx -9, it's 1514916 bytes. I don't think Go 1.5 could do any better than
    upx -9. To save
    more flash storage, you can use xz -9 to compress the binary, and
    decompress directly
    to memory (tmpfs) to execute, because most of the data is read-only, this
    won't waste
    much RAM. xz -9 can bring the storage requirement down to 1106484. Of
    course, lzma2
    decompression is memory hungry and slow, so you need to trade off between
    saved
    permanent storage and runtime/memory overhead.

    It probably doesn't matter much if you only have one Go application (you
    can build everything
    into the same binary, aka busybox style.)

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jothiram Selvam at Jan 12, 2015 at 8:59 am
    @minux: Thanks for providing with numbers. If and when we develop, I will
    update this thread with our findings. I would be interesting in hearing
    from Josh about the experience with running GO on embedded ARM hardware.

    Best Regards,
    Joe.

    On Sat, Jan 10, 2015 at 10:31 AM, minux wrote:

    On Sat, Jan 10, 2015 at 4:15 AM, Jothiram Selvam wrote:

    We are developing a baseboard management firmware in which we have
    numerous binaries running. Our current storage is 64MB (with memory 128MB),
    some of our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic)
    64MB of memory is probably too small for Go. Obviously this depends on how
    much
    memory you want to spare for Go applications, and how much concurrent
    traffic do you
    expect the Go application to handle.

    I believe Josh (CCed) has built some embedded ARM hardware powered by Go,
    perhaps
    he can comment more.

    web server using golang. Any binary size over a couple of MB would be
    difficult to justify . This implementation is supposed to ship by the end
    of this year. So I wanted to wait and see whether Go1.5 would help the
    case. I’m leaning more towards GO, as it is more easier to move from C
    development, compared to nodejs. Do you believe that choosing GO would be a
    wise and feasible decision.
    I build a basic http server, without any handlers, just bare
    net/http.ListenAndServe.

    The binary size for linux/arm (latest tip, with CGO_ENABLED=0), is 4848448
    bytes, after
    upx -9, it's 1514916 bytes. I don't think Go 1.5 could do any better than
    upx -9. To save
    more flash storage, you can use xz -9 to compress the binary, and
    decompress directly
    to memory (tmpfs) to execute, because most of the data is read-only, this
    won't waste
    much RAM. xz -9 can bring the storage requirement down to 1106484. Of
    course, lzma2
    decompression is memory hungry and slow, so you need to trade off between
    saved
    permanent storage and runtime/memory overhead.

    It probably doesn't matter much if you only have one Go application (you
    can build everything
    into the same binary, aka busybox style.)
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Josh Bleecher Snyder at Feb 3, 2015 at 10:00 pm

    @minux: Thanks for providing with numbers. If and when we develop, I will
    update this thread with our findings. I would be interesting in hearing from
    Josh about the experience with running GO on embedded ARM hardware.
    You can get some extra binary size savings with -ldflags="-w -s". Note
    though that these are not officially supported and make debugging
    harder.

    I'm happy to answer any specific questions about my Go ARM
    experiences, although please cc golang-nuts instead of golang-dev for
    such questions. Also useful might be my GopherCon talk last year,
    which touches on the topic:
    http://www.confreaks.com/videos/3423-gophercon2014-embedded-go-and-bluetooth-low-energy-hardware.
    The truth is that my experience was fairly uneventful, in a good way.
    I wrote code, paid moderate attention to allocation, profiled as
    necessary, and it pretty much just worked. We spent marginally more on
    the BOM to use Go over (say) C, but probably made it back in system
    stability and software development costs.

    -josh

    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrewchamberss at Jan 11, 2015 at 10:51 pm
    You could try link all programs into the same executable, then using
    symlinks to differentiate them and manually call the correct main. That way
    you only pay for each library once. I think the OS will share pages across
    program instances saving ram.

    Though generally I have found the gc compilers do have a large overhead in
    terms of binary size vs LoC compared to something like C, which I assume is
    from the extra debug and runtime symbols needed.
    On Saturday, January 10, 2015 at 10:16:35 PM UTC+13, Jothiram Selvam wrote:

    @Russ: @Minux:

    We are developing a baseboard management firmware in which we have
    numerous binaries running. Our current storage is 64MB (with memory 128MB),
    some of our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic) web server using
    golang. Any binary size over a couple of MB would be difficult to justify .
    This implementation is supposed to ship by the end of this year. So I
    wanted to wait and see whether Go1.5 would help the case. I’m leaning more
    towards GO, as it is more easier to move from C development, compared to
    nodejs. Do you believe that choosing GO would be a wise and feasible
    decision.

    @Dave:

    Our baseboard management firmware directly runs on custom ARM SoCs.

    For building purposes we use Qemu -
    http://wiki.qemu.org/Main_Page
    http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

    Best Regards,
    Joe.


    On Sat, Jan 10, 2015 at 1:00 AM, minux <mi...@golang.org <javascript:>>
    wrote:
    if permanent storage is the issue (but not volatile memory), you can try
    use upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrewchamberss at Jan 11, 2015 at 10:52 pm
    *I mean large overhead per line of code after the size of an empty program
    is subtracted.

    On Monday, January 12, 2015 at 11:51:13 AM UTC+13, andrewc...@gmail.com
    wrote:
    You could try link all programs into the same executable, then using
    symlinks to differentiate them and manually call the correct main. That way
    you only pay for each library once. I think the OS will share pages across
    program instances saving ram.

    Though generally I have found the gc compilers do have a large overhead in
    terms of binary size vs LoC compared to something like C, which I assume is
    from the extra debug and runtime symbols needed.
    On Saturday, January 10, 2015 at 10:16:35 PM UTC+13, Jothiram Selvam wrote:

    @Russ: @Minux:

    We are developing a baseboard management firmware in which we have
    numerous binaries running. Our current storage is 64MB (with memory 128MB),
    some of our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic) web server using
    golang. Any binary size over a couple of MB would be difficult to justify .
    This implementation is supposed to ship by the end of this year. So I
    wanted to wait and see whether Go1.5 would help the case. I’m leaning more
    towards GO, as it is more easier to move from C development, compared to
    nodejs. Do you believe that choosing GO would be a wise and feasible
    decision.

    @Dave:

    Our baseboard management firmware directly runs on custom ARM SoCs.

    For building purposes we use Qemu -
    http://wiki.qemu.org/Main_Page
    http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

    Best Regards,
    Joe.

    On Sat, Jan 10, 2015 at 1:00 AM, minux wrote:

    if permanent storage is the issue (but not volatile memory), you can try
    use upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jothiram Selvam at Jan 12, 2015 at 8:57 am
    @Andrew: Currently we have already a running stack with so many binaries
    developed under C. It wouldn’t be feasible for us to move everything or at
    least some of them directly to GO (given the validation effort and our
    existing customers). My plan is to start with web server only.

    I will keep your suggestion in mind to link multiple programs into the same
    executable in the future. However, if the GO community can keep the binary
    size in mind when developing the new compiler/linker, it would help in a
    longer run to get GO running on embedded systems (as you would realise, in
    our discussions we always speak about sizes and memory consumption because
    of the cost involved when selling a million servers, where a fraction of $1
    will cost us $1 million)

    Best Regards,
    Joe.

    On Sun, Jan 11, 2015 at 11:51 PM, wrote:

    You could try link all programs into the same executable, then using
    symlinks to differentiate them and manually call the correct main. That way
    you only pay for each library once. I think the OS will share pages across
    program instances saving ram.

    Though generally I have found the gc compilers do have a large overhead in
    terms of binary size vs LoC compared to something like C, which I assume is
    from the extra debug and runtime symbols needed.
    On Saturday, January 10, 2015 at 10:16:35 PM UTC+13, Jothiram Selvam wrote:

    @Russ: @Minux:

    We are developing a baseboard management firmware in which we have
    numerous binaries running. Our current storage is 64MB (with memory 128MB),
    some of our customers also use only 32MB of storage (with memory 64MB). I’m
    investigating on an option to develop and run (basic) web server using
    golang. Any binary size over a couple of MB would be difficult to justify .
    This implementation is supposed to ship by the end of this year. So I
    wanted to wait and see whether Go1.5 would help the case. I’m leaning more
    towards GO, as it is more easier to move from C development, compared to
    nodejs. Do you believe that choosing GO would be a wise and feasible
    decision.

    @Dave:

    Our baseboard management firmware directly runs on custom ARM SoCs.

    For building purposes we use Qemu -
    http://wiki.qemu.org/Main_Page
    http://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

    Best Regards,
    Joe.

    On Sat, Jan 10, 2015 at 1:00 AM, minux wrote:

    if permanent storage is the issue (but not volatile memory), you can try
    use upx to pack
    the Go binary. The packed binary generally go down to about 30% of the
    original size,
    and the runtime unpacking overhead is quite tolerable too.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedJan 9, '15 at 8:01p
activeFeb 3, '15 at 10:00p
posts13
users8
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase