Remix.run Logo
Remix clone Hacker News
new | show | ask | jobsGithub
▲ yulaow 2 days ago

I am not in META but for what I read on blind, assuming it is true, they are not spending any time in long planning sessions or in getting into details of the implementation plan at all, and they could not anymore considering how many PRs in parallel they are requested to manage

▲spacedcowboy a day ago | parent | next [-]

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 a day 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 a day ago | parent | prev | next [-]

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

▲Silhouette a day 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 a day 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).

▲jazzyjackson a day ago | parent | prev | next [-]

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

▲bee_rider a day 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 a day ago | parent [-]

Ssshhh. I like to try things before promising them :)

▲smokel a day ago | parent | prev | next [-]

> Hacker News isn't interested

I wouldn't be too sure about that :)

▲spacedcowboy a day 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 a day 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 a day 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 :)

▲ch_sm a day ago | parent | prev | next [-]

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

▲spacedcowboy a day 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.

▲_zoltan_ a day ago | parent | prev | next [-]

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

▲spacedcowboy 15 hours ago | parent [-]

Well, the end product might be similar, but the approach is a bit different. 'xc' is a language in its own right, and it can be compiled (with xcc) to both the CPU and GPU (and I have plans to make it work on a Zynq too, a sort of HLS).

The C front-end I'm currently working on is something that looks at the LLVM IR that clang produces and converts it to xc-IR, then runs the data-parallel extraction through the same routines as the original xc language. Consider it to be a 'Y' branch on the inputs - you can feed it LLVM IR or xc source code, they both get convered to xc-IR and from then onwards it's all the same.

So yes, you get tiled work-units, overlapping in time between compute/data-transport and tuned so that actually works, and an opportunistic scheduler that sends them to whatever worker can handle it at the instant of being sent. That opportunistic nature means the faster cards (eg my 5080) will naturally get more work, because the scheduler just keeps all cards busy. The divide between the 5080 and the 3090 in my Windows test box is about 2:1.

But the scheduler is also aware of networked GPUs - my M4 max has a pretty fast GPU, but it's connected to my wife's M3 Max by thunderbolt, and I measured a 37 Gbit/sec connection, so my app can send data to be processed over that very fast link and get results back. If you have a 10GBit nic, then it will work pretty well too, if your nic is "only" 1Gbit then modern GPU speed means that unless your work-units are really computationally intensive, it'll be faster to do it locally - and xcd will work that out at runtime and adopt that faster approach.

▲JMKH42 a day ago | parent | prev [-]

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

▲mepiethree a day ago | parent | prev [-]

Do you think they are actually shipping anything useful any faster? Muse is pretty impressive. I’m not seeing radical progress otherwise