LightMachine

9 ms·

61.
by LightMachine 2y ago
Uhm author here. Not sure why this tweet is on Hacker News, as it is just a non-technical "blog post". But I've posted a follow-up today with some code and details, if you're curious: https://x.com/Victor
62.
by LightMachine 2y ago
While it is not fast in a single-thread, it is still 5x-7x faster than Node.js today for programs that are allocate a lot. If all you want is to run a program faster, and doesn't mind a bit more energy, Bend could be useful for you tod
63.
by LightMachine 2y ago
That is actually an amazing idea. I'll adopt it.
64.
by LightMachine 2y ago
It is not in alpha, nor not ready. You can use it in production today, if you want to. It is just not fast . That is different. CPython is still 100x slower than C, and is widely deployed in practice.
65.
by LightMachine 2y ago
I agree... Just a note: we are NOT 10x slower than Python. I think a lot of people got the wrong message from this thread. HVM is actually quite fast already. It is just that, on this specific program, Python was doing no allocations, while
66.
by LightMachine 2y ago
I really appreciate the feedback, but the claim is that the performance scales linearly with cores, and it does. Also that it runs on GPUs, and it does. Yet, asking what is its "floating point operations per second" is nonsense, b
67.
by LightMachine 2y ago
This is on CPU vs GPU. A GPU core (shading unit) is 100x weaker than a CPU core, thus the difference. ON the GPU, HVM's performance scales almost 16000x with 16000x cores. Thus the "near ideal speedup". Not everyone knows how
68.
by LightMachine 2y ago
I really think I take criticism well... The problem is that people were criticizing us for not doing things that were literally done on the second paragraph. So at this point it didn't feel like productive criticism? That's like b
69.
by LightMachine 2y ago
I have no idea what you're trying to convey, but I'm Victor Taelin. Also very cool comment on that thread, hypothesizing on whether we'd be able to ever run it on GPUs. We did it! That is what we're announcing today.
70.
by LightMachine 2y ago
Thanks for the feedback. Some corrections: We do use multi-level caching, and you can achieve 5x higher performance by using it correctly. FFI is already implemented, just not published, because we want to release it with graphics rendering
71.
by LightMachine 2y ago
You're comparing CPU cores to GPU cores! It is "only" 50x because a single GPU core is 100x weaker than a CPU core! Within CUDA cores, it is actually a linear speedup! It does 2k MIPS with 1 CUDA core, and ~28000 MIPS with 16
72.
by LightMachine 2y ago
But it literally says we believe it is the future of parallel computing! If it was faster than GCC today, we would've written present :')
73.
by LightMachine 2y ago
Thanks for the feedback! Some clarifications: 1. I didn't accuse you of doing something wrong, just that your claim was wrong! It has been proven that Interaction Combinators are an optimal model of concurrent computation. I also point
74.
by LightMachine 2y ago
Immutable textures and strings. Perhaps actual mutable arrays. Many numeric types like F64, U64, I64. And some vector types like F16x4.
75.
by LightMachine 2y ago
Dude we're running unrestricted recursion and closures on GPUs! If that's not cool to you, I apologize, but that mind-blowingly cool to me, and I wanted to share it, even though the codegen is still initial. Hell I was actually go
76.
by LightMachine 2y ago
That's a great feedback actually, thank you. We'll add the disclaimer before the install instructions instead!
77.
by LightMachine 2y ago
So use a metric that makes absolutely no sense on given domain, instead of one that is completely correct, sensible, accurate, stablished on the literature, and vastly superior in context? What even is a FLOPS in the context of Interaction
78.
by LightMachine 2y ago
Thanks, and I apologize if I got defensive, it is just that I put so much effort on being truthful, double-checking, putting disclaimers everywhere about every possible misinterpretation. Hell this is behind install instructions: > our c
79.
by LightMachine 2y ago
Right below install instructions, on Bend's README.md: > But keep in mind our code gen is still on its infancy, and is nowhere as mature as SOTA compilers like GCC and GHC. Second paragraph of Bend's GUIDE.md: > While cool,
80.
by LightMachine 2y ago
Scaling with cores is synonym of parallel.
81.
by LightMachine 2y ago
You're wrong. The Haskell code is compiled to a loop, which we didn't optimize for yet. I've edited the README to use the Bitonic Sort instead, on which allocations are unavoidable. Past N=20, HVM2 performs 4x faster than GHC
82.
by LightMachine 2y ago
I apologize, I gave you the wrong answer. I thought you was talking about the DEMO example, which ran ~30% slower than expected. Instead, you were talking about the README, which was actually incorrect. I noticed the error and edited it. I
83.
by LightMachine 2y ago
I agree with you. But then there's the entire "release fast, don't wait before it is perfect". And, then, there's the case that people using it will guide us to iteratively building what is needed. I'm still tr
84.
by LightMachine 2y ago
The only claim I made is that it scales linearly with cores. Nothing else! I'm personally putting a LOT of effort to make our claims as accurate and truthful as possible, in every single place. Documentation, website, demos. I spent ho
85.
by LightMachine 2y ago
I believe the single-core version was running slower due to the memory getting full. The benchmark was adding 2^30 numbers, but HVM2 32-bit has a limit of 2^29 nodes. I've re-ran it with 2^28 instead, and the numbers are `33.39 seconds
86.
by LightMachine 2y ago
Exactly, this kind of thing always happens with these loops, which is why I think programs that allocate are fairer. But then people point out that the C allocator is terrible, so we can't make that point :')
87.
by LightMachine 2y ago
Bend has no tail-call optimization yet. It is allocating a 1-billion long stack, while C is just looping. If you compare against a C program that does actual allocations, Bend will most likely be faster with a few threads. Bend's codeg
88.
by LightMachine 2y ago
Running on 42 minutes is mots likely a bug. Yes, we haven't done much testing outside of M3 Max yet. I'm aware it is 2x slower on non-Apple CPUs. We'll work on that. For the `sum` example, Bend has a huge disadvantage, becaus
89.
by LightMachine 2y ago
We will have 64-bit boxed numbers really soon! As in, next month, or earlier if users find this to be a higher priority.
90.
by LightMachine 2y ago
the single-thread case ran a little slower than it should on this live demo due to a mistake on my part: `run` redirected to the Rust interpreter, rather than the C interpreter. the Rust one is a little bit slower. the numbers on the site a

More ›