This paper considers implementing the Object Oriented Programming Model directly in the hardware to serve as a base to exploit object-level parallelism, speculation and heterogeneous computing. Towards this goal, we present a new execution model called Object
Oriented execution Model - OOM - that implements the OO Programming Models. All OOM hardware structures are objects and the OOM Instruction Set directly utilizes objects while hiding other complex hardware structures. OOM maintains all high-level programming language information until execution time. This enables efficient
extraction of available parallelism in OO serial code at
execution time with minimal compiler support. Our results
show that OOM utilizes the available parallelism better
than the OoO (Out-of-Order) modelPeer ReviewedPostprint (published version

Cristal Kestelman, Adrián

González Blanco, Ruben

Markovic, Nikola

Nemirovsky, Daniel

Unsal, Osman Sabri

Valero Cortés, Mateo

English

UPCommons. Portal del coneixement obert de la UPC

1Object Oriented execution Model (OOM)Nikola Markovic †, Daniel Nemirovsky †, Ruben Gonzalez ł, Osman Unsal †,Mateo Valero †, Adrian Cristal †‡Barcelona Supercomputing Center (BSC) †c/ Jordi Girona, 31 08034, Barcelona (Spain)Chalmers University of Technology (CUT) łSE-412 96 Gothenburg (Sweden)Artificial Intelligence Research Institut - Spanish National Research Council (IIIA-CSIC) ‡E-08193 Bellaterra, Catalonia (Spain){nikola.markovic,daniel.nemirovsky, osman.unsal,mateo.valero, adrian.cristal}@bsc.es,rgonzalez@chalmers.seAbstract—This paper considers implementing the ObjectOriented Programming Model directly in the hardwareto serve as a base to exploit object-level parallelism,speculation and heterogeneous computing. Towards thisgoal, we present a new execution model called ObjectOriented execution Model - OOM - that implements theOO Programming Models. All OOM hardware structuresare objects and the OOM Instruction Set directly utilizesobjects while hiding other complex hardware structures.OOM maintains all high-level programming languageinformation until execution time. This enables efficientextraction of available parallelism in OO serial code atexecution time with minimal compiler support. Our resultsshow that OOM utilizes the available parallelism betterthan the OoO (Out-of-Order) model.Index Terms—Object-Oriented, parallel and asyn-chronous execution.I. INTRODUCTIONTHE Chip Multi Processor (CMP) has made a greatimpact on processor design during the past twodecades since CPU design hit the power wall. Duringthe 1990’s, computer architects presented several CMPdesigns [15], [16]. It provides several advantages over thecentralized superscalar approach [8]. Firstly, the simpledesign of CMP enables high clock rate and allows theimplementation of fast communication network in eachof the processing units. Additionally time-consumingdesign validation phase is alleviated. Finally, availablesilicon space is better utilized [6]. In the past tenyears, many high-performance processor vendors haveintroduced designs that can execute multiple threadssimultaneously on the same chip through simultaneousmultithreading [10], multiple cores [17] or a combinationof the two [11]. These designs utilize nonspeculativeThread-Level Parallelism (TLP) smoothly.Nevertheless, the execution time of a sequential appli-cation or of a single thread of a parallelized applicationstill suffers from the same issues as twenty years ago.Lam et al. [9] shows that finding a significant levelof parallelism in numerical programs where controlflow is not data dependent is a simple task for thecompiler, however that is not the case if the controlflow is data dependent. The study also points out thatin case of non-numerical programs, processors that donot support speculative execution will hardly be efficientin extracting parallelism. Recent approaches that areusually referred to as speculative TLP decrease theexecution time of these applications. These approachesexecute several speculative threads in parallel. Threadsare speculative in the sense that they can be data orcontrol dependent on other threads and therefore theirproper execution and commitment are not guaranteed.Two main ways to leverage speculative TLP are reducingthe execution time of high-latency instructions by meansof side effects with helper threads [3], [4], [13] andparallelizing the application into speculative threads forexample in [1], [7], [14] among others.On the other hand, writing parallel applications formulticore processors still appears to be an extremelydifficult task for ordinary programmers [12]. A solution,we believe, is to allow programmers to continue workingwith the most successful programming model to date,the Object-Oriented model, and to move the complexityof parallelization of sequential applications for multiplehomogeneous or heterogeneous cores to hardware. Asa way of accomplishing that, we propose a new andunique execution model, leveraging an Object-Oriented2(OO) programming model. We see it as an architecturethat ports software concepts into hardware by formingan abstract, virtual hardware layer. This hardware layeris able to preserve semantic information specified by theprogrammer in a high level language for execution time.In this paper, we present an Object Oriented executionmodel. In contrast to previously mentioned proposalsthat tend to leverage parallelism by extracting blocksof instructions with the least possible amount of dataand control dependences and forming separate threadsout of them, our OO model exploits parallelism bypreserving and leveraging information available at thehigh level programming language code to hardware. Ourmodel represents data as objects, user defined functionsas contexts, and operations - hardware implementedinstructions and functions eg. add, sub, cmp, etc. Anobject can store and manage multiple versions of adata value. Each context has its own memory space.By having memory space per context, we are breakingthe traditional stack into smaller pieces. The model alsodefines a new ISA that consists of three basic instructionsand operations.The OO model provides two main advantages. First,better data locality, where objects are smaller units of lo-cality. Second, an asynchronous, control independent andparallel execution which preserves the sequential view ofprogram. The methods are executing asynchronously, intheir own context without any other interferences, whereinput/output parameters are sent in an asynchronous way.This opens up possibilities for dynamic optimization,which was not feasible at compile time. We compare thelevel of available parallelism, on the quicksort algorithmapplied on a linked list. Our results show that the idealOOM utilizes better available parallelism than the idealOoO (Out-of-Order) model. It is also able to exploitapproximately the same level of parallelism for differentlevels of operation granularity, which makes it veryflexible compared to the OoO model.II. MODEL EXPLANATIONIn this section, we describe the Object Oriented execu-tion Model. First we describe OOM Instruction Set Ar-chitecture (ISA), explaining in detail the most importantISA instructions and their functionalities. Second, weexplain the concept of objects in our model. We providea detailed description of each object’s functionality andits role in OOM. Finally we provide an explanationof an asynchronous, control independent and parallelexecution flow.A. OOM ISAThis ISA consists of three basic instructions andoperations. Operations are hardware-implemented in-structions or functions e.g. add, sub, cmp, etc. Thethree basic instructions are: call , send and select . Theinstruction call triggers the execution of a context or anoperation. send sends the reference of an object to acontext or operation, while select fetches references ofobjects encapsulated inside of an object - class attributes.A set of these instructions is assigned to each context(similar to the instructions inside of a function).Each call instruction inside the list of instructions ofa context has a unique sequential number. This numberis statically assigned at compile time and representsthe sequential order in which the context or operationinvoked should be committed inside of the calling con-text, like a sequential order of operation inside of thefunction. While executed call instruction also assignsa dynamically calculated ID to the created context oroperation. The call instruction calculates the ID based onits parent context ID and the sequential number assignedto it inside its parent context. This ID represents theposition of the invoked context or operation inside globalsequential commit view of the program.B. OOM ObjectsThe OO model defines two types of objects: objectand context. User defined functions and methods arerepresented as a kind of an object called context. Thecontext has its own memory space where it stores ref-erences to objects that are argumenta and local valuesof a user defined function or method. It also has the listof instructions. The heart of the OO model are objectswhich manage and store the data and behave ”like hard-ware threads”. All objects are hardware implemented.The objects can be divided into two different kinds. Firstkind of objects are basic objects. These objects are forbasic types like int, float, bool, char, etc. The basic objectstores and manages multiple versions of data through aversioning mechanism, explained in Subsection II-B1.The second kind of objects are complex objects. Theyare for user-defined types like classes and structures. Thecomplex object has a set of references to other basicor complex objects e.g. attributes of a class, fields of astructure, etc.Since each data type has a set of instructions ormethods that can be performed on it, for the basic typeslike int they are the instructions like sub, add, cmp, mov,etc. while for the class they are the methods and thefunctions of the class, each basic object has the set of3operations and complex object has the set of contextsthat can be performed on it.Both kinds of objects behave “like hardware threads”of execution. When an instruction call is executed, a newmessage is sent to an object to execute one of its contextsor operation. Objects manage a list of its contexts oroperations scheduled for execution and executes themwhen it gets the processor.1) Versioning mechanism: A basic object has a tableof values. The table of values has two fields: a key and avalue. The table key is ID of operations that produced thevalue. Whenever some operation produces a new valuefor the object, a pair consisting of the operation’s ID andthe produced value is stored in the basic object table.An entry to the table whose corresponding key is the IDof a committed operation is called a committed entry.Only one entry at the time can be the committed entry,all other entries are considered to be speculative entries.Allthough the entries may be stored out-of-order in thetable, they are always committed in a sequential orderwhen an operation corresponding to the key in the tableis committed. As the new entry becomes the committedentry, the previous committed entry is deleted from thetable along with any entries stored by mis-speculativelyexecuted operations.C. OOM executionIf the static program control flow is represented as adirected graph, where nodes are contexts and operationsand arcs represent flow from one node to another, thenthe program execution can be viewed as going throughthat directed graph. The fact that the traditional stackis broken allows this directed control flow graph of thestatic program to be represented through smaller directedgraphs where each small graph contains only contextsthat share memory space. Small graphs become nodes ofthe large graph. Allthough data and control dependenciesbetween small graphs still remain, their instructionsand operations can be scheduled for parallel executionon different processing units. The fine granularity ofoperations inside contexts allows for the execution ofonly those instructions and operations that have theirinput data ready.III. OOM ARCHITECTUREIn Fig. 1. we present a possible architecture for theObject Oriented execution Model. The Object Creationand Allocation Unit creates objects and assigns them tothe Object Processors. Each Object Processor is associ-ated with a scratch pad memory called Object Memory.Several objects can be mapped on the same Object  ObjectMemoryObjectProcessorMainMemoryObject Creation & Allocation UnitCompiled Application CodeShared ObjectReferencesMultiprocessor,CMP, SMT,FPGA,Vector PorcessorFig. 1. Object-Oriented execution Model architectureProcessor. Shared Object References is a scratch padmemory shared by all Object Processors in the system.It keeps information where each object is located.An Object Processor is the minimum execution unit.The OOM Architecture is a group of Object Proces-sors collaborating to do execution. This Architectureimplements a Virtual Hardware layer (Object Orientedexecution Model). Each Object Processor is internallyflexible. It can support different hardware implementa-tions. Flexible Internal Hardware Model of the ObjectProcessor can be managed by many possible cores e.g.Out-of-Order processor, In-order processor (embedded),Multiprocessor, Vector processor, Processor + FPGA(Reconfigurable Architectures), Data flow processor, etc.IV. RESULTSTo depict the available parallelism for the quicksortalgorithm on the linked list we used DDG (DynamicDependency Graph) analysis methodology of the algo-rithm presented in [2]. The DDG of the program is apartially ordered, directed, acyclic graph where the nodesof the graph represent computation that occurred duringthe execution of the program, and the edges representdependencies that force a specific order on the executionof the instructions. To give an upper bound on theavailable parallelism, we analyze a DDG containing onlytrue data dependencies. For the ideal OoO model weused the Pin Tool to generate traces, while for the idealOOM we implemented the functional level simulatorto generate traces. For the ideal models we take thatall instructions, memory accesses and messages sentthrough interconnection network take one cycle.Fig. 2. shows the available parallelism (note thathorizontal axis represents the list size as the number ofelements in the list). For the ideal OOM, we present4050100150200250OoO InstOoO BBOOM FGOOM CGList sizeAvailable Parallelism10 100 1000 10000 100000Fig. 2. Available parallelism of the quicksort algorithm on the linkedlist - for the ideal OoO model on the instruction and basic block leveland for the ideal OOM model on fine and coarse grained levelresults for two levels of operation granularity. First oneis fine granularity where the operations are like sub, add,cmp, etc. instructions of the basic types int, float, etc. Thesecond one is coarse grained where the operations arewhole functions like function that adds an element to thelist, function that pops an element form the list, etc. ofthe class types list. Results from Fig. 2. show that whilethe ideal OoO model always extracts approximately thesame level of parallelism, on the other hand our idealOOM is able to extract more parallelism as the number ofobject and the instructions executed in system increases,and even outpacing the OoO model, because it exploitsdata locality in a natural way. Fig. 2. also shows that ourmodel is able to extract almost the same level of availableparallelism for different granularity of operations, whichis not the case for the OoO model.V. CONCLUSION AND FUTURE WORKThe goal of this paper has been to propose a newexecution model that moves the high-level programminglanguage paradigm closer to hardware. It is based on theObject Oriented Language Model, being one of the mostsuccessful models, extracts better data and execution lo-cality and helps to apply hardware optimizations relatedto parallelism and speculation more effectively.The OO execution Model offers a novel asynchronous,control independent, parallel and object-aware execu-tion model. In this model, methods are executed asyn-chronously in their own context, where all input/outputcommunication between them is done in an asyn-chronous way. This OO execution model can offer avery aggressive approach in speculative scenarios. Theprocessor based on OOM does not require deterministichardware. Its execution unit can use anything from a sim-ple execution unit, FPGA, OoO Processor, MultithreadedProcessor, to a complex CMP. The OO execution modelmanages the execution of OOM ISA code through aspecial software/hardware virtual layer. This opportunityopens interesting windows for heterogeneous executionwhere some objects can be bound to specific hardware.Finally, we have demonstrated that the ideal OOMutilizes the available parallelism better than the idealOoO model and that it is able to extract almost the samelevel of parallelism on fine and coarse grained level whilethe OoO model fails to do so. We will continue workingon our functional level simulator, to extend it and portit to an FPGA board using Bluespec environment.REFERENCES[1] H. Akkary, M. Driscoll, ”A Dynamic Multithreading Processor”,Proc. 31st Int’l Symp. on Microarchitecture, pp. 226, 1998.[2] T. Austin, G. Sohi, ”Dynamic Dependency Analysis of OrdinaryPrograms”, The 19th Int’l Symp. on Computer Architecture, pp.342, 1992.[3] R. Chappel, J. Stark, S. Kim, S. Reinhardt, Y. Patt, ”SimultaneousSubordinate Microthreading (SSMT)”, Proc. 26th Int’l Symp.Computer Architecture, pp. 186-195, 1999.[4] J. Collins, H. Wang, D. Tullsen, C. Hughes, Y. Lee, D. Lavery,J. Shen, ”Speculative Precomputation: Long Range Prefetchingof Delinquent Loads”, Proc. 28th Int’l Symp. Computer Archi-tecture, pp. 14, 2001.[5] M. Fillo, S. Keckler, W. Daly, N. Carter, A. Chang, Y. Gurevich,W. Lee, ”The M-Machine Multicomputer”, Proc. 28th Int’l Symp.Computer Microarchitecture, pp. 146, 1995.[6] L. Hammond, B. Neyfeh, K. Olukotun, ”A Single-Chip Multi-processor”, Computer,vol. 30, no. 9, pp. 79, 1997.[7] L. Hammond, M. Willey, K. Olukotun, ”Data Speculation Sup-port for a Chip Multiprocessor”, Proc. 8th Int’l Conf. Archi-tectural support for Programming Languages and OperatingSystems, 1998.[8] M. Johnson, ”Superscalar Microprocessor Design”, PrenticeHall, 1990.[9] M. Lam, R. Wilson, ”Limits of Control Flow on Parallelism”,Proc. 19th Int’l Symp. Computer Architecture, pp. 46, 1992.[10] T. Marr et al., ”Hyperthreading Technology Architecture andMicroarchitecture”, Intel Technology J.,vol. 6, no. 1, 2002.[11] A. Mendelson et al., ”CMP implementation in the Intel CoreDuo Processor”, Intel Technology J., vol. 10, no. 2, 2006.[12] D.Patterson et al., ”The parallel computing landscape: a Berke-ley view”, Low Power Electronics and Design, pp. 231, 2007.[13] A. Roth, G. Sohi, ”Spevulative data-driven Multithreading”,Proc. 7th Int’l Symp. High-Performance Computer Architecture,pp. 37, 2001.[14] S. Sarangi, W. Liu, J. Torrellas, Y. Zhou, ”ReSlice: SelectiveRe-Execution of Long-Retired Misspeculated Instructions UsingForward Slicing”, Proc. 38stInt’l Symp. on Microarchitecture, pp.257, 2005.[15] J. Smith, S. Vajapeyam, ”Trace Processors: Moving to FourthGeneration Microarchitectures”, IEEE Computer,vol. 30, no. 9,pp. 68, 1997.[16] G. Sohi, S. Breach, T. Vijaykumar, ”Multiscalar Processors”,Proc. 22nd Int’l Symp. Computer Architecture, pp. 414, 1995.[17] S. Storino, D. Borkenhagen, ”A Multithreaded 64-bit PowerPCCommercial RISC Processor Design”, Proc. 11th Int’l Conf.High-Performance Chips, 1999.[18] D. Tullsen, S. Eggers, H. Levy, ”Simultaneous Multithreading:Maximizing On-Chip Parallelism”, Proc. 22nd Int’l Symp. Com-puter Architecture, pp. 392, 1995.

Object oriented execution model (OOM)

This paper considers implementing the Object Oriented Programming Model directly in the hardware to serve as a base to exploit object-level parallelism, speculation and heterogeneous computing. Towards this goal, we present a new execution model called Object

Oriented execution Model - OOM - that implements the OO Programming Models. All OOM hardware structures are objects and the OOM Instruction Set directly utilizes objects while hiding other complex hardware structures. OOM maintains all high-level programming language information until execution time. This enables efficient

extraction of available parallelism in OO serial code at

execution time with minimal compiler support. Our results

show that OOM utilizes the available parallelism better

than the OoO (Out-of-Order) modelPeer Reviewe

UPCommons

https://upcommons.upc.edu/bitstream/2117/24801/1/Object%20Oriented%20execution%20Model%20%28OOM%29.pdf

Object oriented execution model (OOM)

Abstract

Similar works

Full text

Available Versions

UPCommons. Portal del coneixement obert de la UPC

UPCommons