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

121–130 of 157 posts

Re: Rewriting a high performance vector database in Rust

#121

Post by codespin »

cercatrova wrote: post #115
lupire wrote: post #86

I liked the part where they said Python is too slow because it's garbage collected, and didn't show any metrics, and then built a new solution and Rust and didn't show metics to compare to the original system. Makes me think the eng lead just wanted to do Rust, and made up a rationalization.

Well, we already know Python is inherently slower than Rust or any compiled language really, so does one really need metrics to know that the Rust implementation was faster?

a perf change without perf numbers is a bug

Re: Rewriting a high performance vector database in Rust

#122

Post by nicoburns »

kaladin_1 wrote: post #41

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

> Is Rust such a straight-forward language that people new to the language can write a very performant programme

Yes. At least that was my experience coming to Rust from a primarily JavaScript background. My first Rust program wasn't as fast as it could have been (I know a lot more about optimising programs now than I did then), but it was still ~30x faster than the JavaScript and Pythons versions my company had attempted to write first. That's without putting all that much effort into optimising it.

Re: Rewriting a high performance vector database in Rust

#123

Post by code_biologist »

jiggawatts wrote: post #114
smitty1e wrote: post #106

What is a vector database? https://www.pinecone.io/learn/vector-database/ ...was less than informative.

Standard row-oriented databases store columns on disk like so: ABCABCABCABC Vector databases store them like this: AAAABBBBCCCC This allows faster queries if you just need one (or a few) columns, because unrelated columns don’t have to be processed at all. Caches are more efficient, vector CPU instructions can be used, etc… The downside is that random single row access is more expensive because a row has to be reasse…

You're describing a column store there, not a vector store.

Re: Rewriting a high performance vector database in Rust

#125

Post by nicoburns »

krona wrote: post #61
pornel wrote: post #51

Earlier quoted context omitted.

Despite Rust's steep learning curve, it's also paradoxically easy to add novice Rust programmers to a project. This is because inexperienced Rust programmers are relatively harmless. Noob mistakes won't compile, rather than running into dangerous gotchas. You can tell noobs not to use `unsafe` (and there are ways to enforce that), and mostly they'll just write inefficient or non-idiomatic code, but the code will be f…

Memory sanitizers, address sanitizers, leak sanitizers, threading sanitizers, undefined behaviour sanitizers. The visual studio core guidelines checker. The clang-tidy core guideline checker. I could go on but my point is, the landscape does not really look like how you've painted it.

Would you trust someone new to C++ to use these properly? The great thing about Rust is that you get all this and more (Rust's static checks are a lot more watertight) right out of the box without any configuration.

Re: Rewriting a high performance vector database in Rust

#126

Post by nicoburns »

arriu wrote: post #47
kaladin_1 wrote: post #41

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

I agree, rust has a difficult learning curve. I’ve often heard at least a year is required to really feel confident.

For me it was ~2 weeks to get out of "learning mode" and into actually writing production code. 3 months to feel proficient. Maybe a year to feel that I had reached parity of fluency with languages I already knew.

Re: Rewriting a high performance vector database in Rust

#127

Post by nicoburns »

slt2021 wrote: post #39
mattnewton wrote: post #20

Earlier quoted context omitted.

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 the…

I believe the main reason Python is slow is because the cpython project has rejected performance enhancements in favour of keeping the code simple. JavaScript has similar semantics to Python, and its performance is not far behind Java/C# at all.

Re: Rewriting a high performance vector database in Rust

#128

Post by maccard »

lupire wrote: post #79
dymk wrote: post #57

Earlier quoted context omitted.

It takes longer to learn how to use C++ to the same level of proficiency and correctness compared to Rust, in my experience. It's harder to write an incorrect program in Rust.

What are the main correctness risks in C++ if you just never use a raw pointer?

I write c++ every day. Theres no such thing as "just never use a raw pointer", as existing code will use pointers, libraries become pointers, and there's no "non-owning" equivalent of a unique pointer. Even if there was:

- lifetimes are hard. The core guidelines recommend using span and string view, but correct usage of those isnt straightforward:

    std::string_view make(const std::string& in)
    {
        return in;
    }
Is not safe, at all. Span is also super dangerous:

    std::vector vec = {1, 2};
    std::span sp = vec;
    vec.push-back(1);
Lambda capture semantics are another area where you might end up surprised by the behaviour too, (and by surprised, I mean you'll have memory issues).

Then there's all the normal stuff that still exists like slicing, lack of bounds checking, resource leaks because of improper inheritance use, data races, use-after-free issues. Sure these can be caught by a sanitizer with enough effort, but they still exist.

Re: Rewriting a high performance vector database in Rust

#129

Post by throwaway2392 »

viig99 wrote: post #113
lupire wrote: post #86

I liked the part where they said Python is too slow because it's garbage collected, and didn't show any metrics, and then built a new solution and Rust and didn't show metics to compare to the original system. Makes me think the eng lead just wanted to do Rust, and made up a rationalization.

Same, "We knew that C++ was harder to scale and maintain high quality as you build a dev team" this just sounds arbitary and a weak excuse to use rust, C++-20 is as scalable as rust with a very rich ecosystem.

> ...with a very rich ecosystem.

As someone who was heavy in C++14/17 it's much nicer in Go/Rust-land.

As much as I love Bjarne, I'm not coming back.

Re: Rewriting a high performance vector database in Rust

#130

Post by Arcuru »

pornel wrote: post #51
kaladin_1 wrote: post #41

I have no problem with people rewriting their projects in whatever language they see fit. What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++. So, I wonder, if his in-house devs could pick up Rust that they previously couldn't write, why does he think he can not hire a good programmer and charge him to learn the stack the company uses. Why m…

Despite Rust's steep learning curve, it's also paradoxically easy to add novice Rust programmers to a project. This is because inexperienced Rust programmers are relatively harmless. Noob mistakes won't compile, rather than running into dangerous gotchas. You can tell noobs not to use `unsafe` (and there are ways to enforce that), and mostly they'll just write inefficient or non-idiomatic code, but the code will be f…

I think it's great that Rust is safe in that way, where you can have novice programmers write code and you can be pretty sure it won't break anything else.

I recently spent some time fixing performance issues in some novice Rust code, and while the code was pretty clearly written by someone new to systems programming it still all worked fine - https://jackson.dev/post/rust-coreutils-dd/

Post reply on HN