Graph-Based Program Specification Compiler for Parallel Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing graph-based computation systems face inefficiencies in execution, particularly in reconfiguring data parallelism, load balancing, and startup times, due to unnecessary process initiation and memory wastage, and lack mechanisms for efficient data passing and scheduling between computation components.
Innovation Solution
A computing system that includes a storage system for graph-based program specifications with a compiler generating a target program specification by recognizing different link configurations between components, enabling dynamic optimization of computing resources and control/data flow constraints, and using buffers to manage data flows, allowing for concurrent execution and efficient resource allocation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If processes are initiated at the start-up of graph execution, then components can be executed in parallel, but startup time increases and memory is wasted due to unnecessary process initiation
Solution Approach 1:
The system performs preliminary actions by pre-configuring the execution environment, compiling the graph specification into an optimized execution plan, and pre-allocating resources before actual graph execution begins. This eliminates the need to initiate processes at startup, reducing startup time while maintaining parallel execution capability.
Solution Approach 2:
The system dynamically adjusts process initiation based on actual execution needs rather than pre-initiating all processes. The execution engine dynamically spawns processes for components that need to run in parallel, avoiding unnecessary process initiation and reducing both startup time and memory waste.
2Productivity
If multiple processes are used to execute components, then parallelism is achieved, but memory consumption increases due to process overhead
Solution Approach 1:
The system merges multiple component executions into a unified execution context where possible, sharing common resources such as memory spaces, data buffers, and execution environments. This reduces the per-process memory overhead while maintaining parallel execution capability through coordinated multi-threading or process sharing.
Solution Approach 2:
The system creates universal process templates that can serve multiple components with similar execution requirements. Instead of creating dedicated processes for each component, a single process template can be instantiated and reused across multiple components, reducing overall memory consumption while supporting parallelism.
3Ease of operation
If data flows are implemented using operating system data communication services, then data can be passed between components, but communication overhead and latency increase
Solution Approach 1:
The system introduces an intermediary execution engine that sits between components and manages data flow directly, bypassing operating system data communication services. This intermediary maintains efficient in-memory data buffers and manages data passing between components through shared memory or direct memory access, significantly reducing communication overhead and latency while maintaining ease of operation.
4Adaptability or versatility
If instances of components are hosted on separate server computers, then distribution is achieved, but reconfiguration and load balancing become difficult
Solution Approach 1:
The system implements dynamic component placement and reconfiguration capabilities where the execution engine can dynamically assign components to different servers or computing nodes based on current load conditions, resource availability, and performance requirements. This maintains distribution capability while making reconfiguration and load balancing straightforward through centralized control and dynamic scheduling.
Data Source
Figure 1
Figure 2A~2B
Figure 2C
AI summary
A graph-based program specification (110) includes components corresponding to tasks and directed links between ports of the components, including: a first type of link configuration between ports of linked components, corresponding to transfer of control or transfer of a single data element, and a second type of link configuration between ports of linked components, corresponding to transfer of multiple data elements. A compiler (120) generates a target program specification including control code representing at least one control graph including graph nodes representing the components, where at least two are connected based on links of the first type. A computing node (152) initiates execution of the target program specification, and manages computing resources for links of the second type, the computing resources including at least one of: a buffer for storing data elements provided by an output port, or a buffer for storing data elements provided to an input port.