[erlang-questions] OTP-9649 and further changes

[José Valim]

I believe it is also worth mentioning that according to Joe Armstrong "the
abuse of param modules are here to stay" and should be documented:

https://groups.google.com/group/erlang-programming/browse_thread/thread/c59e72387167a834/82441aed16f8a7ba?show_docid=82441aed16f8a7ba&pli=1

Cheers,

*
José Valim
www.plataformatec.com.br
Founder and Lead Developer
*

On Sun, Jun 10, 2012 at 9:00 PM, Yurii Rashkovskii <yrashk@REDACTED> wrote:

> 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
> _______________________________________________
> erlang-questions mailing list
> 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/20120610/6a46c8ad/attachment.htm>