brian-armstrong

Joined 11 years ago

Karma
5,217
Submissions
1,079
Member since
Nov 29
View on Hacker News

Recent submissions

Comment · 19 hours ago
I'm still holding out for the sequel
Comment · 8 days ago
Oh no! This is going in the wrong direction, isn't it? From the headline, I'd assumed the takeaway was encouraging small changes (and 1000 LoC is not "small" by any definition) and maybe encouraging the author to refactor at larger sizes to make human review easier. Instead it's just bypassing human review entirely?

Code review is such a key step to the feedback loop and helps keep people current on the changes as they come out. Skipping that entirely is just inviting disaster.

Comment · 17 days ago
Thank you, glad you liked it
Comment · 1 month ago
Ah, in that case, you would certainly be excused for trying to kill one or two of them.
Comment · 2 months ago
The people who still use Windows yet complain about this are quite confusing to me. There's been every indication that it will keep going like this for years now, and the cost of switching is just not that high. If you're still riding that train it's time to just embrace it.
Comment · 2 months ago
Is this related to the streaming service of the same name?
Comment · 2 months ago
Interesting. I'll have to give it a try. If I understand your suggestion, you're saying that rather than doing 2 lookups for logs, then an addition, and then another lookup to exp back, we could just precompute the whole thing for any 2 arguments and do one lookup in a table? It's worth noting that some of the operations already use the mul_log format which just does an add with wraparound, but I could certainly see the big table option helping when we truly need field.mul

As far as LDPC, I'd love to, but I need to get a better understanding of them first. I'll probably go for Turbo next just because conceptually they feel closer to the convolutional codes I have already. But time willing, it'd be fun to do both.

Comment · 2 months ago
Oh! Gotcha! I put a table in the README that lays it all out https://github.com/brian-armstrong/fec#performance

tldr: My library matches or beats libfec's SSE2 assembly for convolutional codes and pretty steadily beats it in Reed-Solomon. For the convolutional codes, my crate is using a generic, templated decoder rather than hand-written assembly, so it was nice to see that I could match the performance.

Comment · 2 months ago
I used the benchmarking binaries that ship with libfec. My own crate has a libfec-compatible C shim, so I can link the benchmark against the Rust crate. The benchmark itself reports time spent for a given number of iterations, so the throughput can just be extrapolated from that.
Comment · 2 months ago
You could certainly call this crate through a shim in goestools but you'd have to add a Rust dependency. But you could also rewrite goestools in Rust, though it wouldn't be a small undertaking. This crate does have everything you'd need for the forward error correction, at least.
Comment · 3 months ago
The models would have to get significantly better for this to help, though. Unedited LLM dialog is quite bad. Though, I wouldn't put it past AAAs to try anyway.
Comment · 4 months ago
I read these stories and I can never figure out how people are managing to use these $200 plans. If I really go full bore, I can sometimes max out the $20 plan. Even then, it already produces more code than I can reasonably review and merge.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton