Reviewer 1	 top

Summary and High Level Discussion
monospace
This paper presents a new technique for performing integer matrix multiplication. The algorithm functions by decomposing higher precision operations (int64, int32) into a series of less expensive Int8 operations, so as to better take advantage of modern hardware features. Notably, the method is not subject to rounding errors, such that the resulting operations are bitwise identical to those performed using higher bit width integer types. However, these benefits come at the expense of a loss of allowable range of the input integer matrices.

Strengths
monospacemarkdown
This is a highly interesting problem space with potential application to a wide variety of simulations.

Clearly written paper, well organized.

Algorithm is well presented and its pros and cons in the body of the paper are clearly articulated.

Weaknesses
monospacemarkdown
As described in detail in Section 4.2, the loss of usable range in the input data greatly reduces the utility of the method. For Int64, use of the method would restrict max values to be ~2^52 instead of ~2^63 (as discussed in Section 4.2). Similar issues arise for Int32 and Int16.

The significant loss of range does not align with the strong claims made in the abstract and repeated throughout the paper: "This paper addresses a key question: Can low-precision hardware accelerate exact high-precision matrix multiplication (MM) while reducing communication costs? We answer affirmatively with a framework for exact integer MM…" The claim of "exact" matrix multiplication seems unsupported as typical int16/int32/int64 operations would not be "exactly" supported under this method, as there is massive truncation. The user would need to upcast to a larger type before calling this method or otherwise lose precision for operations that were out of supported range (e.g., become inexact). Upcasting seems like it may negate many (or all?) advantages of the method.

Comments for Rebuttal
monospacemarkdown
Is it appropriate to use the term "exact" when truncating typical int16/32/64 integer types? This seems wrong to me, but if there is a positive broad consensus already in the field regarding the use of this term in the presence of truncation, perhaps the authors can provide 3 or more references to back up their claim.

For the general use case where truncation of typical integer ranges is not acceptable, how does the requirement that the user upcast all input values to the next higher precision impact the asymptotic performance? Should there be a "best case" and "worst case" set of numbers given, depending on whether the values exceed the allowed range or not?

Detailed Comments for Authors
monospace
The paper is well written and edited -- I don't have any fine-grained editorial comments.

Scored Review Questions

rec
pap924s2	STRONG REJECT (0)

Reviewer 3	 top

Summary and High Level Discussion
monospace
This paper presents a new parallel algorithm for integer matrix multiplication that splits each element into multiple lower-precision elements and uses Karatsuba's algorithm to perform fast polynomial multiplication, which constructs elements of the output in a higher precision. The theoretical foundation for the algorithm is described, and the feasibility of a practical implementation on modern int8 hardware is also presented. Finally, a novel 4D parallel matrix multiplication algorithm based on the idea is presented, and it is shown that this 4D algorithm asymptotically reduces communication costs relative to state of the art 3D algorithms.

Strengths
monospacemarkdown
The idea is novel, and it has a strong theoretical basis
A novel single-node algorithm and distributed algorithm are presented

Weaknesses
monospacemarkdown
no implementation or experimental data
limited to integer matrix multiplication

Comments for Rebuttal
monospace
This paper is really exciting, but I do not feel comfortable accepting it given that it only presents theoretical results. In the presence of strong experimental results, I would argue to accept the paper.

Can a better justification for the utility of integer matrix multiplication be made? I think floating point matrix multiplication is much more commonly used.

Detailed Comments for Authors
monospace
See rebuttal comments.

Scored Review Questions

rec
pap924s2	REJECT (1)

Reviewer 4	 top

Summary and High Level Discussion
monospace
The authors introduce an algorithm for running high-precision, distributed integer matmul with low-precision integer elements. The framework represents high-precision integer elements polynomials with low-precision integer coefficients. This transforms the input matrix into a 3D tensor with a precision dimension, and turns the computation of a single output element into a convolution between the corresponding polynomials in the input 3D tensors. The authors use a modified Karatsuba approach for this convolution, with optimizations to preserve sign and avoid integer overflow. They also analyze the communication complexity of distributed 2D SUMMA matmul when using this approach.

Strengths
monospace
The authors explain their method clearly, and the paper is well-written
The communication analysis is appreciated, including its comparison to baseline SUMMA
Parallelization across the precision dimension feels interesting and novel

Weaknesses
monospace
The idea behind the paper is interesting (i.e. decomposing integer matmul into a matmul with polynomial elements, and applying Karatsuba), but the paper feels too theoretical for SC and incomplete in its current form. Specifically,

There are no empirical results in the paper, which feels necessary for SC. I think experiments that show this approach outperforming either prior methods or at least an implementation without karatsuba (both in serial and distributed settings) would be useful.

The use cases for this method seems unclear. It is true that tensor cores provide higher FP8 flops than standard arithmetic units on FP64, but NVIDIA does have FP64 tensor core units as far as I understand. Can try authors clarify when this method would be useful?

Comments for Rebuttal
monospace
See strengths and weaknesses

Detailed Comments for Authors
monospace
See strengths and weaknesses

Scored Review Questions

rec
pap924s2	WEAK REJECT (2)
Response to Reviewers

We are humbled and encouraged that reviewers appreciated the novelty of our core idea and its strong theoretical foundation.  We acknowledge the main concern about the paper's theoretical nature and lack of empirical results, potentially limiting its relevance to the SC community.

To this end, we have already provided a bitwise-validated NumPy implementation of the sequential algorithm in the artifact description (which may not have been visible due to the double-blind policy).

Based on the insightful reviewer feedback, we have identified potential issues that may hinder conversion of theory into practice and developed a clear plan to bridge this gap and make our work immediately valuable to the SC community.

Bridging Theory and Practice

As a theory-in-practice paper, we recognize the challenges practitioners face when translating theoretical advances into working systems:

Underspecified algorithms: Crucial parameters may lack clear selection criteria, important pre/post-processing steps might be omitted or impractical, and guidance on when to apply techniques may be missing.

Hidden costs: Algorithmic constants concealed in big-O notation or non-dominant sequential costs can become bottlenecks in practice, especially in strong scaling scenarios.

Unrealistic computation models: Theoretical assumptions may not match existing hardware, making implementation challenging.

To address these issues and increase the paper's utility, we commit to the following additions:

Proposed Additions for Camera-Ready Version
1. Reference Implementation (part of software artifact)

PyTorch implementation of the distributed 4D algorithm

User-configurable precision levels (working precision, long/short word sizes)

Demonstrates mapping of precision dimension to hardware parallelism

2. Enhanced Algorithm Specification (main paper and appendix)

High-level pseudocode in main paper

Detailed pseudocode in appendix matching Python implementation

Fine-grained cost expressions (computation/communication/messages) beyond dominant terms

3. Empirical Validation to Ground Theoretical Claims

Empirical evaluation using reference implementation to validate theoretical cost expressions

Demonstration that hidden constants in asymptotic analysis are practical

Analysis of performance scaling with number of splits (k)

This will be added as a new section

4. Practical Use Case: High-Precision Floating-Point Multiplication

Appendix demonstrating FP32/FP64 matrix multiplication using our integer algorithm via equilibration and quantization

Source code and empirical error analysis to guide users

Clear guidance to prevent erroneous application to floating-point matrices

Response to Reviewer 1: "Exactness" and Range Limitations

We appreciate the critical analysis of range limitations. We clarify:

Definition of "Exact": Our method produces outputs bitwise identical to standard high-precision integer multiplication. The limitation is on input range, not computational exactness.

Overcoming Range Limitations: The ~52-bit range using k=8 splits is not fundamental. For full int64 range, we increase splits to k=10, trading small performance cost for full coverage while maintaining bitwise exactness. Given input word sizes, we can determine optimal k at runtime—users need not upcast to larger types.

Additional Remarks: The primary reason for range reduction is signed int8 representation, requiring 1 bit for sign in each split. This limitation could be addressed with unsigned int8 support or clever optimization.

Response to Reviewer 3: Utility and Applications

We agree that integer MM is less common than FP MM. In practice, one could apply these techniques to FP cases, and we will provide an example heuristic for higher-precision FP MM. However, we focus on exact MM in this paper as it provides a cleaner demonstration of using low-bitwidth hardware for reducing computation and communication.

Response to Reviewer 4: FP64 Tensor Cores

The throughput difference is substantial: H100's FP64 tensor cores achieve 67 TFLOPS vs. FP8's 3,958 TFLOPS—roughly a 60x ratio.

Naive emulation of exact 64-bit MM using 8-bit hardware requires k²=64 operations, yielding ~62 TFLOPS effective throughput.

Our method requires only k^(log 3/log 2) ≈ 27 operations, yielding ~147 TFLOPS effective throughput—approximately 2x faster than native FP64.

This analysis is simplified (we provide algorithms for integer MM with some efficiency loss on current hardware), but demonstrates the potential. Moreover, improvements are asymptotic in k—using 4-bit, 2-bit, or binary computation would yield much higher speedups.

Additionally, our 4D tiling algorithm reduces asymptotic data transfer for different k values, which is impossible with FP64 tensor cores.

Broader Contribution: Breaking the Hardware-Software Cycle

Our work introduces a general principle: exploiting the precision dimension for parallelism, cache efficiency, and communication reduction. This extends beyond matrix multiplication to matrix-vector operations, iterative solvers, tensor contractions, stencil computation, and FFT.

However, we face a chicken-and-egg problem:

Hardware designers don't prioritize low-precision integer support due to lack of applications

Algorithm designers cannot fully exploit precision decomposition without hardware support

Current hardware (int64→int8, k=8) shows limited benefits, but true power emerges with smaller bitwidths (int4, int2, binary). Our work aims to break this cycle by demonstrating concrete benefits and inspiring hardware evolution.

We are committed to making these theoretical advances accessible and practical for the SC community, bridging the gap between algorithmic innovation and real-world impact.

what do you strongly liked about the rebuttal and disliked. Should I change my rating about paper? you are r1