| Author |
Message |
|
| Guest |
 Posted: Tue Oct 03, 2006 9:40 am |
 |
|
|
Guest
|
Hello,
I'm trying to find out how Erlang processes work / what they're made
of. I know they don't share their memory with each other (have their
own heaps), in order to communicate do so by message passing that are
serialised data. They run one after another, per cpu/core. The
schedular decides which process should get to go next. They stop
processing when they come to a point where they're waiting for a
message or after they've been processing for a certain amount of time.
All this is handled by the language/runtime system and happens within
user space.
Each process is very lightweight. I'm struggling to find out how
they're lightweight. They're stackless? Is that correct? On the stack,
with things that use them, local variables are stored. What happens to
a process's local variables when it's switched out of control (due to
coming to a point where it's waiting for a message or reached its time
limit)? Each process must have local variables don't they? So what
happens to them? Where do they get stored? If you have a set of local
variables per process then how is each process considered so
lightweight? And if you don't have a set of local variables per process
then how can they operate reasonably -- local variables persisting seem
essential? A set of local variables must get stored per process and if
you have hundreds of thousands of processes that's not so lightweight
is it?
Also how do processes correspond to functions? Is it just one function
per process? Processes and functions are very much tied up with each
other; one to one?
Any info or pointers to things that contain info on this would be much
appreciated.
Thanks, Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| uwiger |
| Posted: Tue Oct 03, 2006 10:29 am |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
Check out the recent thread at Lambda the Ultimate:
"What Makes Erlang Processess Tick?"
http://lambda-the-ultimate.org/node/1742
BR,
Ulf W
> -----Original Message-----
> From: erlang-questions-bounces@erlang.org
> [mailto:erlang-questions-bounces@erlang.org] On Behalf Of Ben Dougall
> Sent: den 3 oktober 2006 11:31
> To: erlang-questions@erlang.org
> Subject: [erlang-questions] how are erlang process lightweight?
>
> Hello,
>
> I'm trying to find out how Erlang processes work / what
> they're made of. I know they don't share their memory with
> each other (have their own heaps), in order to communicate do
> so by message passing that are serialised data. They run one
> after another, per cpu/core. The schedular decides which
> process should get to go next. They stop processing when they
> come to a point where they're waiting for a message or after
> they've been processing for a certain amount of time.
> All this is handled by the language/runtime system and
> happens within user space.
>
> Each process is very lightweight. I'm struggling to find out
> how they're lightweight. They're stackless? Is that correct?
> On the stack, with things that use them, local variables are
> stored. What happens to a process's local variables when it's
> switched out of control (due to coming to a point where it's
> waiting for a message or reached its time limit)? Each
> process must have local variables don't they? So what happens
> to them? Where do they get stored? If you have a set of local
> variables per process then how is each process considered so
> lightweight? And if you don't have a set of local variables
> per process then how can they operate reasonably -- local
> variables persisting seem essential? A set of local variables
> must get stored per process and if you have hundreds of
> thousands of processes that's not so lightweight is it?
>
> Also how do processes correspond to functions? Is it just one
> function per process? Processes and functions are very much
> tied up with each other; one to one?
>
> Any info or pointers to things that contain info on this
> would be much appreciated.
>
> Thanks, Ben.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@erlang.org
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
  
|
| Guest |
| Posted: Tue Oct 03, 2006 11:14 am |
|
|
|
Guest
|
Ben Dougall wrote:
> I'm trying to find out how Erlang processes work / what they're made
> of.
As Ulf said, chech out the discussion at LtU, but here are
some quick answers to fill in the blanks:
> They stop processing when they come to a point where they're waiting
> for a message or after they've been processing for a certain amount
> of time. All this is handled by the language/runtime system and
> happens within user space.
Yes. Process switching is not triggered by real time, but by a counter
which is decremented at (approximately) each function call. (Using
interrupts has too much overhead.)
> Each process is very lightweight. I'm struggling to find out how
> they're lightweight. They're stackless? Is that correct?
No, each process has a stack. But the stack is initially very small
(on the order of 16-32 words, I think), and grows as needed.
> What happens to a process's local variables when it's switched out of
> control (due to coming to a point where it's waiting for a message or
> reached its time limit)? Each process must have local variables don't
> they? So what happens to them? Where do they get stored? If you have
> a set of local variables per process then how is each process
> considered so lightweight?
Of course processes have local variables, and these are stored on the
stack while the process is switched out. How much memory is used (stack
plus heap) per process depends completely on what the process does and
how it was written. Processes which only receive messages and respond
to them quickly before going back to sleep, and which do not need to
keep track of state between messages, might never need to grow their
stacks at all, and might only use heap memory temporarily.
> if you have hundreds of thousands of processes that's not so
> lightweight is it?
Yes it is, compared to threads which typically need at least a few K of
allocated stack regardless of whether it will be used. Thread
implementations have become better in recent years, but Erlang processes
are still lightweight any way you count.
> Also how do processes correspond to functions? Is it just one
> function per process? Processes and functions are very much tied up
> with each other; one to one?
Functions are just program text. Just like several people can read from
the same piece of paper, several processes may run the same code
simultaneously (and usually do). For example, a single function might
implement the main loop of a server process, with 100.000 process
instances running that loop at the same time (and not all of them being
at the same program point).
/Richard
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 11:35 am |
|
|
|
Guest
|
Hello Ulf,
Yes, thanks -- already read it and followed the links, and asked a
previous similar question in that forum
<http://lambda-the-ultimate.org/node/1692> "what are the differences
between erlang process and pthread threads?".
Does the "What Makes Erlang Processess Tick?" thread and any of its
answers and links address what happens to local variables of each
process? The info that I said below in my question on this list was got
from that "What Makes Erlang Processess Tick?" thread. Also this was
useful: <http://www.defmacro.org/ramblings/concurrency.html> "Erlang
Style Concurrency".
This was quite interesting from "Erlang Style Concurrency": "[Erlang
processes are] very cheap to start up and destroy and are very fast to
switch between because under the hood they're simply functions."
So that seems to be the thing, so far as memory footprint goes: threads
have a stack and that stack is, as usual, made up or an indefinite
number of frames -- potentially many/infinite -- grows per new function
call. Whereas Erlang processes are tied very tightly (one to one) to
functions, and a function's memory usage amount to one frame of a
stack. So an Erlang process is limited to a frame of a stack.
Am I on the right track there? It's the memory footprint of an Erlang
process and the memory footprint of a normal thread -- comparison of
the two I'm interested in.
I still can't help feel that, if what I've just said is correct, that
the Erlang process way and the normal thread way are just two different
ways of organising the same thing and amount to the same size of memory
footprint. If you have one thread and call three functions from that
thread then you have a stack with three frames. If you want to do the
same work with Erlang processes then you'd need three Erlang processes
each using up their own frame -- so three frames. Much the same memory
footprint, just organised/named differently. I suppose you organise
your Erlang funtions/processes accordingly. If those three function
calls are often done one after the other, then don't have them as
separate functions -- have them as one function.
Any corrections of any of that would be appreciated.
Thanks, Ben.
On Tuesday, October 3, 2006, at 11:23 am, Ulf Wiger (TN/EAB) wrote:
>
> Check out the recent thread at Lambda the Ultimate:
>
> "What Makes Erlang Processess Tick?"
>
> http://lambda-the-ultimate.org/node/1742
>
> BR,
> Ulf W
>
>> -----Original Message-----
>> From: erlang-questions-bounces@erlang.org
>> [mailto:erlang-questions-bounces@erlang.org] On Behalf Of Ben Dougall
>> Sent: den 3 oktober 2006 11:31
>> To: erlang-questions@erlang.org
>> Subject: [erlang-questions] how are erlang process lightweight?
>>
>> Hello,
>>
>> I'm trying to find out how Erlang processes work / what
>> they're made of. I know they don't share their memory with
>> each other (have their own heaps), in order to communicate do
>> so by message passing that are serialised data. They run one
>> after another, per cpu/core. The schedular decides which
>> process should get to go next. They stop processing when they
>> come to a point where they're waiting for a message or after
>> they've been processing for a certain amount of time.
>> All this is handled by the language/runtime system and
>> happens within user space.
>>
>> Each process is very lightweight. I'm struggling to find out
>> how they're lightweight. They're stackless? Is that correct?
>> On the stack, with things that use them, local variables are
>> stored. What happens to a process's local variables when it's
>> switched out of control (due to coming to a point where it's
>> waiting for a message or reached its time limit)? Each
>> process must have local variables don't they? So what happens
>> to them? Where do they get stored? If you have a set of local
>> variables per process then how is each process considered so
>> lightweight? And if you don't have a set of local variables
>> per process then how can they operate reasonably -- local
>> variables persisting seem essential? A set of local variables
>> must get stored per process and if you have hundreds of
>> thousands of processes that's not so lightweight is it?
>>
>> Also how do processes correspond to functions? Is it just one
>> function per process? Processes and functions are very much
>> tied up with each other; one to one?
>>
>> Any info or pointers to things that contain info on this
>> would be much appreciated.
>>
>> Thanks, Ben.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@erlang.org
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 11:45 am |
|
|
|
Guest
|
Richard,
On Tuesday, October 3, 2006, at 12:03 pm, Richard Carlsson wrote:
> No, each process has a stack. But the stack is initially very small
> (on the order of 16-32 words, I think), and grows as needed.
Thanks very much for the reply. Having only skimmed it I now see that
my response to Ulf's reply is full of rubbish. Will read/digest your
reply fully now.
Thanks, Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 12:04 pm |
|
|
|
Guest
|
On 3 Oct 2006, at 12:25, Ben Dougall wrote:
>
> So that seems to be the thing, so far as memory footprint goes:
> threads
> have a stack and that stack is, as usual, made up or an indefinite
> number of frames -- potentially many/infinite -- grows per new
> function
> call. Whereas Erlang processes are tied very tightly (one to one) to
> functions, and a function's memory usage amount to one frame of a
> stack. So an Erlang process is limited to a frame of a stack.
This is where you are going wrong. An erlang function is only related
to a process in the sense that processes evaluate functions. Each
process has its own stack that can grow/shrink as much as it needs.
It is not nearly as different to pthreads as you describe. The
efficiency gains of Erlang are *only* those of being able to optimise
process switching and do custom memory management. Erlang processes
are actually more akin to UNIX processes as they do not share state.
Think of them as exactly like UNIX processes with much less overhead
and much nicer message passing.
Having the flexibility to implement language specific memory
management and process switching with custom message passing are big
wins until UNIX implements the same things directly. I suspect that
is not likely to happen soon.
Sean
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 12:54 pm |
|
|
|
Guest
|
On Tuesday, October 3, 2006, at 12:58 pm, Sean Hinde wrote:
> On 3 Oct 2006, at 12:25, Ben Dougall wrote:
>
>> So that seems to be the thing, so far as memory footprint goes:
>> threads
>> have a stack and that stack is, as usual, made up or an indefinite
>> number of frames -- potentially many/infinite -- grows per new
>> function
>> call. Whereas Erlang processes are tied very tightly (one to one) to
>> functions, and a function's memory usage amount to one frame of a
>> stack. So an Erlang process is limited to a frame of a stack.
>
> This is where you are going wrong. An erlang function is only related
> to a process in the sense that processes evaluate functions. Each
> process has its own stack that can grow/shrink as much as it needs.
>
> It is not nearly as different to pthreads as you describe. The
> efficiency gains of Erlang are *only* those of being able to optimise
> process switching and do custom memory management.
I've just coming to that conclusion from Richard's reply, as from what
he was saying there is not much difference between thread and Erlang
process memory footprints.
> Erlang processes are actually more akin to UNIX processes as they do
> not share state. Think of them as exactly like UNIX processes with
> much less overhead and much nicer message passing.
Yes I understand that. It was how they've ended up so light is what I
was interested in. And I now realise that it's the fact that it's all
(the switching etc.) handled in user space by the Erlang system where
the efficiency/saving comes from. So it's not so much a saving of
memory space (although I guess there is at least a bit of memory space
saving) but a saving in the amount of memory-shifting-round that the
machine needs to do. Less memory-shifting-round is necessary with E.P.s
than threads.
> Having the flexibility to implement language specific memory
> management and process switching with custom message passing are big
> wins until UNIX implements the same things directly. I suspect that is
> not likely to happen soon.
Right, thanks very much,
Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 12:57 pm |
|
|
|
Guest
|
On Tuesday, October 3, 2006, at 12:03 pm, Richard Carlsson wrote:
>> Each process is very lightweight. I'm struggling to find out how
>> they're lightweight. They're stackless? Is that correct?
>
> No, each process has a stack. But the stack is initially very small
> (on the order of 16-32 words, I think), and grows as needed.
>
>> What happens to a process's local variables when it's switched out of
>> control (due to coming to a point where it's waiting for a message or
>> reached its time limit)? Each process must have local variables don't
>> they? So what happens to them? Where do they get stored? If you have
>> a set of local variables per process then how is each process
>> considered so lightweight?
>
> Of course processes have local variables, and these are stored on the
> stack while the process is switched out. How much memory is used (stack
> plus heap) per process depends completely on what the process does and
> how it was written. Processes which only receive messages and respond
> to them quickly before going back to sleep, and which do not need to
> keep track of state between messages, might never need to grow their
> stacks at all, and might only use heap memory temporarily.
Sounds so similar to a thread? What's the main difference in terms of
memory usage? Just packed more efficiently?
>> if you have hundreds of thousands of processes that's not so
>> lightweight is it?
>
> Yes it is, compared to threads which typically need at least a few K of
> allocated stack regardless of whether it will be used. Thread
> implementations have become better in recent years, but Erlang
> processes
> are still lightweight any way you count.
So now I'm thinking the only difference between a thread and an Erlang
process, so far as memory footprint goes, is the packing of each frame
in the stack, and possibly the loss of some not so essential variables
of the frame format?
I'm still puzzled by the fact that there is considered such a
difference in resource consumption, especially in the amount of memory
used, between a thread and an Erlang process.
Maybe it's not so much the memory footprint that is so lightweight with
Erlang processes compared with threads, but the savings that having all
this handled in user space gives? So Erlang processes don't give so
much of a memory space saving, but a data-shifting-round saving?
Thanks, Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| gordon guthrie |
| Posted: Tue Oct 03, 2006 1:20 pm |
|
|
|
User
Joined: 02 Sep 2006
Posts: 17
|
Ben
> So to sum up, from an implementation of Erlang processes point of view,
> Erlang processes are _very_ similar to threads apart from:
Well on pre-R11 Erlang bear in mind that they all run inside a single
operating system thread...
> - each process/thread has it's own memory space which is never shared
> with others, and they communicate via message passing.
They communicate by message passing ONLY which means there is no overhead
for suspended processes (ie processes in receive-> ) as they can only be
'awakened' by another process (or timed out by the runtime)
> - the mechanics of the process/thread is not handled by the OS outside
> user space, but by the Erlang runtime system in user space -- inside
> the programme's process(that use of "process" being the normal unix
> one).
Yes, but the programme's THREAD as above...
> And the savings of doing all the switching etc. in user space is a main
> reason Erlang processes can be so lightweight. That, and also the loss
> of the need for locks etc.
Gordon
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 1:24 pm |
|
|
|
Guest
|
So to sum up, from an implementation of Erlang processes point of view,
Erlang processes are _very_ similar to threads apart from:
- each process/thread has it's own memory space which is never shared
with others, and they communicate via message passing.
- the mechanics of the process/thread is not handled by the OS outside
user space, but by the Erlang runtime system in user space -- inside
the programme's process(that use of "process" being the normal unix
one).
And the savings of doing all the switching etc. in user space is a main
reason Erlang processes can be so lightweight. That, and also the loss
of the need for locks etc.
Thanks, Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 03, 2006 5:20 pm |
|
|
|
Guest
|
On 10/3/06, Ben Dougall <bend@freenet.co.uk> wrote:
>
> On Tuesday, October 3, 2006, at 12:58 pm, Sean Hinde wrote:
>
> > On 3 Oct 2006, at 12:25, Ben Dougall wrote:
> >
> >> So that seems to be the thing, so far as memory footprint goes:
> >> threads
> >> have a stack and that stack is, as usual, made up or an indefinite
> >> number of frames -- potentially many/infinite -- grows per new
> >> function
> >> call. Whereas Erlang processes are tied very tightly (one to one) to
> >> functions, and a function's memory usage amount to one frame of a
> >> stack. So an Erlang process is limited to a frame of a stack.
> >
> > This is where you are going wrong. An erlang function is only related
> > to a process in the sense that processes evaluate functions. Each
> > process has its own stack that can grow/shrink as much as it needs.
> >
> > It is not nearly as different to pthreads as you describe. The
> > efficiency gains of Erlang are *only* those of being able to optimise
> > process switching and do custom memory management.
>
> I've just coming to that conclusion from Richard's reply, as from what
> he was saying there is not much difference between thread and Erlang
> process memory footprints.
>
> > Erlang processes are actually more akin to UNIX processes as they do
> > not share state. Think of them as exactly like UNIX processes with
> > much less overhead and much nicer message passing.
>
> Yes I understand that. It was how they've ended up so light is what I
> was interested in. And I now realise that it's the fact that it's all
> (the switching etc.) handled in user space by the Erlang system where
> the efficiency/saving comes from. So it's not so much a saving of
> memory space (although I guess there is at least a bit of memory space
> saving) but a saving in the amount of memory-shifting-round that the
> machine needs to do. Less memory-shifting-round is necessary with E.P.s
> than threads.
The way switching is done and the contract that Erlang processes have
with the scheduler are different than with pthreads. The fixed
overhead Erlang process overhead is less than what it takes just to
save the state of all the CPU registers on some platforms (if it is on
the order of 16-32 words)! Also, the stack of a pthread has to be
preallocated and of a fixed size, and there's other bookkeeping that
pthreads do that Erlang processes do not have to.
So, switching is faster and processes are cheaper. If pthreads didn't
suck, we wouldn't be here 
-bob
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Oct 04, 2006 12:24 am |
|
|
|
Guest
|
Ben Dougall <bend@freenet.co.uk> is still confused.
And THIS is confusing him:
This was quite interesting from "Erlang Style Concurrency": "[Erlang
processes are] very cheap to start up and destroy and are very fast to
switch between because under the hood they're simply functions."
Erlang processes are *NOT* functions.
Erlang process : Erlang function
::
Posix or Windows thread : C function
The principles are exactly the same.
However,
(1) Posix and Windows thread implementations are SEVERELY limited by
the fact that they are designed to support statically typed
languages with no garbage collector information which can create
pointers to objects in the stacks and save those pointers anywhere.
That means that Posix and Windows thread implementations
CANNOT MOVE OR RESIZE STACKS, because they don't know where the
pointers are and could not fix them. (Note that static typing
isn't the main problem; the Burroughs B6700 operating system
could and did dynamically move and resize stacks with no worries
at all, because the hardware required pointers to be tagged, so
the operating system could be absolutely sure of finding and
fixing all of them. I was stunned back in 1979 to discover how
primitive other computers were.)
Because Posix and Windows thread implementations cannot move or
resize stacks,
(A) you the programmer have to say how big they will be
(B) to get this right it is absolutely essential that the C
compiler tell you how big stack frames are (but it never does)
and how deep the stack can get (but it never does that either).
So you have to over-estimate with a rather large safety factor.
(C) heaven help you if you guess wrong, because the hardware,
operating system, and run-time library will cheerfully see
your program crash and burn.
So you REALLY have to over-estimate with a very large safety
factor.
Erlang does keep around enough information (for garbage collection)
so that it CAN find and fix all the necessary pointers whenever a
stack has to be moved or resized. So
(D) you never have to make guesses, and
(E) stacks can start very small => lightweight in memory use.
(2) Posix and Windows thread implementations need the help of the
operating system for several key operations. Context switches
are known to be very very bad for caches; a paper from DEC WRL
showed that in that system a context switch could foul up your
cache to the point where it took many thousands of instructions
to recover, and of course by that time you have another context
switch.
The Erlang process implementation is user-level, sometimes
called "green threads". No kernel memory is needed for an
Erlang process. Erlang process switching does mean that the
stack data for the process switched out of is gradually lost
from the cache, BUT what goes into the instruction cache is the
emulator, and that stays cached. There are no traps out to the
operating system and back again (which can be quite slow; deep
recursion on SPARCs used to be very painful because of that).
So Erlang process switching is cheap => lightweight in time.
(3) You might imagine that Java solves problems (1) and (2), and
indeed it does. But Java is an imperative programming language;
computation proceeds by smashing the state of mutable objects.
If two or more processes try to access the same mutable object
they can get terribly confused. So every access to an object
that *might* be shared with another process has to be 'synchronised'
(or is it 'synchronized'? I wish they had chosen a word that
everyone agreed how to spell). This is called "locking". Much of
the locking is done implicitly when you call synchronised methods,
but that doesn't affect the point that there has to be a heck of a
lot of it.
Java implementors have put unbelievable amounts of work into trying
to make locking fast. They still can't make it as fast as not locking.
Although Java had Vector, it acquired ArrayList. What's the
difference? Vector expects to be shared, and does oodles of locking;
ArrayList expects not to be shared, and does no locking. It's faster.
Although Java had StringBuffer, it acquired StringBuilder? What's
the difference? Just that StringBuffer expects to be shared, and
does oodles of locking; StringBuilder has exactly the same interface
but expects not to be shared, and does no locking. It's faster.
In Erlang, there are no mutable data structures[*], and in any case,
no process can access another process's data in any way, so there is
no need for locking in routine calculations. Obviously, loading and
unloading modules requires locking, and data base access had better
involve some kind of locking, but routine calculations marching over
data structures and building results DON'T need any locking.
[*] I lied: there is something called "the process dictionary".
But that is not and cannot be shared with any other process, so you
STILL don't need locking.
Result: Erlang needs little or no locking for routine calculations
=> lightweight in time.
Even message sending and receiving could, I believe, be done
without locking using lock-free queues. I have no idea whether it
would be worth while.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Oct 04, 2006 9:53 pm |
|
|
|
Guest
|
Hello Richard,
> Ben Dougall <bend@freenet.co.uk> is still confused.
>
> And THIS is confusing him:
> This was quite interesting from "Erlang Style Concurrency": "[Erlang
> processes are] very cheap to start up and destroy and are very fast to
> switch between because under the hood they're simply functions."
>
> Erlang processes are *NOT* functions.
I did think Erlang processes and functions might be the same (have a
one to one relationship) to start with mainly because of that above
statement but not after Richard Carlsson's reply. After I'd read his
reply I fully understood that this was not the case so I'm not still
confused on that issue at all now. (more below).
> Erlang process : Erlang function
> ::
> Posix or Windows thread : C function
>
> The principles are exactly the same.
> However,
>
> (1) Posix and Windows thread implementations are SEVERELY limited
> by
> the fact that they are designed to support statically typed
> languages with no garbage collector information which can
> create
> pointers to objects in the stacks and save those pointers anywhere.
>
> That means that Posix and Windows thread implementations
> CANNOT MOVE OR RESIZE STACKS, because they don't know where the
> pointers are and could not fix them. (Note that static typing
> isn't the main problem; the Burroughs B6700 operating system
> could and did dynamically move and resize stacks with no worries
> at all, because the hardware required pointers to be tagged, so
> the operating system could be absolutely sure of finding and
> fixing all of them. I was stunned back in 1979 to discover how
> primitive other computers were.)
>
> Because Posix and Windows thread implementations cannot move or
> resize stacks,
> (A) you the programmer have to say how big they will be
> (B) to get this right it is absolutely essential that the C
> compiler tell you how big stack frames are (but it never does)
> and how deep the stack can get (but it never does that either).
> So you have to over-estimate with a rather large safety factor.
> (C) heaven help you if you guess wrong, because the hardware,
> operating system, and run-time library will cheerfully see
> your program crash and burn.
> So you REALLY have to over-estimate with a very large safety
> factor.
>
> Erlang does keep around enough information (for garbage collection)
> so that it CAN find and fix all the necessary pointers whenever a
> stack has to be moved or resized. So
> (D) you never have to make guesses, and
> (E) stacks can start very small => lightweight in memory use.
>
> (2) Posix and Windows thread implementations need the help of the
> operating system for several key operations. Context switches
> are known to be very very bad for caches; a paper from DEC WRL
> showed that in that system a context switch could foul up your
> cache to the point where it took many thousands of instructions
> to recover, and of course by that time you have another context
> switch.
>
> The Erlang process implementation is user-level, sometimes
> called "green threads". No kernel memory is needed for an
> Erlang process. Erlang process switching does mean that the
> stack data for the process switched out of is gradually lost
> from the cache, BUT what goes into the instruction cache is the
> emulator, and that stays cached. There are no traps out to the
> operating system and back again (which can be quite slow; deep
> recursion on SPARCs used to be very painful because of that).
> So Erlang process switching is cheap => lightweight in time.
>
> (3) You might imagine that Java solves problems (1) and (2), and
> indeed it does. But Java is an imperative programming language;
> computation proceeds by smashing the state of mutable objects.
> If two or more processes try to access the same mutable object
> they can get terribly confused. So every access to an object
> that *might* be shared with another process has to be 'synchronised'
> (or is it 'synchronized'? I wish they had chosen a word that
> everyone agreed how to spell). This is called "locking". Much of
> the locking is done implicitly when you call synchronised methods,
> but that doesn't affect the point that there has to be a heck of a
> lot of it.
>
> Java implementors have put unbelievable amounts of work into trying
> to make locking fast. They still can't make it as fast as not
> locking.
> Although Java had Vector, it acquired ArrayList. What's the
> difference? Vector expects to be shared, and does oodles of locking;
> ArrayList expects not to be shared, and does no locking. It's faster.
> Although Java had StringBuffer, it acquired StringBuilder? What's
> the difference? Just that StringBuffer expects to be shared, and
> does oodles of locking; StringBuilder has exactly the same interface
> but expects not to be shared, and does no locking. It's faster.
>
> In Erlang, there are no mutable data structures[*], and in any case,
> no process can access another process's data in any way, so there is
> no need for locking in routine calculations. Obviously, loading and
> unloading modules requires locking, and data base access had better
> involve some kind of locking, but routine calculations marching over
> data structures and building results DON'T need any locking.
> [*] I lied: there is something called "the process dictionary".
> But that is not and cannot be shared with any other process, so you
> STILL don't need locking.
>
> Result: Erlang needs little or no locking for routine calculations
> => lightweight in time.
>
> Even message sending and receiving could, I believe, be done
> without locking using lock-free queues. I have no idea whether it
> would be worth while.
Right, comparing normal threads to Erlang processes, I was starting to
think there wasn't so much of a memory space saving so far as E.P.s go
-- a bit but not much. But from from what you're saying there is quite
a bit of saving because of the inflexible and large nature of thread's
stacks. I already appreciated that time savings come from no shared
memory so no locks, and scheduling and switching done in user space so
much less work required by the machine in shifting stuff round when
switching but had missed the savings of memory part.
Thanks for all the info. Very useful. Haven't soaked it up fully yet --
will do.
Thanks, Ben.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| cheung |
| Posted: Fri Feb 17, 2012 6:58 am |
|
|
|
Guest
|
| Santorum, Nike Air Max 90 53, has sold Air Max UK himself in the Republican primaries Nike Air Max 95 as both a Washington outsider and a social conservative, stressing his family's coal-mining background and his appeal to religious Air Max and Air Max 95 working-class voters. His personal finances tell a different story, detailing the trajectory of a politician who grew more prosperous in the Senate and Cheap Air Max became a millionaire afterward, at times capitalizing on his Beltway connections.His 2010 tax returns show he made more than Nike Air Max $550,000 in media Air Max 90 and consulting fees - paid to him through a corporation he set up, Excelsior LLC. The previous year, Santorum made more than $820,000 in fees, also paid through the same firm.But his newfound affluence reflects his ties to Washington's business and lobbying circles during his 12 years in the Senate and his transition into their world after Nike Air Max 95 Cheap he left office.The returns Cheap Nike Air Max 90 for 2007-10 show the income for Santorum and his wife, Karen, has grown since he left the Senate after being defeated in 2006. |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
