[erlang-questions] OTP-9649 and further changes

[Yurii Rashkovskii]

I also got a piece of advise to calculate the cost of running an empty
cycle on both versions of the runtime. It was about 70,000
microseconds on both. This means that while the speedup remains the
same, the cost of actual operations has to be dropped even lower, to
about 0.0370 microseconds per call (on that hardware)

On Sun, Jun 10, 2012 at 11:48 AM, Yurii Rashkovskii <yrashk@REDACTED> wrote:
> 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