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 <mich...@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 > mich...@sciabarra.com > > ----- Original message ----- > From: Carlos Santana <csantan...@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 <gro...@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 <mich...@sciabarra.com> wrote on 12/11/2018 10:37:56 AM: >> >>> From: Michele Sciabarra <mich...@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 >>> mich...@sciabarra.com >>> >>> >>> >>> ----- Original message ----- >>> From: David P Grove <gro...@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 <mich...@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 > <csantan...@gmail.com>
