Yeah, I'm retired. The only person I have to answer to regarding progress is me. I'm a stubborn son of a bitch when it comes to choosing quality over speed...

That doesn't mean I don't like progress mind :) This morning I got the preliminary results of a 'C' front-end to the compiler (it uses clang to compile to LLVM IR, then translates to our IR, then feeds that IR into the autovectoriser as if it had parsed the code itself). So for the exact same source code I now have:

     ┌─────────────┬────────────┬──────────────────────┬──────────┐
     │  Benchmark  │ clang -O2  │ xcc --par-auto (GPU) │ Speed-up │
     ├─────────────┼────────────┼──────────────────────┼──────────┤
     │ saxpy       │ 1,546 µs   │ 726 µs               │ 2.1×     │
     ├─────────────┼────────────┼──────────────────────┼──────────┤
     │ Mandelbrot  │ 394,238 µs │ 2,110 µs             │ 187×     │
     ├─────────────┼────────────┼──────────────────────┼──────────┤
     │ nbody       │ 37,090 µs  │ 1,035 µs             │ 36×      │
     ├─────────────┼────────────┼──────────────────────┼──────────┤
     │ perlin      │ 78,016 µs  │ 1,850 µs             │ 42×      │
     ├─────────────┼────────────┼──────────────────────┼──────────┤
     │ mandel_deep │ 73.2 s     │ 55.8 ms              │ 1,312×   │
     └─────────────┴────────────┴──────────────────────┴──────────┘

Those are some pretty fine speedups, from naive C, with no alterations from the standard "C" code - it automatically finds places that can be made data-parallel, tracks the data-hazards to make sure its safe to "GPU" and writes all the kernels, boilerplate and data-stream-management if necessary. Obviously the checksums have to match, so I know it did the work correctly too :)

Hacker News isn't interested - any post I make linking to the webpages is immediately blocked/dead so I'll wait until the C++ front-end is ready (some time next week) and announce it somewhere else. A compiler that takes standard C/C++ code and speeds it up by automatically finding data-parallel areas and scheduling them on the GPU with no programming overhead is pretty rare.

Oh, and it manages the local network as well, so you can run xcd on machines on your lan, or via the TB4/5 bridge between Macs and it'll schedule on other GPUs, just like it manages multiple GPUs on the local machine. It characterises both latency and compute-time to figure out which devices are worth scheduling on.

▲ ggsp 2 hours ago | parent | next [-]

After asking my LLM some questions to barely grasp what you are working on, I can now say: very cool!

For anyone wondering, the thing lives at https://compile-xc.org/ ;)

▲ rpdillon 4 hours ago | parent | prev | next [-]

Awesome, this is genuinely-cool HN material. Thanks for sharing.

▲

Silhouette 3 hours ago | parent [-]

Upvotes don't appear publicly on HN so I'll comment to agree with this. I'm sorry if earlier information about this compiler got lost in the whirlwind. Data parallelism is a hard problem and these results look genuinely impressive so I for one would definitely be interested in hearing more about it and maybe discussing it further when there are interesting developments.

	▲	spacedcowboy 3 hours ago \| parent [-]
		Thanks :) Still working on some of the data-parallel recognition in LLVM IR space. In order to support both C and C++ with the same data-parallel section extraction, I moved the detection from the ‘xc source code’ phase to the IR lowering phase, meaning that everything could ‘feed in’ to the same routines. That’s caused a little friction with the slightly different ways the LLVM IR from clang and xc’s IR encode loops. The above results are all single-loop extractions and the double-loop ones are still ongoing. The system works in 3 stages: 1) by being greedy about which loops could possibly vectorise and marking them, 2) by analysing the IR to reject loops which do pointer-aliasing, or object manipulation, or… and then 3) by measuring the fastest way these known-safe kernels could execute. Which brings me onto one nice thing I haven’t mentioned: that the GPU choice(s) are made at runtime, not compile time, and the system automatically measures (and then persists so it doesn’t have to measure again) the fastest way to run a kernel on the current machine. It handles MSL on Apple devices, PTX on Nvidia cards, Spir-v on Windows, Linux, and Android, and WGSL in the browser. It’ll quite happily divide up the parallel task across a 3090 and a 5080 on my Windows test box for example, with the 5080 doing ~2/3 of the work, because the scheduler is opportunistic. All without writing anything other than plain C with nary a mention of the GPU. Give me a week or two, and I’ll probably announce it on phoronix (which might then get a mention on HN if it goes down well there, and it’ll be a different url so hopefully won’t be insta-dead).

▲ bee_rider 3 hours ago | parent | prev | next [-]

So, the real input to your autovectorizer is LLVM IR; you could soon enough support any language that has an LLVM front-end? (I say soon enough instead of immediately because I’m sure there’s some manual wiring up to do). That seems like a pretty big deal. Do Fortran next, pls. :)

	▲	spacedcowboy 3 hours ago \| parent [-]
		Ssshhh. I like to try things before promising them :)

▲ jazzyjackson 4 hours ago | parent | prev | next [-]

Hell yea I love that computers are getting another chance at becoming compute fabric, just using each others GPUs. Sick.

▲ smokel 3 hours ago | parent | prev | next [-]

> Hacker News isn't interested

I wouldn't be too sure about that :)

▲

spacedcowboy 3 hours ago | parent [-]

I’m being a little cynical - I’ve submitted it twice (though the ‘C’ front end is new) and it bombed both times - the second time within seconds of submission.

I think it’s my own fault, I’ve posted the link to the compiler pages several times in what I thought were relevant posts, and I think HN thinks I’m spamming. So I’m not posting the home page for a while and we’ll see if a future submission “takes”

▲

john_strinlai 3 hours ago | parent [-]

might be worth firing an email to hn@ycombinator.com. they should be able to tell you why your submission was auto-killed, and might work with you to ensure your next submission isnt.

	▲	spacedcowboy 3 hours ago \| parent [-]
		I actually did email the second time because it was clearly an automated response, but I didn’t hear anything back. Not too surprising, Dan is a very busy guy, and he doesn’t know me from Adam :)

▲ _zoltan_ an hour ago | parent | prev | next [-]

sounds very cool - is this basically "C" support for cuTile? :)

▲ ch_sm 4 hours ago | parent | prev | next [-]

That is pretty adventurous, but it sounds really cool! Will it be open source?

	▲	spacedcowboy 3 hours ago \| parent [-]
		Yep. I’d give the link but I think HN thinks I’m spamming because I’ve mentioned it too many times before in posts - hence immediate death of any submission, so I’m not mentioning it for a while to see if that tails off. Bottom line: GPL3 for the compiler, standard library exclusions for derived works, so use it for anything but feed me back improvements to the compiler itself, and you don’t get to redistribute it as your own.

▲ JMKH42 4 hours ago | parent | prev [-]

I like it! The Rust crew would love this I bet.