PaperlayerView exact revision on arXiv

Source-linked AI summary

A Feature-Major Codebook for Memory-Efficient Sparse-Binary Self-Organizing Maps: Scaling a MEDLINE Atlas to 1.05 Million Neurons on a Single Consumer GPU

Andrew James Amos

arXiv:2608.24067v1cs.LGcs.DC

TL;DR

At MEDLINE scale, SOM training is impractical because BMU search repeatedly reads a large codebook, making memory movement decisive. The paper uses feature-major storage with tiled, fused search to improve that bottleneck, enabling converged maps up to 1,048,576 neurons while preserving exact BMU quality.

  • Problem

    SOM construction at MEDLINE scale is limited by BMU searches that repeatedly read the codebook, constraining practical atlas resolution.

  • Method

    The paper stores the codebook feature-major and combines coalesced tiled reuse with fused score accumulation and argmin selection.

  • Results

    The system reaches 1,048,576 neurons on a 141 GB H200 and remains the only tested implementation running 262,144 neurons on a 24 GB GPU.

  • Takeaways & Limitations

    A full-MEDLINE browsable atlas can be built in minutes on a single GPU, with resolution governed by available compute rather than a data-imposed ceiling.

  • Takeaways & Limitations

    Measurements used a single RTX 4090, and the layout argument was not confirmed on datacentre GPUs.

Abstract

from arXiv · show

A self-organising map turns a large corpus into a browsable two-dimensional atlas, but building one at MEDLINE scale has been impractical: the best-matching-unit (BMU) search that dominates training is bound by the bandwidth needed to read the codebook every epoch. I show that this bottleneck is largely an artefact of codebook layout. Storing it feature-major with each feature's weights contiguous, W[v.M+i], recasts the search as a tiled sparse-dense product in which every loaded weight column is reused across a tile of samples. Varying only the layout, with implementation, precision and update rule held fixed, accelerates the BMU search by 4.5-8.5x. Because an exact-argmin BMU is invariant to how the codebook is stored, this gain costs nothing: held-out quantisation error agrees with a cuSPARSE baseline to within 0.5% at every map size. Against that baseline the advantage is a crossover rather than a constant: cuSPARSE.SOM is faster at small maps, SparseBin.SOM is 1.5x faster at 128x128 and 2.6x at 256x256, and at 512x512 it is the only one that runs at all on 24 GB. Paired with a radius-independent box-blur update and a convergence-based stopping rule, it trains a converged map over 29.9 million MEDLINE articles in about 72 s at 64x64 on one 24 GB GPU, and accommodates 262,144 neurons (512x512 edges) where every alternative algorithm I tested exceeds memory constraints. On a 141 GB H200 it reaches 1,048,576 neurons (1024x1024 edges) - to my knowledge the largest self-organising map yet reported. Held-out error follows a smooth power law with no elbow across three decades of map size, so the limit on resolution is compute rather than any breakpoint in the data. At matched work the design is ~82x faster than MedSOM, the CUDA implementation behind our earlier MEDLINE atlases and, at 128x128, 621x faster than the best available multicore-CPU library.

1. Introduction

At MEDLINE scale, SOM construction is primarily a memory-bandwidth problem in repeated BMU searches. The paper addresses it with feature-major codebooks and tiled sparse-dense computation, enabling much larger maps without changing exact BMU quality.

  • Motivation: MEDLINE-scale SOM training is dominated by BMU searches that repeatedly read an M×V codebook across epochs.Node-major storage causes strided, uncoalesced memory accesses, making the search memory-bandwidth-bound.
  • Method: Feature-major storage makes feature weights contiguous, enabling coalesced reads and reuse across samples sharing a feature within a tile.The layout stores weights as W[v·M+i] and supports a tiled BMU kernel.
  • Quality: Exact-argmin BMUs preserve assignments regardless of codebook layout, so the layout change affects speed without changing intrinsic clustering quality.The evaluation separates BMU/layout effects from update-rule effects using quantisation, topographic, and dead-unit measures.

2. Background and related work

The paper situates batch SOMs, quality measures, GPU and CPU implementations, sparse kernels, and prior large maps. Existing approaches differ in representation, BMU computation, update strategy, and how map size is selected.

  • Self-organizing maps and quality measures: Batch SOM training alternates BMU assignment with neighbourhood-weighted prototype updates whose kernel shrinks over training.The paper evaluates quantisation error, topographic error, and dead-unit fraction as intrinsic quality measures.
  • GPU and parallel SOM implementations: Exact Euclidean BMU search is standard for most compared implementations, whereas MedSOM normalises its codebook and uses maximum dot products.This distinction affects search computation and prototype interpretability.
  • GPU and parallel SOM implementations: At MEDLINE vocabulary scale, somoclu’s sparse multicore-CPU kernel is viable, while its dense GPU path is infeasible because dense codebooks and inputs become enormous.MedSOM provides a same-task GPU baseline but uses node-major codebooks and per-node update loops.
  • Sparse kernels, memory layout, and the roofline: The BMU search is closely related to SpMM, and cuSPARSE output ordering isolates feature-major versus node-major layout effects within one library.The roofline framing motivates maximising achieved bandwidth and arithmetic intensity through coalesced reads and reuse.
  • Map size selection: WEBSOM reached 1,002,240 nodes, but its map size was chosen by computational feasibility and browsing use rather than a data-derived optimality criterion.It enlarged a smaller trained grid by inserting nodes and interpolating weights.
  • Map size selection: Automatic-size methods such as SMLSOM and growing or hierarchical SOMs have mainly been demonstrated on much smaller datasets.The paper extends prior MEDLINE SOM work from approximately 10^5 to approximately 10^6 neurons.

3. Method

The method reorganizes sparse SOM BMU computation around feature-major codebook access, tiled reuse, and exact reproducible argmin evaluation, then combines it with efficient updates and adaptive convergence.

  • Feature-major codebook: Feature-major storage makes each sparse feature’s M weights contiguous, converting strided gathers into coalesced reads with tile-level reuse.The layout stores weights as W[v·M+i], while node-major storage uses W[i·V+v].
  • SpMM-tile BMU kernel: The tiled BMU kernel loads each distinct feature column once, applies it across TA samples, accumulates in registers, and fuses top-two selection without materializing an N×M score matrix.The production tile uses TA = 16, with the feature union bounded by min(TA·nnz, V).
  • Update and convergence: The neighbourhood update is implemented as a separable box blur of lattice accumulators, giving O(M) cost for any neighbourhood radius σ.Unnormalised numerator and denominator blurs preserve the weighted mean, with clamped lattice boundaries.
  • Update and convergence: PCA initialization permits a smaller initial radius, improving held-out quantisation error by roughly 1% while trimming a few epochs, and stopping occurs when distortion plateaus.The adaptive stopping rule replaces a fixed epoch count.
  • BMU correctness: Exact-argmin BMUs are invariant to codebook layout, while sorted feature accumulation and lowest-index tie-breaking provide bit-reproducible assignments.Thus the layout changes access cost rather than the resulting BMUs.
  • Feature-major codebook: 4.5-8.5× BMU-search acceleration comes from the layout alone when implementation, precision, and update rule are held fixed.The comparison isolates the memory-layout and BMU-access change.

4. Experimental setup

The evaluation uses a fixed MEDLINE corpus, shared quality scoring, and GPU, CUDA, cuSPARSE, and CPU comparators, while documenting implementation asymmetries and reproducibility materials.

  • Hardware and reproducibility: The largest 1024×1024 sweep map is trained on an H200 SXM with 141 GB VRAM, while the main implementation comparisons use an RTX 4090 with 24 GB.The CPU baseline runs on 28 host threads.
  • Hardware and reproducibility: The released data, scripts, and code support reproducibility, while AI assistance was used for implementation, experiments, analysis scripts, and statistical analyses under author direction.The paper states that figures are computed from released measurements and contain no uncomputed AI-generated content.
  • Corpus: The corpus contains 29,903,261 PubMed 2026-baseline articles with at least five MeSH descriptors over 30,766 descriptors.The snapshot excludes records outside the MeSH-indexed MEDLINE subset and applies the five-descriptor floor.
  • Baselines: Four named comparators are evaluated: SparseBin.SOM, SparseFloat.SOM, cuSPARSE.SOM in both orderings, MedSOM, and somoclu.The comparison includes the introduced sparse-binary and sparse-float designs, same-GPU cuSPARSE variants, prior CUDA MedSOM, and multicore CPU somoclu.
  • Comparison design: All implementation comparisons use identical corpus and map sizes, matched training budgets and σ endpoints where applicable, and one shared cosine evaluator.The paper discloses remaining asymmetries in kernels, hardware, initialization, and schedule drivers.
  • Evaluation metrics: Quality is scored externally using quantisation error, topographic error, and dead-unit fraction rather than trusting each implementation’s internal metrics.QE is computed under cosine distance for cross-implementation comparison, with native Euclidean QE reported where relevant.

5. Results

Feature-major storage delivers a large isolated BMU speed-up without changing exact assignments, while end-to-end gains emerge mainly at larger maps. Quality is governed by the update and stopping rule, and the approach remains feasible where alternatives hit memory limits.

  • 5.1. Codebook layout: feature- versus node-major: 8.5× at 32×32, with a 4.5×–8.1× advantage across the remaining ladder, when feature-major and node-major layouts are compared with all else fixed.The comparison holds implementation, precision, update, and stopping rule constant, isolating memory layout.
  • 5.1. Codebook layout: feature- versus node-major: 1.65× versus 1.07×: halving the codebook to FP16 benefits feature-major storage much more than node-major storage.The different response to reduced read volume shows that access pattern, rather than storage format alone, is the primary bottleneck.
  • 5.2. Equal-quality comparison with cuSPARSE: a crossover, and a capacity wall: 0.5%: held-out quantisation error agrees with the cuSPARSE baseline at every map size, while SparseBin.SOM is slightly ahead on topographic error and dead-unit fraction.At 256×256, topographic error is 0.033 versus 0.037 and dead-unit fraction is 10.7% versus 17.4%.
  • 5.2. Equal-quality comparison with cuSPARSE: a crossover, and a capacity wall: 1.5× at 128×128 and 2.6× at 256×256: SparseBin.SOM overtakes cuSPARSE after a crossover between 32×32 and 64×64.At 32×32 cuSPARSE is 2.8× faster, while at 512×512 both cuSPARSE layouts exhaust the 24 GB card and SparseBin.SOM trains on.
  • 5.3. Quality is set by the update, not the BMU: 0.013–0.033 topographic error: replacing the Gaussian neighbourhood with three box passes, then adding Kaski-Lagus stopping, brings baseline quantisation error within 0.5% of SparseBin.SOM.The exact-argmin BMU is identical across these runs, so the reported quality differences track the update and stopping rule.
  • 5.4. The update phase, and where training time actually goes: 98.7% to 99.5%: BMU search dominates training wall-clock time from 32×32 through 512×512, making layout optimisation central at scale.The factorised box-blur update grows from 0.031 to 0.248 seconds per epoch across 32×32 to 256×256, versus 0.027 to 3.60 seconds for the cuSPARSE update.
  • 5.5. The efficiency chain, and the capacity wall: 621× at 128×128 and 655× at 256×256: the GPU-versus-CPU advantage rises with map size before flattening as scaling rates converge.These end-to-end figures combine layout, update rule, and precision; the isolated layout effect is 4.5×–8.5%.

6. Discussion

The discussion identifies memory traffic, especially codebook access and score-block materialization, as the central scaling constraint and shows how feature-major storage plus fusion addresses it. These design choices enable large MEDLINE atlases while leaving resolution limited by compute rather than an error-curve breakpoint.

  • Mechanism: 4.5-8.5× faster BMU search results from feature-major codebook storage and tiled reuse when other factors are held fixed.Feature-major layout makes weight reads coalesced and reuses loaded feature columns across samples in a tile.
  • Mechanism: 6.92 TB of score-block read-back accounts for half the sparse-dense path’s traffic and three-quarters of its elapsed kernel time at 256×256.The fused search keeps accumulations in registers and avoids materializing the score block.
  • Map-size scaling: A large map preserves within-topic resolution that small maps lose, separating research fronts such as CAR-T trials and treatment approaches into contiguous neuron regions.Small maps can place CAR-T beside other cancer immunotherapy, but larger maps resolve structure within that region.

7. Limitations

The evaluation is limited by hardware coverage, comparison scope, and selected measurement conditions. Several headline comparisons therefore do not establish uniform advantages across architectures, map sizes, or implementations.

  • All measurements used a single RTX 4090, leaving datacentre-GPU transferability and cross-GPU BMU identity unconfirmed.
  • The per-epoch advantage over cuSPARSE appears only above roughly 128×128, while the 128×128 wall-clock gain partly reflects fewer converged epochs.
  • Neither implementation is uniformly leaner in DRAM traffic, and 256×256 figures are sampled and scaled rather than exhaustively captured.
  • Profiling covers only two map sizes on one architecture, and the somoclu comparison uses a single map size chosen as its most favourable point.
  • The MedSOM comparison is timing-only because per-epoch codebook normalisation makes its quantisation error non-comparable, while the size sweep uses one seed per run.

8. Data and code availability

The anonymised binary MeSH corpus, software, baselines, evaluator, and reproduction pipeline are publicly released. Reproduction is offered at outline and full depths with substantially different costs and coverage.

  • The anonymised corpus is available from Zenodo under CC0 1.0 and contains only binary MeSH descriptor vectors without identifiers, titles, abstracts, authors, or journal data.
  • The corpus derives from the PubMed 2026 annual baseline and does not represent NLM’s most current available data.
  • The implementation, cuSPARSE baseline, shared evaluator, and reproduction pipeline are released under the MIT licence at the paper’s GitHub repository.
  • Reproduction profiles: The outline profile takes about three hours on one 24 GB GPU and checks effect directions and magnitudes without reproducing published values or intervals.
  • Reproduction profiles: The full profile runs five seeds across edges 32 to 512 for every implementation and takes approximately 6.5 days on the same card.

9. Declarations

The paper is solely authored, builds on earlier MEDLINE self-organising-map work, reports no dedicated funding or competing interests, and uses public metadata without human or animal subjects.

  • A.J.A. is the sole author responsible for the work’s conception, design, implementation, experiments, analysis, and writing.
  • The work builds on a MEDLINE self-organising-map programme developed with Kyungmi Lee, Tarun Sen Gupta, and Bunmi S. Malau-Aduli.
  • The research received no specific grant from public, commercial, or not-for-profit funding agencies.
  • The study analysed publicly available MeSH metadata with no human participants, animal subjects, identifiable personal data, or ethics approval requirement.
  • Generative AI assistance was used for manuscript drafting, revision, structuring, and reference-metadata verification, followed by author review and editing.

Appendix A. Provenance of tables and figures

All tables and figures are traceable to files in a frozen result set and can be recomputed through the released scripts. The provenance mapping distinguishes schematics, prose-support files, and table-specific datasets.

  • Every table and figure is computed from a file in the frozen result set, enabling tracing and recomputation through the release scripts.
  • Figures 1 and 2 are schematics without measured data, while sigma0_sweep.parquet and bringup_gate.json support prose claims.
  • Table provenance: Table 8 uses efficiency_sweep.parquet, Table 9 uses size_sweep.parquet and the H200 run log, and Tables 10 and 11 use roofline profiling CSV files.
Loading 2608.24067v1…