Erlang basic doubts about String, message passing and context switching overhead

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang basic doubts about String, message passing and context switching overhead

Bhag Chandra
Hello,

I have been coding in Erlang for 2 years.  A wonderful language but not very big community, so I cant discuss my questions with programmers around me (Java, Python guys). I found out about this list today.

I have some fundamental doubts about the Erlang. It would be great if someone can help me clarify them.


1) "Strings in Erlang are internally treated as a list of integers of each character's ASCII values, this representation of string makes operations faster. For example, string concatenation is constant time operation in Erlang."  Can someone explain why?

2) "It makes sense to use Erlang only where system's availability is very high".  Is it not a very general requirement of most of the systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are high availability systems, so we can use Erlang in all of them?

3) "Every message which is sent to a process, goes to the mailbox of that process. When process is free, it consumes that message from mailbox". So how exactly does process ask from the mailbox for that message? Is there a mechanism in a process' memory which keeps polling its mailbox. I basically want to understand how message is sent from mailbox to my code in process.

4) We say that a message is passed from process A to process B by simply using a bang (!) character, but what happens behind the scenes to pass this message? Do both processes establish a tcp connection first and then pass message or what?

5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr. Armstrong is talking about the difference between the context switching overhead between OS threads and Erlang processes. He says, thread context switching is of order 700 words but Erlang process context switching is ... ?
I cant understand what he said, if someone could tell.


P.S. Please excuse for any grammatical errors, English is not my first language.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Hugo Mills-2
On Wed, Jan 11, 2017 at 12:28:56AM +0530, Bhag Chandra wrote:
> I have been coding in Erlang for 2 years.  A wonderful language but not
> very big community, so I cant discuss my questions with programmers around
> me (Java, Python guys). I found out about this list today.
>
> I have some fundamental doubts about the Erlang. It would be great if
> someone can help me clarify them.

   I can answer some of them.

> 1) "Strings in Erlang are internally treated as a list of integers of each
> character's ASCII values, this representation of string makes operations
> faster. For example, string concatenation is constant time operation in
> Erlang."  Can someone explain why?

   That's not right. String concatenation is O(n), not O(1). When
constructing the concatenation A ++ B, the list A must be traversed in
order to place each character at the head of the result list.

> 2) "It makes sense to use Erlang only where system's availability is very
> high".  Is it not a very general requirement of most of the systems?
> Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are
> high availability systems, so we can use Erlang in all of them?
>
> 3) "Every message which is sent to a process, goes to the mailbox of that
> process. When process is free, it consumes that message from mailbox". So
> how exactly does process ask from the mailbox for that message? Is there a
> mechanism in a process' memory which keeps polling its mailbox. I basically
> want to understand how message is sent from mailbox to my code in process.
   This is the "receive" expression. It runs a set of matches against
the mailbox and returns the first matching message.

> 4) We say that a message is passed from process A to process B by simply
> using a bang (!) character, but what happens behind the scenes to pass this
> message? Do both processes establish a tcp connection first and then pass
> message or what?

   Erlang processes aren't the same thing as OS processes. Typically,
you'll have one VM (a node), which will run anywhere between dozens
and millions of erlang processes. This all takes place under one OS
process -- the VM. Communications between erlang processes are handled
internally to the VM.

   If you're doing distributed erlang, you'll have several nodes
(possibly, but not always, on the different machines). These nodes
connect to each other with permanent TCP connections, over which they
talk the erlang distribution protocol.

   Hugo.

--
Hugo Mills             | Great films about cricket: Batsman Begins
hugo@... carfax.org.uk | starring Christian Bail
http://carfax.org.uk/  |
PGP: E2AB1DE4          |

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Kenneth Lakin
On 01/10/2017 12:03 PM, Hugo Mills wrote:
>    This is the "receive" expression. It runs a set of matches against
> the mailbox and returns the first matching message.

I think of receive as being similar to select(2). You have a data source
you're interested in pulling data from (your mailbox), and you can
choose to either wait up to a certain amount of time for new data
(receive ... after T ...) or you can block your process until new data
appears. Of course -as you mention- receive lets you pattern match on
messages, so you aren't forced to process messages that are not of interest.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Karolis Petrauskas-2
In reply to this post by Hugo Mills-2
Hi,

On Tue, Jan 10, 2017 at 10:03 PM, Hugo Mills <[hidden email]> wrote:

> On Wed, Jan 11, 2017 at 12:28:56AM +0530, Bhag Chandra wrote:
>> I have been coding in Erlang for 2 years.  A wonderful language but not
>> very big community, so I cant discuss my questions with programmers around
>> me (Java, Python guys). I found out about this list today.
>>
>> I have some fundamental doubts about the Erlang. It would be great if
>> someone can help me clarify them.
>
>    I can answer some of them.
>
>> 1) "Strings in Erlang are internally treated as a list of integers of each
>> character's ASCII values, this representation of string makes operations
>> faster. For example, string concatenation is constant time operation in
>> Erlang."  Can someone explain why?
>
>    That's not right. String concatenation is O(n), not O(1). When
> constructing the concatenation A ++ B, the list A must be traversed in
> order to place each character at the head of the result list.

You can have constant time concatenation if you can consider your
strings as iolist() (which you can on most IO functions). Example:

A = "hello", B = "world", C = [A , " ", C].
io:format("~s", [C]). % This will print "hello world"

>
>> 2) "It makes sense to use Erlang only where system's availability is very
>> high".  Is it not a very general requirement of most of the systems?
>> Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are
>> high availability systems, so we can use Erlang in all of them?

For me its usually much easier to develop a system in Erlang, that
other language, even if it has no high availability requirements.
Despite my 12 years experience in Java.

>> 3) "Every message which is sent to a process, goes to the mailbox of that
>> process. When process is free, it consumes that message from mailbox". So
>> how exactly does process ask from the mailbox for that message? Is there a
>> mechanism in a process' memory which keeps polling its mailbox. I basically
>> want to understand how message is sent from mailbox to my code in process.
>
>    This is the "receive" expression. It runs a set of matches against
> the mailbox and returns the first matching message.
>
>> 4) We say that a message is passed from process A to process B by simply
>> using a bang (!) character, but what happens behind the scenes to pass this
>> message? Do both processes establish a tcp connection first and then pass
>> message or what?
>
>    Erlang processes aren't the same thing as OS processes. Typically,
> you'll have one VM (a node), which will run anywhere between dozens
> and millions of erlang processes. This all takes place under one OS
> process -- the VM. Communications between erlang processes are handled
> internally to the VM.
>
>    If you're doing distributed erlang, you'll have several nodes
> (possibly, but not always, on the different machines). These nodes
> connect to each other with permanent TCP connections, over which they
> talk the erlang distribution protocol.
>
>    Hugo.
>
> --
> Hugo Mills             | Great films about cricket: Batsman Begins
> hugo@... carfax.org.uk | starring Christian Bail
> http://carfax.org.uk/  |
> PGP: E2AB1DE4          |
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

Karolis
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Bob Ippolito
In reply to this post by Bhag Chandra

On Tue, Jan 10, 2017 at 10:58 AM, Bhag Chandra <[hidden email]> wrote:
Hello,

I have been coding in Erlang for 2 years.  A wonderful language but not very big community, so I cant discuss my questions with programmers around me (Java, Python guys). I found out about this list today.

I have some fundamental doubts about the Erlang. It would be great if someone can help me clarify them.


1) "Strings in Erlang are internally treated as a list of integers of each character's ASCII values, this representation of string makes operations faster. For example, string concatenation is constant time operation in Erlang."  Can someone explain why?


The description of a string's internal representation is correct, but concatenation is O(n). Most people end up using binaries of utf8 encoded text instead of strings (lower constant factors), and iolists to concatenate data for output (which is constant time, since you're just a rose tree of data to be traversed later).
 
2) "It makes sense to use Erlang only where system's availability is very high".  Is it not a very general requirement of most of the systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are high availability systems, so we can use Erlang in all of them?

You can use Erlang any time, but high availability in distributed systems is where Erlang is a better fit than many other options. Whatsapp in particular does use Erlang. The reasons not to use Erlang in these situations are generally related to familiarity and momentum.
 
3) "Every message which is sent to a process, goes to the mailbox of that process. When process is free, it consumes that message from mailbox". So how exactly does process ask from the mailbox for that message? Is there a mechanism in a process' memory which keeps polling its mailbox. I basically want to understand how message is sent from mailbox to my code in process.

4) We say that a message is passed from process A to process B by simply using a bang (!) character, but what happens behind the scenes to pass this message? Do both processes establish a tcp connection first and then pass message or what?

There's plenty written on these topics available in this list archive and various places online. I'd start by searching for "erlang scheduler" and then scan for the bits that talk about messages and mailboxes. TCP connections are only involved when sending messages between separate notes in distributed erlang, local messages are sent and received by manipulating local data structures.
 
5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr. Armstrong is talking about the difference between the context switching overhead between OS threads and Erlang processes. He says, thread context switching is of order 700 words but Erlang process context switching is ... ?
I cant understand what he said, if someone could tell.

Words is a measure of memory, an Erlang process (by default) has an overhead of 309 words according to the efficiency guide. http://erlang.org/doc/efficiency_guide/processes.html
 
-bob


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Richard A. O'Keefe-2
In reply to this post by Bhag Chandra


On 11/01/17 7:58 AM, Bhag Chandra wrote:
> 1) "Strings in Erlang are internally treated as a list of integers of
> each character's ASCII values, this representation of string makes
> operations faster. For example, string concatenation is constant time
> operation in Erlang."  Can someone explain why?

Pretty much all of this is somewhere between misleading and confusing.
Mind you, pretty much everything about strings in general is
somewhere between confusing and misguided, whatever the programming
language, especially since the introduction of Unicode.

The closest thing to the truth is to say that Erlang has no native
string datatype whatsoever.  Instead, there are several general purpose
data types that are pressed into service to fake it.

(1) An atom is a unique string.  There's more to say about them,
but the general rule is DON'T use them for strings.

(2) A list of character codes is stringy.  Once upon a time character
codes were 8-bit quantities, so taking two computer words per character
was sneered at.  Unicode has a 21-bit character set these days.  (Not
only that, it's now racist and sexist, so that you can distinguish
between pink/yellow male/female astronaut, I kid you not.  Why do we
need a character "man in business suit levitating"?)  The astral planes
are increasingly being populated, "Version 9.0 adds exactly 7,500
characters, for a total of 128,172 characters."

Let X = "1....m" and Y = "1...n".
Then X ++ Y concatenates them in O(m) time.
NOT O(1).

(3) For many purposes, a *tree* of numbers and pairs can be used to
hold text.  It is *this* that allows O(1) concatenation:
[X|Y] *isn't* the string "1...m1...n" but can in certain contexts
*represent* it.  You can, for example, build up a text of total
size S in O(S) time and then flatten it (or write it or transmit it)
in O(S) time.

Look up the 'iolist()' type in Erlang documentation.

(4) The 'binary' type was originally a byte string and is now a
bit string.  A byte sequence can of course represent a string,
with the encoding of the text being provided by context.  It
used to be common to use Latin 1, it's now common to use UTF8.
There is library code to help with this, but frankly, Unicode
is so appallingly complex that there will probably never be
enough library support (in any language).

Concatenating byte strings of length m and n costs O(m+n)>

(5) A tree of numbers and pairs could also contain binaries.

The important thing about strings is that they are good at
accepting data you don't care to inspect further, storing it,
and giving it back later, and LOUSY at almost anything else,
in EVERY programming language.

One of the ways that they are lousy is that thanks to Unicode's
rules, there is *structure* in strings (which were historically
unstructured), so that you can have a well formed string of
2 characters, split it into two 1-character strings, and find
that at least one of those strings is no longer legal.
(Emoji flags, for example.)


>
> 2) "It makes sense to use Erlang only where system's availability is
> very high".  Is it not a very general requirement of most of the
> systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc
> they all are high availability systems, so we can use Erlang in all of them?

I do not think many people in this mailing list would say
"it makes sense to use Erlang ONLY where availability [must be] high."

People use Erlang (and other languages running on the Erlang VM,
such as LFE and Elixir) for all sorts of things.  Yes, Erlang is
not as fast as other languages.

Let's have some perspective on that, though.
Just today I measured four programs to solve the same problem,
using the same structure, written in four languages.
C          0.04 sec    -- has types
Smalltalk  0.25 sec    -- lacks them
Java       0.65 sec    -- has types
Python     2.98 sec    -- lacks them.
Have figures like that ever stopped anyone using Python?
Have they even encouraged people to switch to Smalltalk?

People use a programming language when it lets them get
the job at hand done to an adequate standard.
These days this is as much about infrastructure such as
profiling, test coverage analysis, test frameworks,
documentation tools, libraries, interface support (JSON,
XML, ASN.1, Protobufs, whatever) as it is about the
language as such.

I find that it makes sense to use Erlang whenever concurrency
is important/useful, because it's so much easier to get
concurrent programs right than in Java or C11 or pretty much
anything else (although Ada comes close).  There are of course
plenty of libraries for other languages that claim to add
Erlang-style abilities to those languages; what they don't
mention is that you cannot remove dangers by adding libraries.
For example, gets() has been deprecated in C; the OpenBSD
linker tells you off if you use it.  There are safer alternatives.
But nothing can stop you writing your own version of gets(),
and the OpenBSD linker has no idea that mygets() is just as
dangerous as gets() ever was.

> 3) "Every message which is sent to a process, goes to the mailbox of
> that process. When process is free, it consumes that message from
> mailbox". So how exactly does process ask from the mailbox for that
> message? Is there a mechanism in a process' memory which keeps polling
> its mailbox. I basically want to understand how message is sent from
> mailbox to my code in process.

"When process is free" should presumably be
"When that process is RUNNING and FEELS LIKE checking its mailbox,
  that message MAY BE consumed if it is one the process WANTS to
  consume."

A process reads from its mailbox using the 'receive' construction,
described in for example Learn You Some Erlang For Great Good
(http://learnyousomeerlang.com) which I recommend.  This happens
when the code decides it is time to try to receive a message.

If you know about message passing in UNIX,
Pid ! Msg       is like msgsnd(    Queue, Msg, Msg_Size, Flags)
                      or mq_send(   Queue, Msg, Msg_Size, Prio)
receive ... end is like msgrcv(    Queue, Msg, Msg_Size, Type, Flags)
                      or mq_receive(Queue, Msg, Msg_Size, &Prio)

That is, sending happens when there is something EXPLICIT in the
code to make it happen, and receiving happens when there is
something EXPLICIT in the code to make it happen, and there is
buffering in between so things don't have to be simultaneous.

> 4) We say that a message is passed from process A to process B by simply
> using a bang (!) character, but what happens behind the scenes to pass
> this message? Do both processes establish a tcp connection first and
> then pass message or what?

First of, we have Erlang "nodes" that are Unix or Windows "processes",
and inside them we have Erlang "processes" that are like Unix or Windows
"threads" except much cheaper; the word "fibres" is sometimes used to
describe similar things in those environments.

Erlang processes inside nodes on different machines may well use
TCP connections automatically set up between the nodes.  Or they
could use something else.  They could in principle use Infiniband
or carrier pigeons.

Erlang processes inside different nodes on the same machine
could use any IPC facility provided by the host OS, such as
System V message queues, POSIX message queues, pipes, UNIX sockets,
...

Erlang processes inside the same node will use shared memory,
which might or might not involve copying, depending on the Erlang
version.  Whatever happens, it's likely to be cheaper than TCP.

> 5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr.
> Armstrong is talking about the difference between the context switching
> overhead between OS threads and Erlang processes. He says, thread
> context switching is of order 700 words but Erlang process context
> switching is ... ?

He said that OS thread switching MOVES about 700 words,
while Erlang process switching involves THREE REGISTERS.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Alex S.
Not to start a holy war, but Unicode is not complex, it just has a lot of tables. And pretty much any modern language has immensely better Unicode support built in than Erlang.
Thankfully there's ux.

About processes and mailboxes. Every process has its share of scheduler's memory, which is used for mailbox, stack and heap. Send operation simply writes to the end of mailbox. Receive matches all the inbox (there is a temporary area too, the algorithm is clever to not block incoming messages) and selects one according to the pattern. Receiving a message which contains a freshly-created reference is optimized, otherwise it potentially has to search the whole mailbox.

VM (BEAM) is actually several OS processes to allow for multi-core execution. They share almost nothing, and each one is executing one Erlang process at one time. When process switching happens, it's almost a matter of one pointer to an internal structure changing; of course, as always with virtual machines, the price is more indirection and slower code.

Strings are a mess. Generally there should only be lists of characters, and binaries containing UTF-8, but some things work with lists of bytes and other such bullshit. IO lists, for one, are generally deep lists of bytes and binaries, but not always. In general, you have to be either very careful with Unicode wrangling, or just give up like many other did before you.

11 янв. 2017 г. 3:12 пользователь "Richard A. O'Keefe" <[hidden email]> написал:


On 11/01/17 7:58 AM, Bhag Chandra wrote:
1) "Strings in Erlang are internally treated as a list of integers of
each character's ASCII values, this representation of string makes
operations faster. For example, string concatenation is constant time
operation in Erlang."  Can someone explain why?

Pretty much all of this is somewhere between misleading and confusing.
Mind you, pretty much everything about strings in general is
somewhere between confusing and misguided, whatever the programming
language, especially since the introduction of Unicode.

The closest thing to the truth is to say that Erlang has no native
string datatype whatsoever.  Instead, there are several general purpose
data types that are pressed into service to fake it.

(1) An atom is a unique string.  There's more to say about them,
but the general rule is DON'T use them for strings.

(2) A list of character codes is stringy.  Once upon a time character
codes were 8-bit quantities, so taking two computer words per character
was sneered at.  Unicode has a 21-bit character set these days.  (Not
only that, it's now racist and sexist, so that you can distinguish
between pink/yellow male/female astronaut, I kid you not.  Why do we
need a character "man in business suit levitating"?)  The astral planes
are increasingly being populated, "Version 9.0 adds exactly 7,500 characters, for a total of 128,172 characters."

Let X = "1....m" and Y = "1...n".
Then X ++ Y concatenates them in O(m) time.
NOT O(1).

(3) For many purposes, a *tree* of numbers and pairs can be used to
hold text.  It is *this* that allows O(1) concatenation:
[X|Y] *isn't* the string "1...m1...n" but can in certain contexts
*represent* it.  You can, for example, build up a text of total
size S in O(S) time and then flatten it (or write it or transmit it)
in O(S) time.

Look up the 'iolist()' type in Erlang documentation.

(4) The 'binary' type was originally a byte string and is now a
bit string.  A byte sequence can of course represent a string,
with the encoding of the text being provided by context.  It
used to be common to use Latin 1, it's now common to use UTF8.
There is library code to help with this, but frankly, Unicode
is so appallingly complex that there will probably never be
enough library support (in any language).

Concatenating byte strings of length m and n costs O(m+n)>

(5) A tree of numbers and pairs could also contain binaries.

The important thing about strings is that they are good at
accepting data you don't care to inspect further, storing it,
and giving it back later, and LOUSY at almost anything else,
in EVERY programming language.

One of the ways that they are lousy is that thanks to Unicode's
rules, there is *structure* in strings (which were historically
unstructured), so that you can have a well formed string of
2 characters, split it into two 1-character strings, and find
that at least one of those strings is no longer legal.
(Emoji flags, for example.)



2) "It makes sense to use Erlang only where system's availability is
very high".  Is it not a very general requirement of most of the
systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc
they all are high availability systems, so we can use Erlang in all of them?

I do not think many people in this mailing list would say
"it makes sense to use Erlang ONLY where availability [must be] high."

People use Erlang (and other languages running on the Erlang VM,
such as LFE and Elixir) for all sorts of things.  Yes, Erlang is
not as fast as other languages.

Let's have some perspective on that, though.
Just today I measured four programs to solve the same problem,
using the same structure, written in four languages.
C          0.04 sec    -- has types
Smalltalk  0.25 sec    -- lacks them
Java       0.65 sec    -- has types
Python     2.98 sec    -- lacks them.
Have figures like that ever stopped anyone using Python?
Have they even encouraged people to switch to Smalltalk?

People use a programming language when it lets them get
the job at hand done to an adequate standard.
These days this is as much about infrastructure such as
profiling, test coverage analysis, test frameworks,
documentation tools, libraries, interface support (JSON,
XML, ASN.1, Protobufs, whatever) as it is about the
language as such.

I find that it makes sense to use Erlang whenever concurrency
is important/useful, because it's so much easier to get
concurrent programs right than in Java or C11 or pretty much
anything else (although Ada comes close).  There are of course
plenty of libraries for other languages that claim to add
Erlang-style abilities to those languages; what they don't
mention is that you cannot remove dangers by adding libraries.
For example, gets() has been deprecated in C; the OpenBSD
linker tells you off if you use it.  There are safer alternatives.
But nothing can stop you writing your own version of gets(),
and the OpenBSD linker has no idea that mygets() is just as
dangerous as gets() ever was.

3) "Every message which is sent to a process, goes to the mailbox of
that process. When process is free, it consumes that message from
mailbox". So how exactly does process ask from the mailbox for that
message? Is there a mechanism in a process' memory which keeps polling
its mailbox. I basically want to understand how message is sent from
mailbox to my code in process.

"When process is free" should presumably be
"When that process is RUNNING and FEELS LIKE checking its mailbox,
 that message MAY BE consumed if it is one the process WANTS to
 consume."

A process reads from its mailbox using the 'receive' construction,
described in for example Learn You Some Erlang For Great Good
(http://learnyousomeerlang.com) which I recommend.  This happens
when the code decides it is time to try to receive a message.

If you know about message passing in UNIX,
Pid ! Msg       is like msgsnd(    Queue, Msg, Msg_Size, Flags)
                     or mq_send(   Queue, Msg, Msg_Size, Prio)
receive ... end is like msgrcv(    Queue, Msg, Msg_Size, Type, Flags)
                     or mq_receive(Queue, Msg, Msg_Size, &Prio)

That is, sending happens when there is something EXPLICIT in the
code to make it happen, and receiving happens when there is
something EXPLICIT in the code to make it happen, and there is
buffering in between so things don't have to be simultaneous.

4) We say that a message is passed from process A to process B by simply
using a bang (!) character, but what happens behind the scenes to pass
this message? Do both processes establish a tcp connection first and
then pass message or what?

First of, we have Erlang "nodes" that are Unix or Windows "processes",
and inside them we have Erlang "processes" that are like Unix or Windows
"threads" except much cheaper; the word "fibres" is sometimes used to
describe similar things in those environments.

Erlang processes inside nodes on different machines may well use
TCP connections automatically set up between the nodes.  Or they
could use something else.  They could in principle use Infiniband
or carrier pigeons.

Erlang processes inside different nodes on the same machine
could use any IPC facility provided by the host OS, such as
System V message queues, POSIX message queues, pipes, UNIX sockets,
...

Erlang processes inside the same node will use shared memory,
which might or might not involve copying, depending on the Erlang
version.  Whatever happens, it's likely to be cheaper than TCP.

5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr.
Armstrong is talking about the difference between the context switching
overhead between OS threads and Erlang processes. He says, thread
context switching is of order 700 words but Erlang process context
switching is ... ?

He said that OS thread switching MOVES about 700 words,
while Erlang process switching involves THREE REGISTERS.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Richard A. O'Keefe-2
> Not to start a holy war, but Unicode is not complex, it just has a lot of
> tables.

Wrong.  Unicode really is hugely complex.

John Wheeler is quoted as saying
 "If you are not completely confused by quantum mechanics,
  you do not understand it."
Now apply this to Unicode:
  If you think you understand Unicode, you don't.

There are language tags.
(This is something that was explicitly ruled out of the Unicode
design, then came back in after all.)

There are variation selectors.

Unicode has support not just for text of varying
directionality, but for *mixed* directionality,
with the result that interpreting a Unicode string
requires maintaining a direction stack, with characters
like POP DIRECTIONAL FORMATTING.

I am not saying that you have to do this yourself;
what I am saying is that chopping up a Unicode string
is in general not a meaningful operation.

Another example: there's a set of characters like this:
take next two trees and paste them horizontally
take next three trees and paste them horizontally
take next two trees and paste them vertically
take next three trees and paste them vertically
used for approximating Chinese characters not yet
supported (and yes these things do nest).

This means that in order to move forward one "character"
in a string, it is necessary to parse a tree (no, a
regular expression cannot do this; these things are
*nested* and regular expressions can't do matching
brackets).

Did I mention the rules for emoji?  Look at the rules
for emoji and weep.

I repeat: moving forwards or backwards ONE
user-oriented character in a Unicode string is HARD.

> And pretty much any modern language has immensely better Unicode
> support built in than Erlang.

Pretty much any modern language is moving in this area;
Unicode support in modern Fortran and modern COBOL and
modern C is not that great.  (ICU4C is not part of any
C standard.)

One of the things that make Unicode difficult is that things
keep *changing*.  They try very hard to keep things stable,
but characters do still from time to time change class
(what was once an upper case letter may become a sign, for
one example).

I had code for moving backwards and forwards that took into
account the difference between base characters and floating
diacriticals.  It *didn't* take variation selectors into account.
(Because when I wrote the code there weren't any.)
Nor did I handle language tags.
(Because at the time language tags had been ruled out forever.)



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Garrett Smith-5
On Wed, Jan 11, 2017 at 3:28 PM,  <[hidden email]> wrote:

>> Not to start a holy war, but Unicode is not complex, it just has a lot of
>> tables.
>
> Wrong.  Unicode really is hugely complex.
>
> John Wheeler is quoted as saying
>  "If you are not completely confused by quantum mechanics,
>   you do not understand it."
> Now apply this to Unicode:
>   If you think you understand Unicode, you don't.
>
> There are language tags.
> (This is something that was explicitly ruled out of the Unicode
> design, then came back in after all.)
>
> There are variation selectors.
>
> Unicode has support not just for text of varying
> directionality, but for *mixed* directionality,
> with the result that interpreting a Unicode string
> requires maintaining a direction stack, with characters
> like POP DIRECTIONAL FORMATTING.
>
> I am not saying that you have to do this yourself;
> what I am saying is that chopping up a Unicode string
> is in general not a meaningful operation.
>
> Another example: there's a set of characters like this:
> take next two trees and paste them horizontally
> take next three trees and paste them horizontally
> take next two trees and paste them vertically
> take next three trees and paste them vertically
> used for approximating Chinese characters not yet
> supported (and yes these things do nest).
>
> This means that in order to move forward one "character"
> in a string, it is necessary to parse a tree (no, a
> regular expression cannot do this; these things are
> *nested* and regular expressions can't do matching
> brackets).
>
> Did I mention the rules for emoji?  Look at the rules
> for emoji and weep.
>
> I repeat: moving forwards or backwards ONE
> user-oriented character in a Unicode string is HARD.
>
>> And pretty much any modern language has immensely better Unicode
>> support built in than Erlang.
>
> Pretty much any modern language is moving in this area;
> Unicode support in modern Fortran and modern COBOL and
> modern C is not that great.  (ICU4C is not part of any
> C standard.)
>
> One of the things that make Unicode difficult is that things
> keep *changing*.  They try very hard to keep things stable,
> but characters do still from time to time change class
> (what was once an upper case letter may become a sign, for
> one example).
>
> I had code for moving backwards and forwards that took into
> account the difference between base characters and floating
> diacriticals.  It *didn't* take variation selectors into account.
> (Because when I wrote the code there weren't any.)
> Nor did I handle language tags.
> (Because at the time language tags had been ruled out forever.)

I am completely confused by this AND ALSO I do not understand it.
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Richard A. O'Keefe-2


On 12/01/17 10:52 AM, Garrett Smith wrote:
> I am completely confused by this AND ALSO I do not understand it.

Join the club!

Seriously, I recommend the book "Unicode Demystified".

On the one hand, it cleared up a lot of things I thought
I understood but didn't.

On the other hand, it revealed large complex aspects of
Unicode that I was too ignorant of to know how ignorant
I was.

On the gripping hand, it is several major releases out of
date, and things have only got worse.  But it *is* a great
foundation.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Michael Truog
In reply to this post by Bhag Chandra
This thread started to talk about the need for unicode functionality in Erlang and how it exists currently in Elixir but not in Erlang.  I created a repository with the Elixir functions created as Erlang functions in an Erlang module as an example of what I want at https://github.com/okeuday/unicode_data/

The generated module (unicode_data) only includes functions from the first Erlang module contained in unicode.ex (Elixir.String.Unicode) though it does bring up some important topics:
1) Add the unicode version to the Erlang module version.  The generated unicode_data module has a timestamp suffix, so we know both the unicode version and the timestamp when the unicode_data module was generated.
2) Use only lists, not binaries, to make sure all temporary data stays on the heap of the Erlang process.  That should be best for performance, though I haven't proved that with any performance testing.

I haven't added tests, though I have compared the unicode_data Erlang module, to the Elixir.String.Unicode module and the data looks correct.  Mainly thought this would help the discussion.

Best Regards,
Michael

On 01/10/2017 10:58 AM, Bhag Chandra wrote:
Hello,

I have been coding in Erlang for 2 years.  A wonderful language but not very big community, so I cant discuss my questions with programmers around me (Java, Python guys). I found out about this list today.

I have some fundamental doubts about the Erlang. It would be great if someone can help me clarify them.


1) "Strings in Erlang are internally treated as a list of integers of each character's ASCII values, this representation of string makes operations faster. For example, string concatenation is constant time operation in Erlang."  Can someone explain why?

2) "It makes sense to use Erlang only where system's availability is very high".  Is it not a very general requirement of most of the systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are high availability systems, so we can use Erlang in all of them?

3) "Every message which is sent to a process, goes to the mailbox of that process. When process is free, it consumes that message from mailbox". So how exactly does process ask from the mailbox for that message? Is there a mechanism in a process' memory which keeps polling its mailbox. I basically want to understand how message is sent from mailbox to my code in process.

4) We say that a message is passed from process A to process B by simply using a bang (!) character, but what happens behind the scenes to pass this message? Do both processes establish a tcp connection first and then pass message or what?

5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr. Armstrong is talking about the difference between the context switching overhead between OS threads and Erlang processes. He says, thread context switching is of order 700 words but Erlang process context switching is ... ?
I cant understand what he said, if someone could tell.


P.S. Please excuse for any grammatical errors, English is not my first language.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Dan Gudmundsson-3
We have started to work on a new string module, we will make a PR when we have decided directions of how the api should look like.

Basic stuff like uppercase, lowercase, to_nfc, to _nfd and gc (grapheme_clusters) are implemented for unicode:chardata() input, I have used elixir's module as inspiration.

That is the easy part, writing a nice api on top of that is the hard part and naming the module
something different than string.

/Dan

On Sun, Jan 15, 2017 at 3:25 AM Michael Truog <[hidden email]> wrote:
This thread started to talk about the need for unicode functionality in Erlang and how it exists currently in Elixir but not in Erlang.  I created a repository with the Elixir functions created as Erlang functions in an Erlang module as an example of what I want at https://github.com/okeuday/unicode_data/

The generated module (unicode_data) only includes functions from the first Erlang module contained in unicode.ex (Elixir.String.Unicode) though it does bring up some important topics:
1) Add the unicode version to the Erlang module version.  The generated unicode_data module has a timestamp suffix, so we know both the unicode version and the timestamp when the unicode_data module was generated.
2) Use only lists, not binaries, to make sure all temporary data stays on the heap of the Erlang process.  That should be best for performance, though I haven't proved that with any performance testing.

I haven't added tests, though I have compared the unicode_data Erlang module, to the Elixir.String.Unicode module and the data looks correct.  Mainly thought this would help the discussion.

Best Regards,
Michael


On 01/10/2017 10:58 AM, Bhag Chandra wrote:
Hello,

I have been coding in Erlang for 2 years.  A wonderful language but not very big community, so I cant discuss my questions with programmers around me (Java, Python guys). I found out about this list today.

I have some fundamental doubts about the Erlang. It would be great if someone can help me clarify them.


1) "Strings in Erlang are internally treated as a list of integers of each character's ASCII values, this representation of string makes operations faster. For example, string concatenation is constant time operation in Erlang."  Can someone explain why?

2) "It makes sense to use Erlang only where system's availability is very high".  Is it not a very general requirement of most of the systems? Whatsapp to Google to FB to Amazon to Paypal to Barclays etc they all are high availability systems, so we can use Erlang in all of them?

3) "Every message which is sent to a process, goes to the mailbox of that process. When process is free, it consumes that message from mailbox". So how exactly does process ask from the mailbox for that message? Is there a mechanism in a process' memory which keeps polling its mailbox. I basically want to understand how message is sent from mailbox to my code in process.

4) We say that a message is passed from process A to process B by simply using a bang (!) character, but what happens behind the scenes to pass this message? Do both processes establish a tcp connection first and then pass message or what?

5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 ) Mr. Armstrong is talking about the difference between the context switching overhead between OS threads and Erlang processes. He says, thread context switching is of order 700 words but Erlang process context switching is ... ?
I cant understand what he said, if someone could tell.


P.S. Please excuse for any grammatical errors, English is not my first language.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Loïc Hoguin-3
Great work!

Does this include (some) support for locales? As far as I recall they
are necessary to do uppercasing and lowercasing properly.

If this includes support for locales, or would in the future, may I
suggest 'text' for the module name? Otherwise something else. :-)

On 01/15/2017 10:01 AM, Dan Gudmundsson wrote:

> We have started to work on a new string module, we will make a PR when
> we have decided directions of how the api should look like.
>
> Basic stuff like uppercase, lowercase, to_nfc, to _nfd and gc
> (grapheme_clusters) are implemented for unicode:chardata() input, I have
> used elixir's module as inspiration.
>
> That is the easy part, writing a nice api on top of that is the hard
> part and naming the module
> something different than string.
>
> /Dan
>
> On Sun, Jan 15, 2017 at 3:25 AM Michael Truog <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     ||This thread started to talk about the need for unicode
>     functionality in Erlang and how it exists currently in Elixir but
>     not in Erlang.  I created a repository with the Elixir functions
>     created as Erlang functions in an Erlang module as an example of
>     what I want at https://github.com/okeuday/unicode_data/
>
>     The generated module (unicode_data) only includes functions from the
>     first Erlang module contained in unicode.ex (Elixir.String.Unicode)
>     though it does bring up some important topics:
>     1) Add the unicode version to the Erlang module version.  The
>     generated unicode_data module has a timestamp suffix, so we know
>     both the unicode version and the timestamp when the unicode_data
>     module was generated.
>     2) Use only lists, not binaries, to make sure all temporary data
>     stays on the heap of the Erlang process.  That should be best for
>     performance, though I haven't proved that with any performance testing.
>
>     I haven't added tests, though I have compared the unicode_data
>     Erlang module, to the Elixir.String.Unicode module and the data
>     looks correct.  Mainly thought this would help the discussion.
>
>     Best Regards,
>     Michael
>
>
>     On 01/10/2017 10:58 AM, Bhag Chandra wrote:
>>     Hello,
>>
>>     I have been coding in Erlang for 2 years.  A wonderful language
>>     but not very big community, so I cant discuss my questions with
>>     programmers around me (Java, Python guys). I found out about this
>>     list today.
>>
>>     I have some fundamental doubts about the Erlang. It would be great
>>     if someone can help me clarify them.
>>
>>
>>     1) "Strings in Erlang are internally treated as a list of integers
>>     of each character's ASCII values, this representation of string
>>     makes operations faster. For example, string concatenation is
>>     constant time operation in Erlang."  Can someone explain why?
>>
>>     2) "It makes sense to use Erlang only where system's availability
>>     is very high".  Is it not a very general requirement of most of
>>     the systems? Whatsapp to Google to FB to Amazon to Paypal to
>>     Barclays etc they all are high availability systems, so we can use
>>     Erlang in all of them?
>>
>>     3) "Every message which is sent to a process, goes to the mailbox
>>     of that process. When process is free, it consumes that message
>>     from mailbox". So how exactly does process ask from the mailbox
>>     for that message? Is there a mechanism in a process' memory which
>>     keeps polling its mailbox. I basically want to understand how
>>     message is sent from mailbox to my code in process.
>>
>>     4) We say that a message is passed from process A to process B by
>>     simply using a bang (!) character, but what happens behind the
>>     scenes to pass this message? Do both processes establish a tcp
>>     connection first and then pass message or what?
>>
>>     5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 )
>>     Mr. Armstrong is talking about the difference between the context
>>     switching overhead between OS threads and Erlang processes. He
>>     says, thread context switching is of order 700 words but Erlang
>>     process context switching is ... ?
>>     I cant understand what he said, if someone could tell.
>>
>>
>>     P.S. Please excuse for any grammatical errors, English is not my
>>     first language.
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Dan Gudmundsson-3
On Sun, Jan 15, 2017 at 10:48 AM Loïc Hoguin <[hidden email]> wrote:
Great work!

You have not seen it yet :-)
 

Does this include (some) support for locales? As far as I recall they
are necessary to do uppercasing and lowercasing properly.


No not currently I have taken the elixir approach of a basic unicode support without locale handling, that is another can of worm which I guess can be opened later if there is need.
But we don't have locale support anywhere else and I don't want start with adding that first,
then will we never get any unicode support.
From my understanding for uppercase and lowercase there very few cases which need
the locale to correctly transform them.

/Dan
 
If this includes support for locales, or would in the future, may I
suggest 'text' for the module name? Otherwise something else. :-)

On 01/15/2017 10:01 AM, Dan Gudmundsson wrote:
> We have started to work on a new string module, we will make a PR when
> we have decided directions of how the api should look like.
>
> Basic stuff like uppercase, lowercase, to_nfc, to _nfd and gc
> (grapheme_clusters) are implemented for unicode:chardata() input, I have
> used elixir's module as inspiration.
>
> That is the easy part, writing a nice api on top of that is the hard
> part and naming the module
> something different than string.
>
> /Dan
>
> On Sun, Jan 15, 2017 at 3:25 AM Michael Truog <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     ||This thread started to talk about the need for unicode
>     functionality in Erlang and how it exists currently in Elixir but
>     not in Erlang.  I created a repository with the Elixir functions
>     created as Erlang functions in an Erlang module as an example of
>     what I want at https://github.com/okeuday/unicode_data/
>
>     The generated module (unicode_data) only includes functions from the
>     first Erlang module contained in unicode.ex (Elixir.String.Unicode)
>     though it does bring up some important topics:
>     1) Add the unicode version to the Erlang module version.  The
>     generated unicode_data module has a timestamp suffix, so we know
>     both the unicode version and the timestamp when the unicode_data
>     module was generated.
>     2) Use only lists, not binaries, to make sure all temporary data
>     stays on the heap of the Erlang process.  That should be best for
>     performance, though I haven't proved that with any performance testing.
>
>     I haven't added tests, though I have compared the unicode_data
>     Erlang module, to the Elixir.String.Unicode module and the data
>     looks correct.  Mainly thought this would help the discussion.
>
>     Best Regards,
>     Michael
>
>
>     On 01/10/2017 10:58 AM, Bhag Chandra wrote:
>>     Hello,
>>
>>     I have been coding in Erlang for 2 years.  A wonderful language
>>     but not very big community, so I cant discuss my questions with
>>     programmers around me (Java, Python guys). I found out about this
>>     list today.
>>
>>     I have some fundamental doubts about the Erlang. It would be great
>>     if someone can help me clarify them.
>>
>>
>>     1) "Strings in Erlang are internally treated as a list of integers
>>     of each character's ASCII values, this representation of string
>>     makes operations faster. For example, string concatenation is
>>     constant time operation in Erlang."  Can someone explain why?
>>
>>     2) "It makes sense to use Erlang only where system's availability
>>     is very high".  Is it not a very general requirement of most of
>>     the systems? Whatsapp to Google to FB to Amazon to Paypal to
>>     Barclays etc they all are high availability systems, so we can use
>>     Erlang in all of them?
>>
>>     3) "Every message which is sent to a process, goes to the mailbox
>>     of that process. When process is free, it consumes that message
>>     from mailbox". So how exactly does process ask from the mailbox
>>     for that message? Is there a mechanism in a process' memory which
>>     keeps polling its mailbox. I basically want to understand how
>>     message is sent from mailbox to my code in process.
>>
>>     4) We say that a message is passed from process A to process B by
>>     simply using a bang (!) character, but what happens behind the
>>     scenes to pass this message? Do both processes establish a tcp
>>     connection first and then pass message or what?
>>
>>     5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 )
>>     Mr. Armstrong is talking about the difference between the context
>>     switching overhead between OS threads and Erlang processes. He
>>     says, thread context switching is of order 700 words but Erlang
>>     process context switching is ... ?
>>     I cant understand what he said, if someone could tell.
>>
>>
>>     P.S. Please excuse for any grammatical errors, English is not my
>>     first language.
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang basic doubts about String, message passing and context switching overhead

Jesper Louis Andersen-2
I'd suggest looking a bit at what the Go people are doing here as well. They have this problem at a large scale at Google, so I expect them to have handling of some of the nastier corner cases. Some observations:

* They keep part of the unicode handling outside of the standard library. This allows it to develop independently of the main code base, which in some cases is nice. The things that seems to be in the separate package are collation, normalization, and canocalization. I have a hunch this happens because these things tend to update a bit like time zones and SSL top-level certificates: haphazardly. By keeping it outside, you avoid the problem of having to wait for a new major release, or even having to push a new minor release because some random pacific island decided on their monthly meeting to switch their collation rules :)

* Keep it rather simple for starters. The Elixir set is probably what "most people need supported".

* Currently, I'm mostly interested in normalization and canocalization. I have some data where this would be highly useful to have access to directly from Erlang.

On Sun, Jan 15, 2017 at 11:17 AM Dan Gudmundsson <[hidden email]> wrote:
On Sun, Jan 15, 2017 at 10:48 AM Loïc Hoguin <[hidden email]> wrote:
Great work!

You have not seen it yet :-)
 

Does this include (some) support for locales? As far as I recall they
are necessary to do uppercasing and lowercasing properly.


No not currently I have taken the elixir approach of a basic unicode support without locale handling, that is another can of worm which I guess can be opened later if there is need.
But we don't have locale support anywhere else and I don't want start with adding that first,
then will we never get any unicode support.
From my understanding for uppercase and lowercase there very few cases which need
the locale to correctly transform them.

/Dan
 
If this includes support for locales, or would in the future, may I
suggest 'text' for the module name? Otherwise something else. :-)

On 01/15/2017 10:01 AM, Dan Gudmundsson wrote:
> We have started to work on a new string module, we will make a PR when
> we have decided directions of how the api should look like.
>
> Basic stuff like uppercase, lowercase, to_nfc, to _nfd and gc
> (grapheme_clusters) are implemented for unicode:chardata() input, I have
> used elixir's module as inspiration.
>
> That is the easy part, writing a nice api on top of that is the hard
> part and naming the module
> something different than string.
>
> /Dan
>
> On Sun, Jan 15, 2017 at 3:25 AM Michael Truog <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     ||This thread started to talk about the need for unicode
>     functionality in Erlang and how it exists currently in Elixir but
>     not in Erlang.  I created a repository with the Elixir functions
>     created as Erlang functions in an Erlang module as an example of
>     what I want at https://github.com/okeuday/unicode_data/
>
>     The generated module (unicode_data) only includes functions from the
>     first Erlang module contained in unicode.ex (Elixir.String.Unicode)
>     though it does bring up some important topics:
>     1) Add the unicode version to the Erlang module version.  The
>     generated unicode_data module has a timestamp suffix, so we know
>     both the unicode version and the timestamp when the unicode_data
>     module was generated.
>     2) Use only lists, not binaries, to make sure all temporary data
>     stays on the heap of the Erlang process.  That should be best for
>     performance, though I haven't proved that with any performance testing.
>
>     I haven't added tests, though I have compared the unicode_data
>     Erlang module, to the Elixir.String.Unicode module and the data
>     looks correct.  Mainly thought this would help the discussion.
>
>     Best Regards,
>     Michael
>
>
>     On 01/10/2017 10:58 AM, Bhag Chandra wrote:
>>     Hello,
>>
>>     I have been coding in Erlang for 2 years.  A wonderful language
>>     but not very big community, so I cant discuss my questions with
>>     programmers around me (Java, Python guys). I found out about this
>>     list today.
>>
>>     I have some fundamental doubts about the Erlang. It would be great
>>     if someone can help me clarify them.
>>
>>
>>     1) "Strings in Erlang are internally treated as a list of integers
>>     of each character's ASCII values, this representation of string
>>     makes operations faster. For example, string concatenation is
>>     constant time operation in Erlang."  Can someone explain why?
>>
>>     2) "It makes sense to use Erlang only where system's availability
>>     is very high".  Is it not a very general requirement of most of
>>     the systems? Whatsapp to Google to FB to Amazon to Paypal to
>>     Barclays etc they all are high availability systems, so we can use
>>     Erlang in all of them?
>>
>>     3) "Every message which is sent to a process, goes to the mailbox
>>     of that process. When process is free, it consumes that message
>>     from mailbox". So how exactly does process ask from the mailbox
>>     for that message? Is there a mechanism in a process' memory which
>>     keeps polling its mailbox. I basically want to understand how
>>     message is sent from mailbox to my code in process.
>>
>>     4) We say that a message is passed from process A to process B by
>>     simply using a bang (!) character, but what happens behind the
>>     scenes to pass this message? Do both processes establish a tcp
>>     connection first and then pass message or what?
>>
>>     5) At 30:25 in this video ( https://youtu.be/YaUPdgtUYko?t=1825 )
>>     Mr. Armstrong is talking about the difference between the context
>>     switching overhead between OS threads and Erlang processes. He
>>     says, thread context switching is of order 700 words but Erlang
>>     process context switching is ... ?
>>     I cant understand what he said, if someone could tell.
>>
>>
>>     P.S. Please excuse for any grammatical errors, English is not my
>>     first language.
>>
>>
>>     _______________________________________________
>>     erlang-questions mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     http://erlang.org/mailman/listinfo/erlang-questions
>
>     _______________________________________________
>     erlang-questions mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions