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

[Amir Chaudhry <amc79@xxxxxxxxx>]

> On 2 Jul 2015, at 15:20, Anil Madhavapeddy <anil@xxxxxxxxxx> 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
> 

Good to know. I'm still curious about what the figures are currently for 
mirage-www. From other sites/info, it seems that machinery for (secure) static 
site comes to ~5MB -- so the rest would be content (assuming crunch and cohttp, 
I believe).

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