I'm writing a language called xc and its compiler, xcc for the last 6 months or so (full disclosure: with a lot of help from Claude). I've finally got version 1 (actually v1.0.1) out, for Linux (x86-64 and arm64, including the Pi 5), macOS and Windows.
The idea: you write an ordinary loop, the compiler works out whether it can run in parallel, and it emits both a multi-core CPU version and GPU kernels (MSL, PTX, SPIR-V or WGSL, all generated by xcc itself without needing an SDK installed).
At run time the program measures each block on that machine and keeps the faster placement.
Examples:
- On an M3 Max a Mandelbrot block takes 13.7 ms on all 16 cores and 1.3 ms on the GPU
- On a Ryzen 9955HX's 2-CU integrated Radeon the GPU loses to the 32 CPU threads, so it stays on the CPU.
The compiler also reads plain old C via clang's front end and does the same thing to C loops, with no pragmas. Comparing xcc to OpenMP for both gcc and clang (with the helping hand of "#pragma omp parallel for" gives (times in ms):
Geometric mean: xcc is 2.1x faster than GCC+OpenMP and 3.0x faster than clang+OpenMP.
All the builds are checked to make sure they give the same result - no point having a benchmark that doesn't produce the same result! xcc has a notable win for nbody, because its vectorisation is better (across bodies) but perlin has been a bit of a bugbear throughout the leading-up-to-v1 timespan.
Platform-specific binary tarballs, the sources, OpenMP versions and method are on the site (linked from github), and there are Phoronix Test Suite profiles if you'd like to run them yourself.
It's only just made v1 so there's a few rough edges: C++ through clang is in-progress (but not official yet), and the Pi 5's GPU is slow. Not sure if that's the Pi or the code yet...
There's more to the language but I don't want this to be an essay! The real, honest-to-$deity cool thing is the automatic parallelising of standard C/xc loops and being able to run that code on the GPU with no boilerplate - "ARC for Algorithms" (what Objective-C's ARC did for memory management), it "just works".
Very keen to get feedback and fix any gaps. I think it's generally useful right now, but it is "v1" - Bug reports welcome as GitHub issues...
I'm writing a language called xc and its compiler, xcc for the last 6 months or so (full disclosure: with a lot of help from Claude). I've finally got version 1 (actually v1.0.1) out, for Linux (x86-64 and arm64, including the Pi 5), macOS and Windows.
The idea: you write an ordinary loop, the compiler works out whether it can run in parallel, and it emits both a multi-core CPU version and GPU kernels (MSL, PTX, SPIR-V or WGSL, all generated by xcc itself without needing an SDK installed).
At run time the program measures each block on that machine and keeps the faster placement.
Examples:
- On an M3 Max a Mandelbrot block takes 13.7 ms on all 16 cores and 1.3 ms on the GPU
- On a Ryzen 9955HX's 2-CU integrated Radeon the GPU loses to the 32 CPU threads, so it stays on the CPU.
The compiler also reads plain old C via clang's front end and does the same thing to C loops, with no pragmas. Comparing xcc to OpenMP for both gcc and clang (with the helping hand of "#pragma omp parallel for" gives (times in ms):
Geometric mean: xcc is 2.1x faster than GCC+OpenMP and 3.0x faster than clang+OpenMP.All the builds are checked to make sure they give the same result - no point having a benchmark that doesn't produce the same result! xcc has a notable win for nbody, because its vectorisation is better (across bodies) but perlin has been a bit of a bugbear throughout the leading-up-to-v1 timespan.
Platform-specific binary tarballs, the sources, OpenMP versions and method are on the site (linked from github), and there are Phoronix Test Suite profiles if you'd like to run them yourself.
It's only just made v1 so there's a few rough edges: C++ through clang is in-progress (but not official yet), and the Pi 5's GPU is slow. Not sure if that's the Pi or the code yet...
There's more to the language but I don't want this to be an essay! The real, honest-to-$deity cool thing is the automatic parallelising of standard C/xc loops and being able to run that code on the GPU with no boilerplate - "ARC for Algorithms" (what Objective-C's ARC did for memory management), it "just works".
Very keen to get feedback and fix any gaps. I think it's generally useful right now, but it is "v1" - Bug reports welcome as GitHub issues...