It's the author's own benchmark, but it shows the system doesn't work. Recursion isn't hard to eliminate for pure functions; there's nothing inherently wrong with it.

The authors made obviously false claims. That this is an extremely fast implementation. When it's not. That's really poor form.

Okay, no. I know I called out performance in my post, but that was just from my observations. It surprised me to see something be that much slower than pure python. If you show me a near-python code example in a new language, as someone who mostly writes python code, I'm going to go and write it in python and see how it compares performance wise.

The authors never made any kind of false claims at all. You're reading a lot in to both their README and my post.

They've updated the README for a bit of clarity, but even re-reading the README as it was when I looked this morning (and even a few from before) it hasn't claimed to be fast. The claims are all related to the features that it does have, around parallelisation.

I don't get it. Are people on HN so completely ignorant of even the most basic CS101 concepts?

That's not how complexity theory works at all. If your constants are massive you can make anything look like it scales well.

Imagine a compiler that adds in a very large sleep that's inversely proportional to the number of cores. There you go. My compiler now emits code that scales linearly. Of course it's very slow. Where do I pick up my Turing award?

I never thought that CS education was this bad.

Where did he claim it is fast? As far as I can see the only claim is that it scales linearly with cores. Which it actually seems to do.

They show benchmarks with massive performance improvements. That clearly implies that the system is fast. Where's the disclaimer that this performance is worse than Python but eats up an entire massive GPU?

The readme is also blatantly lies: "It is not the kind of algorithm you'd expect to run fast on GPUs." Bitonic sort on GPUs is a thing and it performs well.

The gaslighting is just amazing here.

I'll give you the benefit of the doubt in case README changed, but here's the benchmark it claims, currently, against it's own execution modes:

CPU, Apple M3 Max, 1 thread: 12.15 seconds

CPU, Apple M3 Max, 16 threads: 0.96 seconds

GPU, NVIDIA RTX 4090, 16k threads: 0.21 seconds

The README mentions "fast" in 2 places, none of which is comparing to other languages.

Yes and those benchmarks are real. Showing linear speed up in the number cores when writing standard code is a real achievement. If you assumed that somehow means this is a state of the art compiler with super blazing performance is on no one but you. The readme lays it out very clearly.

I'm astounded by the level of ignorance of basic CS101 principles shown in this thread. You've clearly never taken a class on parallel computing or complexity theory? Geez. HN is decaying.

the irony in you blasting all over this thread is that you dont know how it even works. You have 0 idea if their claims of scaling linearly are causing bottlenecks in other places as you state, if you read actual docs on this its clear that the actaul "compiler" part of the compiler was put on the backburner while the parallellization was figured out and as that is now done a bunch of optimizations will come in the next year

If you want to bring up CS101 so badly, surely turing machines and lambda calculus would be more relevant.

The actually interesting claim is that somebody has found a practical use for Interaction Combinators as a computing model for putting GPUs to work.

You're missing some context, it's not bitonic sort itself that would present an issue with GPUs, it's the "with immutable tree rotations" part, which in a naive implementation would imply some kind of memory management that would have trouble scaling to thousands of cores.