Erlang Micro Edition.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Erik Reitsma (RY/ETM)-2

> Alex Arnon <alex.arnon> wrote:
> I would like to hear your opinions on the usefulness of
> creating a
> small-footprint Erlang VM.
>
> Compared with Java, Erlang *is* small-footprint.
> The smallest program I've ever managed to run with Sun's Java
> (on a Sun machine) was 32MB of virtual memory; Erlang is 7MB.

But a Java 2 Micro Edition requires a lot less memory (2MB or so), since it runs on mobile phones. So, even if Erlang is smaller that Java Standard Edition, it is no Micro Edition yet.
I would love to be able to run Erlang on my Windows Mobile Edition phone (epecially with some GUI interface).

*Erik.


Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Alex Arnon-3
Thank you all very much for your answers. I see that every one of you
sees it somewhat differently - this is very interesting, and more
opinions would be most welcome :)
Christophe, I was thinking more along the lines of trying to assess
how large/heavy a ground-up rebuild of a VM that will be as simple as
possible, with a minimum of BIFs and features. As Joe said, bignums
will probably be out (though at least 32-bit integers must be
supported), and as James suggested the library layout might be
different. The thing is that it is difficult for me to assess the
scope of such a project right now - I am not familiar with the
operation of the VM, or even with the file format/bytecodes (though I
have browsed a bit through docs and the code... does anyone have
"proper", up-to-date documentation?).
My gut feeling tells me that a ground-up rewrite is necessary:
- Portability and embeddability.
- As Christophe suggested, make support for low-level services (BIFs)
a config-time selection.
- Tighter control of operation. E.g. memory management strategy could
be compile-time selectable.
- A chance to find that minimal closure of functionality that a small
embedded system would need.


Cheers,
Alex.


Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Thomas Lindgren-5


--- Alex Arnon <alex.arnon> wrote:

> Christophe, I was thinking more along the lines of
> trying to assess
> how large/heavy a ground-up rebuild of a VM that
> will be as simple as
> possible, with a minimum of BIFs and features.

First of all, what's the point of an Erlang without
BIFs and features?

OK, I'm being a bit facetious, but there has to be a
reason to choose Erlang too. Also, I would suspect
that most developers want to add more nifty stuff for
the next model, so things will likely creep back in.

Restructuring the system to get rid of unused features
may be a Good Thing even so. (By moving more features
into Erlang, one can omit them more easily.)

> My gut feeling tells me that a ground-up rewrite is
> necessary:

Uh-oh :-) First, let's see what can be done to the
existing system. As a simple baseline, I stripped an
R9C2 installation (x86, slackware):

(I'm not sure how the executables are used, so I list
them all)

Before strip:
 4282779 beam
 4306296 beam.elib
 4305231 beam.elib.shared
 4281706 beam.shared

After strip:
  970192 beam
  978544 beam.elib
  985008 beam.elib.shared
  976656 beam.shared

So there are some easy gains to be made in storage
space, at least.

At startup, both the stripped and unstripped beam
processes appear to occupy about ~4.2 MB of memory, of
which ~1.4 MB is shared. Some flag tweaking may reduce
that a bit further.

The VM sees 2.8 MB of this: 0.6 MB is used by
processes, and 2.2 MB shared (1.4 MB bytecode from 70
modules, the rest atoms, binaries, and ets).

Of course, practical use will size up those areas. One
real system, when idling after test, has a 7.4 MB VM,
wherein 1.9 MB is used by processes, bytecode uses 4.0
MB (~250 loaded modules) and the rest is for ets,
atoms and binaries. The entire (unstripped) process is
13 MB, which I'd say is fairly normal for a realistic
Erlang node.

Peak memory use may be much higher, of course. First,
a database may increase the ets size quite a bit.
Second, an active system will use more (transient)
space for processes.

Best,
Thomas



               
__________________________________
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html 



Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Alex Arnon-3
On 6/30/05, Thomas Lindgren <thomasl_erlang> wrote:

>
>
> --- Alex Arnon <alex.arnon> wrote:
>
> > Christophe, I was thinking more along the lines of
> > trying to assess
> > how large/heavy a ground-up rebuild of a VM that
> > will be as simple as
> > possible, with a minimum of BIFs and features.
>
> First of all, what's the point of an Erlang without
> BIFs and features?
>
> OK, I'm being a bit facetious, but there has to be a
> reason to choose Erlang too. Also, I would suspect
> that most developers want to add more nifty stuff for
> the next model, so things will likely creep back in.
>
> Restructuring the system to get rid of unused features
> may be a Good Thing even so. (By moving more features
> into Erlang, one can omit them more easily.)
>
> > My gut feeling tells me that a ground-up rewrite is
> > necessary:
>
> Uh-oh :-) First, let's see what can be done to the
> existing system. As a simple baseline, I stripped an
> R9C2 installation (x86, slackware):
>
> (I'm not sure how the executables are used, so I list
> them all)
>
> Before strip:
>  4282779 beam
>  4306296 beam.elib
>  4305231 beam.elib.shared
>  4281706 beam.shared
>
> After strip:
>   970192 beam
>   978544 beam.elib
>   985008 beam.elib.shared
>   976656 beam.shared
>
> So there are some easy gains to be made in storage
> space, at least.
>
> At startup, both the stripped and unstripped beam
> processes appear to occupy about ~4.2 MB of memory, of
> which ~1.4 MB is shared. Some flag tweaking may reduce
> that a bit further.
>
> The VM sees 2.8 MB of this: 0.6 MB is used by
> processes, and 2.2 MB shared (1.4 MB bytecode from 70
> modules, the rest atoms, binaries, and ets).
>
> Of course, practical use will size up those areas. One
> real system, when idling after test, has a 7.4 MB VM,
> wherein 1.9 MB is used by processes, bytecode uses 4.0
> MB (~250 loaded modules) and the rest is for ets,
> atoms and binaries. The entire (unstripped) process is
> 13 MB, which I'd say is fairly normal for a realistic
> Erlang node.
>
> Peak memory use may be much higher, of course. First,
> a database may increase the ets size quite a bit.
> Second, an active system will use more (transient)
> space for processes.
>
> Best,
> Thomas
>
>
>
>
> __________________________________
> Yahoo! Mail
> Stay connected, organized, and protected. Take the tour:
> http://tour.mail.yahoo.com/mailtour.html
>
>


Thomas,

I'd like to give an example of what I would use a Micro-Edition for:

Small device, e.g. home ADSL router. This machine would have a small
Linux or NetBSD kernel running, possibly an SSH daemon and a few other
processes. Memory budget = ~8MB. Maybe 12 or 16.
I'd like to envision an Erlang VM which would perform all (or most)
high-level services:
- It would have access to sockets (including RAW ones) and pipes.
- It would be able to open files and read/write. binary<=>eterm would
be useful in any case.
- I would like to be able to easily build and link in port drivers for
controlling special devices.
- I would like to be able to constrain resource usage per application, e.g.:
    - Process priorities.
    - Memory usage constraints (per-process or process group).

Now, how cut-down would the functionality of such a VM and standard library be?
Would a statically-linked one take less than a MB? More? About 500KB, maybe?
How about the runtime usage? Could we write a DHCP server that would
need only 30KB of heap space? A web management interface - 200K?


Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Matthias Lang-2
Alex Arnon writes:

 > I'd like to give an example of what I would use a Micro-Edition for:

 > Small device, e.g. home ADSL router. This machine would have a small
 > Linux or NetBSD kernel running, possibly an SSH daemon and a few other
 > processes. Memory budget = ~8MB. Maybe 12 or 16.

I have a device at home which you could call an "ADSL router". It sits
between my ADSL modem and my PC. It has two ethernet ports, a 50MHz
PPC CPU and 32MByte of DRAM. It runs Erlang R9C to do some port
forwarding, act as an HTTP proxy, an FTP proxy, a dynamic DNS client
and to re-login to ADSL whenever my ISP kicks me out.

Right now, the Erlang VM has RSS = 4556kByte.

Matthias


Reply | Threaded
Open this post in threaded view
|

Distributed Erlang embeded startup problem

Eranga Udesh-5
Hi,

I have created a target system. It's a distributed system, having 2 optional nodes, if one failes
application failover to the other node. If the high priority node comes alive it takes over.

Attached files are,
sys.config - configuration file in one node. The other node's file just have the name of this node
in "sync_nodes_optional"
esme.system - Linux init file

The init file is located at /etc/rc.d/init.d and in linked to /etc/rc.d/rc3.d/S91esme.system

When I ran init files manually, the system starts well. When a node fails, it fall backs and everything
works smoothly.

But when I restart both systems, once they come up, I see both are running the same application.
Looks like it doesn't take the applcation as a distributed application. Is there anything missin in my
sys.config file? That file is located in the releases/1.0 of that release directory.

When I execute the command, nodes() in one node, I can see that it has connected to other node too.

What puzzeling me is, why it runs correctly when I ran manually and why it doesn't in a system
reboot. Is it an environment settins or commnd line parameter problem?

Please help.

Thanks in advance,
- Eranga

--------------This mail sent through OmniBIS.com--------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sys.config
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20050701/3378256c/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: esme.system
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20050701/3378256c/attachment-0001.ksh>

Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Thomas Lindgren-5
In reply to this post by Alex Arnon-3


--- Alex Arnon <alex.arnon> wrote:

> I'd like to envision an Erlang VM which would
> perform all (or most)
> high-level services:
> - It would have access to sockets (including RAW
> ones) and pipes.
> - It would be able to open files and read/write.
> binary<=>eterm would
> be useful in any case.
> - I would like to be able to easily build and link
> in port drivers for
> controlling special devices.
> - I would like to be able to constrain resource
> usage per application, e.g.:
>     - Process priorities.
>     - Memory usage constraints (per-process or
> process group).

At present, there is no support for memory constraints
inside of Erlang. Also, there is no raw socket
support. (Though there seems to be a libpcap driver
somewhere out there.)

> Now, how cut-down would the functionality of such a
> VM and standard library be?

Mildly extended, considering the above; though you
could in principle get rid of some stuff too.

> Would a statically-linked one take less than a MB?
> More? About 500KB, maybe?

Difficult to say, though Matt Lang's experience in
that other mail indicates <5MB in toto for something
reasonable.

>From the process statistics, it looked like the
current emulator was about 1.4 MB + data areas. You
could pare it down in three ways (at least). All of
them will need a bit of non-standard digging in the
code.

1. Get rid of unused Erlang code -- edit stdlib.app
and kernel.app and pray.

2. Get rid of unused BIFs -- edit or remove the C
files and edit the appropriate config tables so that
those primitives are not provided to the compiler.
Pray some more :-)

3. Pulling out deeply integrated functionality. Well,
hack it until it works, I guess.

I'd do them in that order, as needed, basically.

> How about the runtime usage? Could we write a DHCP
> server that would
> need only 30KB of heap space? A web management
> interface - 200K?

A fresh erlang process is normally pretty small --
about 1 KB of "overhead". The process stack is shrunk
and grown automatically as needed. Here is some more
data:

http://erlang.se/doc/doc-5.4/doc/efficiency_guide/advanced.html

A simple protocol FSM doesn't need a lot of data on
top of that. For DHCP, I guess you will also use
timer.erl to keep track of leases and an ets table for
keeping track of assigned addresses. It doesn't sound
too demanding, spacewise.

Considering web servers, there are a couple already
(inets, yaws). Those are fairly full-featured, but
serving a static page, say, still shouldn't be too
costly. I'm not sure about the current space costs,
but my intuition is that they are modest.

There are three costs to consider:
- the extra erlang code for a feature
- the persistent space (e.g., ets tables and server
processes) to provide the service
- the transient space (e.g., the allocation done to
service a single request)

Hmmm ... In the end I guess there is no substitute for
a bit of experimentation :-)

Best,
Thomas



               
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com


Reply | Threaded
Open this post in threaded view
|

Erlang Micro Edition.

Alex Arnon-3
On 7/1/05, Thomas Lindgren <thomasl_erlang> wrote:

[snip]

>
> Hmmm ... In the end I guess there is no substitute for
> a bit of experimentation :-)
>

Indeed :)

Thomas and Matthias - thank you for your replies. I will take a deeper
look at the current VM code. It seems that it most definitely should
be the starting point.

Cheers,
Alex.