[erlang-questions] About Erlang system performance
Fred Hebert
mononcqc@REDACTED
Fri Nov 9 22:13:42 CET 2012
From "The HiPE/x86 Erlang Compiler: System Description and Performance
Evaluation" (page 4):
HiPE extends the standard Erlang/OTP runtime system to permit Erlang
processes to execute both interpreted code and native machine code.3
Each process has two stacks, one for interpreted code and one for
native code. This simplifies garbage collection and exception
handling, since each stack contains only frames of a single type.
paper.dvi
Control flow between interpreted and native code, e.g. at function
calls and returns, is handled by a mode-switch interface. The
implementation uses linker-generated proxy code stubs and software
trap return addresses to trigger the appropriate mode-switches when
invoked. Two important properties of the mode-switch interface are
that it preserves tail-recursion (i.e., no sequence of consecutive
mode-switching tailcalls grows either stack by more than a
constant), and that it imposes no runtime overhead on same-mode
calls and returns (i.e., from native to native or from BEAM to BEAM).
To me this is an indication of a cost happening when switching modes
(otherwise why specify there is no overhead on same-mode calls and
returns), and if I recall correctly both Kostis Sagonas and Jesper Louis
Andersen mentioned the same behavior to me at conferences.
So the problem is that if I'm stuck in a tight loop and constantly
calling non-HiPE functions and then returning to HiPE, the cost of
switching could dwarf HiPE improvements within that loop. Sticking to
HiPE only for that part of the code would help me benefit more from the
native code.
I couldn't go in deeper detail than this, because I'm not knowledgeable
enough to go dive into it and figure things out, though. If more details
are needed, either Kostis or Jesper (or anyone else who knows) could
add to the conversation, if they have the time for it, that is.
On 12-11-09 2:36 PM, Max Lapshin wrote:
> What exactly gives performance problems, when calling from HiPE to
> beam and back?
> Marshalling arguments?
>
> But NIF doesn't require marshalling data. Maybe it is possible to
> achieve something like in LLVM, when function is transparently
> compiled from bytecode to some native.
>
> Maybe there were some discussions on this mailing list about it?
>
>
> On Fri, Nov 9, 2012 at 11:06 PM, Fred Hebert <mononcqc@REDACTED
> <mailto:mononcqc@REDACTED>> wrote:
>
> We've used HiPE in parts of our system that required tight fast
> loops. Whenever we need something to go fast due to some
> algorithmic complexity, /and/ that we can manage to isolate it as
> a single unit that doesn't need to call to non-HiPE code, we will
> try to convert it.
>
> Basically, I've been told that HiPE and Beam have some overhead
> when it comes to switching from one to the other. When we have a
> bit of code that is a hotspot, I'll try to inline whatever calls
> are made to other modules (mostly lists), compile only that module
> with HiPE, and let it do its thing. Sometimes benchmarks go in
> HiPE's favour, sometimes not.
>
> In a particular instance of our stack, it gave us nearly 2x
> speedup on loop & search operations that frequently happen more
> than 50,000 times per second. Definitely worth it, and it's been
> running in production for months, just for that single module.
>
>
> On 12-11-09 8:45 AM, Valentin Micic wrote:
>> Interestingly enough, this was a kind of conclusion we've arrived
>> at as well -- the good performance of Beam, combined with
>> "perceived instability", acted as a serious deterrent for me.
>> But Max, wouldn't you like to know if there are any brave souls
>> out there that were prepared to go beyond perceptions and
>> successfully tried it in "real-life" situation?
>>
>> V/
>>
>>
>> On 09 Nov 2012, at 3:34 PM, Max Bourinov wrote:
>>
>>> Unrelated, but: we were considering to give a try to HiPE but so
>>> far there is no need to do it for us because Beam outperforms
>>> everything else in our problem domain.
>>>
>>>
>>> Best regards,
>>> Max
>>>
>>>
>>>
>>>
>>> On Fri, Nov 9, 2012 at 5:16 PM, Valentin Micic
>>> <valentin@REDACTED <mailto:valentin@REDACTED>> wrote:
>>>
>>> Unrelated, but would be interesting to find out -- are there
>>> any commercial-grade (let alone carrier-grade) systems that
>>> take advantage of HiPE?
>>>
>>>
>>> V/
>>>
>>> On 09 Nov 2012, at 2:11 PM, Schneider wrote:
>>>
>>> > you're right. HIPE generates compiled code.
>>> > my mistake.
>>> > take a look here for more info's about HIPE:
>>> > http://user.it.uu.se/~kostis/Papers/erlang03.pdf
>>> <http://user.it.uu.se/%7Ekostis/Papers/erlang03.pdf>
>>> >
>>> > greatz Johannes
>>> >
>>> >
>>> > On Fr 09 Nov 2012 13:07:49 CET, Matti Oinas wrote:
>>> >> Correct me if I'm wrong but doesn't HIPE compile to
>>> native code?
>>> >>
>>> >> --
>>> >> Matti
>>> >>
>>> >> On Fri, Nov 9, 2012 at 1:57 PM, Schneider <js@REDACTED
>>> <mailto:js@REDACTED>> wrote:
>>> >>> Erlang is a language, which produced byte-code which
>>> get' interpreted by the
>>> >>> Erlang engine. C++ instead generates mashing-code which
>>> has on the one hand
>>> >>> a much better performance, on the other hand,
>>> >>> some disadvantages like incompatibility between
>>> different OSs.
>>> >>>
>>> >>> greatz Johannes
>>> >>>
>>> >>>
>>> >>> On Fr 09 Nov 2012 09:42:21 CET, hume npx wrote:
>>> >>>>
>>> >>>> Hi, all:
>>> >>>> I'am new to erlang, after investigate some benchmark
>>> such as at
>>> >>>>
>>> http://shootout.alioth.debian.org/u64q/which-programs-are-fastest.php,
>>> >>>> I found that erlang compiler is not so good at speed?
>>> the benchmark
>>> >>>> shows that erlang Hipe is 13x slowdown compared to C++,
>>> as compared to
>>> >>>> Haskell GHC (3.3x slowdown), go 2.98x slowdown or even
>>> javascript v8
>>> >>>> is about 1x faster than erlang, I investigated the
>>> erLLVM project
>>> >>>> which reported similar results to Hipe, you know
>>> performance is so
>>> >>>> important nowadays, what caused the hard to improve
>>> performace of
>>> >>>> erlang or just there are not people working on it?
>>> Erlang is
>>> >>>> attractive to me after several days studying, but with
>>> great
>>> >>>> performance will be more attractive and competitive to
>>> some languages
>>> >>>> such as go etc.
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> erlang-questions mailing list
>>> >>>> erlang-questions@REDACTED
>>> <mailto:erlang-questions@REDACTED>
>>> >>>> http://erlang.org/mailman/listinfo/erlang-questions
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> erlang-questions mailing list
>>> >>> erlang-questions@REDACTED
>>> <mailto:erlang-questions@REDACTED>
>>> >>> http://erlang.org/mailman/listinfo/erlang-questions
>>> >
>>> >
>>> > _______________________________________________
>>> > erlang-questions mailing list
>>> > erlang-questions@REDACTED
>>> <mailto:erlang-questions@REDACTED>
>>> > http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121109/5c414908/attachment.htm>
More information about the erlang-questions
mailing list