MAmaximilianburke·Jul 23, 2026
ISPC isn’t Intel-only: https://github.com/ispc/ispc
In Everyone should know SIMDispc
ispc
C++2012–2026
ispc / ispc
ispc
Intel® Implicit SPMD Program Compiler
14Distinct people
15Mentions
0Explicit recommenders
3KGitHub stars
What to know before exploring
What it is
Intel® Implicit SPMD Program Compiler
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:24:10 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year15 dated mentions
Observed mentions: 2012-01-26 16:39:00 UTC to 2026-07-23 03:55:31 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 3 | 0 | 3 |
What Hacker News says
15 sourcesFor similar languages / compilers in this area:
1. ISPC [1], the Intel® Implicit SPMD Program Compiler also compiles SIMD programs with branches and other control flow efficiently using predication/masking etc.
2. Futhark [2] compiles nice-looking functional programs into efficent parallel GPU/CPU code.
[1]: https://github.com/ispc/ispc
[2]: https://futhark-lang.org/
In Show HN: Lockstep – A data-oriented programming languageYes, it works with AMD CPUs as well as various ARM ones, e.g. Apple silicon.
See for instance https://github.com/ispc/ispc/pull/2160
In AVX-512: First Impressions on Performance and ProgrammabilityThis flexibility of CUDA is a software facility, which is independent of the hardware implementation.
For any SIMD processor one can write a compiler that translates a program written for the SIMT programming model into SIMD instructions. For example, for the Intel/AMD CPUs with SSE4/AVX/AVX-512 ISAs, there exists a compiler of this kind (ispc: https://github.com/ispc/ispc).
In How to Think About GPUsISPC: Implicit SPMD Program Compiler
3 points · Open discussionIt's about the author's language named Apple[1], took a few seconds since Apple Array System unfortunately sounds like some MacOS framework.
For people prefer C-like syntax, there is ispc[2], which supports x86 AVX and ARM Neon programming via LLVM.
[1] https://github.com/vmchale/apple
[2] https://github.com/ispc/ispc
In Compiling Array Languages for SIMD [pdf]This so-called GPU programming model has existed many decades before the appearance of the first GPUs, but at that time the compilers were not so good like the CUDA compilers, so the burden for a programmer was greater.
As another poster has already mentioned, there exists a compiler for CPUs which has been inspired by CUDA and which has been available for many years: ISPC (Implicit SPMD Program Compiler), at https://github.com/ispc/ispc .
NVIDIA has the very annoying habit of using a lot of terms that are different from those that have been previously used in computer science for decades. The worst is that NVIDIA has not invented new words, but they have frequently reused words that have been widely used with other meanings.
SIMT (Single-Instruction Multiple Thread) is not the worst term coined by NVIDIA, but there was no need for yet an
Read the rest
other acronym. For instance they could have used SPMD (Single Program, Multiple Data Stream), which dates from 1988, two decades before CUDA.
Moreover, SIMT is the same thing that was called "array of processes" by C.A.R. Hoare in August 1978 (in "Communicating Sequential Processes"), or "replicated parallel" by Occam in 1985 or "PARALLEL DO" by "OpenMP Fortran" in 1997-10 or "parallel for" by "OpenMP C and C++" in 1998-10.
Each so-called CUDA kernel is just the body of a "parallel for" (which is multi-dimensional, like in Fortran).
The only (but extremely important) innovation brought by CUDA is that the compiler is smart enough so that the programmer does not need to know the structure of the processor, i.e. how many cores it has and how many SIMD lanes each core has. The CUDA compiler distributes automatically the work over the available SIMD lanes and available cores and in most cases the programmer does not care whether two executions of the function that must be executed for each data item are done on two different cores or on two different SIMD lanes of the same core.
This distribution of the work over SIMD lanes and over cores is simple when the SIMD operations are maskable, like in GPUs or in AVX-512 a.k.a. AVX10 or in ARM SVE. When masking is not available, like in AVX2 or Armv8-A, the implementation of conditional statements and expressions is more complicated.
Have you looked at [ISPC - Intel SPMD Program Compiler][0]?
[0]: https://github.com/ispc/ispc
In Prefix Sum with SIMDIntel has a opensource SPMD compiler: https://github.com/ispc/ispc
In Duff’s Device in 2021> how should we write code today?
Write in a GPU-style "compute shader" language and let the compiler pick the fastest ways of doing things on each ISA?
https://github.com/ispc/ispc
In SIMD Everywhere: 0.5.0> I think it might be difficult to purposefully cripple AMD in an open source project.
It's not as explicit as it has been in the past, but the CPUID checks for very specific feature sets aligned with particular Intel models may not match AMD models, producing worse code on AMD models that support featuresets above baseline AVX2:
https://github.com/ispc/ispc/blob/master/check_isa.cpp#L106-...
That said, I don't assume malice here and I haven't investigated thoroughly. Most likely they just want to support their own silicon well and that's what they know.
It's possible they would accept similar support for AMD µarchs in the OSS project (or maybe not).
I wouldn't draw too much inference from the ARM example, as I don't see ARM as an Intel competitor. AMD, on the other hand, is currently very competitive with Intel.
In Intel SPMD Program Compiler: A Compiler for High-Performance SIMD ProgrammingYou don't have to guess. The process of upstreaming and the [then] current state of ARM support is described here: https://pharr.org/matt/blog/2018/04/29/ispc-retrospective.ht...
Not sure what conclusions to draw from that, but it looks like ARM support was finally made first class this past August: https://github.com/ispc/ispc/blob/cf90189/docs/ReleaseNotes....
I think it might be difficult to purposefully cripple AMD in an open source project.
In Intel SPMD Program Compiler: A Compiler for High-Performance SIMD ProgrammingLink for the lazy: https://github.com/ispc/ispc/
In The IBM POWER8 Review: Challenging the Intel XeonIntel releases ISPC; a compiler for a C-based SPMD programming language
2 points · Open discussionOh, K's in memory processing model is surely compatible with modern GPUs - at last for most primitives.
The thing I'm not sure about is whether the transfer overhead (GPU, CPU, Memory) would still be worth it in the general case. There's a question of what you're actually comparing to - e.g. you can have a (relatively) naive implementation, like the first commit of Kona was. You can have Arthur's cache-optimized-but-still-pure-C-and-CPU implementation (I think the main kona branch is comparable these days, but I'm not sure), which is faster.
And then, you can compare it to an SSE2/SSE4 version, still on the CPU; such a version does not exist afaik, but is easier to code than you would expect if you use ispc (https://github.com/ispc/ispc/tree/master/examples) or cilk-plus -- simple things with no data dependencies, as many K primitives are
Read the rest
, often get a 4x speedup with ISPC.
Oh, and by the way, thanks for your work on kona and this message -- I've only been following kevinlawler's branch, but I'll start following you too.