I'm starting to learn Erlang which is an amazing language thanks to isolation, fault tolerance, function programming and hot swaping of the code.
I could notice that to fix some performance issue sometimes I can use port to interact with C or other languages.
My wonder is the capacity of hot code replacement using port. Do you have already face this issue in a running system?
May an identification based on hash can help to identity the version of the port to use?
Thanks
Related
I'm going to start the development of an application on a Zynq board. My task is basically to port an existing application running on a Microblaze on the dual core ARM.
What I'm wondering about is which O.S. to use on the new system, because I have no experience at all in this field.
It seems to me that there are four main approaches:
1) Petalinux (use both cores)
2) Petalinux+FreeRTOS (use both cores)
3) FreeRTOS (use only a core)
4) Baremetal (use only a core)
What my application has to do is to move a big amount of data between Ethernet and multiple custom links, so it has to serve a lot of interrupts and command a lot of DMA operations.
How much is the overhead introduced by Petalinux in the interrupt service with respect to baremetal or FreeRTOS? Do you think that, for this kind of work, is faster a single core application running without any OS or, for example, a Petalinux application that has the overhead of the OS (and of the synchronization mechanisms like semaphores or mutex)?
I know the question is not precise and quite vague, but having no experience in the field I strongly need some initial hints.
Thank you.
As you say, this is too vague to give a considered answer because it really depends on your application (when does it not). If you need all the 'stuff' that is available for Linux and boot time is not an issue then go with that. If you need actual real time behaviour, fast boot time, simplicity, and don't need anything Linux specific, then FreeRTOS might be your best choice. There is a Zynq FreeRTOS TCP project that uses the BSD style sockets interface (like Linux) here: http://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCPIP_FAT_Examples_Xilinx_Zynq.html
Usually the performance should not differ alot.
If you compile your linux with a well optimizing compiler there is a good chance to be faster compared to bare metal.
But if you need hard real time linux is not suitable for you.
There is a good whitepaper from Altera but should fit for Xilinx too:
whitepaper on real time jitter
please could you explain to me an architecture of the LING platform? I don't understand how ling interacts with xen and then with hw - is ling vm talking to xen microkernel directly though c api?
thanks :)
I do not have an in-depth knowledge of the project but I think I can give you some pointers for further research.
1) concept of unikernel: http://queue.acm.org/detail.cfm?id=2566628
2) a podcast about this project: http://mostlyerlang.files.wordpress.com/2013/10/020-erlang-on-xen.mp3
From what I understand, based on the unikernel concept, LING has rewritten part of erlang/otp to improve the startup time and remove OS attack vectors. It also translates BEAM files to a custom instrument set.
LING communicates with Xen using 'hypercalls'. The hypercalls mostly used during inital configuration, such as setting page tables. Later the communication with virtual devices happens mostly through shared pages and (soft) interrupts. This is exactly the interface paravirtualised Linux kernel is using when running as Xen guest.
I am working on Erlang robotic project. I have made a wallfollower robot program which has two files 1. a C program to communicate with hardware(I think we can not directly use Erlang for this) and 2. Erlang program to call these functions. I want to know where(platforms) I can run this robot.
Is it possible to run this robot over micro-controller (8051 or ARM7) based hardware?
Is it possible to convert Erlang program into C code or directly into .hex file?
You might want to have a look to this project:
http://erlang-embedded.com/
They presented it today at the Erlang Factory Conference in London.
Also, you might want to contact someone from the DMI (formerly DIIT) from Catania, Italy. They spent many years working on Erlang powered robots:
http://eurobot.dmi.unict.it/?p=16
Hope this helps.
To the best of my knowledge:
there isn't any port of Erlang VM over micro-controllers (assuming it would even make sense)
there isn't any way to turn Erlang BEAM code to .hex format: BEAM VM code needs a virtual machine to operate in.
If you want something lightweight with task/threading capability for micro-controllers, why not consider TinyOS ?
The Erlang VM does a lot more than just interpret the erlang bytecode for you. It also handles the interprocess messaging, and does a lot of the heavy lifting that makes erlang so robust and fault tolerant. translating erlang code to machine code would require translating a good portion of the vm code as well. You'd be better off porting the vm itself to a micro-controller and running the apps on that.
I've just started reading Joe Armstrongs book on Erlang and listened to his excellent talk on Software Engineering Radio.
Its an interesting language/system and one whose time seems to have come around with the advent of multi-core machines.
My question is: what is there to stop it being ported to the JVM or CLR? I realise that both virtual machines aren't setup to run the lightweight processes that Erlang calls for - but couldn't these be simulated by threads? Could we see a lightweight or cutdown version of Erlang on a non Erlang VM?
You could not use JVM/CLR libraries, given their reliance on mutable objects.
Erlang exception handling is quite different from JVM and CLR exceptions, you would need to handle this somehow.
Implementing processes as threads would mean that any sizable Erlang system runs out of memory pretty fast (process size on my machine on creation: 1268 bytes, thread stack size in CLR: 1 MB) and communication between processes is much slower than in Erlang.
What you probably want is an Actor Model implementation on JVM or CLR.
Scala and Clojure have already been mentioned. In addition, there are many Actor implementations for JVM:
Kilim, Functional Java, Jetlang, Actors Guild, ActorFoundry, and at least one for CLR: Retlang, which can be used from any JVM/CLR language.
For educational reasons, we are implementing a subset of ErlangVM for CLR. We were highly inspired by Kresten Krab Thorup and his project Erjang, a JVM based Erlang VM. Erjang uses kilim framework for representing lightweight processes, and it starts to attract attention.
Javalimit - Erjang's author blog.
Erjang repository
This is a well trod-discussion. Some context might be useful.
From the Erlang mailing list last November:
The start of a long discussion thread
continuing here
and going a bit mental here
and ending on Joe's contribution.
My contribution to the debate about Erlang on the JVM? No, not a good idea :(
Nothing at all, actually. You might have a look at Clojure, which is an interesting functional language built on the JVM.
Axum -- an incubation project on the CLR -- was clearly inspired by Erlang.
Erjang is a virtual machine for Erlang, which runs on Java™.
I don't know of any technical problem inhiting this.
Actually Scala (a JVM functional language) uses what is called an Actor Model that is very similar to, and as I understand it borrows heavily from, the Erlang model of shared-nothing concurrency.
Threads could not simulate Erlang processes. They're much too heavy-weight.
Just for completeness additional source about topic.
Possible? Yes. Practical? Well, probably not; they solve different problems in very different ways, and thus have lots of major differences in the way they do things. This would make porting hard, and performance would likely suffer severely. That doesn't mean it can't be done, just that there are better ways to accomplish what such a port would bring to the table.
I would really like to know about support for the following in Erlang.
Support for Windows COM. COM support in itself covers all requirements regarding accessing Access, Excel and Word documents. Both read and write.
PDF generation and printing. Note printing is easy if it can be done on a Windows printer server. And many printers don't have any driver beside Windows.
And a good database support which doesn't make any task harder than doing it on a SQL server. Erlang Mnesia is OK, given that there is nothing harder to perform on Mnesia than on any SQL server.
The business app that I am planning to port will be web based. It will be nice if I could port it to GUI later, but asking for that might be too much for Erlang, I guess. I am OK with that.
Edit: I would like to add that support for MS-Office is not that a big deal. A language only needs to support COM. And the whole microsoft world will be at your door step. Even Perl/PHP/Python/Ruby has COM support. Though none of those languages were born for the Windows world.
Even if I'm a great Erlang/OTP fan currently developing my application server (http://code.google.com/p/tideland-eas/) in Erlang I think it's not the right tool for you. Erlang is brilliant in the domain of concurrency, distribution, and reliability. But you need a tough integration into the Microsoft world. So maybe you should take a look at F# to get at least a kind of Erlang feeling here.
If you want COM support you better work with more microsoft-friendly language
The same
The same, but erlang has ODBC interface that allows you to work with 'ordinary' SQL-servers. I know it can mysql, not sure for mssql
Anyway you should think about some helping applications like 'print_pdf.exe', 'change_word.exe' that would be managed by erlang system, but not one erlang application which doing everything. Please read about C Nodes and Erlang FAQ's question "What sort of applications is Erlang particularly suitable for?"
-- sorry my English )