GitHub user rich7420 edited a discussion: [DISCUSSION] Apache Mahout 2026 Q4 Roadmap
## Context QuMat and QDP have evolved significantly over the last several releases. QDP now includes work around: - CUDA and AMD ROCm execution; - multiple quantum data encodings; - DLPack / GPU-pointer paths; - batching and asynchronous prefetch; - memory management; - preprocessing and validation; - realistic QML benchmarks; - CPU / PyTorch reference implementations. There are also several recent issues around runtime and performance engineering, for example: - #1227 — compute-kernel performance and comparison with `torch.compile()` - #1410 — end-to-end QDP profiling - #1429 — pipeline memory estimation - #1430 — fail-fast VRAM validation - #1431 — Python bindings for preprocessing Taken together, I think there is an interesting question about how we want QDP to evolve, but I do not think we need to answer that question completely in this roadmap issue. ## Areas I am personally interested in Below are areas I think may be worth discussing for Q3–Q4 2026. These are **not commitments or an ordered project roadmap**. ### QDP correctness and benchmark quality Possible work includes: - CUDA / ROCm semantic and numerical conformance; - clearer benchmark definitions; - reproducible benchmark metadata; - separating kernel, data-to-state, pipeline, and end-to-end benchmarks; - ensuring cross-framework comparisons perform equivalent operations. Given that performance is an important part of QDP, I think benchmark reproducibility and correctness are especially valuable. ### Runtime observability and memory planning There is already ongoing / proposed work around: - end-to-end profiling (#1410); - memory estimation (#1429); - fail-fast VRAM checks (#1430); - preprocessing (#1431). It may be useful to coordinate these as a broader runtime / observability effort. ### QDP interoperability Today QuMat is an important consumer of QDP. I think it is worth exploring whether QDP should also become easier to use independently from QuMat, for example from existing PennyLane or Qiskit workflows. A small external-framework prototype could help us understand whether this is actually useful before introducing larger abstractions. ### Quantum preparation runtime / planning One possible longer-term direction is to think of QDP as the preparation layer between classical data and quantum computation. That might eventually include concepts such as: - preparation semantics; - backend capabilities; - implementation/provider selection; - memory and copy planning; - preparation profiling. I have opened / plan to open a separate proposal issue for this idea so that the architectural discussion does not make this roadmap issue too large. ### QPU preparation research QDP's current direct-state preparation is primarily useful for simulator workflows. A physical QPU requires a different preparation path, typically an executable circuit rather than direct state-vector handoff. It may be interesting longer term to investigate whether simulator preparation and QPU circuit preparation can share some common high-level encoding semantics. I would consider this a research topic rather than a near-term roadmap commitment. ## What I do *not* think this roadmap needs to decide I do not think we need to decide in this issue whether Mahout should become: - a complete replacement for PennyLane or Qiskit; - a generic GPU data engine; - a general device runtime or compiler; - a fixed sequence of 0.x / 1.0 feature milestones. Those are larger questions and should be discussed separately if contributors want to pursue them. ## Community request Please comment below with any of the following: 1. What do you plan to work on during Q3–Q4 2026? 2. What features or capabilities would you most like to see? 3. Which areas are you willing to help implement, review, benchmark, or document? 4. Are any of the areas above better handled outside Mahout core? 5. Are there existing issues that should be grouped into a larger tracking issue / EPIC? 6. If you are a maintainer and willing to help coordinate a larger effort, please say so. I am especially interested in hearing from users of QuMat/QDP about where the current bottlenecks are in real workflows. The intent here is to make it easier for contributors with overlapping interests to find each other and to help the individual issues we work on add up to a coherent direction. GitHub link: https://github.com/apache/mahout/discussions/1465 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
