Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting a high performance vector database in Rust

pinecone.io

Post reply on HN
Print view View original

31–40 of 157 posts

Re: Rewriting a high performance vector database in Rust

#31

Post by pclmulqdq »

dxhdr wrote: post #13
22SAS wrote: post #5

Glanced through the article, and I see no comparisons on how performance of the DB is in Rust versus their current C++ implementation, no mention of if maintaining the Rust code is easier than their C++ codebase, no stats on how devs are ramping up and how it's tackling their "hard to find a dev who knows both C++ and Python well" issue.

Article also states that the switch from C++ to Rust improves "low level optimized instruction sets, memory layout, and running async tasks." The first two are also strengths of C++, and for the third the article says that "Rust is async, and Tokio is the one of the most popular async providers ... However, it’s not great for running CPU intensive workloads, like with Pinecone." Puzzling.

My past experience with Rust async code is that both async-std and Tokio are fairly unimpressive on performance (as async code goes), particularly if you compare to ScyllaDB's runtime or other similar C++ async runtimes.

Re: Rewriting a high performance vector database in Rust

#32

Post by jerf »

howinteresting wrote: post #30
pjmlp wrote: post #27

Earlier quoted context omitted.

Assuming there is even a Rust library replacement to start with. People keep forgetting C++ has 30 years of being deployed in production. Rust is 2022 is like using C++ in 1990's in terms of ecosystem.

This is just plain false. C++ in the 1990s had nothing like serde for example.

The minimum bar for a language has moved up significantly since the 1990s. It isn't enough to just have a neat new idea, you need to ship with nearly-best-of-breed JSON serialization, a web server, a huge standard library with not just strings but things like compression and a lot of networking, and a laundry list of other things (give or take a few things) just to make it to the "barely viable alternate choice" point.

Nice as a language consumer, but a bummer that building new languages and getting some attention is so much harder than it used to be.

Re: Rewriting a high performance vector database in Rust

#33

Post by avgcorrection »

ayewo wrote: post #18

Rewriting in Rust is not a meme, it's a cycle. Before Rust became viable, rewrites were done in Go. From the archives: - Rewriting a large production system in Go https://news.ycombinator.com/item?id=6234736 (2013) - How We Moved Our API From Ruby to Go https://news.ycombinator.com/item?id=9693743 (2015) - Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App https://news.ycombinator.com/it…

The stable release of Go was maybe four years or so before Rust. So what you’re saying seems to be that people like to rewrite their tech in young and hyped (for good or bad or neutral) languages. Because there is little connection between Rust and Go (other than chronology).

Re: Rewriting a high performance vector database in Rust

#34

Post by rastignack »

howinteresting wrote: post #30
pjmlp wrote: post #27

Earlier quoted context omitted.

Assuming there is even a Rust library replacement to start with. People keep forgetting C++ has 30 years of being deployed in production. Rust is 2022 is like using C++ in 1990's in terms of ecosystem.

This is just plain false. C++ in the 1990s had nothing like serde for example.

Where are the production grade and pure rust tls library ? Key-value store ? Ldap client ? SSH client ?

Re: Rewriting a high performance vector database in Rust

#36

Post by [deleted] »

ayewo wrote: post #18

Rewriting in Rust is not a meme, it's a cycle. Before Rust became viable, rewrites were done in Go. From the archives: - Rewriting a large production system in Go https://news.ycombinator.com/item?id=6234736 (2013) - How We Moved Our API From Ruby to Go https://news.ycombinator.com/item?id=9693743 (2015) - Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App https://news.ycombinator.com/it…

[deleted]

Re: Rewriting a high performance vector database in Rust

#38

Post by darksaints »

pjmlp wrote: post #27
riskable wrote: post #24

Earlier quoted context omitted.

> Which is why old timers eventually learn to just deliver with ~~boring~~ buggy technology. There's a reason why folks take the time to rewrite things in Rust. No matter how good you are at C/C++ you will encounter bugs that you would not have if you had written it in Rust.

Assuming there is even a Rust library replacement to start with. People keep forgetting C++ has 30 years of being deployed in production. Rust is 2022 is like using C++ in 1990's in terms of ecosystem.

The C++ IDEs available up until about 10 years ago were complete garbage. C++ still doesn't even have a good package manager. All the build systems are pure chaos. The largest C++ package manager has 1500 packages. In comparison, rust's package manager and build system are way easier to use and already have 94,000 packages available to users.

That's not exactly fair to C++ because entire categories of dev tools (like build systems, package managers, IDEs, debuggers, version control, static analyzers, etc.) have matured after C++ did. And let's not forget that when C++ was new, most libraries were proprietary licensed and paid for, whereas today almost all libs are open source. And those improvements (along with general size of the programming community) mean that a trendy language today is going to develop and mature a lot faster than a formerly trendy language did 30 years ago.

IMO Rust in 2022 is a lot closer to java in 2005 than C++ in the 1990s.

Re: Rewriting a high performance vector database in Rust

#39

Post by slt2021 »

mattnewton wrote: post #20
fwip wrote: post #3

> First of all, Python is a garbage collected language, which means it can be extremely slow for writing anything high performance at scale. I don't think garbage collection is in the top 3 causes of why Python is slow.

This might be a difference of semantics- there is a difference between garbage collection as a concept being slow and python's GIL approach. My understanding is that the GIL would almost always make the top 3 reason of why python is slow in practice - it works for a very specific single threaded execution model but can't really take advantage of modern processors.

I think GIL is not the reason for slowness, it just specifies single threaded interpreter execution model. You can always spin up more interpreters to take advantage of multiple cores.

The reason for slowness - is the weak dynamic type system of Python.

Every single instruction need to be type checked at runtime and thus making everything slow.

Compare to C#/Java which have GC but both are amazingly fast, because these languages have stricter type system. If you add JIT on top (which can selectively replace MSIL/java opcodes with native machine instructions) and it makes perf on par with natively compiled languages like C++.

Re: Rewriting a high performance vector database in Rust

#40

Post by sbdivuvu »

avgcorrection wrote: post #33
ayewo wrote: post #18

Rewriting in Rust is not a meme, it's a cycle. Before Rust became viable, rewrites were done in Go. From the archives: - Rewriting a large production system in Go https://news.ycombinator.com/item?id=6234736 (2013) - How We Moved Our API From Ruby to Go https://news.ycombinator.com/item?id=9693743 (2015) - Matrix and Riot Confirmed as the Basis for France’s Secure Instant Messenger App https://news.ycombinator.com/it…

The stable release of Go was maybe four years or so before Rust. So what you’re saying seems to be that people like to rewrite their tech in young and hyped (for good or bad or neutral) languages. Because there is little connection between Rust and Go (other than chronology).

No post body was provided.
Post reply on HN