Compilers often just build up more and more data structures in memory until the end when they then release everything more or less at once. With an arena you can then just throw away the whole arena at the end, assuming there are no resource handles that need to be closed in drop().
A long time ago I read an article about someone speeding up a C++ compiler that is itself written in C++ (was it g++? maybe clang?). They simply patched out delete so it did nothing. The compiler used marginally more memory but ran much faster, since releasing all the small objects one by one is just useless work at the end of the compilation.
A GCed language has a similar behavior and could therefore be fast in that case. It just builds up all the objects and then when the program exists it doesn't have to GC them all, it just throws away the whole process memory. So I can imagine one could "optimize" a compiler written in a GCed language by deactivating the GC.
I read on here a few months ago about some high-frequency trading system being written in Java and running with no garbage collector enabled, because the application is closed at the end of trading each day and it's extremely fast without garbage collection.
We're currently use pgvectorscale. Some questions:
- Will pg_vectorsearch eventually also support vectors bigger than 1968 dimensions? E.g. VoyageAI can create embeddings with 2048 dimensions (but we don't actually need that at the moment, only 1024).
- Why did you choose C this time and not Rust, as you did with pgvectorscale?
- Why did you not just extend pgvectorscale with another index type instead of creating a whole new extensions?
- Almost certainly. In fact, there is already a submitted PR contribution for larger dimensions.
- C is much better integrated into Postgres, doesn't require pgrx. Given also experience developing pg_textsearch, and the acceleration from AI-assisted development and testing, have moved back to more C with extensions.
- Two reasons. First, decision to move back to C. Second, if there ultimately isn't much code overlap, better to keep them separate for easier adoption (smaller footprint and security/correctness envelop)
8.8 million people? Wikipedia says Denmark only has 6 million people! Historical data too? People from other countries that had any treatment in Denmark?
I think the claim is that GCC supports a few obscure platforms that LLVM doesn't. Don't ask me which, that is just the claim that I heard multiple times. So it's not Rust that limits platforms, but LLVM. And they say the GCC backend efforts of Rust are meant to deal with that.
There are many. Two big ones are Alpha and PA-RISC. NetBSD and Linux continue to support both. Linux distro choices are pretty much limited to Gentoo though.
reply