Repository navigation
Temporal vs Non Temporal Stores
In computer architecture and programming, particularly in the context of memory operations and caching, "temporal" and "non-temporal" refer to hints provided to the processor about data locality. These concepts are crucial for optimizing performance in applications dealing with large datasets, such as multimedia processing, scientific computing, or data streaming.
Temporal stores assume the data will be reused soon (temporal locality), while non-temporal stores indicate the data won't be reused imminently, allowing the processor to bypass or minimize cache usage to prevent cache pollution.
Temporal Locality: This is the principle that if a memory location is accessed, it's likely to be accessed again soon. Standard store operations (e.g., regular MOV instructions in x86 assembly) leverage this by allocating space in the CPU cache, ensuring faster future access.
Non-Temporal (or Streaming) Stores: These are specialized instructions (e.g., MOVNTI or SSE streaming stores like MOVNTPS in Intel architectures) that signal to the processor that the data being stored has no temporal locality—meaning it won't be read back soon. Instead of filling the cache, the data is written directly to memory or uses a write-combining buffer, which helps avoid displacing useful cached data.
Non-temporal stores are especially useful for write-once data patterns, like copying large arrays or processing video frames, where caching the output would waste resources.
| Aspect | Temporal Stores | Non-Temporal Stores |
|---|---|---|
| Data Reuse Expectation | High (data likely reread soon) | Low (data not reused in near future) |
| Cache Behavior | Allocates and fills cache lines for quick reuse | Bypasses cache; uses write-combining or direct memory write to avoid pollution |
| Performance Benefit | Reduces latency for repeated accesses | Improves throughput for streaming/large data; prevents cache thrashing |
| Use Cases | General-purpose code, loops with data reuse | Multimedia, large array copies, one-time writes (e.g., display lists in graphics) |
| Examples in x86 | Standard MOV, STORE instructions | MOVNTI, MOVNTPS, MOVNTDQ (SSE/AVX) |
| Potential Drawbacks | Can evict other useful data from cache if overused | May introduce bugs if misused; slower if data is unexpectedly reused |
Choose Temporal Stores for most scenarios where data exhibits reuse patterns, as they align with default caching mechanisms and exploit temporal locality to minimize memory access latency.
Opt for Non-Temporal Stores in performance-critical code involving non-reusable data, but use them cautiously—profile your application to ensure they provide a net benefit, as improper use can degrade performance.
Mess uses temporal stores by default because this behavior is closest to the behavior of most real applications. Most applications benefit from caching and exhibit temporal locality in their memory access patterns.
For architectures that support it, non-temporal stores can provide a closer-to-memory representation of the bandwidth-latency curves, but this comes at the cost of realistic application behavior modeling.
| Architecture | Non-Temporal Store | Temporal Store |
|---|---|---|
| x86-64 (AVX) | vmovntps |
vmovaps |
| x86-64 (AVX-512) | vmovntps zmm |
vmovaps zmm |
| ARM (NEON) | not currently exposed in Mess |
str q / stp q,q
|
| ARM (SVE) | stnt1d |
st1d |
| Power (VSX) |
stxvd2x (with hints) |
stxvd2x |
| RISC-V (RVV) | varies | vs |
Note: Not all architectures support non-temporal stores. Support varies by ISA and specific implementation.
Non-temporal stores can be toggled in include/KernelTypes.h:
// In KernelConfigMultiSeq
bool use_nontemporal_stores = false; // Default: disabled (uses temporal stores)To enable non-temporal stores:
- Edit
include/KernelTypes.h - Change
use_nontemporal_storestotrue - Rebuild the benchmark
On current ARM backends, this toggle changes the SVE store path (st1d to stnt1d). The current NEON paths do not expose a separate non-temporal store form in Mess.
Consider using non-temporal stores when:
- You want to measure closer-to-memory bandwidth curves
- You're benchmarking streaming workloads
- You want to avoid cache pollution effects
- You're studying raw memory system performance
Use temporal stores (default) when:
- You want to model realistic application behavior
- Your target applications exhibit temporal locality
- You're comparing with application-level benchmarks
- Load-Store-vs-Read-Write - Understanding memory operations
- Traffic generator setup - Kernel configuration
- Architecture-Support - Platform-specific details
