openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michele Sciabarra <>
Subject Re: I created a variant of the go runtime that is faster at init time
Date Wed, 12 Dec 2018 09:42:07 GMT
Indeed I was thinking to create a docker account  "openwhisk-contrib" to place those, let's
say, unofficial images.
I am not sure who should own this account, I think should be owned by the community(not me)
but with a less strict policy to accept images. 

  Michele Sciabarra

----- Original message -----
From: Felix Meschberger <>
To: "" <>
Subject: Re: I created a variant of the go runtime that is faster at init time
Date: Wed, 12 Dec 2018 09:09:58 +0000


>From the sidelines…

I understand that there is limited bandwidth to support all sorts of runtimes .. But I wonder,
whether such a thing would not have a space in some sort of an „unsupported“ contrib area

I myself like the idea of smaller binaries but wonder how you solve the dynmic linking issue
of provisioning the dependency dynamic libraries in the container ?


> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <>:
> I am perfectly fine if we do not provide a gccgo runtime, it was not a big work, and
I did it to see if it is possible to generate small executables also for go, since the swift
one is very small. 
> Aside from the fact that actionloop-gccgo-v1.10  is the faster runtime both in run and
init time (a personal satisfaction) if the init time is NOT a problem, I agree that there
are no reasons to provide also an official gccgo version.
> On Slack Markus asked to measure also the Init time but in all honesty I do not know
how important is to provide also faster init time.
> -- 
>  Michele Sciabarra
> ----- Original message -----
> From: Carlos Santana <>
> To:
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Tue, 11 Dec 2018 07:58:19 -0800
> Let’s stick with the 1.11 stock compiler, produces greater portability abs
> allows us to make updates to the base linux image with low risk for braking
> an exec built previously
> Not worth for the init, in general a busy app doesn’t suffer a lot of cold
> start and on the flip side a infrequent app can leverage stemcell a/prewarm
> I think if you want to investigate maybe opening an issue or start
> discussion with go community on how the compiler can be improve if if their
> flags that we are not using to optimized the binary
> — Carlos
> On Tue, Dec 11, 2018 at 7:46 AM David P Grove <> wrote:
>> Sorry.
>> I mean do not bother providing a gccgo variant of the go runtime.  Stick
>> with the official golang compiler at 1.11.   I don't see the small speedup
>> in init time as being enough to justify supporting two variants of go
>> actions.
>> --dave
>> Michele Sciabarra <> wrote on 12/11/2018 10:37:56 AM:
>>> From: Michele Sciabarra <>
>>> To:
>>> Date: 12/11/2018 10:38 AM
>>> Subject: Re: I created a variant of the go runtime that is faster atinit
>> time
>>> Sorry not sure what you mean. Do you suggest I apply the change to use
>>> gccgo in the official runtime, even if it is stuck at go 1.10 (the
>>> latest is go 1.11) or I drop the idea of providing another runtime that
>>> is faster to initialize? Would not be better to release both a gccgo
>>> 1.10 and a golang 1.11 instead so I leave the choice to users? The first
>>> produces smaller binaries but it is a bit slower and it is stuck to go
>>> 1.10, the second is faster but it is slower to initialize because the
>>> executable is bigger.--
>>>  Michele Sciabarra
>>> ----- Original message -----
>>> From: David P Grove <>
>>> To:
>>> Subject: Re: I created a variant of the go runtime that is faster at
>>> init timeDate: Tue, 11 Dec 2018 10:17:51 -0500
>>> Michele Sciabarra <> wrote on 12/11/2018
>>> 07:23:14 AM:>
>>>> Then I created a variant of the go runtime, using GccGo.  GccGo is a
>>>> Go compiler, updated to Go version 1.10, that compiles using the Gcc
>>>> compiler infrastructure. As a result, it produces dynamically linked
>>>> executables that are smaller than the binaries produced by the
>>>> standard Go compiler.
>>>> ...
>>>> GccGo is a bit slower than Go (but it is still the second faster
>>>> runtime) but it is now the faster at init time because the
>>>> executable is around 50k (and zipped it is only 17k).
>>>> I am unsure if replace GccGo in the official runtime or provide
>>>> both. The fact that the executable is small so it leads to faster
>>>> init time I think it is important, but the  GccGo compiler it is a
>>>> bit behind in term of language support.
>>> My advice is to stick with the official runtime.  I think that is
>>> betterfor end users.
>>> --dave
> -- 
> Carlos Santana
> <>

View raw message