Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

greptime.com

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#41

Post by tracker1 »

adrian_b wrote: post #35
netprole wrote: post #17

Earlier quoted context omitted.

I don't think I understand the comparison. Can you think of another one that involves a weapon and directed violence?

When I see a knife, it never suggests a weapon, unless it is the kind of knife that is really a weapon, like a double-edged stiletto, or it is wielded by someone who has obvious intentions to use it as a weapon. The knife from that logo does not look like a weapon, but just like a standard utility knife. Moreover, a crab cannot move a knife in the way in which it is used as a weapon, e.g. for stabbing, but only in a…

Thank you. Sometimes these trains of sensitivity in thought threads can be annoying.

I definitely appreciate your contextual perspective and the ability to express it much more clearly and calmly than my own initial reaction.

I'm not sure if we submit, as a society, need to see more Tex Avery cartoons as children.

I genuinely feel that either a new civil war in the US and or global conflict is eminent and the young of today are largely ill prepared to say the least.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#42

Post by sgift »

kjksf wrote: post #39
sapiogram wrote: post #31

Earlier quoted context omitted.

The Go code is already hyper-optimized by experts, just not by the blog authors, so you don't read about it here. As someone who has tried to write high-performance Go code on occasion, I can assure you that a ton of digging would have been required on that side as well.

To bring this discussion back to earth, the Go code in question is: https://github.com/VictoriaMetrics/easyproto/blob/master/rea... I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code? As someone who also writes Go, I don't see any "hyper optimizations" in the code. It just decodes the bytes of Protocol Buffer us…

> I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code?

https://victoriametrics.com/team/ - Let's see. Author of multiple performance-optimized libraries with a masters degree in computer software engineering and a background in highly scalable systems (as needed for adtech). Sounds pretty much like an expert for optimizing code to me.

> And I've seen this trick before so it's not some secret, expert-only knowledge.

So, if you know it it's not export knowledge or what's your argument here?

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#43

Post by kasey_junk »

kjksf wrote: post #39
sapiogram wrote: post #31

Earlier quoted context omitted.

The Go code is already hyper-optimized by experts, just not by the blog authors, so you don't read about it here. As someone who has tried to write high-performance Go code on occasion, I can assure you that a ton of digging would have been required on that side as well.

To bring this discussion back to earth, the Go code in question is: https://github.com/VictoriaMetrics/easyproto/blob/master/rea... I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code? As someone who also writes Go, I don't see any "hyper optimizations" in the code. It just decodes the bytes of Protocol Buffer us…

He’s probably most well known in the golang community for fasthttp which is a widely used and highly optimized golang replacement for the golang stdlib. I’m a long term golang developer and I think calling him a golang optimization “expert” is fair.

That said, I agree with your assessment about this particular code. It’s fairly straightforward idiomatic go.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#44

Post by K0nserv »

About step 2: You still need to drop items, that's required for Vec to be sound. By not calling `Vec::clear` and instead using

    pub struct RepeatedField {
        vec: Vec,
        len: usize,
    }
with indexing patterns like `self.vec[..self.len]` and setting `self.len = 0` to clear you avoid the cost of dropping all items at once(like Vec::clear does). However you still have to drop items, so with this solution the cost is amortised in `RepeatedField::push` and other methods that do `self.vec[i] = new_item`.

> It's designed to avoid the drop overhead

Isn't true. You don't avoid the the overhead, at most you delay/amortise it.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#45

Post by sapiogram »

kjksf wrote: post #39
sapiogram wrote: post #31

Earlier quoted context omitted.

The Go code is already hyper-optimized by experts, just not by the blog authors, so you don't read about it here. As someone who has tried to write high-performance Go code on occasion, I can assure you that a ton of digging would have been required on that side as well.

To bring this discussion back to earth, the Go code in question is: https://github.com/VictoriaMetrics/easyproto/blob/master/rea... I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code? As someone who also writes Go, I don't see any "hyper optimizations" in the code. It just decodes the bytes of Protocol Buffer us…

> I don't see why did you label Aliaksandr Valialkin, the author, an "expert". I mean, he's no dummy but what exactly makes him an expert on optimizing Go code?

I was trying to convey the meaning of "far more experienced than the blog post authors", but without having to insult the authors. It's a good writeup after all, and I'm glad they took the time.

We must have some different interpretations of what "optimized" means. This is the very first piece of code in the file you linked:

  func (fc *FieldContext) NextField(src []byte) ([]byte, error) {
      if len(src) >= 2 {
        n := uint16(src[0])> (8 + 3))
            fc.wireType = wireTypeLen
            fc.data = src[:msgLen]
            src = src[msgLen:]
            return src, nil
        }
    }
    // ... function continues beyond this point
As far as I can tell, this entire codepath exists solely as an optimization. I spent many years working on a chess engine for fun, so I'm pretty well versed in bit twiddling, but I'm seriously struggling with this. Like, is it doing `(n&0x8080 == 0)` to check to whether length is less than 0x80? Is that even correct?

I think "hyper optimized" is a completely fair characterization. But we clearly work in different industries.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#46

Post by v0y4g3r »

fredrikholm wrote: post #28
riku_iki wrote: post #19

Earlier quoted context omitted.

> but typically rust or c++ would be faster after heavy optimisation; it is concerning how much digging was required to optimize rust code in this case.

Whilst still being 1/3rd slower than the Go version.

The Go version is not a naive implementation, it's also the well optimized version from VictoriaMetrics.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#47

Post by v0y4g3r »

K0nserv wrote: post #44

About step 2: You still need to drop items, that's required for Vec to be sound. By not calling `Vec::clear` and instead using pub struct RepeatedField { vec: Vec , len: usize, } with indexing patterns like `self.vec[..self.len]` and setting `self.len = 0` to clear you avoid the cost of dropping all items at once(like Vec::clear does). However you still have to drop items, so with this solution the cost is amortised…

WriteRequest::timeseries is a vector (https://github.com/prometheus/prometheus/blob/main/prompb/re...) and the repeated file `Timeseries::labels` and `Timeseries::samples` are reused across different timeseries. You don't have to alloc a new vector for the lables and samples for each new timeseries instance.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#48

Post by K0nserv »

v0y4g3r wrote: post #47
K0nserv wrote: post #44

About step 2: You still need to drop items, that's required for Vec to be sound. By not calling `Vec::clear` and instead using pub struct RepeatedField { vec: Vec , len: usize, } with indexing patterns like `self.vec[..self.len]` and setting `self.len = 0` to clear you avoid the cost of dropping all items at once(like Vec::clear does). However you still have to drop items, so with this solution the cost is amortised…

WriteRequest::timeseries is a vector ( https://github.com/prometheus/prometheus/blob/main/prompb/re... ) and the repeated file `Timeseries::labels` and `Timeseries::samples` are reused across different timeseries. You don't have to alloc a new vector for the lables and samples for each new timeseries instance.

That would be true if you used `Vec::clear` too, it doesn't allocate a new vector. My point was that you still end up running Drop implementations with RepeatedField, just not all at once. See https://play.rust-lang.org/?version=stable&mode=debug&editio...

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#49

Post by fnordpiglet »

netprole wrote: post #17
reacharavindh wrote: post #12

Earlier quoted context omitted.

Exactly, then why does it matter that the author had anything in their post as a figure of speech or analogy? Is it wrong to post a meme of a dog sitting near fire - https://knowyourmeme.com/memes/this-is-fine As a joke from SREs who handle firefighting calls? Does it offend dog lovers, people who are scared of fire?

I don't think I understand the comparison. Can you think of another one that involves a weapon and directed violence?

How about the image of the dog / fire viewed by someone who was orphaned and horribly scarred for life as a child in a household fire?

Trauma exists in all forms in our world. Sometimes the extremity of trauma is used in jest simply because it’s so extreme and at odds with the situation. That’s a form of absurdist humor that absolutely runs the risk of triggering someone that the extreme situation is personal to, but was never intended to hurt anyone.

I think almost everyone considers that situation - someone triggered by personal trauma when seeing a cartoon crab attacking a cartoon gopher with a knife on a programming blog about performance between two programming languages - sad and has empathy for those suffering from a relived trauma. That must be debilitating in life and no one is insensitive to that level of embodied suffering.

However, likewise, almost no one feels sympathy for the person who pulls out a code of conduct to kill any cartoon humor not designed for the Sunday serialization of a national newspaper.

Re: Fivefold Slower Compared to Go? Optimizing Rust's Protobuf Decoding Performance

#50

Post by steveklabnik »

netprole wrote: post #2

In the image at the top of the article, why is the Rust crab altered to have "angry" eyes and holding a knife aimed at the Go gopher? Aside from the joke of "don't bring a knife to a protobuf fight" the inference of violence sucks and lessens the spirit of friendly competition and "all in good fun." I don't know if Rust has a code-of-conduct or rules for use of their mascot, but I bet this doesn't follow it.

Ferrous (the crab) is deliberately not an official mascot, and is in the public domain. There is no code of conduct or rules.
Post reply on HN