Where does Pony's performance vis-a-vis Erlang/BEAM come from? The absence of dynamic typing? Better scheduler?
Most message passing on BEAM is done via copying. Pony can share the memory directly because the compiler enforces safe sharing via deny capabilities. You can only send 3 basic types to another actor:
iso -> mutable memory that you have the sole reference to val -> immutable reference. you can read but you can't write tag -> an opaque reference. good for sending messages to actors or doing identity comparisons
The type system certainly helps as well. It allows us to give LLVM hints on optimizations it can make. The type system also helps because we can do "dangerous but fast" things safely because we can prove they are safe in this instance.
Compiling to native code via LLVM is another area for performance wins.
That said, Erlang has over 20 years of rock solid production usage behind it and that unto itself is a quite a selling point. At this point in time, I'd suggest Pony to Erlang/Elixir users if they need more performance, otherwise, I'd stick with Erlang for now.
> The type system also helps because we can do "dangerous but fast"
> things safely because we can prove they are safe in this instance.
Static typing would mean the engine can know for sure what |foo| is and where to look for |bar|, allowing faster, guaranteed-correct code to be emitted ahead of time. Dynamic typing makes it harder to offer speed, correctness, security, and good memory usage all at once.
Mercury has uniqueness types, so can be remain referentially transparent while compiling to code that mutates. The compiler has fairly advanced automatic parallelization and can in some cases do compile-time garbage collection (i.e. it knows at compile time when an object will become inaccessible).
--
See e.g. https://bluishcoder.co.nz/2010/06/02/safer-c-code-using-ats....
That said, thanks for your work on Rust! Count me a big fan of the language.
Also, I think saying that the ATS has no unsafe{} sections is misleading: it isn't explicitly marked in the source, but the compiler still cannot check the "ownership" annotations in the imports are correct, or that, say, the preconditions of the functions (which may lead to undefined behaviour when violated) are satisfied. In other words, all of that code is implicitly surrounded in an `unsafe` block.
A Rust API designed for people to use will also not have unsafe code, e.g. https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhe...
(The linearity is essentially handled by destructors: the common case is the clean-up is just that, clean-up, and so destructors work well. It is definitely more annoying to 100%-type-check APIs that have more interesting clean-up/closing procedures but these are rarer.)
You end up with a definition that checks at compile time that:
* We don't exceed the memory bounds of the source buffer
* We don't exceed the memory bounds of the destination buffer
* The destination buffer is at least the minimium size required by the function documentation
* We can't treat the destination buffer as a string if the function fails
* We can't treat the destination buffer as an array of bytes if the function succeeds
* Off by one errors due to null terminator handling are removed
* Checking to see if the function call failed is enforced
And there's no overhead at runtime.
Aren't you mixing up flexibility for the programmer with flexibility for the compiler?
The more restrictions the programmer has, the more flexibility the compiler has to change instructions and still produce the same results.
It's garbage collector is superior, having to do much less work than in beam.
The data workload for each thread is much smaller. objects are tiny, messages are mostly referenced (shared) and not copied.
erlang does more. it already supports distributed actors, so there's a little overhead also.
One nice thing about the Pony GC is it can GC actors that are waiting for messages but will never receive one. In some other languages I've used I end up with processes idling in a receive on channel living forever but never able to exit because nothing is going to put a message in the channel.