You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Michele Sciabarra <mi...@sciabarra.com> on 2018/12/11 12:23:14 UTC
I created a variant of the go runtime that is faster at init time
Hello all,
I was concerned about the fact that the Go runtime is a bit slow at init time. As I suspected, the problem is in the size of the executable, that is almost 2Mb. This is structural for Go since it compiles statically.
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.
You can see the results in the updated benchmark. The new runtime is actionloop-gccgo-v8
https://sciabarracom.github.io/incubator-openwhisk-runtime-actionloop/
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.
--
Michele Sciabarra
michele@sciabarra.com
Re: I created a variant of the go runtime that is faster at init time
Posted by Felix Meschberger <fm...@adobe.com.INVALID>.
Hi Michele
„Dynamic libraries included in the container" was the answer I was looking for. Thanks
Regards
Felix
> Am 12.12.2018 um 10:49 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> To answer to the second part of your question:
>
> if you compile a Go program with the native go compiler, the final executable links statically everything including the garbage collector and other stuff. If you use gccgo, those things are dynamic libraries and are not included in the executable.
>
> I created the gccgo image using ubuntu (bionic) and installing the gccgo package, hence all the required dynamic libraries are included in the docker image.
>
> Furthermore, the executable is created by the image itself (using the precompilation feature of the "actionloop" image) so the executable is created BY the image FOR the image and the dynamic libraries match.
>
> The same happens for the switf image, to create say an executable for swift 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and it will produce an action that can be run in the same image.
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Felix Meschberger <fm...@adobe.com.INVALID>
> To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
> 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
>
> Hi
>
> 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 ?
>
> Regards
> Felix
>
>> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>>
>> 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
>> michele@sciabarra.com
>>
>> ----- Original message -----
>> From: Carlos Santana <cs...@gmail.com>
>> To: dev@openwhisk.apache.org
>> 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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>>>
>>>> From: Michele Sciabarra <mi...@sciabarra.com>
>>>> To: dev@openwhisk.apache.org
>>>> 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
>>>> michele@sciabarra.com
>>>>
>>>>
>>>>
>>>> ----- Original message -----
>>>> From: David P Grove <gr...@us.ibm.com>
>>>> To: dev@openwhisk.apache.org
>>>> 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 <mi...@sciabarra.com> 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
>> <cs...@gmail.com>
>
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
To answer to the second part of your question:
if you compile a Go program with the native go compiler, the final executable links statically everything including the garbage collector and other stuff. If you use gccgo, those things are dynamic libraries and are not included in the executable.
I created the gccgo image using ubuntu (bionic) and installing the gccgo package, hence all the required dynamic libraries are included in the docker image.
Furthermore, the executable is created by the image itself (using the precompilation feature of the "actionloop" image) so the executable is created BY the image FOR the image and the dynamic libraries match.
The same happens for the switf image, to create say an executable for swift 4.2.1 you have to use the image for swift 4.2.1 with the -compile flag, and it will produce an action that can be run in the same image.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Felix Meschberger <fm...@adobe.com.INVALID>
To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
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
Hi
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 ?
Regards
Felix
> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> 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
> michele@sciabarra.com
>
> ----- Original message -----
> From: Carlos Santana <cs...@gmail.com>
> To: dev@openwhisk.apache.org
> 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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>>
>>> From: Michele Sciabarra <mi...@sciabarra.com>
>>> To: dev@openwhisk.apache.org
>>> 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
>>> michele@sciabarra.com
>>>
>>>
>>>
>>> ----- Original message -----
>>> From: David P Grove <gr...@us.ibm.com>
>>> To: dev@openwhisk.apache.org
>>> 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 <mi...@sciabarra.com> 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
> <cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 12, 2018 at 10:10 AM Felix Meschberger
<fm...@adobe.com.invalid> wrote:
> ...I wonder, whether such a thing would not have a space in some sort of an „unsupported“
> contrib area ?...
Big +1, with my incubation mentor hat on - having modules which are
not guaranteed to be supported, nor part of the core product, is great
in terms of community as long as they are clearly marked as such.
It can help bring more active committers, expand the project scope
etc. while keeping the core nice and tight.
-Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Carlos Santana <cs...@gmail.com>.
The go repo could hold the code to produce the 3 runtime images
For example:
action-loop-v1.0.1:tag
action-go-v1.11:tag
action-gccgo-v1.10:tag
- Carlos Santana
@csantanapr
> On Dec 12, 2018, at 9:25 AM, Rodric Rabbah <ro...@gmail.com> wrote:
>
> +1 “I think it would be better to organize around 1 git repo per language.”
>
> -r
>
>> On Dec 12, 2018, at 9:21 AM, David P Grove <gr...@us.ibm.com> wrote:
>>
>> For the runtimes specifically, if it is technically feasible I think it would be better to organize around 1 git repo per language.
>>
>> That repo could contain multiple runtime variants with different degrees of maturity. Several of the runtime repos already contain multiple variants (nodejs, php, python). Can that pattern work for go too?
>>
>> --dave
>>
>> Carlos Santana ---12/12/2018 07:26:56 AM---My 2 cents about the "contrib" repo for best effort support and experimental code we already have a
>>
>> From: Carlos Santana <cs...@gmail.com>
>> To: dev@openwhisk.apache.org
>> Date: 12/12/2018 07:26 AM
>> Subject: Re: I created a variant of the go runtime that is faster at init time
>>
>>
>>
>>
>> My 2 cents about the "contrib" repo for best effort support and
>> experimental code we already have a repo
>>
>> It used be named incubator-openwhisk-experimental, but then we rename it to
>> incubator-openwhisk-devtools [1]
>>
>> If any one has some cool experiments we have created a new folder in the
>> repo and add some trivial travis test
>>
>> [1] https://github.com/apache/incubator-openwhisk-devtools
>> -cs
>>
>> On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra <mi...@sciabarra.com>
>> wrote:
>>
>>> Hmm, I understand the concern but I wonder HOW the "convenience" binaries
>>> should be handled in practice.
>>>
>>> In OpenWhisk what it matters is the runtime you specify with --docker, so
>>> that "convenience" is not really just a convenience, it is a core
>>> requirement.
>>>
>>> We could setup an openwhisk contrib repository, but I cannot image a
>>> single Travis build to be able to rebuild many images (at the moment I have
>>> at least 4) and push all of them to docker hub...
>>>
>>>
>>> --
>>> Michele Sciabarra
>>> michele@sciabarra.com
>>>
>>> ----- Original message -----
>>> From: Felix Meschberger <fm...@adobe.com.INVALID>
>>> To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
>>> Subject: Re: I created a variant of the go runtime that is faster at init
>>> time
>>> Date: Wed, 12 Dec 2018 10:00:07 +0000
>>>
>>> Hi Michele
>>>
>>> This is shaky ground and we don’t want to be the next npm horror story.
>>>
>>> Technically speaking, at Apache we primarily release source packages, all
>>> binary is pure convenience. Granted the convience today is what most people
>>> use.
>>>
>>> So what we should primarily do, as Bertrand hinted, is have a contrib
>>> repository. We can still have a contrib docker account into which the
>>> OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must
>>> be clearly stated that those are not releases, have no release quality and
>>> all the usual disclaimers.
>>>
>>> Regards
>>> Felix
>>>
>>>> Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <michele@sciabarra.com
>>>> :
>>>>
>>>> Actually more than an account on GitHub it is important to have a docker
>>> hub account named "openwhisk-contrib" so you can deploy an action with
>>> something like:
>>>>
>>>> wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
>>>>
>>>> To publish images, you can do sothing as simple as ask, maybe opening a
>>> ticket, to push an image msciab/actionloop-gccgo-v1.10
>>>> to openwhisk-contrib/actionloop-gccgo-v1.10.
>>>>
>>>>
>>>>
>>>> --
>>>> Michele Sciabarra
>>>> michele@sciabarra.com
>>>>
>>>> ----- Original message -----
>>>> From: Bertrand Delacretaz <bd...@apache.org>
>>>> To: dev@openwhisk.apache.org
>>>> Subject: Re: I created a variant of the go runtime that is faster at
>>> init time
>>>> Date: Wed, 12 Dec 2018 10:45:43 +0100
>>>>
>>>> Hi,
>>>>
>>>> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
>>>> <mi...@sciabarra.com> wrote:
>>>>>
>>>>> 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...
>>>>
>>>> Accounts with "openwhisk" in their name should be owned by the
>>>> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
>>>> Foundation - technically being donated as we speak IIUC but that
>>>> doesn't make a real difference.
>>>>
>>>> However what we are discussing here IMO is code repositories as code
>>>> is what the ASF produces. I guess Felix's suggestion is to create one
>>>> or a few openwhisk-contrib-* Git repositories under
>>>> https://github.com/apache/ for such "contrib" modules.
>>>>
>>>> -Bertrand
>>>
>>>
>>
>> --
>> Carlos Santana
>> <cs...@gmail.com>
>>
>>
>>
Re: I created a variant of the go runtime that is faster at init time
Posted by Rodric Rabbah <ro...@gmail.com>.
+1 “I think it would be better to organize around 1 git repo per language.”
-r
> On Dec 12, 2018, at 9:21 AM, David P Grove <gr...@us.ibm.com> wrote:
>
> For the runtimes specifically, if it is technically feasible I think it would be better to organize around 1 git repo per language.
>
> That repo could contain multiple runtime variants with different degrees of maturity. Several of the runtime repos already contain multiple variants (nodejs, php, python). Can that pattern work for go too?
>
> --dave
>
> Carlos Santana ---12/12/2018 07:26:56 AM---My 2 cents about the "contrib" repo for best effort support and experimental code we already have a
>
> From: Carlos Santana <cs...@gmail.com>
> To: dev@openwhisk.apache.org
> Date: 12/12/2018 07:26 AM
> Subject: Re: I created a variant of the go runtime that is faster at init time
>
>
>
>
> My 2 cents about the "contrib" repo for best effort support and
> experimental code we already have a repo
>
> It used be named incubator-openwhisk-experimental, but then we rename it to
> incubator-openwhisk-devtools [1]
>
> If any one has some cool experiments we have created a new folder in the
> repo and add some trivial travis test
>
> [1] https://github.com/apache/incubator-openwhisk-devtools
> -cs
>
> On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra <mi...@sciabarra.com>
> wrote:
>
> > Hmm, I understand the concern but I wonder HOW the "convenience" binaries
> > should be handled in practice.
> >
> > In OpenWhisk what it matters is the runtime you specify with --docker, so
> > that "convenience" is not really just a convenience, it is a core
> > requirement.
> >
> > We could setup an openwhisk contrib repository, but I cannot image a
> > single Travis build to be able to rebuild many images (at the moment I have
> > at least 4) and push all of them to docker hub...
> >
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Felix Meschberger <fm...@adobe.com.INVALID>
> > To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
> > Subject: Re: I created a variant of the go runtime that is faster at init
> > time
> > Date: Wed, 12 Dec 2018 10:00:07 +0000
> >
> > Hi Michele
> >
> > This is shaky ground and we don’t want to be the next npm horror story.
> >
> > Technically speaking, at Apache we primarily release source packages, all
> > binary is pure convenience. Granted the convience today is what most people
> > use.
> >
> > So what we should primarily do, as Bertrand hinted, is have a contrib
> > repository. We can still have a contrib docker account into which the
> > OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must
> > be clearly stated that those are not releases, have no release quality and
> > all the usual disclaimers.
> >
> > Regards
> > Felix
> >
> > > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <michele@sciabarra.com
> > >:
> > >
> > > Actually more than an account on GitHub it is important to have a docker
> > hub account named "openwhisk-contrib" so you can deploy an action with
> > something like:
> > >
> > > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
> > >
> > > To publish images, you can do sothing as simple as ask, maybe opening a
> > ticket, to push an image msciab/actionloop-gccgo-v1.10
> > > to openwhisk-contrib/actionloop-gccgo-v1.10.
> > >
> > >
> > >
> > > --
> > > Michele Sciabarra
> > > michele@sciabarra.com
> > >
> > > ----- Original message -----
> > > From: Bertrand Delacretaz <bd...@apache.org>
> > > To: dev@openwhisk.apache.org
> > > Subject: Re: I created a variant of the go runtime that is faster at
> > init time
> > > Date: Wed, 12 Dec 2018 10:45:43 +0100
> > >
> > > Hi,
> > >
> > > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> > > <mi...@sciabarra.com> wrote:
> > >>
> > >> 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...
> > >
> > > Accounts with "openwhisk" in their name should be owned by the
> > > OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> > > Foundation - technically being donated as we speak IIUC but that
> > > doesn't make a real difference.
> > >
> > > However what we are discussing here IMO is code repositories as code
> > > is what the ASF produces. I guess Felix's suggestion is to create one
> > > or a few openwhisk-contrib-* Git repositories under
> > > https://github.com/apache/ for such "contrib" modules.
> > >
> > > -Bertrand
> >
> >
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
>
>
Re: I created a variant of the go runtime that is faster at init time
Posted by David P Grove <gr...@us.ibm.com>.
For the runtimes specifically, if it is technically feasible I think it
would be better to organize around 1 git repo per language.
That repo could contain multiple runtime variants with different degrees of
maturity. Several of the runtime repos already contain multiple variants
(nodejs, php, python). Can that pattern work for go too?
--dave
From: Carlos Santana <cs...@gmail.com>
To: dev@openwhisk.apache.org
Date: 12/12/2018 07:26 AM
Subject: Re: I created a variant of the go runtime that is faster at
init time
My 2 cents about the "contrib" repo for best effort support and
experimental code we already have a repo
It used be named incubator-openwhisk-experimental, but then we rename it to
incubator-openwhisk-devtools [1]
If any one has some cool experiments we have created a new folder in the
repo and add some trivial travis test
[1]
https://github.com/apache/incubator-openwhisk-devtools
-cs
On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra <mi...@sciabarra.com>
wrote:
> Hmm, I understand the concern but I wonder HOW the "convenience" binaries
> should be handled in practice.
>
> In OpenWhisk what it matters is the runtime you specify with --docker, so
> that "convenience" is not really just a convenience, it is a core
> requirement.
>
> We could setup an openwhisk contrib repository, but I cannot image a
> single Travis build to be able to rebuild many images (at the moment I
have
> at least 4) and push all of them to docker hub...
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Felix Meschberger <fm...@adobe.com.INVALID>
> To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
> Subject: Re: I created a variant of the go runtime that is faster at init
> time
> Date: Wed, 12 Dec 2018 10:00:07 +0000
>
> Hi Michele
>
> This is shaky ground and we don’t want to be the next npm horror story.
>
> Technically speaking, at Apache we primarily release source packages, all
> binary is pure convenience. Granted the convience today is what most
people
> use.
>
> So what we should primarily do, as Bertrand hinted, is have a contrib
> repository. We can still have a contrib docker account into which the
> OpenWhisk PMC can regularly „dump“ binary builds for convience. But it
must
> be clearly stated that those are not releases, have no release quality
and
> all the usual disclaimers.
>
> Regards
> Felix
>
> > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <michele@sciabarra.com
> >:
> >
> > Actually more than an account on GitHub it is important to have a
docker
> hub account named "openwhisk-contrib" so you can deploy an action with
> something like:
> >
> > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
> >
> > To publish images, you can do sothing as simple as ask, maybe opening a
> ticket, to push an image msciab/actionloop-gccgo-v1.10
> > to openwhisk-contrib/actionloop-gccgo-v1.10.
> >
> >
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Bertrand Delacretaz <bd...@apache.org>
> > To: dev@openwhisk.apache.org
> > Subject: Re: I created a variant of the go runtime that is faster at
> init time
> > Date: Wed, 12 Dec 2018 10:45:43 +0100
> >
> > Hi,
> >
> > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> > <mi...@sciabarra.com> wrote:
> >>
> >> 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...
> >
> > Accounts with "openwhisk" in their name should be owned by the
> > OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> > Foundation - technically being donated as we speak IIUC but that
> > doesn't make a real difference.
> >
> > However what we are discussing here IMO is code repositories as code
> > is what the ASF produces. I guess Felix's suggestion is to create one
> > or a few openwhisk-contrib-* Git repositories under
> >
https://github.com/apache/
for such "contrib" modules.
> >
> > -Bertrand
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
Actually, the issue is where to publish in Docker Hub the contrib runtimes, like the `actionloop-gccgo-v1.11` I did that produces smaller executable but uses a different Go compiler, with all the consequences of being "different" (it is not the mainstream one).
It won't go on the standard set of images but some users can find useful. If someone on behalf of apache registers that docker hub username ("openwhisk-contrib), we may publish some of those images also there, keeping them separated. I think it does not matter where the actual github source repo is. For example, that one could be included in the golang repo for example, just published under "openwhisk-contrib" so it is somewhat part of the community work but not the officially released one.
As a side note for example I am trying also to do a PyPy python runtime, another "variant" that could be useful but not official. Source coud go in the python runtime but published on the openwhisk-contrib docker hub account.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Carlos Santana <cs...@gmail.com>
To: dev@openwhisk.apache.org
Subject: Re: I created a variant of the go runtime that is faster at init time
Date: Wed, 12 Dec 2018 04:26:29 -0800
My 2 cents about the "contrib" repo for best effort support and
experimental code we already have a repo
It used be named incubator-openwhisk-experimental, but then we rename it to
incubator-openwhisk-devtools [1]
If any one has some cool experiments we have created a new folder in the
repo and add some trivial travis test
[1] https://github.com/apache/incubator-openwhisk-devtools
-cs
On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra <mi...@sciabarra.com>
wrote:
> Hmm, I understand the concern but I wonder HOW the "convenience" binaries
> should be handled in practice.
>
> In OpenWhisk what it matters is the runtime you specify with --docker, so
> that "convenience" is not really just a convenience, it is a core
> requirement.
>
> We could setup an openwhisk contrib repository, but I cannot image a
> single Travis build to be able to rebuild many images (at the moment I have
> at least 4) and push all of them to docker hub...
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Felix Meschberger <fm...@adobe.com.INVALID>
> To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
> Subject: Re: I created a variant of the go runtime that is faster at init
> time
> Date: Wed, 12 Dec 2018 10:00:07 +0000
>
> Hi Michele
>
> This is shaky ground and we don’t want to be the next npm horror story.
>
> Technically speaking, at Apache we primarily release source packages, all
> binary is pure convenience. Granted the convience today is what most people
> use.
>
> So what we should primarily do, as Bertrand hinted, is have a contrib
> repository. We can still have a contrib docker account into which the
> OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must
> be clearly stated that those are not releases, have no release quality and
> all the usual disclaimers.
>
> Regards
> Felix
>
> > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <michele@sciabarra.com
> >:
> >
> > Actually more than an account on GitHub it is important to have a docker
> hub account named "openwhisk-contrib" so you can deploy an action with
> something like:
> >
> > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
> >
> > To publish images, you can do sothing as simple as ask, maybe opening a
> ticket, to push an image msciab/actionloop-gccgo-v1.10
> > to openwhisk-contrib/actionloop-gccgo-v1.10.
> >
> >
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Bertrand Delacretaz <bd...@apache.org>
> > To: dev@openwhisk.apache.org
> > Subject: Re: I created a variant of the go runtime that is faster at
> init time
> > Date: Wed, 12 Dec 2018 10:45:43 +0100
> >
> > Hi,
> >
> > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> > <mi...@sciabarra.com> wrote:
> >>
> >> 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...
> >
> > Accounts with "openwhisk" in their name should be owned by the
> > OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> > Foundation - technically being donated as we speak IIUC but that
> > doesn't make a real difference.
> >
> > However what we are discussing here IMO is code repositories as code
> > is what the ASF produces. I guess Felix's suggestion is to create one
> > or a few openwhisk-contrib-* Git repositories under
> > https://github.com/apache/ for such "contrib" modules.
> >
> > -Bertrand
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Carlos Santana <cs...@gmail.com>.
My 2 cents about the "contrib" repo for best effort support and
experimental code we already have a repo
It used be named incubator-openwhisk-experimental, but then we rename it to
incubator-openwhisk-devtools [1]
If any one has some cool experiments we have created a new folder in the
repo and add some trivial travis test
[1] https://github.com/apache/incubator-openwhisk-devtools
-cs
On Wed, Dec 12, 2018 at 2:13 AM Michele Sciabarra <mi...@sciabarra.com>
wrote:
> Hmm, I understand the concern but I wonder HOW the "convenience" binaries
> should be handled in practice.
>
> In OpenWhisk what it matters is the runtime you specify with --docker, so
> that "convenience" is not really just a convenience, it is a core
> requirement.
>
> We could setup an openwhisk contrib repository, but I cannot image a
> single Travis build to be able to rebuild many images (at the moment I have
> at least 4) and push all of them to docker hub...
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Felix Meschberger <fm...@adobe.com.INVALID>
> To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
> Subject: Re: I created a variant of the go runtime that is faster at init
> time
> Date: Wed, 12 Dec 2018 10:00:07 +0000
>
> Hi Michele
>
> This is shaky ground and we don’t want to be the next npm horror story.
>
> Technically speaking, at Apache we primarily release source packages, all
> binary is pure convenience. Granted the convience today is what most people
> use.
>
> So what we should primarily do, as Bertrand hinted, is have a contrib
> repository. We can still have a contrib docker account into which the
> OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must
> be clearly stated that those are not releases, have no release quality and
> all the usual disclaimers.
>
> Regards
> Felix
>
> > Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <michele@sciabarra.com
> >:
> >
> > Actually more than an account on GitHub it is important to have a docker
> hub account named "openwhisk-contrib" so you can deploy an action with
> something like:
> >
> > wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
> >
> > To publish images, you can do sothing as simple as ask, maybe opening a
> ticket, to push an image msciab/actionloop-gccgo-v1.10
> > to openwhisk-contrib/actionloop-gccgo-v1.10.
> >
> >
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Bertrand Delacretaz <bd...@apache.org>
> > To: dev@openwhisk.apache.org
> > Subject: Re: I created a variant of the go runtime that is faster at
> init time
> > Date: Wed, 12 Dec 2018 10:45:43 +0100
> >
> > Hi,
> >
> > On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> > <mi...@sciabarra.com> wrote:
> >>
> >> 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...
> >
> > Accounts with "openwhisk" in their name should be owned by the
> > OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> > Foundation - technically being donated as we speak IIUC but that
> > doesn't make a real difference.
> >
> > However what we are discussing here IMO is code repositories as code
> > is what the ASF produces. I guess Felix's suggestion is to create one
> > or a few openwhisk-contrib-* Git repositories under
> > https://github.com/apache/ for such "contrib" modules.
> >
> > -Bertrand
>
>
--
Carlos Santana
<cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
Hmm, I understand the concern but I wonder HOW the "convenience" binaries should be handled in practice.
In OpenWhisk what it matters is the runtime you specify with --docker, so that "convenience" is not really just a convenience, it is a core requirement.
We could setup an openwhisk contrib repository, but I cannot image a single Travis build to be able to rebuild many images (at the moment I have at least 4) and push all of them to docker hub...
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Felix Meschberger <fm...@adobe.com.INVALID>
To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
Subject: Re: I created a variant of the go runtime that is faster at init time
Date: Wed, 12 Dec 2018 10:00:07 +0000
Hi Michele
This is shaky ground and we don’t want to be the next npm horror story.
Technically speaking, at Apache we primarily release source packages, all binary is pure convenience. Granted the convience today is what most people use.
So what we should primarily do, as Bertrand hinted, is have a contrib repository. We can still have a contrib docker account into which the OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must be clearly stated that those are not releases, have no release quality and all the usual disclaimers.
Regards
Felix
> Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> Actually more than an account on GitHub it is important to have a docker hub account named "openwhisk-contrib" so you can deploy an action with something like:
>
> wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
>
> To publish images, you can do sothing as simple as ask, maybe opening a ticket, to push an image msciab/actionloop-gccgo-v1.10
> to openwhisk-contrib/actionloop-gccgo-v1.10.
>
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Bertrand Delacretaz <bd...@apache.org>
> To: dev@openwhisk.apache.org
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Wed, 12 Dec 2018 10:45:43 +0100
>
> Hi,
>
> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> <mi...@sciabarra.com> wrote:
>>
>> 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...
>
> Accounts with "openwhisk" in their name should be owned by the
> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> Foundation - technically being donated as we speak IIUC but that
> doesn't make a real difference.
>
> However what we are discussing here IMO is code repositories as code
> is what the ASF produces. I guess Felix's suggestion is to create one
> or a few openwhisk-contrib-* Git repositories under
> https://github.com/apache/ for such "contrib" modules.
>
> -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Felix Meschberger <fm...@adobe.com.INVALID>.
Hi Michele
This is shaky ground and we don’t want to be the next npm horror story.
Technically speaking, at Apache we primarily release source packages, all binary is pure convenience. Granted the convience today is what most people use.
So what we should primarily do, as Bertrand hinted, is have a contrib repository. We can still have a contrib docker account into which the OpenWhisk PMC can regularly „dump“ binary builds for convience. But it must be clearly stated that those are not releases, have no release quality and all the usual disclaimers.
Regards
Felix
> Am 12.12.2018 um 10:55 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> Actually more than an account on GitHub it is important to have a docker hub account named "openwhisk-contrib" so you can deploy an action with something like:
>
> wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
>
> To publish images, you can do sothing as simple as ask, maybe opening a ticket, to push an image msciab/actionloop-gccgo-v1.10
> to openwhisk-contrib/actionloop-gccgo-v1.10.
>
>
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Bertrand Delacretaz <bd...@apache.org>
> To: dev@openwhisk.apache.org
> Subject: Re: I created a variant of the go runtime that is faster at init time
> Date: Wed, 12 Dec 2018 10:45:43 +0100
>
> Hi,
>
> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> <mi...@sciabarra.com> wrote:
>>
>> 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...
>
> Accounts with "openwhisk" in their name should be owned by the
> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> Foundation - technically being donated as we speak IIUC but that
> doesn't make a real difference.
>
> However what we are discussing here IMO is code repositories as code
> is what the ASF produces. I guess Felix's suggestion is to create one
> or a few openwhisk-contrib-* Git repositories under
> https://github.com/apache/ for such "contrib" modules.
>
> -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
Actually more than an account on GitHub it is important to have a docker hub account named "openwhisk-contrib" so you can deploy an action with something like:
wsk create myaction --docker openwhisk-contrib/actionloop-gccgo-v1.10
To publish images, you can do sothing as simple as ask, maybe opening a ticket, to push an image msciab/actionloop-gccgo-v1.10
to openwhisk-contrib/actionloop-gccgo-v1.10.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Bertrand Delacretaz <bd...@apache.org>
To: dev@openwhisk.apache.org
Subject: Re: I created a variant of the go runtime that is faster at init time
Date: Wed, 12 Dec 2018 10:45:43 +0100
Hi,
On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
<mi...@sciabarra.com> wrote:
>
> 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...
Accounts with "openwhisk" in their name should be owned by the
OpenWhisk (P)PMC as the name is a trademark of the Apache Software
Foundation - technically being donated as we speak IIUC but that
doesn't make a real difference.
However what we are discussing here IMO is code repositories as code
is what the ASF produces. I guess Felix's suggestion is to create one
or a few openwhisk-contrib-* Git repositories under
https://github.com/apache/ for such "contrib" modules.
-Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
I asked already to change the title name. I do not believe it will be a huge problem but I "naively" used just OpenWhisk in my proposal.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Bertrand Delacretaz <bd...@apache.org>
To: dev@openwhisk.apache.org
Subject: Re: I created a variant of the go runtime that is faster at init time
Date: Sat, 15 Dec 2018 10:14:13 +0100
On Wed, Dec 12, 2018, at 3:03 PM Carlos Santana <cs...@gmail.com> wrote:
> The book is named learning OpenWhisk...
As discussed elsewhere that should preferably be "learning Apache
OpenWhisk", unless there are strong publisher constraints
More details at https://www.apache.org/foundation/marks/#books
-Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Dec 12, 2018 at 3:03 PM Carlos Santana <cs...@gmail.com> wrote:
> The book is named learning OpenWhisk...
As discussed elsewhere that should preferably be "learning Apache
OpenWhisk", unless there are strong publisher constraints
More details at https://www.apache.org/foundation/marks/#books
-Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Carlos Santana <cs...@gmail.com>.
The book is name learning OpenWhisk, it’s ok to have a matching Github .org/repo I don’t see any problem you are not using “openwhisk” to miss represent
I think to make it legit, send request to the PPMC at private@openwhisk.apache.org asking if it’s ok.
This is similar as if someone that wants to create a cool logo T-shirt for an OpenWhisk learning workshop Meetup and what to use the logo or brand or modify the logo a bit.
- Carlos Santana
@csantanapr
> On Dec 12, 2018, at 5:50 AM, Michele Sciabarra <mi...@sciabarra.com> wrote:
>
>
>> Accounts with "openwhisk" in their name should be owned by the
>> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
>> Foundation - technically being donated as we speak IIUC but that
>> doesn't make a real difference.
>
> Uh oh... I created a github organizations named "learning-openwhisk" that contains all the sources of the book, also titled "Learning OpenWhisk" being published by O'Reilly.... should I drop that GitHub organization and move everything in some other place to avoid... legal issues ? :)
Re: I created a variant of the go runtime that is faster at init time
Posted by Felix Meschberger <fm...@adobe.com.INVALID>.
Yes, a single contrib repository. I guess we still would want to lock it down but be more open to accept contributions, provided IP is properly transferred
Regards
Felix
> Am 12.12.2018 um 10:45 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
> Hi,
>
> On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
> <mi...@sciabarra.com> wrote:
>>
>> 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...
>
> Accounts with "openwhisk" in their name should be owned by the
> OpenWhisk (P)PMC as the name is a trademark of the Apache Software
> Foundation - technically being donated as we speak IIUC but that
> doesn't make a real difference.
>
> However what we are discussing here IMO is code repositories as code
> is what the ASF produces. I guess Felix's suggestion is to create one
> or a few openwhisk-contrib-* Git repositories under
> https://github.com/apache/ for such "contrib" modules.
>
> -Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
> Accounts with "openwhisk" in their name should be owned by the
>OpenWhisk (P)PMC as the name is a trademark of the Apache Software
>Foundation - technically being donated as we speak IIUC but that
>doesn't make a real difference.
Uh oh... I created a github organizations named "learning-openwhisk" that contains all the sources of the book, also titled "Learning OpenWhisk" being published by O'Reilly.... should I drop that GitHub organization and move everything in some other place to avoid... legal issues ? :)
Re: I created a variant of the go runtime that is faster at init time
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Dec 12, 2018 at 10:42 AM Michele Sciabarra
<mi...@sciabarra.com> wrote:
>
> 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...
Accounts with "openwhisk" in their name should be owned by the
OpenWhisk (P)PMC as the name is a trademark of the Apache Software
Foundation - technically being donated as we speak IIUC but that
doesn't make a real difference.
However what we are discussing here IMO is code repositories as code
is what the ASF produces. I guess Felix's suggestion is to create one
or a few openwhisk-contrib-* Git repositories under
https://github.com/apache/ for such "contrib" modules.
-Bertrand
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
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
michele@sciabarra.com
----- Original message -----
From: Felix Meschberger <fm...@adobe.com.INVALID>
To: "dev@openwhisk.apache.org" <de...@openwhisk.apache.org>
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
Hi
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 ?
Regards
Felix
> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> 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
> michele@sciabarra.com
>
> ----- Original message -----
> From: Carlos Santana <cs...@gmail.com>
> To: dev@openwhisk.apache.org
> 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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>>
>>> From: Michele Sciabarra <mi...@sciabarra.com>
>>> To: dev@openwhisk.apache.org
>>> 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
>>> michele@sciabarra.com
>>>
>>>
>>>
>>> ----- Original message -----
>>> From: David P Grove <gr...@us.ibm.com>
>>> To: dev@openwhisk.apache.org
>>> 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 <mi...@sciabarra.com> 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
> <cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Felix Meschberger <fm...@adobe.com.INVALID>.
Hi
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 ?
Regards
Felix
> Am 11.12.2018 um 17:47 schrieb Michele Sciabarra <mi...@sciabarra.com>:
>
> 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
> michele@sciabarra.com
>
> ----- Original message -----
> From: Carlos Santana <cs...@gmail.com>
> To: dev@openwhisk.apache.org
> 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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>>
>>> From: Michele Sciabarra <mi...@sciabarra.com>
>>> To: dev@openwhisk.apache.org
>>> 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
>>> michele@sciabarra.com
>>>
>>>
>>>
>>> ----- Original message -----
>>> From: David P Grove <gr...@us.ibm.com>
>>> To: dev@openwhisk.apache.org
>>> 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 <mi...@sciabarra.com> 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
> <cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
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
michele@sciabarra.com
----- Original message -----
From: Carlos Santana <cs...@gmail.com>
To: dev@openwhisk.apache.org
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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>
> > From: Michele Sciabarra <mi...@sciabarra.com>
> > To: dev@openwhisk.apache.org
> > 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
> > michele@sciabarra.com
> >
> >
> >
> > ----- Original message -----
> > From: David P Grove <gr...@us.ibm.com>
> > To: dev@openwhisk.apache.org
> > 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 <mi...@sciabarra.com> 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
<cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by Carlos Santana <cs...@gmail.com>.
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 <gr...@us.ibm.com> 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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>
> > From: Michele Sciabarra <mi...@sciabarra.com>
> > To: dev@openwhisk.apache.org
> > 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
> > michele@sciabarra.com
> >
> >
> >
> > ----- Original message -----
> > From: David P Grove <gr...@us.ibm.com>
> > To: dev@openwhisk.apache.org
> > 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 <mi...@sciabarra.com> 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
<cs...@gmail.com>
Re: I created a variant of the go runtime that is faster at init time
Posted by David P Grove <gr...@us.ibm.com>.
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 <mi...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
> From: Michele Sciabarra <mi...@sciabarra.com>
> To: dev@openwhisk.apache.org
> 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
> michele@sciabarra.com
>
>
>
> ----- Original message -----
> From: David P Grove <gr...@us.ibm.com>
> To: dev@openwhisk.apache.org
> 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 <mi...@sciabarra.com> 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
>
Re: I created a variant of the go runtime that is faster at init time
Posted by Michele Sciabarra <mi...@sciabarra.com>.
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
michele@sciabarra.com
----- Original message -----
From: David P Grove <gr...@us.ibm.com>
To: dev@openwhisk.apache.org
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 <mi...@sciabarra.com> 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
Re: I created a variant of the go runtime that is faster at init time
Posted by David P Grove <gr...@us.ibm.com>.
Michele Sciabarra <mi...@sciabarra.com> 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 better
for end users.
--dave