Re: tiny toplevel

Re: tiny toplevel

[ortmann]

> However, a very simple experiment shows that the Caml toplevels are
> not extremely big, compared to usual command interpreters:

> mouton:/$ ps ug
> USER  PID %CPU %MEM   VSZ  RSS TTY   STAT START TIME COMMAND
> weis 7506  0.1  0.7  1564  904 pts/5 S    14:15 0:00 /bin/bash -i
> weis 7546  0.1  1.2  2840 1652 pts/5 T    14:16 0:00 ocamlrun /usr/bin
> weis 7656  1.6  0.5  1484  660 pts/5 T    14:17 0:00 camlrun /usr/loca
> weis 7665  0.0  0.6  2252  844 pts/5 T    14:18 0:00 perl
> weis 7657  0.0  0.6  2500  876 pts/5 R    14:18 0:00 ps ug

> Hope this helps,
> Pierre Weis

Any idea how big Java is?

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ortmann@us.ibm.com / internal 8.553.6795 / external 507.253.6795
ortmann@isl.net home 507.288.7732

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas

Re: tiny toplevel

[Markus Mottl]

On Tue, 08 Aug 2000, ortmann@us.ibm.com wrote:
> > USER  PID %CPU %MEM   VSZ  RSS TTY   STAT START TIME COMMAND
> > weis 7546  0.1  1.2  2840 1652 pts/5 T    14:16 0:00 ocamlrun /usr/bin
> > weis 7656  1.6  0.5  1484  660 pts/5 T    14:17 0:00 camlrun /usr/loca

> Any idea how big Java is?

Interesting question - I tried it out on a Sun Ultra 5:

    PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  11183 markusm    1   5    0 3000K 2448K run     0:10 33.63% ocaml
  11184 markusm    1  15    0 4232K 2656K run     0:04 18.04% java
  11402 markusm    1   5    0 1960K 1272K run     0:01  5.27% ocamlrun

The OCaml-program:

  while true do () done

The Java-program (an example of conciseness ;)

  class test {
    public static void main (String args[]) {
      while (true);
    }
  }

One could argue now that the initial heap settings for Java are larger (I
don't know), but even explicitely setting them to the lowest level does not
allow it to "beat" OCaml:

java -ms1000 test:

  11270 markusm    1   5    0 3336K 2480K run     0:05 23.44% java

No match for OCaml (even the toplevel interpreter is smaller), not even to
mention caml-light, which is at least 2-3 times smaller...

I don't know how Java scales up with more interesting programs, but I don't
expect any surprises here... - so if somebody wants to go "embedded", don't
do it with Java... ;)

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: tiny toplevel

[Georges Mariano]

Markus Mottl wrote:

> Interesting question - I tried it out on a Sun Ultra 5:
thanks ;)


> I don't know how Java scales up with more interesting programs, but I don't
> expect any surprises here... - so if somebody wants to go "embedded", don't
> do it with Java... ;)
Statitics are good but your conclusion is wrong because
who said that "embedded" interpreters are "standard" interpreters ??

Obviously this is not the case, and taking Java as an example is
also wrong because "embedded JAVA" is not JAVA but somthing close
to JavaCard (in the SmartCards **specific** context), 
so different constraints, specifications, and language
 
Suppose that you are able to define a JAVA language subset
wich is small enough to be embedded in, say, smartcards,
but in the same time, you're not able to define the same subset for Ocaml
(recall, it's a supposition!! :-)
=> you can't have OScard (Ocaml for Smart Cards :-)
despite the comparison we made on "initial" interpreters...

If I understand P. Weis, one thing is to remove Object Programming from
OCaml, then you have something close to CamlLight toplevel, ok.
In the context of an embedded system you may remove I/O filesystem
functions ?? (I don't know exactly what is an embedded system...)

and what else ??


 
-- 
> Georges MARIANO                 tel: (33) 03 20 43 84 06
> INRETS, 20 rue Elisee Reclus    fax: (33) 03 20 43 83 59
> 59650 Villeneuve d'Ascq         mailto:mariano@terre.inrets.fr
> FRANCE.                         
> http://www3.inrets.fr/Public/ESTAS/Mariano.Georges/
> http://www3.inrets.fr/BUGhome.html         mailto:Bforum@estas1.inrets.fr

Re: tiny toplevel

[Markus Mottl]

On Wed, 09 Aug 2000, Georges Mariano wrote:
> > I don't know how Java scales up with more interesting programs, but I don't
> > expect any surprises here... - so if somebody wants to go "embedded", don't
> > do it with Java... ;)
> Statitics are good but your conclusion is wrong because
> who said that "embedded" interpreters are "standard" interpreters ??

Right - on the the other hand, I could imagine that one could tweak the
interpreters of (O)Caml for "embedded systems", too: as we could see,
"caml-light" has a significantly smaller memory footprint, and we may not
have reached the ground yet...

> Obviously this is not the case, and taking Java as an example is
> also wrong because "embedded JAVA" is not JAVA but somthing close
> to JavaCard (in the SmartCards **specific** context), 
> so different constraints, specifications, and language

I cannot compare Apples to Oranges. It wouldn't be fair to take a "slim"
version of a Java interpreter and compare it with a "fat" OCaml
interpreter. Given the same purpose of the interpreters (running it on
"normal" machines), OCaml seems to be the better choice in terms of memory
consumption. Extrapolating the results to embedded systems may not be
justified, but taking the opposite view point without additional
information is probably even less so...

> Suppose that you are able to define a JAVA language subset
> wich is small enough to be embedded in, say, smartcards,
> but in the same time, you're not able to define the same subset for Ocaml
> (recall, it's a supposition!! :-)
> => you can't have OScard (Ocaml for Smart Cards :-)
> despite the comparison we made on "initial" interpreters...

Right, but it could be the other way round, too. Correct me if I am wrong,
but I suppose that runtime systems for object oriented languages are more
likely to consume more memory than ones for "just" a functional core.

E.g., given that the type system of Java is not 100% secure (statically),
it may require more code to do runtime checks.

> If I understand P. Weis, one thing is to remove Object Programming from
> OCaml, then you have something close to CamlLight toplevel, ok.
> In the context of an embedded system you may remove I/O filesystem
> functions ?? (I don't know exactly what is an embedded system...)

Maybe the developers can say more about this, but I guess it is not easy to
"peel out" just the core functionality.  OCaml seems to be mainly addressed
at "normal" computing, which addresses my needs, anyway. But who knows,
maybe OCaml has a bright future in embedded system?  (I always wanted to
run my micro-wave in a referentially transparent way... ;)

Best regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl

Re: tiny toplevel

[Xavier Leroy]

> Statitics are good but your conclusion is wrong because
> who said that "embedded" interpreters are "standard" interpreters ??

Well, in your initial message, it wasn't clear what you meant by
"embedded interpreter":

1- This can mean an interpreter for a scripting language embedded in a
larger application, e.g. TCL, Perl or PHP in Apache, Basic in MS
Office, etc.

2- This can also mean a bytecode interpreter and runtime system running
in an embedded computer.

The requirements are quite different in both cases.  For instance,
scripts are generally presented as source code, so, for OCaml, 1-
corresponds roughly to the OCaml toplevel (ocaml).  On the other hand,
embedded computers generally run binary code or object code, so 2-
corresponds only the the OCaml bytecode interpreter and runtime system
(ocamlrun).

> Obviously this is not the case, and taking Java as an example is
> also wrong because "embedded JAVA" is not JAVA but somthing close
> to JavaCard (in the SmartCards **specific** context), 
> so different constraints, specifications, and language
>  
> Suppose that you are able to define a JAVA language subset
> wich is small enough to be embedded in, say, smartcards,
> but in the same time, you're not able to define the same subset for Ocaml
> (recall, it's a supposition!! :-)
> => you can't have OScard (Ocaml for Smart Cards :-)
> despite the comparison we made on "initial" interpreters...

I'm glad you mentioned smartcarts and JavaCard, because I have
extensive, first-hand experience with these.  There's a lot to be said
here, but I'll try to focus on a few key points.

First, the main issue with smart cards (and to a lesser extent with
other embedded systems) isn't code size, but data size.  Smart cards
usually come with a lot more ROM (for storing the bytecode interpreter
and runtime system) than EEPROM (nonvolatile memory for storing
bytecode programs and persistent data), and ridiculously small amounts
of RAM (128 bytes to 1 Kbyte) for storing the stack and short-lived data.

It's no big deal to fit a JavaCard virtual machine in the ROM space
(been there, done that), and it wouldn't be hard to fit a Caml virtual
machine either.  The real issues are compactness of bytecode, heap
management, and stack management.  For instance, JavaCard allocates
all its objects in EEPROM, and doesn't have GC *at all*; this means
applications allocate few objects, and only at program initialization
time; the program should then run in constant space, updating in-place
the preallocated data.  The small RAM size also means that the stack
must stay very small, prohibiting any kind of recursive programming.

So, even though JavaCard looks like a pretty large subset of Java, the
programming style of JavaCard developers is radically different from
that of Java programmers, and resembles a lot traditional embedded C style
(i.e. no dynamic allocation at all).  In my opinion, the smart
card market would have been a lot better with some kind of safe C, or
Pascal, or Forth, rather than Java; but they needed a bytecode
interpreter and type safety, so of course they turned to Java.

Now, could you do the same with Caml?  Almost -- maybe with a
different implementation strategy for closures, so that a function
definition doesn't systematically allocate if it is closed.  But the
subset of the language in which you'd have to program would be ugly
and most of the advantages of Caml would be lost.

The situation is quite different for other embedded devices,
e.g. mobile phones, debit card machines at gas stations, electronic
fuel injection systems, etc.  These are quite respectable computers,
with 16 or 32-bit processors (Intel 8086, Motorola 68000, Motorola
PPC), and memory in the 100k-1M range.  In the early 90's, Caml Light
ran on machines no more powerful than this (640k PC, 1M Mac Plus, not
to mention the 64k partitions of the Palm Pilot in the late 90's).

Granted, OCaml has moved away from this kind of platform and towards
modern desktop machines.  For instance, the OCaml bytecode is 3.5
times bigger than the Caml Light bytecode, in exchange for faster
interpretation.  Going the other way would not be a big problem; it's
just that there is no need yet.

> If I understand P. Weis, one thing is to remove Object Programming from
> OCaml, then you have something close to CamlLight toplevel, ok.

In defense of OCaml's objects, they add very little complexity to the
bytecode interpreter and runtime system: *one* bytecode instruction,
and a bytecode library.  They do add a lot of complexity to the
typechecker and compiler, though.

> In the context of an embedded system you may remove I/O filesystem
> functions ?? (I don't know exactly what is an embedded system...)
> and what else ??

You'd probably remove the filesystem functions, yes, and replace them
with I/O functions tailored to what's connected to the embedded system
(e.g. serial port on a smart card; small keyboard and small screen on
a debit card machine; etc).  Also, you could remove everything that
has to do with dynamically loading the bytecode from a file; the
bytecode is usually (but not always) already there in your memory
space.  A lot of portability crutf can go away, because you know
exactly the machine.  E.g. don't worry about malloc() returning
non-contiguous memory chunks; just use your memory allocator.  Etc, etc.

On the other hand, there are things that the OS does for you on a
desktop computer that you may have to do by hand: interrupt handling,
talking directly to the peripherals, dealing with unreliable EEPROM
writes, etc.

It's quite a different world from programming desktop systems...

- Xavier Leroy

tiny toplevel

[Georges Mariano]

Hello,

I know it is possible to create (specific) toplevels
by adding some stuff to the original toplevel but...
is it possible to do the reverse, i.e creating toplevels
by removing some (supposed) unnecessary libraries/components ??

By the way, what's the size of the "smallest" possible toplevel 
(if 'smallest' make sense...) ??

(why this question ??? well, no particular point but
think 
	- about comparing "scripting language" interpreters (size)
	- about "tiny ocaml" or "embedded ocaml" ...
)

[I have no idea about what can be removed from the original toplevel :-)
just a question
]
Thanks
-- 
> Georges MARIANO                 tel: (33) 03 20 43 84 06
> INRETS, 20 rue Elisee Reclus    fax: (33) 03 20 43 83 59
> 59650 Villeneuve d'Ascq         mailto:mariano@terre.inrets.fr
> FRANCE.                         
> http://www3.inrets.fr/Public/ESTAS/Mariano.Georges/
> http://www3.inrets.fr/BUGhome.html         mailto:Bforum@estas1.inrets.fr

Re: tiny toplevel

[Pierre Weis]

> Hello,
> 
> I know it is possible to create (specific) toplevels
> by adding some stuff to the original toplevel but...
> is it possible to do the reverse, i.e creating toplevels
> by removing some (supposed) unnecessary libraries/components ??
> 
> By the way, what's the size of the "smallest" possible toplevel 
> (if 'smallest' make sense...) ??
> 
> (why this question ??? well, no particular point but
> think 
>         - about comparing "scripting language" interpreters (size)
>         - about "tiny ocaml" or "embedded ocaml" ...
> )
> 
> [I have no idea about what can be removed from the original toplevel :-)
> just a question
> ]
> Thanks
> -- 
> > Georges MARIANO                 tel: (33) 03 20 43 84 06
> > INRETS, 20 rue Elisee Reclus    fax: (33) 03 20 43 83 59

It is not easy to remove ``unnecessary libraries/components'' from the
toplevel executable program, since you need all the compiler anyway,
in order to ``interpret'' the language. If you want to remove
something, you should probably remove features from the language (for
instance use Caml Light instead of Objective Caml!).

However, a very simple experiment shows that the Caml toplevels are
not extremely big, compared to usual command interpreters:

mouton:/$ ps ug
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
weis      7506  0.1  0.7  1564  904 pts/5    S    14:15   0:00 /bin/bash -i
weis      7546  0.1  1.2  2840 1652 pts/5    T    14:16   0:00 ocamlrun /usr/bin
weis      7656  1.6  0.5  1484  660 pts/5    T    14:17   0:00 camlrun /usr/loca
weis      7665  0.0  0.6  2252  844 pts/5    T    14:18   0:00 perl
weis      7657  0.0  0.6  2500  876 pts/5    R    14:18   0:00 ps ug

Hope this helps,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/