llvm dev - Apr 2019 - Feasibility of cling/llvm interpreter for JIT replacement

Dear Sir/Madam


Our company, 4Js software, has developed an SQL data base software that 
runs under different operating systems: Windows, Linux, Mac OS X. This 
software compiles each SQL statement into a C program that is compiled 
"on the fly" and executed by our JIT, Just In Time compiler.

We wanted to port it to Apple's iOS, and spent a lot of time 
retargetting the JIT for supporting the ARM 64 CPU, but to our surprise, 
when everything was ready, we learned that Apple iOS forbids software to 
generate dynamically an executable.

After several months of reflections we think we can get around this 
problem  by using a C interpreter. Instead of compiling it to machine 
code, we would pass the generated C program to  a C interpreter that 
would interpret the C program.

After looking at several interpreters, we think that the llvm based 
CLING interpreter could do the job. To test these ideas, we have 
recompiled the llvm/Clang system in a small linux/ARM64 based machine. 
Our preliminary tests seem to work and cling is able to load the 
generated program.

There are several possible problems that we see.


The first and most obvious one is the incredible size of the CLING 
interpreter (200MB stripped). Our whole data base is 80MB stripped. We 
are targetting an Apple iPad, boosted with 1TO SSD/6GB RAM. What would 
be the minimum requirements for CLING in terms of RAM size?

The second question is that we have still concerns over the overall 
approach. Do you see any problems with this architecture? Can it work on 
principle?

The third question concerns the feasibility of our JIT generating byte 
codes for the LLVM interpreter, boosting performance and reducing RAM 
footprint. Would that be a better solution than using the CLING 
interpreter? Is that possible within Apple's iOS?

And yet another question is the need to modify the CLING interpreter so 
that it receives its input from a character buffer instead of a file, 
and other small tweaks. Is that possible?

Are there any copyright issues? Are we allowed to embed the llvm 
software into our system? Of course we would publish any modifications 
done to the source code.

We thank you in advance for any answers to the questions above.


Yours sincerely


Jacob Navia

iOS Project Manager

4Js Software. https://4js.com
28 Quai Gallieni, 92150 Suresnes

FRANCE

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/b0fd224b/attachment.html>

Is there any reason not to use traditional approaches like ChaiScript?

Zhang
> 在 2019年4月10日，09:21，jacob navia via llvm-dev <llvm-dev at
lists.llvm.org> 写道：
> 
> Dear Sir/Madam
> 
> 
> 
> Our company, 4Js software, has developed an SQL data base software that
runs under different operating systems: Windows, Linux, Mac OS X. This software
compiles each SQL statement into a C program that is compiled "on the
fly" and executed by our JIT, Just In Time compiler.
> 
> We wanted to port it to Apple's iOS, and spent a lot of time
retargetting the JIT for supporting the ARM 64 CPU, but to our surprise, when
everything was ready, we learned that Apple iOS forbids software to generate
dynamically an executable.
> 
> After several months of reflections we think we can get around this problem
by using a C interpreter. Instead of compiling it to machine code, we would pass
the generated C program to  a C interpreter that would interpret the C program.
> 
> After looking at several interpreters, we think that the llvm based CLING
interpreter could do the job. To test these ideas, we have recompiled the
llvm/Clang system in a small linux/ARM64 based machine. Our preliminary tests
seem to work and cling is able to load the generated program.
> 
> There are several possible problems that we see.
> 
> 
> 
> The first and most obvious one is the incredible size of the CLING
interpreter (200MB stripped). Our whole data base is 80MB stripped. We are
targetting an Apple iPad, boosted with 1TO SSD/6GB RAM. What would be the
minimum requirements for CLING in terms of RAM size?
> 
> The second question is that we have still concerns over the overall
approach. Do you see any problems with this architecture? Can it work on
principle?
> 
> The third question concerns the feasibility of our JIT generating byte
codes for the LLVM interpreter, boosting performance and reducing RAM footprint.
Would that be a better solution than using the CLING interpreter? Is that
possible within Apple's iOS?
> 
> And yet another question is the need to modify the CLING interpreter so
that it receives its input from a character buffer instead of a file, and other
small tweaks. Is that possible?
> 
> Are there any copyright issues? Are we allowed to embed the llvm software
into our system? Of course we would publish any modifications done to the source
code.
> 
> We thank you in advance for any answers to the questions above.
> 
> 
> 
> Yours sincerely
> 
> 
> 
> Jacob Navia
> 
> iOS Project Manager
> 
> 4Js Software. https://4js.com
> 28 Quai Gallieni, 92150 Suresnes
> 
> FRANCE
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/b1124920/attachment.html>

Hi Jacob,

On 4/10/19 11:21 AM, jacob navia via llvm-dev wrote:
>
> Dear Sir/Madam
>
>
> Our company, 4Js software, has developed an SQL data base software 
> that runs under different operating systems: Windows, Linux, Mac OS X. 
> This software compiles each SQL statement into a C program that is 
> compiled "on the fly" and executed by our JIT, Just In Time
compiler.
>
> We wanted to port it to Apple's iOS, and spent a lot of time 
> retargetting the JIT for supporting the ARM 64 CPU, but to our 
> surprise, when everything was ready, we learned that Apple iOS forbids 
> software to generate dynamically an executable.
>
> After several months of reflections we think we can get around this 
> problem  by using a C interpreter. Instead of compiling it to machine 
> code, we would pass the generated C program to  a C interpreter that 
> would interpret the C program.
>
> After looking at several interpreters, we think that the llvm based 
> CLING interpreter could do the job. To test these ideas, we have 
> recompiled the llvm/Clang system in a small linux/ARM64 based machine. 
> Our preliminary tests seem to work and cling is able to load the 
> generated program.
>
> There are several possible problems that we see.
>
>
> The first and most obvious one is the incredible size of the CLING 
> interpreter (200MB stripped). Our whole data base is 80MB stripped. We 
> are targetting an Apple iPad, boosted with 1TO SSD/6GB RAM.
>
   How do you do the strip? I have nightly releases of cling here: 
https://github.com/vgvassilev/cling/releases the release is around 23MB 
and unzipped is around 80. I am pretty sure we can strip it further
down.
>
> What would be the minimum requirements for CLING in terms of RAM size?
>
   That's a hard question: running `./bin/cling ".q"` shows around
23Mb
peak rss. `./bin/cling "#include <vector>" ".q"` shows
34 Mb and so on.
It depends on what sort of things you will be
compiling/interpreting.
>
> The second question is that we have still concerns over the overall 
> approach. Do you see any problems with this architecture? Can it work 
> on principle?
>
> The third question concerns the feasibility of our JIT generating byte 
> codes for the LLVM interpreter, boosting performance and reducing RAM 
> footprint. Would that be a better solution than using the CLING 
> interpreter? Is that possible within Apple's iOS?
>
> And yet another question is the need to modify the CLING interpreter 
> so that it receives its input from a character buffer instead of a 
> file, and other small tweaks. Is that possible?
>
   `./bin/cling '#include <iostream>' 'printf("hello
world!\n");'`
works. Did you mean a different use-case?
>
> Are there any copyright issues? Are we allowed to embed the llvm 
> software into our system? Of course we would publish any modifications 
> done to the source code.
>
   I am not a lawyer. LLVM is licensed under a MIT-like (University of 
Illinois/NCSA) license (soon will be Apache-2.0). Cling is dual licensed 
under "UI/NCSAOSL" and "LGPL".

   Let me know if you need any further help on cling!

Best, Vassil
> We thank you in advance for any answers to the questions above.
>
>
> Yours sincerely
>
>
> Jacob Navia
>
> iOS Project Manager
>
> 4Js Software. https://4js.com
> 28 Quai Gallieni, 92150 Suresnes
>
> FRANCE
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190410/00d8d971/attachment-0001.html>

chaiscript isn't very performant - far away from a real JITer

Am 10.04.2019 um 11:33 schrieb mayuyu.io via llvm-dev:
> Is there any reason not to use traditional approaches like ChaiScript?
>
> Zhang
>
> > 在 2019年4月10日，09:21，jacob navia via llvm-dev <llvm-dev at
lists.llvm.org> 写道：
> >
> > Dear Sir/Madam
> >
> >
> >
> > Our company, 4Js software, has developed an SQL data base software
that runs under different operating systems: Windows, Linux, Mac OS X. This
software compiles each SQL statement into a C program that is compiled "on
the fly" and executed by our JIT, Just In Time compiler.
> >
> > We wanted to port it to Apple's iOS, and spent a lot of time
retargetting the JIT for supporting the ARM 64 CPU, but to our surprise, when
everything was ready, we learned that Apple iOS forbids software to generate
dynamically an executable.
> >
> > After several months of reflections we think we can get around this
problem  by using a C interpreter. Instead of compiling it to machine code, we
would pass the generated C program to  a C interpreter that would interpret the
C program.
> >
> > After looking at several interpreters, we think that the llvm based
CLING interpreter could do the job. To test these ideas, we have recompiled the
llvm/Clang system in a small linux/ARM64 based machine. Our preliminary tests
seem to work and cling is able to load the generated program.
> >
> > There are several possible problems that we see.
> >
> >
> >
> > The first and most obvious one is the incredible size of the CLING
interpreter (200MB stripped). Our whole data base is 80MB stripped. We are
targetting an Apple iPad, boosted with 1TO SSD/6GB RAM. What would be the
minimum requirements for CLING in terms of RAM size?
> >
> > The second question is that we have still concerns over the overall
approach. Do you see any problems with this architecture? Can it work on
principle?
> >
> > The third question concerns the feasibility of our JIT generating byte
codes for the LLVM interpreter, boosting performance and reducing RAM footprint.
Would that be a better solution than using the CLING interpreter? Is that
possible within Apple's iOS?
> >
> > And yet another question is the need to modify the CLING interpreter
so that it receives its input from a character buffer instead of a file, and
other small tweaks. Is that possible?
> >
> > Are there any copyright issues? Are we allowed to embed the llvm
software into our system? Of course we would publish any modifications done to
the source code.
> >
> > We thank you in advance for any answers to the questions above.
> >
> >
> >
> > Yours sincerely
> >
> >
> >
> > Jacob Navia
> >
> > iOS Project Manager
> >
> > 4Js Software. https://4js.com
> > 28 Quai Gallieni, 92150 Suresnes
> >
> > FRANCE
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Le 10/04/2019 à 11:33, mayuyu.io a écrit :
> Is there any reason not to use traditional approaches like ChaiScript?
>
> Zhang
>
Yes, that would mean generating chai script and not C, as it is done 
now. That would mean writing a new back end for a specific port to an 
specific architecture (iOS) and special casing all the backend of the 
SQL-->C compiler.


That is (of course) doable, but it is a LOT of work.