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

141–150 of 157 posts

Re: Rewriting a high performance vector database in Rust

#141

Post by AtlasBarfed »

likeabbas wrote: post #6
jalino23 wrote: post #4

rewriting everything in rust is not just a meme?

Memes typically have some basis in reality. If your project reaches a point where it could benefit from fearless concurrency or better memory control, Rust is probably your best bet at the moment. I could see huge benefits from Kafka and Cassandra being re-written in Rust.

20 year JVM programmer and current Cassandra user.

Rust rewrite of cassandra, if it could reach feature parity with 4.0, would be a good thing. (C++ port already sortof exists with ScyllaDB but they haven't reached feature parity yet)

Re: Rewriting a high performance vector database in Rust

#142

Post by orf »

nicoburns wrote: post #127
slt2021 wrote: post #39

Earlier quoted context omitted.

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.

JS has vastly different semantics to Python, one that lends itself much more to the kind of JIT optimisations needed to make it more performant.

Re: Rewriting a high performance vector database in Rust

#144

Post by pjmlp »

estebank wrote: post #134
pjmlp wrote: post #95

Earlier quoted context omitted.

Just like it will happen to Rust when it achieves 30 years of history, getting features every six weeks. How many epochs will exist in 30 years?

As a rough estimate? 10, but I don't know what you think that means. If you look at what [changes] were introduced by the [2018] and [2021] editions, they weren't as earth shattering as some might think: 2018: - Module system changes - Mandatory associated fn argument names - dyn, async, await and try are now keywords - You can't write `let s = libc::getenv(k.as_ptr()) as const _;` anymore, instead needing `let s = l…

Yes, with every Rust shop using their own set of favourite features, which in 30 years that will be plenty to choose from.

This isn't unique to C++ as people like to criticize, compare C# 11, Java 19, Python 3.10, C23... with everything in between down to their initial versions.

Re: Rewriting a high performance vector database in Rust

#145

Post by menaerus »

TehCorwiz wrote: post #46
menaerus wrote: post #35

Quoted post unavailable.

I care. Programming languages give us different frameworks and guardrails to express computational tasks similarly to how written and spoken languages give us a different set of concepts with which to express ideas. New languages mean a potentially different way of thinking about a problem. Some ideas which are difficult to express in one language are trivial in another. Discovering these differences is one of the jo…

You seem to come from a point as if I don't care about the intricate knowledge of programming languages or as if I don't care about learning how different languages manage to solve the same problem but from a different angle or with a different approach. I really do.

What I don't see here in this article is none of that with some very loose arguments around picking Rust vs some other system programming language. Very typical of such type of articles regardless whether they're coming from Rust, C++, Go etc. "I rewrote XYZ in Rust" or "I rewrote XYZ in C++" or "I rewrote XYZ in Go" is basically like saying "I rewrote XYZ in a Turing-complete language". Go figure. How relevant that really is?

Any problem can be solved in any programming language but the important distinction which is very often left unspoken and not demonstrated is what is it that you managed to improve? Is it that you managed to improve the code quality, shorten the development cycle, decreased the number of bugs or was it that you managed to improve the performance? In absence of ability to demonstrate the pros and cons of the approach one took, I will keep finding such articles biased with the lack of real content and therefore annoying. Some will call it programming language circle*erking.

Re: Rewriting a high performance vector database in Rust

#146

Post by TehCorwiz »

menaerus wrote: post #145
TehCorwiz wrote: post #46

Earlier quoted context omitted.

I care. Programming languages give us different frameworks and guardrails to express computational tasks similarly to how written and spoken languages give us a different set of concepts with which to express ideas. New languages mean a potentially different way of thinking about a problem. Some ideas which are difficult to express in one language are trivial in another. Discovering these differences is one of the jo…

You seem to come from a point as if I don't care about the intricate knowledge of programming languages or as if I don't care about learning how different languages manage to solve the same problem but from a different angle or with a different approach. I really do. What I don't see here in this article is none of that with some very loose arguments around picking Rust vs some other system programming language. Very…

This isn't a technical article. This is an article about about an organization making a business decision based on broad goals, not specific tasks. They explained the technical and human requirements they wanted to optimize for and explained the other options they had available to them and why they chose the way they did. Then they explained their experience. This article is for managers, team leads, directors, to help them navigate similar business decisions.

You original comment was purely dismissive of the entire concept of advocating for and sharing the experience of different languages. You also seem very focused on the technicality that "You can program anything in any language" which while true, you CAN write a Facebook clone in [brainfuck](https://en.wikipedia.org/wiki/Brainfuck), you wouldn't want to for many reasons. For real(tm) languages the decision is harder.

Re: Rewriting a high performance vector database in Rust

#147

Post by makmanalp »

makmanalp wrote: post #45

> If you’re using a higher level language, you’re not going to have access to how the memory is laid out. A simple change, like removing indirection in our list, was an order of magnitude improvement in our latencies since there’s memory prefetching in the compiler and the CPU can anticipate which vectors are going to be loaded next in order to improve the memory footprint. This is a common experience and I'm still s…

Noticing that the above stream of consciousness might have come across as crotchety - that was not my intention! A better way to phrase this might have been "the benefits of memory safety and human conveniences of a modern language can be worth giving up a bit of control, even in cases where it might be legitimately beneficial", which was supposed to be praise for the Rust model :-)

Re: Rewriting a high performance vector database in Rust

#148

Post by SleepyMyroslav »

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…

>a very performant programme

You might need to define what is "very performant".

I come from C++ performance work side in games. Typical C++ is ~10 times slower than optimized C++. And optimized C++ is sometimes ~2-10 times slower than what game hardware can do. What limits many projects is that cost of going to 'next level' of performance is also nonlinear. Where is on this scale Rust code written by new to the language?

Re: Rewriting a high performance vector database in Rust

#149

Post by dymk »

kstrauser wrote: post #42
slt2021 wrote: post #39

Earlier quoted context omitted.

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'd argue Python is strongly, dynamically typed, and that "weak" and "dynamic" are on different axes.

It's always interesting how often people confuse the dichotomy of "strong/weak typing" with "static/dynamic typing". They are orthogonal to each other indeed - you can have languages that are in each of the four possible combinations.

Re: Rewriting a high performance vector database in Rust

#150

Post by fwip »

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.

Well, the author went on to rule out Java and Go because they garbage connected, so I don't think they meant the GIL.
Post reply on HN