CSC/ECE 517 Fall 2009/wiki1b 11 cc
Static vs. dynamic o-o languages from the perspective of performance
Object-oriented languages can be analyzed into either dynamical or statical language by their type handling mechanism. The former delays the type decision until run time ( type feedback ), in turn the latter determines and strongly restricts type usage in compile time (concrete type inference ).
One parameter to measure the performance of the code are calls, they not only slow down the program through the calling overhead but also the opportunities to optimize the code are destroyed because of dynamically-dispatched calls. Object oriented programs tendency is to contain more calls at the source level rather than at procedural level since the programming style in object oriented encourages factoring code into small pieces to obtain fine-grained reuse, this pactice makes more difficult the optimization and thus the performance.
It is important to mention that traditional compilers are unable to remove dynamical calls, therefore the object oriented programs usually exhibit a higher calling frequency than procedural programs. The frequent calls, combined with the scarce opportunities for traditional code optimizations, can lead to poor run-time performance.
To eliminate dynamical calls by statically binding or in-lining them, however it is not that easy, even for the statically-typed lenguages
Consider the following C++ code fragment:
GraphicalObject* obj;
...
obj->moveTo(0, 0);
Although the type declaration, a compiler cannot statically bind the “moveTo” call because it does not know the object’s exact class and thus it cannot determine whether “Point::moveTo” or “Rectangle::moveTo” will be invoked.
Type Inference
Static Object-Oriented Language ( type inference TI)
Statically-typed languages require that all variables are declared with a specific type. The compiler will then ensure that at any given time the variable contains only an object compatible with that type. By enforcing the type constraint on objects contained or referred to by the variable, the compiler can ensure calling method error can never occur at run-time. It enforces safer, more reliable code, and increases efficiency of the resulting product as well. On the other hand, a static type system can hinder evolution of software in some circumstances. Upper classes restrict the inherited ones evolving into various form from its strict type-binding. Eiffel , Java , C# , C++ , Visual Basic
Type Feedback
Dynamic Object-Oriented Language ( type feedback TF)
A dynamic type system doesn't require variables to be declared as a specific type. Any variable can contain any value or object. In many cases this can make the software more flexible and amenable to change. However, care must be taken that variables hold the expected kind of object. Typically, if a variable contains an object of a different type than a user of the object expects, some sort of calling method error is raised at run-time. On the other hand , if the type of the object is not what it was originally expected to be, it may not understand the messages being sent to it. Even worse that it may be interpreted in a wrong way. Smalltalk , Ruby , Python , Perl
Performance Comparison
Table. Performance comparison of type inference and type feedback.
CounterAct
Dynamic O-O languages monitors previous executions of the program to determine the set possible receiver classes. In turn , Static O-O languages computes the set of possible receiver classes by analyzing the program’s source code. This characteristics bring consideration opposed to the belief that the static O-O languages are efficient in performance. Compilers cannot predict the typical usage. With this reason, statical way shows more overhead when leading to calling methods called infrequently in case that the methods are small subset of vast method pool. Therefore a benchmarking in performance was made in [Set reference], to evaluate the relative performance of dynamic and static programs, in order to accomplish this the programs were divided into three groups,
• “Tiny” is a set of very small integer programs on which one would expect type inference to do particularly well since these programs do not use polymorphism. They are included for reference only.
• “Small” is a set of small benchmarks which primarily operate on integers and arrays and contain little polymorphism. These benchmarks are intended to represent the kernels of computationally intensive programs.
• “Large” is a set of application programs which were written by several different programmers and exhibit a variety of object-oriented programming styles.
After that a suite of 23 benchmarks were executed, Table XX shows them
The focus will be on the "Large" set of applications since they are closer and realistic to the common applications, the following segment gives the definitions of TF and TI, their analysis and results of performance are based on them, TF and TI are Techniques to optimize dynamic and static code.
Execution Time:
Speed is the ultimate goal of an optimizing compiler. Figure 1 shows the relative execution time of the benchmarks compiled with TF and TI systems
Number of dispatches:
A dispatch is the selection of the correct piece of code for a particular receiver-message pair, a dispatch is independent of whether it requires a call or not. By measuring the number of dispatches that a program performs, it is possible to determine the performance in creating monomorphic call.
Type inference (TI) can determine the exact receiver class for many sends. Since such sends no longer require a dispatch, the overall number of dispatches is reduced.
In contrast, type feedback (TF) requires a dispatch test even if it predicts a single class, because the receiver type always includes the unknown class. Therefore, one would expect TI-compiled programs to execute strictly fewer dispatches than TF-compiled programs.
The benchmark results are shown in Figure (XX)
References
External Links