Is TEPS a measure of model accuracy?

No. It measures graph-processing rate under a defined workload; correctness and analytical quality require separate checks.

What does GTEPS mean?

Billions of traversed edges per second, using the applicable benchmark's definition of the counted edges.

Can two TEPS figures be compared directly?

Only with sufficient context. The graph, kernel, counting rules, timing boundaries and resources must be understood.

AI Glossary / Data engineering and architecture / Intermediate

Traversed edges per second

Definition

Traversed edges per second, or TEPS, is a performance rate used to describe graph-processing work. It divides a defined count of graph edges by the time taken for the measured operation. The Graph 500 benchmark uses TEPS to assess graph-search performance, with specific rules for counting edges, timing kernels, validating results and combining repeated runs.

What it means

A graph represents items as vertices and connections as edges. Searching a graph involves following or examining these connections to discover reachable vertices or determine paths. TEPS describes the speed of a specified graph operation, rather than the number of arithmetic instructions a processor can execute.

The word “traversed” needs context. In Graph 500, the numerator is a benchmark-defined edge count associated with the traversed component, not simply a hardware counter of every edge inspection performed internally. Two implementations may perform different amounts of internal work while being compared against the same normalized task definition.

How it works

A benchmark establishes the graph, operation, starting vertices and correctness criteria. The implementation runs the operation, its specified interval is timed and an edge count is calculated according to the benchmark rules. Dividing that count by elapsed seconds produces a rate.

Graph 500 distinguishes graph construction from its search kernels. Its specification defines the timed search interval and reports construction separately. It also specifies harmonic means for combining TEPS results across searches. A billion edges per second is one giga-TEPS, commonly written GTEPS.

The result reflects the implementation and machine together. Graph operations can involve irregular memory access, communication and synchronization, so arithmetic capability alone does not predict their speed. A meaningful report includes graph scale, algorithm or kernel, hardware resources and validation information alongside the rate.

Three practical examples

1. Graph analytics evaluation: A team compares breadth-first-search implementations on the same graph workload, checking that both return valid results before comparing TEPS.

2. Infrastructure tuning: Engineers change process placement on a cluster and measure whether a representative graph search improves. They retain the same counting and timing definitions to make the comparison interpretable.

3. Benchmark interpretation: A buyer examines a published GTEPS figure together with graph size, resource count and the measured kernel. The figure becomes one piece of evidence rather than a promise about every business query.

Think of it this way

Think of comparing the rate at which teams inspect links in a route map. The comparison only works if everyone agrees what counts as a link, which part of the map is included and when the stopwatch starts and stops.

The analogy has limits. A graph implementation can avoid redundant inspections or use a different search strategy. The benchmark rate can normalize against a defined edge count even when the internal sequence differs. TEPS is therefore not a literal count of identical physical actions across all implementations.

Worked example

Suppose two fictional searches each have a benchmark-defined count of 12 million edges. The first takes 0.4 seconds and the second takes 0.8 seconds. Their rates are 30 million and 15 million TEPS respectively.

The harmonic mean is 2 divided by (1/30 + 1/15), or 20 million TEPS. Because these two searches have equal edge counts, the same result follows from total work divided by total time: 24 million edges divided by 1.2 seconds. An arithmetic mean of the two rates would be 22.5 million TEPS and would not match this combined-work calculation.

If a report instead counted both stored directions of every undirected edge without following the benchmark's counting rules, its numerator could change while runtime stayed constant. That would inflate the apparent rate without improving the actual search. Always establish the count definition before comparing figures.

Illustrative case study

Fictional case study: EdgeMeadow evaluates two graph-processing configurations. Configuration A reports a higher TEPS figure, but its test omits a costly preparation phase and uses a smaller graph than configuration B. The business team initially interprets the difference as proof that A will finish its nightly analysis sooner.

Engineers rerun a controlled comparison and report both the specified search-kernel timing and the complete pipeline time, including required preparation. They also verify the output against the same correctness criteria.

EdgeMeadow discovers that a faster search kernel is useful but does not alone determine the nightly completion time. It keeps TEPS as a diagnostic performance measure while using the full workflow to assess the operational requirement. No commercial benchmark result is implied by this fictional example.

Common misconceptions and mistakes

A common mistake is treating TEPS as floating-point operations per second. Graph traversal and dense numerical arithmetic stress a system differently. Another is comparing rates from different graph structures, counting conventions or timing boundaries as though they measured the same task.

Do not assume that a high rate proves correct output, or that adding more machines always improves efficiency. Communication and coordination can change the result. Also distinguish a kernel benchmark from end-to-end processing: loading, constructing, updating and exporting a graph may be relevant to a business workload even when excluded from a particular timed kernel.

Business use

TEPS can help organizations evaluate systems for data-intensive graph workloads, including relationship analysis and search components used around AI applications. It provides a task-oriented measure that complements processor specifications and arithmetic benchmarks.

For a procurement or deployment decision, pair the rate with representative graph sizes, memory use, elapsed workflow time and resource cost. A configuration that delivers a higher total rate using many more machines may not be the most economical option. Record the benchmark version and validation status so later comparisons do not silently mix incompatible procedures.

Check your understanding

A test doubles its reported edge count without changing either the work or elapsed time. Has its processing performance doubled?

Answer: No. Only the reported numerator changed. A valid comparison must use a consistent, justified counting rule.

Related terms

Breadth First Search
Shortest Paths
Benchmarks
Harmonic mean
Graph traversal
shortest path
benchmark
memory bandwidth
distributed graph processing
throughput

Learn next

Read a graph benchmark result and identify its numerator, timed interval and aggregation method. Then compare the reported kernel time with the complete workflow your application requires.

Sources

Graph 500 benchmark specification, indexed primary text: https://graph500.org/?page_id=12

NVIDIA Grace CPU Benchmarking Guide, Graph500: https://nvidia.github.io/grace-cpu-benchmarking-guide/benchmarks/Graph500/index.html

UMBC research team, Graph 500 performance project: https://hpcreu.umbc.edu/summer2012/projects/team1/

The specification was read through indexed text after direct retrieval timed out. The numerical example and EdgeMeadow case are fictional, not official Graph 500 submissions.

Previous: Traveling salesperson problem Next: Treatment and control groups