KAdot
Joined 15 years ago
Karma
223
Submissions
77
Member since
Oct 2
http://artem.krylysov.com/
View on Hacker NewsRecent submissions
Comment · 1 month ago
Every new EC2 generation is typically slightly more expensive, but the gains in the compute performance are 15-25% or even higher depending on your workload. The same dollar buys you a lot more compute power than a decade ago.
Comment · 2 months ago
I heavily A/B tested Opus vs Sol for two weeks, giving Claude Code and Codex the same tasks and comparing the results. In my experience Sol is much closer to Opus than to Fable, with Opus often beating Sol. The only area where Sol is better is code reviews, which these benchmarks confirm. I wish they included Fable.
Comment · 2 months ago
The benchmark is setup to test 80 MiB dataset on a machine with 32 GiB RAM, which doesn't represent a typical database workload. How does the key-value store perform on larger than RAM datasets? MMAP is fast when the dataset fits in memory, but it can slow to a crawl when it doesn't, especially if the workload is mostly random point lookups.
Comment · 5 months ago
Going back to 4.7 with `claude --model claude-opus-4-7` fixed it for me.
Comment · 6 months ago
Is it closed source?
Comment · 1 year ago
This is not my experience. I've been running RocksDB for 4 years on thousands of machines, each storing terabytes of data, and I haven't seen a single correctness issue caused by RocksDB.
Comment · 1 year ago
> We are interested in making OTAP pipelines safely embeddable, through strict controls on memory and through support for thread-per-core runtimes.
I'm curious about the thread-per-core runtimes, are there even any mature thread-per-core runtimes in Rust around?
Comment · 1 year ago
The benchmark doesn't accurately represent the real-world database performance because the dataset is too small (roughly half a gigabyte based on [1]?), meaning it fits into the page cache bypassing disk I/O.
[1]: https://github.com/voidDB/voidDB/blob/master/test/bench_test...
Comment · 2 years ago
The benchmark is not comparing apples to apples.
prost is the most widely used Protobuf implementation in Rust, maintained by the Tokio organization. prost generates structs and serialization/deserialization code for you.
easyproto according to GitHib Search is used only by two projects. easyproto provides primitives for serializing and deserializing Protobuf, and requires hand writing code to do both.
A fair comparison would be prost vs google.golang.org/protobuf, or easyproto vs parts of quick-protobuf.
In most cases you can make Go as fast as Rust, but from my experience writing performance-sensitive code in Go requires significantly larger time investment and overall requires deeper language expertise. Pebble (RocksDB replacement in Go by CockroachDB) is a good example of this, the codebase is littered with hand-inlined[1] functions, hand-unrolled loops and it's not[2] even using Go memory management for performance critical parts, it's using the C memory allocator and manual memory management.
[prost]: https://github.com/tokio-rs/prost [easyproto]: https://github.com/VictoriaMetrics/easyproto [google.golang.org/protobuf]: https://github.com/protocolbuffers/protobuf-go [quick-protobuf]: https://github.com/tafia/quick-protobuf [1]: https://github.com/cockroachdb/pebble/blob/c34894c46703fd823... [2]: https://github.com/cockroachdb/pebble/blob/master/docs/memor...
Comment · 2 years ago
The redis.io landing page says "from the ones who built it" just wow.