Re: 250 times faster swift actions with the Go server...

[Carlos Santana]

Michele

By the way for a swift runtimes images including swift4 you can use the
current repo runtime for Swift here
https://github.com/apache/incubator-openwhisk-runtime-swift

— Carlos
On Thu, Feb 22, 2018 at 5:03 PM Carlos Santana  wrote:

> Great progress
> On Thu, Feb 22, 2018 at 10:05 AM Rodric Rabbah  wrote:
>
>> This is great. The use of python as the proxy was a historical
>> convenience. Your changes are shaping up nicely; thanks for pushing it
>> forward.
>>
>> -r
>>
>> > On Feb 22, 2018, at 6:08 AM, Michele Sciabarra 
>> wrote:
>> >
>> > After spending a session of learning way more swift I ever wanted to
>> know, I hacked an horrible sample of Swift code implementing the Hello
>> World as a read-stdin-write-std-out loop.
>> >
>> > The code in all his ugliness I do not dare to post is here:
>> >
>> >
>> https://github.com/sciabarracom/openwhisk-runtime-go/blob/pipe-loop/HelloSwift/Sources/Hello/main.swift
>> >
>> > However I used this example to to compare my new implementation in Go
>> with the current one (as described in James Thomas blog post
>> http://jamesthom.as/blog/2017/06/28/serverless-swift-with-openwhisk/)
>> and this is the result:
>> >
>> > +--+---+--+--+--+--+--+-+--+
>> > |  Label   |   #   | Avg  | Med  | 90%  | 95%  | 99%  | Min | Max  |
>> > +--+---+--+--+--+--+--+-+--+
>> > | Current  | 1 | 1097 | 1101 | 1169 | 1191 | 1243 |  19 | 2132 |
>> > | Go+Swift | 1 |4 |4 |6 |6 |   10 |   2 | 1030 |
>> > | TOTAL| 2 |  551 |   66 | 1148 | 1169 | 1221 |   2 | 2132 |
>> > +--+---+--+--+--+--+--+-+--+
>> >
>> > To be honest I am not sure why. As far as I know, Swift support  is
>> implemented as a read-write loop too (or at least this is what looks like
>> to a quick look to the code), however python is not famous to be a
>> performing language (and I suspect the Global Interpreter Lock may play a
>> role in those numbers).
>> >
>> > I did also a comparison of Go and Swift running under my new
>> implementation. Implemented in this way , the are basically the same speed.
>> >
>> > However it is worth to be noted that the image for Golang only is 10MB,
>> but if I have to add swift support you need a lot of libraries on it. I
>> used a docker image based on ibmcom/ubuntu-swift but it is huge (1.8G!), I
>> think a trimmed down version is needed.
>> >
>> > All the code is in my repo in the pipe-loop branch. Now I think I will
>> have to take the time to clean up the code and make it robust.
>> >
>> >
>> > --
>> >  Michele Sciabarra
>> >  openwh...@sciabarra.com
>>
>

Re: 250 times faster swift actions with the Go server...

[Carlos Santana]

Great progress
On Thu, Feb 22, 2018 at 10:05 AM Rodric Rabbah  wrote:

> This is great. The use of python as the proxy was a historical
> convenience. Your changes are shaping up nicely; thanks for pushing it
> forward.
>
> -r
>
> > On Feb 22, 2018, at 6:08 AM, Michele Sciabarra 
> wrote:
> >
> > After spending a session of learning way more swift I ever wanted to
> know, I hacked an horrible sample of Swift code implementing the Hello
> World as a read-stdin-write-std-out loop.
> >
> > The code in all his ugliness I do not dare to post is here:
> >
> >
> https://github.com/sciabarracom/openwhisk-runtime-go/blob/pipe-loop/HelloSwift/Sources/Hello/main.swift
> >
> > However I used this example to to compare my new implementation in Go
> with the current one (as described in James Thomas blog post
> http://jamesthom.as/blog/2017/06/28/serverless-swift-with-openwhisk/) and
> this is the result:
> >
> > +--+---+--+--+--+--+--+-+--+
> > |  Label   |   #   | Avg  | Med  | 90%  | 95%  | 99%  | Min | Max  |
> > +--+---+--+--+--+--+--+-+--+
> > | Current  | 1 | 1097 | 1101 | 1169 | 1191 | 1243 |  19 | 2132 |
> > | Go+Swift | 1 |4 |4 |6 |6 |   10 |   2 | 1030 |
> > | TOTAL| 2 |  551 |   66 | 1148 | 1169 | 1221 |   2 | 2132 |
> > +--+---+--+--+--+--+--+-+--+
> >
> > To be honest I am not sure why. As far as I know, Swift support  is
> implemented as a read-write loop too (or at least this is what looks like
> to a quick look to the code), however python is not famous to be a
> performing language (and I suspect the Global Interpreter Lock may play a
> role in those numbers).
> >
> > I did also a comparison of Go and Swift running under my new
> implementation. Implemented in this way , the are basically the same speed.
> >
> > However it is worth to be noted that the image for Golang only is 10MB,
> but if I have to add swift support you need a lot of libraries on it. I
> used a docker image based on ibmcom/ubuntu-swift but it is huge (1.8G!), I
> think a trimmed down version is needed.
> >
> > All the code is in my repo in the pipe-loop branch. Now I think I will
> have to take the time to clean up the code and make it robust.
> >
> >
> > --
> >  Michele Sciabarra
> >  openwh...@sciabarra.com
>

250 times faster swift actions with the Go server...

[Michele Sciabarra]

After spending a session of learning way more swift I ever wanted to know, I 
hacked an horrible sample of Swift code implementing the Hello World as a 
read-stdin-write-std-out loop.

The code in all his ugliness I do not dare to post is here:

https://github.com/sciabarracom/openwhisk-runtime-go/blob/pipe-loop/HelloSwift/Sources/Hello/main.swift

However I used this example to to compare my new implementation in Go with the 
current one (as described in James Thomas blog post 
http://jamesthom.as/blog/2017/06/28/serverless-swift-with-openwhisk/) and this 
is the result:

+--+---+--+--+--+--+--+-+--+
|  Label   |   #   | Avg  | Med  | 90%  | 95%  | 99%  | Min | Max  |
+--+---+--+--+--+--+--+-+--+
| Current  | 1 | 1097 | 1101 | 1169 | 1191 | 1243 |  19 | 2132 |
| Go+Swift | 1 |4 |4 |6 |6 |   10 |   2 | 1030 |
| TOTAL| 2 |  551 |   66 | 1148 | 1169 | 1221 |   2 | 2132 |
+--+---+--+--+--+--+--+-+--+

To be honest I am not sure why. As far as I know, Swift support  is implemented 
as a read-write loop too (or at least this is what looks like to a quick look 
to the code), however python is not famous to be a performing language (and I 
suspect the Global Interpreter Lock may play a role in those numbers).

I did also a comparison of Go and Swift running under my new implementation. 
Implemented in this way , the are basically the same speed.  

However it is worth to be noted that the image for Golang only is 10MB, but if 
I have to add swift support you need a lot of libraries on it. I used a docker 
image based on ibmcom/ubuntu-swift but it is huge (1.8G!), I think a trimmed 
down version is needed.

All the code is in my repo in the pipe-loop branch. Now I think I will have to 
take the time to clean up the code and make it robust.


-- 
  Michele Sciabarra
  openwh...@sciabarra.com

Re: Getting Started for those in a hurry.

[James Thomas]

Hello Alex!

If you want to run the platform locally, we have a number of options
including using Docker Compose (
https://github.com/apache/incubator-openwhisk-devtools/tree/master/docker-compose),
running a VM using Vagrant (
https://github.com/apache/incubator-openwhisk#quick-start) or even
Kubernetes (https://github.com/apache/incubator-openwhisk-deploy-kube).

Docker Compose is probably the simplest and fastest if you just want to
play around, I wrote up an overview of this approach here recently (
http://jamesthom.as/blog/2018/01/19/starting-openwhisk-in-sixty-seconds/).

If you just want to try OpenWhisk out, you can always sign up
for a free IBM Cloud Functions account which is a managed OpenWhisk
platform with a free tier in the public cloud.

Adding a C# runtime is something people have talked about for a while but
no-one has done much with yet... There is an open isse about this:
https://github.com/apache/incubator-openwhisk/issues/3003

If you can compile the c# source code into a static binary (compiled for
the linux architecture), you can deploy this as a native function without
any changes to the platform. If you do need to provide the runtime as a
native runtime, you will need to implement the simple HTTP API exposed by
the runtime containers that the platform talks to. Another community member
recently added PHP support, so his PR would be a good place to start for
instructions.
https://github.com/apache/incubator-openwhisk/pull/2415

All the runtimes are now in separate projects in Github. Reviewing the
existing runtimes should give you a good place to start. Feel free to ask
questions on here or on the Slack channel.
https://github.com/search?utf8=%E2%9C%93=incubator-openwhisk-runtime=


On 22 February 2018 at 10:05, Alex Hitchins  wrote:

> Hello all,
>
> I'm quite interested in the project, can anyone point me to some resources
> to get me going quickly?
>
> I come from a long C# background and am quite interested in adding this
> tooling (or .Net Core) to the mix of technologies already available.
>
>
> Alexander Hitchins
> 
> E: a...@alexhitchins.com
> W: alexhitchins.com
> M: 07788 423 969
> T: 01892 523 587
>
>
>


-- 
Regards,
James Thomas

Getting Started for those in a hurry.

[Alex Hitchins]

Hello all,

I'm quite interested in the project, can anyone point me to some resources to 
get me going quickly? 

I come from a long C# background and am quite interested in adding this tooling 
(or .Net Core) to the mix of technologies already available.


Alexander Hitchins

E: a...@alexhitchins.com
W: alexhitchins.com
M: 07788 423 969
T: 01892 523 587

Re: Proposal for Project Maturity Model Status

[Bertrand Delacretaz]

On Thu, Feb 22, 2018 at 10:25 AM, Bertrand Delacretaz
 wrote:
> ...I'll do that to update the list of mentors and apart from that that
> page already mostly has links which is fine IMO...

I've updated http://incubator.apache.org/projects/openwhisk.html using
links for the rosters and incubation reports, to avoid having
potentially stale information there.

Hope that works for others, and if not svn and Git are our friends.

FWIW, the incubator.a.o website maintenance instructions are at
https://incubator.apache.org/guides/website.html

-Bertrand

Re: Proposal for Project Maturity Model Status

[Bertrand Delacretaz]

Hi,

On Wed, Feb 21, 2018 at 9:37 PM, Matt Rutkowski  wrote:
...
> http://incubator.apache.org/projects/openwhisk.html
...

The purpose of that page is different, having it is an Incubator
requirement to reflect the podling's "formal" status.

OTOH the maturity model is an informal self-assessment that's often
useful in finding gaps before graduation.

As you mention, the incubator.a.o page is not as convenient to edit -
but it's fine to have links there to the details which are elsewhere,
so IMO it's good to have as much info as possible under
http://openwhisk.incubator.apache.org/ , and just add links from that
incubator.a.o page.

I'll do that to update the list of mentors and apart from that that
page already mostly has links which is fine IMO.

-Bertrand