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:53:49 GMT
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 <michele@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 <fmeschbe@adobe.com.INVALID>
> To: "dev@openwhisk.apache.org" <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 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 <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