From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Real OO Date: 1996/03/27 Message-ID: <4jbmsk$uo5@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 144464317 distribution: world references: <4iuvmi$113p@watnews1.watson.ibm.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-03-27T00:00:00+00:00 List-Id: In article , donh@syd.csa.com.au (Don Harrison) writes: |> Quantitatively, what is the relative difference in efficiency of Jump to |> Subroutine compared with an Indirect Jump to Subroutine? In terms of instruction path length, just another one or two instructions per call. This by itself can be significant in a critical loop, but there are other costs as well. On a RISC machine, the use of an indirect branch instead of a direct one can disable branch prediction, resulting in I-cache misses that cause the machine to stall for the equivalent of several dozen instructions. In addition, the dynamic nature of the branch prevents inlining and interprocedural optimizations that depend on knowing which subprogram is called. |> As Joachim pointed out, Eiffel compilers typically optimise where possible. And as I pointed out, "where possible" tends to mean "in very few places" in practice, at least in the absence of profile-directed feedback. |> Perhaps optimisation by the developer would be more effective but remember |> that efficiency is being traded off against the power and flexibility of |> dynamic binding. No flexibility is being traded off. Your phrase "optimzation by the developer" conjures up images of programs made inflexible and inscrutable to improve efficiency, but that is not required with the Ada mechanism. All that is required is that, in a context where Rect1 and Rect2 are known to both have dynamic type Rectangle_Type, Rect1 and Rect2 should be declared to be of type Rectangle_Type rather than Shape_Type'Class. Then the call Corresponding_Parts_Equal(Rect1, Rect2) is resolved statically rather than dynamically. If anything, this increases the understandability of the code. -- Norman H. Cohen ncohen@watson.ibm.com