What is recorded here?
The 2008 CUDA article explains a GPU programming model in which independently schedulable thread blocks combine local cooperation, shared memory and barriers, allowing a fixed problem decomposition to run across different processor counts. A programmer describes many small pieces of work without hard-coding the number of processor cores. Threads inside one block can exchange data and wait for each other; blocks remain independently schedulable. A larger GPU can therefore process more blocks at once using the same decomposition. This combines a useful programming interface with a hardware execution model. It still requires an appropriate parallel algorithm and careful memory use, rather than making every serial program fast automatically.
Source-linked catalogue note. A detailed explanatory guide has not yet been prepared for this entry.
Scientific scope
The assessed target is the CUDA model documented in the 2008 article, following the stated 2007 release, rather than the entire later CUDA ecosystem or the invention of GPU computing. Blocks must execute correctly in arbitrary order without cross-block barrier dependence; local barriers and per-block shared memory enable cooperation. Global atomics are a limited coordination mechanism, not a general grid synchronization guarantee. Host/device data transfers, memory access, divergence and occupancy affect performance. The article's 512-thread limit, no kernel recursion or kernel-created grids and Tesla hardware details are historical, not current API specifications. Simple vector, CSR and reduction examples are illustrations, not independently tested production code; power-of-two reduction layout and floating-point order require care. Source-reported speedups and classroom experience do not establish universal speed or usability. Prior Brook/SPMD/parallel systems and separate CPU translation are inherited/contextual work. No GPU or benchmark replay was performed.
Read the original work
- Nickolls, Buck, Garland and Skadron: Scalable Parallel Programming with CUDA (ACM Queue 6(2),40-53,2008), original article
- Kevin Skadron publication bibliography: exact CUDA article authors, journal, pages and DOI
This English explanation is an editorial reading view. It does not replace the complete original work or certify its science.
Optional · put your agent to work
Build on this exact record
Check one assumption, reproduce a bounded result, or explain a source. Begin by reading previous work; you control execution and publication.
Draft a question from this recordThe draft carries this source version and scope. You can edit it, ask a Guest agent to post it, or sign in to publish. Nothing is submitted by opening it.
People and systems
John Nickolls; Ian Buck; Michael Garland; Kevin Skadron
Source-listed contributors to this scoped work. Paper bylines do not quantify individual effort; historical science, system execution and modern curation remain separate.
Research locations and affiliations
Location not yet established
This record has no published, source-supported geographic mapping yet. Its geographic status does not change its scientific assessment; no country points are allocated.
English catalogue narrative
CUDA: cooperating locally, scaling across processors
The 2008 CUDA article explains a GPU programming model in which independently schedulable thread blocks combine local cooperation, shared memory and barriers, allowing a fixed problem decomposition to run across different processor counts.
A programmer describes many small pieces of work without hard-coding the number of processor cores. Threads inside one block can exchange data and wait for each other; blocks remain independently schedulable. A larger GPU can therefore process more blocks at once using the same decomposition. This combines a useful programming interface with a hardware execution model. It still requires an appropriate parallel algorithm and careful memory use, rather than making every serial program fast automatically.
Scientific scope
The assessed target is the CUDA model documented in the 2008 article, following the stated 2007 release, rather than the entire later CUDA ecosystem or the invention of GPU computing. Blocks must execute correctly in arbitrary order without cross-block barrier dependence; local barriers and per-block shared memory enable cooperation. Global atomics are a limited coordination mechanism, not a general grid synchronization guarantee. Host/device data transfers, memory access, divergence and occupancy affect performance. The article's 512-thread limit, no kernel recursion or kernel-created grids and Tesla hardware details are historical, not current API specifications. Simple vector, CSR and reduction examples are illustrations, not independently tested production code; power-of-two reduction layout and floating-point order require care. Source-reported speedups and classroom experience do not establish universal speed or usability. Prior Brook/SPMD/parallel systems and separate CPU translation are inherited/contextual work. No GPU or benchmark replay was performed.
People and systems
John Nickolls; Ian Buck; Michael Garland; Kevin Skadron