LightMachine

9 ms·

1.
OptMem: Plug-and-play infinite memory for any agent(github.com)
1 points by LightMachine 2mo ago|3 comments
2.
Claude Plays Pokémon(twitch.tv)
75 points by LightMachine 2y ago|24 comments
3.
Show HN: SupGen, an model-free program synthesizer by examples / dependent types(youtube.com)
21 points by LightMachine 2y ago|9 comments
4.
Optimal context passing with HVM's "pure mutable references"(gist.github.com)
1 points by LightMachine 2y ago|0 comments
5.
HVM3's Optimal Atomic Linker (With Polarization)(gist.github.com)
2 points by LightMachine 2y ago|0 comments
6.
Since Agda->JS is unmaintained, I'm now using Sonnet-3.5 as the compiler(twitter.com)
2 points by LightMachine 2y ago|0 comments
7.
Optimal Evaluation in 1 Minute (or 10 Minutes) (or 10 Years)(gist.github.com)
2 points by LightMachine 2y ago|0 comments
8.
by LightMachine 2y ago
The search space I'm using is that of all functions of a given dependent type. That allows you to make the search space by using a strong enough type. For example, if you search for `Integer -> Integer -> Integer` function, it wi
9.
by LightMachine 2y ago
It will just return the smallest function that passes your tests. It works by enumerating ALL possible functions and running them. Obviously, that naive approach is exponential, so, the entire point is whether we can apply some clever trick
10.
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
11.
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
12.
by LightMachine 2y ago
That is actually an amazing idea. I'll adopt it.
13.
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.
14.
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
15.
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
16.
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
17.
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
18.
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.
19.
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
20.
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
21.
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 :')
22.
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
23.
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.
24.
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
25.
by LightMachine 2y ago
That's a great feedback actually, thank you. We'll add the disclaimer before the install instructions instead!
26.
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
27.
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
28.
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,
29.
by LightMachine 2y ago
Scaling with cores is synonym of parallel.
30.
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

More ›