openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com.INVALID>
Subject Re: I created a variant of the go runtime that is faster at init time
Date Wed, 12 Dec 2018 09:09:58 GMT
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 <michele@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 <csantana23@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 <groved@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 <michele@sciabarra.com> wrote on 12/11/2018 10:37:56 AM:
>> 
>>> From: Michele Sciabarra <michele@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 <groved@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 <michele@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
> <csantana23@gmail.com>

Mime
View raw message