Live data from Hacker News

Rewriting a high performance vector database in Rust

pinecone.io

111–120 of 157 posts

Re: Rewriting a high performance vector database in Rust

#111
post #71

Earlier quoted context omitted.

Another one that never used Borland, Apple, IBM IDEs. Where is the Rust IDE that is half as capable as C++ Builder, MPW/Metrowerks, Visual Age, Zortech? Considering all features they offered across the board in the box, not only code completion.

I've used Borland. I'm sure it was marvelous at the time, but it doesn't hold a candle to CLion or Visual Studio in the 2010s or later.

CLion now ships a cross platform C++ framework with it?

As for Visual Studio, yeah it is great in all aspects, except having nothing else beyond MFC to offer on the GUI department, WinUI is still a mess after UWP.

In any case your examples are for C++ IDEs, reinforcing my case of C++ tooling versus Rust.

Re: Rewriting a high performance vector database in Rust

#112
post #67

Earlier quoted context omitted.

And? A drop in the ocean of libraries.

And virtually no one should be starting new projects in C++ and everyone should switch to Rust.

Start by removing C++ from Rust compiler.

Then go around for Khronos, NVidia, Microsoft, Sony, Nintendo, Unreal, Godot,.... to support Rust on their SDKs.

Re: Rewriting a high performance vector database in Rust

#113
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.

Re: Rewriting a high performance vector database in Rust

#114

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 reassembled from many locations.

Re: Rewriting a high performance vector database in Rust

#115
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?

Re: Rewriting a high performance vector database in Rust

#116
post #39

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…

also, is py still interpreted or jit-compiled?

Re: Rewriting a high performance vector database in Rust

#117
post #89
post #85

Earlier quoted context omitted.

Well... UNSAFE { // TODO: Verify all the lines, all the time, are ok // Just like you do testing, documentation, security and all that // ok? #include using namespace std; int main() { // YOUR CODE } }

What are you saying?

Well if the questions is:

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

All the code on C/C++ IS a correctness "risks". Only constant, manual inspection could(maybe) say otherwise.

What Rust gives is significant reduction of the risks.

Re: Rewriting a high performance vector database in Rust

#118
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?

Yes. If your bottleneck is magnetic disc seeking times, no amount of language change is going to move the needle (hah!).

Re: Rewriting a high performance vector database in Rust

#119

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…

> What stood out for me in the article is him saying that it's difficult getting developers with experience in both Python and C++.

More like they had difficulty finding cheap experienced c++/python devs.

Re: Rewriting a high performance vector database in Rust

#120

Earlier quoted context omitted.

Rust is not boring technology. There's too much ecosystem churn, and new language features are deployed too often. C++ isn't boring technology, either. If you just want to deliver value, I'd recommend Java.

> There's too much ecosystem churn, and new language features are deployed too often. That kinda feels like saying Linux is too crazy because new apps get made for Linux frequently. You can use the same part of the language tomorrow that you used today. Nothing is changing out from under you. If you're afraid of libraries, don't use them. You'd have the same problem in any ecosystem that is new, no?

> That kinda feels like saying Linux is too crazy because new apps get made for Linux frequently.

Apps are okay, but other parts of userland that roll out breaking changes on a regular basis are definitely a problem [1] [2] [3]. Even if they aren't technically part of the kernel, they are usually used with it to provide a complete working system, and they break stuff all the time.

[1]: https://lwn.net/Articles/904892/

[2]: https://lwn.net/Articles/840430/

[3]: https://lwn.net/Articles/777595/

Post reply on HN