In-Core Decompression API for Low-Latency Cacheline Processing

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current CPU performance is limited by DRAM and interconnect bandwidth limitations, which cause delays in data transfer and are exacerbated by high latency in compression and decompression processes, even when using accelerators.

Innovation Solution

An Application Programming Interface (API) for fine-grained low-latency decompression within a processor core, utilizing a decompression engine and a hardware-accelerated instruction (DISA) that decompresses data in cachelines, allowing speculative out-of-order processing and signaling the core upon completion, thereby reducing latency and increasing bandwidth.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If data compression is used to reduce memory bandwidth requirements, then bandwidth efficiency is improved, but decompression latency increases and becomes a performance bottleneck

Engineering Contradiction:
Improvememory bandwidth requirementsVSAvoiddecompression latency
Core Design Contradiction:
Quantity of substanceVSLoss of time

Solution Approach 1:

The decompression operation is divided into fine-grained per-cacheline units rather than operating on large compressed blocks. Each cacheline decompression is independent and can be completed quickly, reducing per-operation latency while still achieving overall bandwidth compression.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Data is pre-compressed and stored in compressed form in the cache hierarchy. When the processor core needs the data, it is already in compressed format ready for rapid decompression, eliminating the need for on-demand compression and reducing latency.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 3:

A dedicated decompression engine acts as an intermediary between the compressed data in memory and the processor core. This specialized hardware unit handles decompression operations efficiently, isolating the latency impact from the core execution pipeline.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Quantity of substance

If traditional compressors are used, then data compression is achieved, but they occupy valuable processor resources and increase decompression latency

Engineering Contradiction:
Improvedata compression capabilityVSAvoidprocessor resource availability
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The decompression function is extracted from the general-purpose processor core and implemented as a separate dedicated engine. This allows the core to focus on computation while the decompression engine handles data decompression independently, freeing up processor resources.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

A dedicated decompression engine serves as an intermediary component between memory and the processor core. This specialized hardware unit handles all decompression operations, preventing them from consuming valuable core cycles and maintaining high processor productivity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS12028094B2Application programming interface for fine grained low latency decompression within processor core
Publication Date: 2024.07.02 INTEL CORP
  • US12028094B2 patent drawing
  • US12028094B2 patent drawing
  • US12028094B2 patent drawing

AI summary

Methods and apparatus relating to an Application Programming Interface (API) for fine grained low latency decompression within a processor core are described. In an embodiment, a decompression Application Programming Interface (API) receives an input handle to a data object. The data object includes compressed data and metadata. Decompression Engine (DE) circuitry decompresses the compressed data to generate uncompressed data. The DE circuitry decompress the compressed data in response to invocation of a decompression instruction by the decompression API. The metadata comprises a first operand to indicate a location of the compressed data, a second operand to indicate a size of the compressed data, a third operand to indicate a location to which decompressed data by the DE circuitry is to be stored, and a fourth operand to indicate a size of the decompressed data. Other embodiments are also disclosed and claimed.