[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Mirage and piÃata numbers



On 02/07/2015 15:20, Anil Madhavapeddy wrote:
> On 2 Jul 2015, at 14:02, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
>> Amir,
>>
>> On 07/02/2015 13:31, Amir Chaudhry wrote:
>>> - Could Hannes or David tell me the size of the PiÃata and its equivalent 
>>> in the traditional stack? (I already have a comparison in kloc but I'm 
>>> curious about the deployed image). 
>> binary size is 8.2M (mostly cow it seems, compressed 1.4MB). traditional
>> stacks: not sure, maybe 200MB?
> Incidentally, I posted a few things that we could do to reduce the binary 
> size further to HN and forgot to mirror it here 
> https://news.ycombinator.com/item?id=9800063
>
> - Native code compilation still includes symbols. Stripping that reduces the 
> size at the obvious cost of debugging ease.
>
> - When an OCaml module is touched for a single function, the entire module is 
> included at present. OCaml 4.02.0 included module aliases to make it easier 
> to break down module hierarchies into less monolithic chunks. They work by 
> exposing module equivalence in the signature, and reduced the size of Unix 
> binaries in Jane Street Core by 90% in some cases; 
> https://blogs.janestreet.com/better-namespaces-through-module-aliases/
>
> - Bytecode (while less performant) can be compressed more easily than native 
> code. We've had DNS and OpenFlow servers that are less than a megabyte in 
> size quite easily when compiled with bytecode.
>
> - Dead code elimination requires some whole program optimisation, and 
> currently only works with bytecode via the OCamlClean tool: 
> http://www.algo-prog.info/ocaml_for_pic/web/index.php?id=ocamlclean .
>
> Porting this to native code is on the TODO list, but needs some fiddling with 
> frame pointers in the generated binaries to do a good job. 
>
> So the overall message is that reducing the deployed binary size is now a 
> compiler problem, since the unikernel architecture lets us provide it with 
> much more information (configuration files and OS libraries as well as the 
> application logic).
>
> -anil
Someone pointed me to this discution.

I have some prototype to eliminate dead code at link time. This is far
from ready yet (some segfault happens), but this already prove to
provide interesting improvements.
The prototype is there:
https://github.com/chambart/ocaml-1/tree/flambda+function_section

With that I managed to get a hello world of ~40kB
-- 
Pierre

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.