1980s: 1 packet per keystroke is too much, we must find a solution to bundle them together, for efficiency (see Nagle's algorithm, delayed ACK), also let's send everything in plaintext, including passwords
2020s: ha! with some advanced probabilistic models, we may be able to deduce something about what is being typed behind one of our layers of encryption, let's sent 100 packets per keystroke to mitigate that
Unfortunate result of the security theater.. "Someone who has access to run privileged application can run side channel attacks! Let's drop cpu performance 20 percent over the world"
What I find particularly ironic is that the title make it feel like Rust gives a 5x performance improvement when it actually slows thing down.
The problem they have software written in Rust, and they need to use the libpg_query library, that is written in C. Because they can't use the C library directly, they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons. Problem is that it is slow.
So what they did is that they wrote their own non-portable but much more optimized Rust-to-C bindings, with the help of a LLM.
But had they written their software in C, they wouldn't have needed to do any conversion at all. It means they could have titled the article "How we lowered the performance penalty of using Rust".
I don't know much about Rust or libpg_query, but they probably could have gone even faster by getting rid of the conversion entirely. It would most likely have involved major adaptations and some unsafe Rust though. Writing a converter has many advantages: portability, convenience, security, etc... but it has a cost, and ultimately, I think it is a big reason why computers are so fast and apps are so slow. Our machines keep copying, converting, serializing and deserializing things.
Note: I have nothing against what they did, quite the opposite, I always appreciate those who care about performance, and what they did is reasonable and effective, good job!
> What I find particularly ironic is that the title make it feel like Rust gives a 5x performance improvement when it actually slows thing down.
Rust didn't slow them down. The inefficient design of the external library did.
Calling into C libraries from Rust is extremely easy. It takes some work to create a safer wrapper around C libraries, but it's been done for many popular libraries.
This is the first and only time I've seen an external library connected via a Rube Goldberg like contraption with protobufs in the middle. That's the problem.
Sadly they went with the "rewrite to Rust" meme in the headline for more clickability.
Writing Rust bindings for arbitrary C data structures is not hard. You just need to make sure every part of your safe Rust API code upholds the necessary invariants. (Sometimes that's non-trivial, but a little thinking will always yield a solution: if C code can do it, then it can be done, and if it can be done, then it can be done in Rust.)
>> But had they written their software in C, they wouldn't have needed to do any conversion at all. It means they could have titled the article "How we lowered the performance penalty of using Rust".
That's not really fair. The library was doing serialization/deserialization which was poor design choice from a performance perspective. They just made a more sane API that doesn't do all that extra work. It might best be titles "replacing protobuf with a normal API to go 5 times faster."
BTW what makes you think writing their end in C would yield even higher performance?
> BTW what makes you think writing their end in C would yield even higher performance?
C is not inherently faster, you are right about that.
But what I understand is that the library they use works with data structures that are designed to be used in a C-like language, and are presumably full of raw pointers. These are not ideal for working in Rust, instead, presumably, they wrote their own data model in Rust fashion, which means that now, they need to make a conversion, which is obviously slower than doing nothing.
They probably could have worked with the C structures directly, resulting in code that could be as fast as C, but that wouldn't make for great Rust code. In the end, they chose the compromise of speeding up conversion.
Also, the use of Protobuf may be a poor choice from a performance perspective, but it is a good choice for portability, it allows them to support plenty of languages for cheaper, and Rust was just one among others. The PgDog team gave Rust and their specific application special treatment.
> which means that now, they need to make a conversion, which is obviously slower than doing nothing.
One would think. But since caches have grown so large, and memory speed and latency haven't scaled with compute, so long as the conversion fits in the cache and is operating on data already in the cache from previous operations, which admittedly takes some care, there's often an embarrassing amount of compute sitting idle waiting for the next response from memory. So if your workload is memory or disk or network bound, conversions can oftentimes be "free" in terms of wall clock time. At the cost of slightly more wattage burnt by the CPU(s). Much depends on the size and complexity of the data structure.
I wonder why they didn't immediately FFI it: C is the easiest lang to write rust binding for. It can get tedious if using many parts of a large API, but otherwise is straightforward.
I write most of my applications and libraries in Rust, and lament that most of the libraries I wish I would FFI are in C++ or Python, which are more difficult.
Protobuf sounds like the wrong tool. It has applications for wire serialization and similar, but is still kind of a mess there. I would not apply it to something that stays in memory.
It’s trivial to expose the raw C bindings (eg a -sys crate) because you just run bindgen on the header. The difficult part can be creating safe, high-performance abstractions.
No it’s not common for two pieces of code within a single process to communicate by serializing the protobuf into the wire format and deserializing it.
It’s however somewhat common to pass in-memory protobuf objects between code, because the author didn’t want to define a custom struct but preferred to use an existing protobuf definition.
Given they heavily used LLMs for this optimization, makes you wonder why they didn’t use them to just port the C library to rust entirely. I think the volume of library ports to more languages/the most performant languages is going to explode, especially given it’s a relatively deterministic effort so long as you have good tests and api contracts, etc
The underlying C library interacts directly with the postgres query parser (therefore, Postgres source). So unless you rewrite postgres in Rust, you wouldn't be able to do that.
Well then why didn’t they just get the LLM to rewrite all of Postgres too /s
I agree that LLMs will make clients/interfaces in every language combination much more common, but I wonder the impact it’ll have on these big software projects if more people stop learning C.
> they had to use a Rust-to-C binding library, that uses Protobuf for portability reasons.
That sounds like a performance nightmare, putting Protobuf of all things between the language and Postgres, I'm surprised such a library ever got popular.
pg_query (TFA) has ~1 million downloads, the postgres crate has 11 million downloads and the related tokio-postgres crate has over 33 million downloads. The two postgres crates currently see around 50x as much traffic as the (special-purpose) crate from the article.
edit: There is also pq-sys with over 12 million downloads, used by diesel, and sqlx-postgres with over 16 million downloads, used by sqlx.
I certainly can't memorize Homer's work, and why would I? In exchange I can do so much more. I can find an answer to just about any question on any subject better than the most knowledgeable ancient Greek specialist, because I can search the internet. I can travel faster and further than their best explorers, because I can drive and buy tickets. I have no fighting experience, but give me a gun and a few hours of training and I could defeat their best champions. I traded the ability to memorize the equivalent of entire books to a set of skills that combined with modern technological infrastructure gives me what would be godlike powers at the time of the ancient Greeks.
In addition to these base skills, I also have specialized skills adapted to the modern world, that is my job. Combined with the internet and modern technology I can get to a level of proficiency that no one could get to in the ancient times. And the best part: I am not some kind of genius, just a regular guy with a job.
And I still have time to swipe on social media. I don't know what kind of brainless activities the ancient Greeks did, but they certainly had the equivalent of swiping on social media.
The general idea is that the more we offload to machines, the more we can allocate our time to other tasks, to me, that's progress, that some of these tasks are not the most enlightening doesn't mean we did better before.
And I don't know what economist mean by "productivity", but we can certainly can buy more stuff than before, it means that productivity must have increased somewhere (with some ups and downs). It may not appear in GDP calculations, but to me, it is the result that counts.
I don't count home ownership, because you don't produce land. In fact, that land is so expensive is a sign of high global productivity. Since land is one of the few things that we need and can't produce, the more we can produce the other things we need, the higher the value of land is, proportionally.
If there is no in-house storage to match, how does it help the grid? It is still needed for cold winter nights, where demand is high and solar panels produce nothing. Hydro can provide the power, but the grid will be running at full load.
Most houses in Canada are heated with natural gas. I'm not negating your overall comment, but in general, cold nights don't strain the grid because of heating needs.
(still good news, as most of Canada's electric generation is low carbon hydro, and the rest of fossil generation can be pushed out with storage and renewables, although I do not have a link handy by province how much fossil generation needs to be pushed out)
I live in New England. We do not have enough natural gas pipeline capacity to meet demand in long periods of very cold weather, and have very limited natural gas storage that can't buffer that for as long as a cold spell can last.
In these periods of time the grid traditionally keeps the lights on by switching over a significant portion of the grid to burning oil for power, and/or with the occasional LNG tanker load into Everett MA. These are both....pretty terrible and expensive solutions.
Burning less natural gas during the day still helps at night/at peak, because it means there's been less draw-down of our limited storage/more refill of it during the day, so we don't have to turn to worse options as heavily at night.
> One thing I like about JPEG-XL is that it supports all kinds of weird image formats.
And it is probably the reason why browser vendors disliked it. Lots of complexity, it means a big library, which is high maintenance with a big attack surface. By comparison, webp is "free" if you have webm, as webp is essentially a single frame video.
AFAIK browsers do not reuse any VP8 codepath for WebP, they just use libwebp, which decodes lossy images in software. WebP has a non-VP8 lossless mode too. The concern about image format attack surface is also probably because of the recent exploit in libwebp.
What kind of pictures can starlink would take? When I look at pictures of starlink satellites, I don't see a camera. Maybe they have one, but if we can't see it, it is most likely useless for observation, except for taking pretty pictures of the Earth, or maybe other passing satellites.
Spy satellites are more like space telescopes, but pointed at the Earth. As an example, Hubble is designed after a spy satellite, the "camera" is pretty massive and obvious.
Starlink can probably be weaponized for a variety of thing, like for communication, obviously, but I don't think earth optical observation is one of them.
Maybe it has changed but Google doesn't look like it uses litigation as its primary weapon. It defends itself but rarely attacks.
The are however more than happy to use technical measures, like blocking accounts. And because of their position, blocking your Google account may be more damaging than a successful lawsuit.
People like being told they are right, and when a response contains that formulation, on average, given the choice, people will pick it more often than a response that doesn't, and the LLM will adapt.
Software tools are not really tools like a knife. They are more like cooking recipes.
Traditionally, people don't pay for cooking recipes, they may pay for cookbooks, that is a nice packaging around the recipes, or they may keep their recipes secret. Cooking recipes are like the software tools of chefs.
The actual tools of developers are computers, which they pay for, like chefs pay for their knives.
Software tools, like recipes cost nothing to copy and distribute, while actual tools, like knives and computers cost money per unit to produce.
2020s: ha! with some advanced probabilistic models, we may be able to deduce something about what is being typed behind one of our layers of encryption, let's sent 100 packets per keystroke to mitigate that
reply