Explore chapters and articles related to this topic
Considerations on the Use of Custom Accelerators for Big Data Analytics
Published in Kuan-Ching Li, Hai Jiang, Albert Y. Zomaya, Big Data Management and Processing, 2017
Vito Giovanni Castellana, Antonino Tumeo, Marco Minutoli, Marco Lattuada, Fabrizio Ferrandi
The proposed design supports parallel execution and dynamic scheduling through the introduction of an adaptive DC [57]. The DC consists of a set of communicating modules, each one associated with an operation. The approach does not require the definition of any execution order (scheduling) at design time, and allows runtime exploitation of parallelism. The controller modules, called execution managers (EMs), start the execution of the associated operations as soon as all their dependencies are satisfied and resource conflicts are resolved. The minimum set of dependencies each operation is subject to, called activating conditions (ACs), is computed by analyzing the Extended Program Dependence Graph (EPDG) of the algorithm, which extends a typical Program Dependence Graph (PDG) with control-flow information, such as loops' back edges. ACs are expressed as logic functions, and specifically synthesized for each EM. Instead, dedicated arbiters, called resource managers (RMs), associated to shared resources manage resource conflicts: if multiple operations compete for a resource, the arbiter establishes which one executes first, according to a priority ordering. EMs communicate through a lightweight token-based schema: each EM receives a token signal whenever a dependency gets satisfied. When the controller has collected all the AC tokens (i.e., all dependencies are satisfied), it checks for resource availability. If the resource associated with the operation is free, execution starts. The approach does not introduce any communication overhead, because it does not use any sophisticated protocol. Since every operation and function is managed independently, the DC can efficiently control several concurrent execution flows. Obtaining the same behavior with centralized FSMs is possible, but not cheap: in fact, the complexity of an FSM controller, in terms of number of states and transitions, is exponential with respect to number of flows. This complexity would lead to unfeasible designs even for relatively small degrees of TLP. The complexity of the DC instead grows linearly with the number of operations, regardless of the latency of the operations and of number of concurrent flows. Figure 14.4 proposes an example of EPDG, annotated with ACs and binding information, and the associated parallel controller architecture. Operations 3, 4, 5 are bound to the same resource C, while operations 6, 7 are bound to D: the corresponding EMs interface with RMs to avoid structural conflicts. In this example, all the operations have unknown latency (e.g., external memory accesses, function calls, speculative operations) and the completion of their execution is notified through explicitly done signals from the datapath to the EMs. If the execution latency is known at design time, this signaling is not required, and the EMs directly manage the timing.
Proactively managing clones inside an IDE: a systematic literature review
Published in International Journal of Computers and Applications, 2022
Sarveshwar Bharti, Hardeep Singh
Graph-Based: Program Dependency Graph (PDG) based techniques obtain the semantic representation like control flow etc. of the source code under consideration and then subgraphs are compared to find the similar subgraphs.