RE: [Caml-list] Big executables from ocamlopt; dynamic librariesagain

RE: [Caml-list] Big executables from ocamlopt; dynamic librariesagain

[Dave Berry]

Do .cmi files use hash-consing?  This can greatly reduce the size of
type information.

-----Original Message-----
From: Jacques Garrigue [mailto:garrigue@kurims.kyoto-u.ac.jp]
Sent: 18 March 2002 05:20
Subject: Re: [Caml-list] Big executables from ocamlopt; dynamic
librariesagain

...
If you've got a look at the size of some .cmi's, you may
realize that including required types in executables may require
potentially huge sizes.
...
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Big executables from ocamlopt; dynamic librariesagain

[Warp]

> If you want to have both security and allow linking everytime it's
> safe, then you would need to do lots of type-checking at link-time
> (runtime for dynamic linking). Basically that every module you depend
> on has an interface at least as good as what you need, checking type
> by type. If you've got a look at the size of some .cmi's, you may
> realize that including required types in executables may require
> potentially huge sizes. And type-checking is sometimes too slow.
>
> As a fall-back solution, there is MD5 hashing. The problem is that
> you're then mixing information for all the contents of a module.
> Any change will produce a new incompatible hash value.
> For instance, every time you add a function to a library, it becomes
> incompatible. And there are new functions in every release of ocaml.

Is the speed really an issue ? I mean... the ocaml compiler is doing that
job, and even more, right ? and its speed looks quite good. Or perhaps this
is an inv-NP problem where checking against a given signature takes exp.
time when producing a valid one is easy :)
Of course, that's true the size of CMI is turning big quite fast. But
including the CMI will be better then including the CMA ( if there is no C
dll behind, in that case, the CMI is bigger than the CMA )

> Note that for C, compatibility policies generally allow adding extra
> functions to a library without changing the version number, since the
> problem, should it arise, can be detected at link time.
>
> And, even worse than that, the current MD5 computation scheme is
> algorithm dependent: it is not based on a normalized view of types,
> but just on a dump of an internal tree structure, which is extremely
> sensitive to any change in the type checking algorithm. This means
> that compatibility can be broken as often as once a week for the CVS
> version!

That MD5 choice is of course well justified , but if that mean breaking
backward compatibily , distribuing ocaml precompiled binaries become
impossible, and then you're closing the ocaml door to many commercial usages
of ocaml, which could greatly improve the size of the community and so the
speed of ocaml development.

> So probably the real answer is that dynamic linking of caml native
> code is possible, but that it would be a lot of work, not so much at
> the compilation level, but more at improving compatibility checking.
> One could argue that the benefits would not be limited to dynamic
> linking alone, but also easier upgrading bewteen ocaml versions, so
> this might be worth it.

Do you mean dynlink of native code from bytecode ?
Whithout a CMI to ensure the type checking ?

Nicolas Cannasse

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners