Graph Compilation Concurrency Control for Latency and Resource Tradeoffs

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing graph-based program compilation methods fail to optimize computational latency and efficiency effectively, as they do not adequately differentiate between components that can concurrently execute and those that cannot, leading to suboptimal performance in terms of latency and resource utilization.

Innovation Solution

The approach groups components into execution sets based on an optimality criterion that allows concurrency only where it results in improved computational efficiency and reduced latency, using a compiler/interpreter to identify and prepare execution sets for parallel execution on a computing platform with multiple nodes, enabling flexible data and control flow management through different types of ports.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If components are allowed to execute concurrently to reduce computational latency, then execution time is reduced, but resource overhead and system complexity increase

Engineering Contradiction:
Improvecomputational latencyVSAvoidresource overhead
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The system segments components into execution sets based on their concurrency characteristics. High-latency operations are identified and placed in separate execution sets that can run concurrently, while low-latency operations are grouped together to execute sequentially. This segmentation allows the system to selectively apply concurrency only where it provides benefit, reducing unnecessary resource overhead while still achieving latency reduction for critical operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The compilation system dynamically determines the execution model for each component based on its latency characteristics. The system adapts its resource allocation and execution strategy according to the specific needs of each operation, allowing flexible transition between sequential and concurrent execution modes. This dynamic approach optimizes the balance between latency reduction and resource utilization for each component individually.

Inventive Principle:
Principle #15Dynamics

2Productivity

If all components are grouped into execution sets for parallel execution, then throughput increases, but execution efficiency decreases due to unnecessary parallelization overhead

Engineering Contradiction:
ImprovethroughputVSAvoidexecution efficiency
Core Design Contradiction:
ProductivityVSPower

Solution Approach 1:

The system applies different execution qualities to different components based on their local characteristics. High-latency components receive the quality of concurrent execution with full parallelization benefits, while low-latency components receive sequential execution to avoid parallelization overhead. This local differentiation ensures that each component executes with the most appropriate mode for its specific needs, optimizing overall system efficiency.

Inventive Principle:
Principle #3Local quality

Solution Approach 2:

Instead of applying full parallelization to all components, the system applies partial parallelization only to the extent necessary. By identifying and isolating only the high-latency operations that benefit from concurrency, the system avoids the excessive action of parallelizing low-latency operations where it would provide no benefit and would only add overhead. This selective approach maintains high throughput for critical paths while preserving execution efficiency for non-critical operations.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP3335116B1Data processing graph compilation
Publication Date: 2024.10.23 AB INITIO TECHNOLOGY LLC
  • EP3335116B1 patent drawingFigure 1
  • EP3335116B1 patent drawingFigure 2~4
  • EP3335116B1 patent drawingFigure 5A~5D

AI summary

A received graph-based program specification (900, 1000) includes: a plurality of components (658, 660, 662), each corresponding to at least one operation; and a plurality of directed links each connecting an upstream component to a downstream component. Processed code is generated representing one or more groups of operations by: identifying a possible level of concurrency in a first group of operations based at least in part on a topology of the graph, such that multiple operations in the first group are not prevented by the topology of the graph from executing concurrently; analyzing at least some of the operations in the first group to determine runtime characteristics associated with the analyzed operations; and generating processed code for executing the operations, where the processed code enforces a reduced level of concurrency in the first group, lower than the identified possible level of concurrency, based at least in part on the determined runtime characteristics.