K GraphFuse¶

The new controlled confirmation uses the repaired implementation across six graph families and two GPUs. Matching-budget, matching-degree packed-balanced CuPy comparisons pass the strong speed gate in 18/20 pooled device–fixture comparisons, with 36.88–83.71% less resident time in the wins. R-MAT loses on both devices. MovieLens recommendation quality matches exactly, but specialized scalar-restart CuPy removes the application median speed advantage: K uses 7.13% more time on RTX and practically ties T4. These are scoped experimental results, separate from native-cuGraph PageRank and the installed API.

Compile compatible linear graph operations once. Reuse sparse CPU or CUDA execution across inputs.

Created by Utkarsh Sinha. Cite K GraphFuse when using its implementation or evidence.

K GraphFuse turns a sequence of compatible graph filters into an ordered matrix polynomial. It evaluates the plan without forming graph matrix powers or a dense graph operator. The package also provides a one-parameter directional derivative, a symmetric Chebyshev resolvent, local sparse propagation and an exact rational residual audit.

K GraphFuse compiles compatible linear stages into an ordered polynomial, then reuses a sparse operator and plan for evaluation

The intended opportunity is repeated graph computation on a reused operator. Compilation, graph conversion and GPU preparation are additional costs. Matching a mathematical operation alone does not establish a production speedup: include downstream quality, transfers, projection, updates and writeback in your evaluation.

Theorem-dependent computation findings¶

The theorem-bound attribution analysis separates the new complete-Crouzeix bound from balancing and GPU fusion. Two of 11 legacy T4 workload records reduce degree: 23→22 and 19→18. Across all eight accepted matched FP64 configurations in those two records, the new-bound plan records 3.56–5.35% less median resident time, with lower observed p95. This is single-run evidence below the separate 10% strong-speed gate. The exact CPU 9→8 boundary is untimed; the checked laptop old/new-bound cases retain equal degrees.

Audited performance evidence¶

Study	Outcome	Read the matching contract
Native cuGraph ranking	66.3% of 89 attempted cases passed the strong speed gate; 29.2% also had both reference errors no worse	Native cuGraph comparison
Strongest tested controls	38.8% overall and 44.7% GPU speed-gate passes	Comparator selection
Precision GPU experiment	Six of six gates; about 20.0–73.3% less median compute time (1.25–3.74x), equivalent to 25.0–273.9% higher derived serial rate	Filters, derivatives and sampled high-precision accuracy

The native denominator includes four K accuracy failures, counted as non-wins. The precision study compares against equivalent tuned FP64 CuPy/PyTorch controls on a constructed asymmetric family, not native cuGraph. Its source is an experimental implementation outside the installed package API. Derived serial rate is based on reciprocal median latency, not measured concurrent throughput. These studies establish scoped measured advantages; they do not establish global leadership or customer savings.

Audited native comparison coverage: 59 of 89 attempted cases pass the strong speed gate, 26 also pass both error comparisons, four cases fail K accuracy confirmation

Six constructed Tesla T4 workloads: about 20.0–73.3% lower median compute time and 25.0–273.9% higher derived serial rate versus tuned FP64 CuPy or PyTorch

Inspect all results, including Graph500, repeated-reference and complete-workflow losses. The original one-run result was 21.28% less median compute time (63.398 ms native / 49.906 ms K; 1.2703x), equivalent to 27.03% higher derived serial rate; the older zero-pass 19-workload study remains available with its original contract.

Start with your task¶

Task	Documentation
Install and check a small CPU example	Installation, first graph filter
Keep a prepared sparse operator on a GPU	CUDA guide
Differentiate graph weights along one direction	Sensitivity guide
Apply a symmetric restarted resolvent	Resolvent guide
Evaluate a real workflow	Application fit, limitations
Read the research and interpret benchmark units	Research paper, metric definitions
Inspect signatures and output contracts	Python API
Audit or rerun the experiment	Methodology, reproduction

Release status¶

Version 0.1.0 is a research and evaluation release. CPU usage requires Python 3.11+, NumPy and SciPy. GPU usage additionally requires a compatible CUDA-enabled PyTorch installation. The numerical core preserves its historical MIT license and original C2Fuse imports. New documentation and package infrastructure use Apache 2.0. Release notes explain the naming and compatibility boundaries.