Erlang info

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

Erlang info

joe mcguckin
I recall one of the design wins Erlang had was a switch from Ericsson? Was this a voice pbx or a packet data switch? I assume Erlang controlled the control plane
functions: If it was a voice switch, surely they must have used C (or similar) to perform the low-level hardware interfacing stuff like voice transcoding, digitization, etc

How easy is it for a  task to fire off a new thread on a different server?

Thanks,

Joe.


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

Re: Erlang info

Jesper Louis Andersen-2
On Tue, Jun 12, 2018 at 9:00 PM joe mcguckin <[hidden email]> wrote:
If it was a voice switch, surely they must have used C (or similar) to perform the low-level hardware interfacing stuff like voice transcoding, digitization, etc


Chances are C is too slow for this operation as well. You usually need either FPGAs or ASICs and then a (thin) C driver layer to interface with the Erlang Control Plane. But I have relatively little knowledge of the actual Ericsson projects and their inner workings.
 
How easy is it for a  task to fire off a new thread on a different server?

Starting a new process on another Erlang node is rather easy. Calling eg, spawn(Node, Fun) will start running Fun on the node Node (which is usually on a different machine).

However, in most systems which need this, you tend to build higher-level solutions out of the underlying primitives depending on what kind of fault-guarantees you are looking for and what kind of problem you are trying to solve. Because working at the lowest level requires a lot of attention to the small details which you would like to solve once and for all.

The reason we tend to say process and not thread is because threads usually implies there is a shared data space all threads can access with locks around data so shared. First, this model is going to break down in a distributed setting (Unless you have direct DMA over the network in a HPC-setting). Second, an Erlang process logically do not share data with each other and owns its own data. The current implementation is very explicit about this, giving each process its own heap, stack and garbage collection. But one could imagine sharing the heap among all processes: because the language is functional, there is no way one process can overwrite the data of another.

The biggest secret is that data is copied between processes, and usually not passed by reference (except a few types of data). Since messages are often small and since this improves data locality (especially when you are distributed), the overhead of doing so tend to be smaller than what people think it is. This also suggests a model where you tend to move the computation to where the data is, rather than moving the data to the computation.

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

Re: Erlang info

lmdthel
You are most likely thinking about the AXD301, it was born as an ATM switch. It used an combination of C/C++, Java and Erlang

At that time (long time ago) The AXD 301 control system, release 3.2, consisted of roughly:
• 1 million lines of Erlang source code
• 400,000 lines of C/C++ code
• 13,000 lines of Java code

(excluding comments and whitespace)
In addition, some 500,000 lines of C code reside on device processors. In the control system, about 100,000 lines of C code constitutes 3rd party software which is started, configured and supervised by corresponding (tiny) Erlang programs.
The above numbers do not include the actual Erlang/OTP product, which contains 240,000 lines of Erlang, 460,000 lines of C/C++ and 15,000 lines of Java.

You can find more details including the numbers above here: http://www.erlang.se/publications/Ulf_Wiger.pdf 

Thomas


On Tue, 12 Jun 2018 at 21:17 Jesper Louis Andersen <[hidden email]> wrote:
On Tue, Jun 12, 2018 at 9:00 PM joe mcguckin <[hidden email]> wrote:
If it was a voice switch, surely they must have used C (or similar) to perform the low-level hardware interfacing stuff like voice transcoding, digitization, etc


Chances are C is too slow for this operation as well. You usually need either FPGAs or ASICs and then a (thin) C driver layer to interface with the Erlang Control Plane. But I have relatively little knowledge of the actual Ericsson projects and their inner workings.
 
How easy is it for a  task to fire off a new thread on a different server?

Starting a new process on another Erlang node is rather easy. Calling eg, spawn(Node, Fun) will start running Fun on the node Node (which is usually on a different machine).

However, in most systems which need this, you tend to build higher-level solutions out of the underlying primitives depending on what kind of fault-guarantees you are looking for and what kind of problem you are trying to solve. Because working at the lowest level requires a lot of attention to the small details which you would like to solve once and for all.

The reason we tend to say process and not thread is because threads usually implies there is a shared data space all threads can access with locks around data so shared. First, this model is going to break down in a distributed setting (Unless you have direct DMA over the network in a HPC-setting). Second, an Erlang process logically do not share data with each other and owns its own data. The current implementation is very explicit about this, giving each process its own heap, stack and garbage collection. But one could imagine sharing the heap among all processes: because the language is functional, there is no way one process can overwrite the data of another.

The biggest secret is that data is copied between processes, and usually not passed by reference (except a few types of data). Since messages are often small and since this improves data locality (especially when you are distributed), the overhead of doing so tend to be smaller than what people think it is. This also suggests a model where you tend to move the computation to where the data is, rather than moving the data to the computation.
_______________________________________________
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