[erlang-questions] OTP-9649 and further changes

[Yurii Rashkovskii]

Björn,

I actually just did a totally unscientific test. I took the maint
branch, and ran 10,000,000 Mod:fn() calls where Mod was passed from
another function call and was just an atom. I ran it on maint, and on
my Mac Pro timer:tc clocked 446983 (that's 0.446 seconds).

After that, I brutally removed tuple call support from apply and
fixed_apply BIFs in beam_emu.c, making `if (is_not_atom(module))` go
straight to error label. I also removed `this` variable which was used
in those checks because there was no need for it anymore.

I re-ran the test, and timer:tc clocked 440680 and around.

So, the runtime cost difference was about 6000 microseconds, or 0.006
seconds, for 10 million calls. If I am not mistaking, this is a 1.35%
speedup on something as low cost as about 0.0446 microseconds per call
(or 0.0440 microseconds per call without support for tuple calls).

Is it this big of a difference to support the removal? What if we made
tuple calls a documented feature? I'd be glad to write an EEP to
support it.

You can find my test patch attached.

P.S. I also ran the same test for a tuple call (in the maint branch),
timer:tc clocked 545656 and around. So there is a penalty for using
tuple calls, but that's expectable and seems to be a reasonable
tradeoff for me.
P.P.S. Please let me know if something in this test is incorrect, I'd
be glad to improve it.


On Sun, Jun 10, 2012 at 10:52 AM, Yurii Rashkovskii <yrashk@REDACTED> wrote:
> Björn,
>
> I wanted to follow up on this. I am investigating this whiole issue
> (as I really would love to keep tuple calls) and I would like to know
> whether you have any numbers on how significant the speed impediment
> of this feature is (the run-time cost incurred in apply/3) that you
> mentioned earlier? Do you have any comparisons?
>
> Yurii
>
> On Mon, Jan 23, 2012 at 11:22 PM, Björn Gustavsson
> <bgustavsson@REDACTED> wrote:
>> 2012/1/24 Yurii Rashkovskii <yrashk@REDACTED>:
>>> Björn,
>>>
>>> Is there any way tuple module calls can be separated from parametrized
>>> modules and subsequently documented and become part of standard
>>> Erlang?
>>>
>>
>> Perhaps.
>>
>> The problem with the current implementation of "tuple modules"
>> is that the M in apply(M, F, A) and M:F(...) has a strange type, i.e. M can
>> be either an atom or a tuple. Unless we implement parameterized modules,
>> we want M to be only an atom. (There is a run-time cost in the
>> implementation of apply/3 to allow parameterized modules/"tuple modules",
>> and parameterized modules prevented an optimization I wanted to do in the
>> compiler for R15B.)
>>
>> We might consider an alternative implementation of "tuple modules"
>> that does not use apply(M, F, A) or M:F(...), using either new BIFs or new
>> syntax. (Example: tuple_module_apply(M, F, A) could behave as apply/3
>> currently behaves, or alternatively only allow M to be a tuple. This is not
>> a serious suggestion, just an example to make it clear what I mean.)
>>
>> I suggest that you write an EEP.
>>
>> --
>> Björn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 2236 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120610/83e8b7a9/attachment.obj>