[Caml-list] -thread and ocamlc vs ocamlc.opt

[Caml-list] -thread and ocamlc vs ocamlc.opt

[Pixel]

% ocamlc -thread threads.cma
% ocamlc.opt -thread threads.cma
Error on dynamically loaded library: /usr/lib/ocaml/dllthreads.so: undefined symbol: extern_sp
% ocamlopt -thread threads.cmxa                           
Cannot find file threads.cmxa

Questions:
- in which case are ocamlc and ocamlc.opt not equivalent?

- in which case are xxx and xxx.opt not equivalent? 
At least, it seems camlp4o.opt is pretty useless (one gets "native-code
program cannot do a dynamic load")

I've been trying to reduce the size of the ocaml rpm which is getting quite
huge (27MB), and doing
  for i in /usr/bin/*.opt ; do
    ln -s `basename $i` `echo $i | sed "s/.opt$//"`
  done
helps!

- should threads.cmxa be included somehow/somewhere? The doc says
    ocamlopt -thread other options threads.cmxa other files
  is that wrong?


Thanks!
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Xavier Leroy]

> % ocamlc -thread threads.cma
> % ocamlc.opt -thread threads.cma
> Error on dynamically loaded library: /usr/lib/ocaml/dllthreads.so: undefined symbol: extern_sp

This is a known bug in 3.04.  The switch to dynamic loading of C
libraries was bound to generate a few rough edges; this is the only
one known so far.

> % ocamlopt -thread threads.cmxa                           
> Cannot find file threads.cmxa

This is normal: you can't use threads in native programs, unless OCaml
was set up to use POSIX threads (configure --with-pthread).

> Questions:
> - in which case are ocamlc and ocamlc.opt not equivalent?

When there is a bug in one and not in the other :-)

> - in which case are xxx and xxx.opt not equivalent? 

Can't answer for general xxx.

> At least, it seems camlp4o.opt is pretty useless (one gets "native-code
> program cannot do a dynamic load")
> 
> I've been trying to reduce the size of the ocaml rpm which is getting quite
> huge (27MB), and doing
>   for i in /usr/bin/*.opt ; do
>     ln -s `basename $i` `echo $i | sed "s/.opt$//"`
>   done
> helps!

Frankly, I would rather remove the .opt compilers from the RPM, rather
than remove the non-.opt compilers.  

Concerning the RPM size, several things should be noted (with tongue
in cheek):

- If you had one package with gcc, gdb, libc and assorted goodies, it
would be even larger
- Mandrake contains even larger packages of even more dubious utility
than OCaml
- It is certainly possible to split it into different packages, if you
think not all users will need everything
- Mandrake could always switch to DVDs as their distribution format :-)

> - should threads.cmxa be included somehow/somewhere? The doc says
>     ocamlopt -thread other options threads.cmxa other files
>   is that wrong?

It also says you have to configure with POSIX threads for this to work.
The reason this is not the default configuration is that you need to
trust your POSIX thread implementation and have a good understanding
of its limitations (slower thread creation, fewer max threads allowed).
My experience as the initial developer of LinuxThreads suggest that
these conditions are not often met...

- Xavier Leroy

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Sven]

On Wed, Jan 16, 2002 at 05:03:35PM +0100, Xavier Leroy wrote:
> Frankly, I would rather remove the .opt compilers from the RPM, rather
> than remove the non-.opt compilers.  

Mmm, ...

Is there really much people using the .opt compilers ? Does it really make
sense to have them packaged ?

I myself was considering splitting them of into a separate debian package,
since they are big, and most probably not used that much.

I could also simply disable the building of them, but am afraid someone will
need them in the future.

Friendly,

Sven LUther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Patrick M Doane]

On Wed, 16 Jan 2002, Sven wrote:

> On Wed, Jan 16, 2002 at 05:03:35PM +0100, Xavier Leroy wrote:
> > Frankly, I would rather remove the .opt compilers from the RPM, rather
> > than remove the non-.opt compilers.
>
> Mmm, ...
>
> Is there really much people using the .opt compilers ? Does it really make
> sense to have them packaged ?

I occasionally use them for larger projects - typically noticing a
compilation speed imrovement of about 50-100%.

I've also been trying to represent a DOM like interface in Caml lately
which really benefits from using the .opt compiler.  There are a large
number of cyclic class types and the typechecking can take a bit of time
so I notice substantial improvements with the .opt compilers (more in the
range of 5x or so as a guess).

Patrick

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Xavier Leroy]

> Is there really much people using the .opt compilers ? Does it really make
> sense to have them packaged ?

They speed up compilations by a factor of 2 or 3.  Some of my
colleagues use them for this reason, but that's because they have
3-year old workstations :-)  With more recent hardware, I've never been
bothered by the compilation speed of the non-.opt compilers, and thus
don't use them except for testing purposes.

> I myself was considering splitting them of into a separate debian package,
> since they are big, and most probably not used that much.

That sounds reasonable to me.

> I could also simply disable the building of them, but am afraid someone will
> need them in the future.

Well, there are always users that cling to their 90 Mhz Pentium :-)

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Sven]

On Wed, Jan 16, 2002 at 05:43:51PM +0100, Xavier Leroy wrote:
> > Is there really much people using the .opt compilers ? Does it really make
> > sense to have them packaged ?
> 
> They speed up compilations by a factor of 2 or 3.  Some of my
> colleagues use them for this reason, but that's because they have
> 3-year old workstations :-)  With more recent hardware, I've never been
> bothered by the compilation speed of the non-.opt compilers, and thus
> don't use them except for testing purposes.
> 
> > I myself was considering splitting them of into a separate debian package,
> > since they are big, and most probably not used that much.
> 
> That sounds reasonable to me.
> 
> > I could also simply disable the building of them, but am afraid someone will
> > need them in the future.
> 
> Well, there are always users that cling to their 90 Mhz Pentium :-)

Ok, i will split them away in the next iteration of my packages, this will
save 3MB of installed stuff for people not using it. It will also make
downloading the ocaml package smaller :)))

Friendly,

Sven Luther
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] -thread and ocamlc vs ocamlc.opt

[Pixel]

Xavier Leroy <xavier.leroy@inria.fr> writes:

[...]

> > I've been trying to reduce the size of the ocaml rpm which is getting quite
> > huge (27MB), and doing
> >   for i in /usr/bin/*.opt ; do
> >     ln -s `basename $i` `echo $i | sed "s/.opt$//"`
> >   done
> > helps!
> 
> Frankly, I would rather remove the .opt compilers from the RPM, rather
> than remove the non-.opt compilers.  

?? switching from non-.opt to .opt makes some impressive speed-ups (x2) when
compiling.

> 
> Concerning the RPM size, several things should be noted (with tongue
> in cheek):
> 
> - If you had one package with gcc, gdb, libc and assorted goodies, it
> would be even larger

the main difference is that not many people would remark if ocaml was not
included ;p

> - Mandrake contains even larger packages of even more dubious utility
> than OCaml

trolls, trolls, vive les trolls :)

> - It is certainly possible to split it into different packages, if you
> think not all users will need everything

done

> - Mandrake could always switch to DVDs as their distribution format :-)

expensive, hard to test, many packages to maintain is costly...

> 
> > - should threads.cmxa be included somehow/somewhere? The doc says
> >     ocamlopt -thread other options threads.cmxa other files
> >   is that wrong?
> 
> It also says you have to configure with POSIX threads for this to work.
> The reason this is not the default configuration is that you need to
> trust your POSIX thread implementation and have a good understanding
> of its limitations (slower thread creation, fewer max threads allowed).
> My experience as the initial developer of LinuxThreads suggest that
> these conditions are not often met...

i don't know much about this. Are these conditions met under linux?


thanks!

--
Pixel
programming languages addict      http://merd.net/pixel/language-study/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr