Activity

1. github-actions

   added

   Office HoursIssue announcing office hours and soliciting associated agenda items.Issue announcing office hours and soliciting associated agenda items.

   on Aug 25, 2026
2. 0PrashantYadav0 commented on Sep 1, 2026

   

   0PrashantYadav0

   on Sep 1, 2026

   Member

   More actions

   Discussion on :
   stdlib-js/stdlib#14873 - feat: add blas/ext/base/snannsumkbn along with C implementation

   Changes:

   1. Two output arrays instead of one packed array.
   2. The count is a real 64-bit integer.
   3. No strides on the outputs. ( since strideSum and strideCount are useless for array of length 1 )

   Question:
   The Int64Array-to-C bridge is new, and it's the part to examine.
   @stdlib/array/int64 isn't a native typed array. It's a polyfill holding a Uint32Array of hi/lo word pairs, and Node-API cannot see through it. I searched the repo and found no addon anywhere that accepts one, so there was no existing pattern to copy.
   What I did: the .native.js wrappers pass count._buffer, the real Uint32Array underneath, and addon.c casts that pointer to int64_t*. It works because the polyfill writes its two words in host order, so the bytes already sit in memory the way a native int64_t does.

   Reaching into _buffer from outside the package is the part I'm least comfortable with. It's a private field, and the whole thing rests on a byte-layout assumption that holds today but isn't guaranteed by anything written down. The 74 native assertions passing is real evidence, though it's evidence from one machine and one architecture. If you'd rather not take that on, the alternatives are a Float64Array count, which loses the integer typing but has boring well-trodden N-API support, or adding a proper argv-strided-int64array napi helper so this isn't a one-off.

   👀React with 👀1Reacted by Abdul Kaium
3. manit2004 commented on Sep 1, 2026

   

   manit2004

   on Sep 1, 2026

   More actions

   Can we have benchmark graphs and roofline analysis charts on the docs page.
4. teddygood commented on Sep 1, 2026

   

   teddygood

   on Sep 1, 2026

   More actions

   Following up on our Zulip discussion about the SIMD results. I’d like to talk about what the next step should be and make sure I understood your comment about GEMM.

   Since the four approaches performed about the same, I’m still not sure how we should choose a SIMD backend. Would it make sense to use a small DSUMPW draft PR to discuss the backend choice and how the code should fit into stdlib, or would it be more useful to try a small Module.ndarray GEMM experiment before making that decision?
5. batpigandme commented on Sep 1, 2026

   

   batpigandme

   on Sep 1, 2026

   Last edited by batpigandme

   Member

   More actions

   Can we have benchmark graphs and roofline analysis charts on the docs page.

   This is a great question, and I have thoughts. Just leaving this (embarrassingly empty) link to /docs/user-guides/, where I think benchmark-related material could find a useful home (and then we give those user-guides a home on the documentation site, too). 🙂

   Also @gunjjoshi's post which is a great example of a contextualized explanation of benchmarks/performance.
6. kgryte commented on Sep 1, 2026

   

   kgryte

   on Sep 1, 2026

   Member

   More actions

   Ref: roofline charts: https://manit2004.github.io/wgblas/modules/benchmarks_nvidia-geforce-gtx-1650.html
7. batpigandme commented on Sep 1, 2026

   

   batpigandme

   on Sep 1, 2026

   Member

   More actions

   AI-Generated Summary

   Caution

   These notes are likely imperfect, especially when it comes to spelling/function/package names

   Meeting Purpose

   Discuss technical refactors, documentation strategy, and project next steps.

   Key Takeaways

   • Count/Value Refactor: The count and value refactor requires a new argv_strided_index_array macro to handle dynamic cblas_int sizing (32- or 64-bit) and a new argv_strided_int64_array macro for general 64-bit argument parsing.
   • Benchmark Docs: Benchmark graphs are for developer docs (e.g., blog posts) to guide optimization, not user docs. The current decomposable doc structure prevents the necessary cross-routine analysis.
   • GEMM Backend: Chanho will create a draft PR with a proposed SIMD backend (XMD or Google Highway), justifying the choice based on maintainability, support, and WebAssembly compatibility.
   • PR Review Efficiency: To speed up reviews, Atharva will add comments to PRs where the benchmark.js path change is already complete, explaining why the file count is lower than expected.

   Topics

   Count/Value Refactor

   • Problem: The current refactor for count and value is incorrect.
   • Solution: Use the strided_base_reinterpret_int64 function to pass a Uint32Array (interleaved high/low words) to the native add-on.
   • New Macros Required:
     • argv_strided_int64_array: General-purpose macro for parsing 64-bit integer arguments.
     • argv_strided_index_array: Dynamically resolves the cblas_int size (32- or 64-bit) based on the input TypedArray type.
   • Implementation: The native add-on must use cblas_int for the count variable, not a hardcoded int64_t, to ensure compatibility.

   Benchmark & Roofline Analysis Docs

   • Proposal: Add benchmark graphs and roofline analysis charts to the docs.
   • Decision: This content is better suited for developer-focused docs (e.g., blog posts) than user-facing function references.
   • Rationale:
     • Context is Key: Raw performance numbers are misleading. Benchmarks must show relative performance (e.g., contiguous vs. non-contiguous arrays) to provide actionable insights.
     • Doc Structure: The current decomposable doc framework prevents the cross-routine comparisons needed for this analysis.
     • Audience Mismatch: Roofline charts are for developers optimizing kernels, not end-users selecting a function.
   • Action: Manit will present his roofline analysis methodology and charts at the next meeting to inform future developer documentation.

   GEMM SIMD Backend Selection

   • Context: Four SIMD backend options (e.g., XMD, Google Highway) showed similar performance for the GEMM experiment.
   • Decision: Chanho will create a draft PR proposing a single backend choice.
   • Evaluation Criteria:
     • Ease of Implementation: Which framework is simpler to integrate?
     • Maintainability: Which framework has the most stable, long-term support?
     • Broadest Support: Which offers the best device and instruction set compatibility?
     • WebAssembly Compatibility: Which is easier to compile to WebAssembly?

   PR Review Process Improvement

   • Problem: Reviewers assume a missing benchmark.js path update if a PR changes fewer than the expected 20 files.
   • Solution: Atharva will add a comment to PRs where the path is already correct, explaining why the file count is lower.

   Sminos PR & Future Tasks

   • Sminos PR: The sminos routine uses three accumulators, deviating from the two used in some BLAS implementations. This is an intentional choice, likely from LAPACK, for performance or accuracy.
   • Future Work: Atharva will continue with current tasks. New strided API work will be available soon, pending the completion of the argv_strided_int64_array and argv_strided_index_array macros.

   Full transcript

   Full office hours transcript
8. batpigandme

   closed this as completedon Sep 24, 2026