<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
From "The HiPE/x86 Erlang Compiler: System Description and
Performance Evaluation" (page 4):<br>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="column">
<blockquote>
<p><span style="font-size: 10pt;">HiPE extends the standard
Erlang/OTP runtime system to permit
Erlang processes to execute both interpreted code and native
machine code.</span><span style="font-size: 7pt;
vertical-align: 4pt;">3
</span></p>
<p><span style="font-size: 10pt;">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.<br>
</span>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
</p>
<p>
<title>paper.dvi</title>
<p><span style="font-size: 10pt;">Control flow between
interpreted and native code, e.g. at function calls and
returns,
is handled by a </span><span style="font-size: 10pt;
font-style: italic;">mode-switch </span><span
style="font-size: 10pt;">interface. The implementation
uses linker-generated </span><span style="font-size:
10pt; font-style: italic;">proxy
code stubs </span><span style="font-size: 10pt;">and </span><span
style="font-size: 10pt; font-style: italic;">software trap
return addresses </span><span style="font-size: 10pt;">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).
</span></p>
</p>
</blockquote>
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.<br>
<p>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.<br>
</p>
</div>
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.<br>
<br>
<div class="moz-cite-prefix">On 12-11-09 2:36 PM, Max Lapshin wrote:<br>
</div>
<blockquote
cite="mid:CAMxVRxChLrVfovk8Z+R-kGABAdVm0ewEa=yTh44LwUNRt23nEQ@mail.gmail.com"
type="cite">What exactly gives performance problems, when calling
from HiPE to beam and back?<br>
Marshalling arguments?<br>
<br>
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.<br>
<br>
Maybe there were some discussions on this mailing list about it?<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Nov 9, 2012 at 11:06 PM, Fred
Hebert <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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, <i>and</i> 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.<br>
<br>
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.<br>
<br>
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.
<div>
<div class="h5"><br>
<br>
<div>On 12-11-09 8:45 AM, Valentin Micic wrote:<br>
</div>
<blockquote type="cite">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.
<div>
<div>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?</div>
<div><br>
</div>
<div>V/</div>
<div>
<div><br>
</div>
<div><br>
<div>
<div>On 09 Nov 2012, at 3:34 PM, Max
Bourinov wrote:</div>
<br>
<blockquote type="cite">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.
<div><br>
</div>
<div><br clear="all">
<div>Best regards,</div>
<div>Max</div>
<br>
<br>
<br>
<br>
<div class="gmail_quote">On Fri, Nov 9,
2012 at 5:16 PM, Valentin Micic <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:valentin@pixie.co.za"
target="_blank">valentin@pixie.co.za</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Unrelated,
but would be interesting to find out
-- are there any commercial-grade
(let alone carrier-grade) systems
that take advantage of HiPE?<br>
<span><font color="#888888"><br>
<br>
V/<br>
</font></span>
<div>
<div><br>
On 09 Nov 2012, at 2:11 PM,
Schneider wrote:<br>
<br>
> you're right. HIPE
generates compiled code.<br>
> my mistake.<br>
> take a look here for more
info's about HIPE:<br>
> <a moz-do-not-send="true"
href="http://user.it.uu.se/%7Ekostis/Papers/erlang03.pdf"
target="_blank">http://user.it.uu.se/~kostis/Papers/erlang03.pdf</a><br>
><br>
> greatz Johannes<br>
><br>
><br>
> On Fr 09 Nov 2012 13:07:49
CET, Matti Oinas wrote:<br>
>> Correct me if I'm wrong
but doesn't HIPE compile to
native code?<br>
>><br>
>> --<br>
>> Matti<br>
>><br>
>> On Fri, Nov 9, 2012 at
1:57 PM, Schneider <<a
moz-do-not-send="true"
href="mailto:js@globe.de"
target="_blank">js@globe.de</a>>
wrote:<br>
>>> Erlang is a
language, which produced
byte-code which get' interpreted
by the<br>
>>> Erlang engine. C++
instead generates mashing-code
which has on the one hand<br>
>>> a much better
performance, on the other hand,<br>
>>> some disadvantages
like incompatibility between
different OSs.<br>
>>><br>
>>> greatz Johannes<br>
>>><br>
>>><br>
>>> On Fr 09 Nov 2012
09:42:21 CET, hume npx wrote:<br>
>>>><br>
>>>> Hi, all:<br>
>>>> I'am new to
erlang, after investigate some
benchmark such as at<br>
>>>> <a
moz-do-not-send="true"
href="http://shootout.alioth.debian.org/u64q/which-programs-are-fastest.php"
target="_blank">http://shootout.alioth.debian.org/u64q/which-programs-are-fastest.php</a>,<br>
>>>> I found that
erlang compiler is not so good
at speed? the benchmark<br>
>>>> shows that
erlang Hipe is 13x slowdown
compared to C++, as compared to<br>
>>>> Haskell GHC
(3.3x slowdown), go 2.98x
slowdown or even javascript v8<br>
>>>> is about 1x
faster than erlang, I
investigated the erLLVM project<br>
>>>> which reported
similar results to Hipe, you
know performance is so<br>
>>>> important
nowadays, what caused the hard
to improve performace of<br>
>>>> erlang or just
there are not people working on
it? Erlang is<br>
>>>> attractive to
me after several days studying,
but with great<br>
>>>> performance
will be more attractive and
competitive to some languages<br>
>>>> such as go etc.<br>
>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>>
erlang-questions mailing list<br>
>>>> <a
moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
>>>> <a
moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
>>><br>
>>><br>
>>><br>
>>>
_______________________________________________<br>
>>> erlang-questions
mailing list<br>
>>> <a
moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
>>> <a
moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
><br>
>
_______________________________________________<br>
> erlang-questions mailing
list<br>
> <a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
erlang-questions mailing list
<a moz-do-not-send="true" href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a>
<a moz-do-not-send="true" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>