Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
amitprasad
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
16 ms
·
1.
▲
by
amitprasad
4mo ago
Our system somewhat predates ublk; at the time we wrote it, FUSE was the most reasonable option. Moving over to ublk would require re-architecting around block devices rather than filesystems, but is indeed something we're looking at!
2.
▲
by
amitprasad
6mo ago
Relevant post: https://modal.com/blog/dollars-per-token-considered-harmful (disclaimer: I work with the author)
3.
▲
by
amitprasad
6mo ago
I’m being a little reductive and ignored Guix purely based on adoption; but you’re completely right. I believe the core argument is that there is a (relatively small) category of these tools of which Nix is the most well-known representativ
4.
▲
The only sane way to use Linux
(amit.prasad.me)
5 points
by
amitprasad
6mo ago
|
2 comments
5.
▲
by
amitprasad
7mo ago
Just because you or I may invest effort into deep-thinking, it does not mean that others will. I'm not worried about this at Modal, but I am worried about this in the greater OSS community. How can I reasonably trust that the tools I
6.
▲
by
amitprasad
7mo ago
To be clear, I am also having the most fun I've had when it comes to side-projects and even more exploratory things at work. I don't derive all my joy from "Good Code" -- that's silly! I would much rather ship tan
7.
▲
by
amitprasad
7mo ago
It's hard to say. Perhaps LLMs of tomorrow will become capable enough to fix the mistakes of LLMs today. If so, great -- I'm worried about nothing. If not, we could see that LLMs of tomorrow struggle to keep up with the bloat of t
8.
▲
by
amitprasad
7mo ago
I would be extremely happy to be proven wrong! I love using agents for exploratory prototypes as well as "rote" work, but have yet to see them really pay off when dealing with existing tech debt. I find that the flaws of agentic w
9.
▲
by
amitprasad
7mo ago
Right: Having "Good Code" is an investment into future velocity. IMO we shouldn't strive to make an entire codebase pristine, but building anything on shaky foundations is a recipe for disaster. Perhaps the frontier models of
10.
▲
by
amitprasad
7mo ago
There's an opportunity-cost here. I use agents to be more productive. As many have noted, "Good Code" doesn't rank highly compared to actually shipping a product. The tragedy, for me, is that the bar has been lowered. Wh
11.
▲
The silent death of good code
(amit.prasad.me)
126 points
by
amitprasad
7mo ago
|
96 comments
12.
▲
by
amitprasad
8mo ago
If you're not looking for GPU snapshotting the ecosystem is relatively mature. Specifically, CPU-only VM-based snapshotting techniques are pretty well understood. However, if you need GPUs, this is a notoriously hard problem. IIRC Fly
13.
▲
by
amitprasad
9mo ago
Generic data stores often don’t have this luxury — if you’re designing a system in which data is relatively opaque, you’re often forced to work with bytes. (e.g. rocksdb, etc)
14.
▲
by
amitprasad
9mo ago
author here -- agreed on all fronts. Mentioned this in the other comment but I approached the topic from a relatively narrow perspective (I was working on a specific project at the time) I think it's worth including these things in a f
15.
▲
by
amitprasad
9mo ago
Unexpected seeing this posted here. I wrote this post mostly out of interest for a personal project and thus it's not actually a very holistic exploration of the topic. May revisit and update it in the future :)
16.
▲
by
amitprasad
10mo ago
How is the 795s7? What do you put it to work on? Just sprung for one at a good price.
17.
▲
by
amitprasad
10mo ago
This is notoriously hard when you start to involve GPUs
18.
▲
by
amitprasad
11mo ago
This is heavily language runtime dependent — there’s nothing that fundamentally stops you from doing anything during the phase between jumping to an entry point and the main()
19.
▲
by
amitprasad
11mo ago
Not so much the confusion of what little endian is, but how we tend to represent it in notation. Of course this confusion was back when I was first learning things in high school, but I imagine I’m not alone in it
20.
▲
by
amitprasad
11mo ago
I think I got stuck in the same rut that I learned address space in whilst writing that diagram. I would tend to agree with you that your model makes much more sense to the student. Related: In notation, one thing that I used to struggle wi
21.
▲
by
amitprasad
11mo ago
You’re right, and I knew this back in February when I wrote most of this post. I must have revised it down incorrectly before posting; will correct. Bit of a facepalm from my side.
22.
▲
by
amitprasad
11mo ago
Ah I should have taken the time to verify; It might also have something to do with the way I was compiling / cross-compiling for RISC-V! More generally, I'm not surprised at the symtab bloat from statically-linking given the absol
23.
▲
The Journey Before main()
(amit.prasad.me)
316 points
by
amitprasad
11mo ago
|
143 comments
24.
▲
The GPU Glossary: Performance
(modal.com)
2 points
by
amitprasad
1y ago
|
0 comments
25.
▲
by
amitprasad
1y ago
Ah yes, you’re completely correct :) General idea was just to highlight some of the dangers of vector registers. I believe the same is true of ymm (256) to a lesser extent.
26.
▲
by
amitprasad
1y ago
Note that, especially on certain Intel architectures, using AVX512 instructions _at all_ can result in the whole processor downclocking, and thus ending up resulting in inconsistent / slower overall performance. https://stac
27.
▲
by
amitprasad
2y ago
Feels like there’s three different ways that JSON objects are represented in KEON. It might be more concise, e.g., in the Newtype case, but the sacrifice seems to be quite a bit more cognitive complexity, which I would personally value over
28.
▲
Notes on Sorted Data
(amit.prasad.me)
1 points
by
amitprasad
2y ago
|
0 comments
29.
▲
Building Thread-safe Async Primitives in 150 lines of Rust
(amit.prasad.me)
4 points
by
amitprasad
2y ago
|
0 comments
30.
▲
by
amitprasad
3y ago
Also relevant: LLM in a flash: Efficient Large Language Model Inference with Limited Memory Apple seems to be gearing up for significant advances in on-device inference using this LLMs https://arxiv.org/abs/2312.11514
More ›