5 ms·

For starters, gVisor is written in Go, which by design won’t have performance of C++/Rust.

stickupkid 4y ago
Citation required on this one... gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern. 1. https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods https://cloud.google.com/kubernetes-engine/docs/concepts/san...
- jhgg 4y ago
  https://www.usenix.org/system/files/hotcloud19-paper-young.pdf https://www.usenix.org/system/files/hotcloud19-paper-young.p...
- staticassertion 4y ago
  https://gvisor.dev/docs/architecture_guide/performance/ https://gvisor.dev/docs/architecture_guide/performance/ https://gvisor.dev/docs/architecture_guide/performance/#network https://gvisor.dev/docs/architecture_guide/performance/#netw... Network performance in gvisor is awful and, by gvisor's own documentation, this is a matter of "implementation costs" ie: it is how gvisor is written, not gvisor's fundamental constructs, that makes it slow. The rest of the benchmarks are notable as well, there are a few other places where the implementation is called out as being a problem.
  - saurik 4y ago
    So maybe they should team up and work on replacing gVisor with something that shares as much code as possible with this new thing, which one would hope would be architected in a way to be able to help replace gVisor?
    - staticassertion 4y ago
      Or maybe not?
      - saurik 4y ago
        Yeah, of course: if you are the kind of company that like a having tens of thousands of engineers working on five different versions of the same thing, with one team explicitly working on solving a problem another team has but without helping them as that's some combination of not-fun and not-promotion-worthy, you can of course do whatever you want.
        staticassertion 4y ago
        Or they have context that helped them decide to do something this way?
        saurik 4y ago
        lol, sure.
        staticassertion 4y ago
        Some obvious context from an outsider: 1. It's designed to run on Fuschia, not Linux 2. Go FFI is very inefficient, you can't just "extend" a Go project with native bindings and get the same performance wins 3. Hopefully the gvisor team learned the obvious lesson that Go is not suitable for this kind of work
    - surajrmal 4y ago
      Not everything needs to be molded into a common base that serves the needs of all. Fuchsia has different constraints than the ones gvisor is written for and choosing to not try to morph gvisor into something it doesn't want to be is okay. Optimizing to solve problems should be the goal. Sharing code is nice to have where it makes sense.
- Fnoord 4y ago
  > Citation required on this one... You mean you'd like to read a source to back up that statement. Nothing is required...
jjtheblunt 4y ago
That's false: you're assuming perhaps reliance on the garbage collector, and overlooking escape analyses (the compiler pass) enabling entire classes of Go programs indistinguishable, after code generation which obviates the garbage collector from user code at least, from optimized C++/Rust.

Citation required on this one... gVisor is used in a lot of places[1] that require more performance than a clock. I'm not saying you can't achieve more performance with C++/rust, what I'm saying is that this probably isn't the primary concern. 1. https://cloud.google.com/kubernetes-engine/docs/concepts/sandbox-pods https://cloud.google.com/kubernetes-engine/docs/concepts/san...

jhgg 4y ago
https://www.usenix.org/system/files/hotcloud19-paper-young.pdf https://www.usenix.org/system/files/hotcloud19-paper-young.p...
staticassertion 4y ago
https://gvisor.dev/docs/architecture_guide/performance/ https://gvisor.dev/docs/architecture_guide/performance/ https://gvisor.dev/docs/architecture_guide/performance/#network https://gvisor.dev/docs/architecture_guide/performance/#netw... Network performance in gvisor is awful and, by gvisor's own documentation, this is a matter of "implementation costs" ie: it is how gvisor is written, not gvisor's fundamental constructs, that makes it slow. The rest of the benchmarks are notable as well, there are a few other places where the implementation is called out as being a problem.
- saurik 4y ago
  So maybe they should team up and work on replacing gVisor with something that shares as much code as possible with this new thing, which one would hope would be architected in a way to be able to help replace gVisor?
  - staticassertion 4y ago
    Or maybe not?
    - saurik 4y ago
      Yeah, of course: if you are the kind of company that like a having tens of thousands of engineers working on five different versions of the same thing, with one team explicitly working on solving a problem another team has but without helping them as that's some combination of not-fun and not-promotion-worthy, you can of course do whatever you want.
      - staticassertion 4y ago
        Or they have context that helped them decide to do something this way?
        saurik 4y ago
        lol, sure.
        staticassertion 4y ago
        Some obvious context from an outsider: 1. It's designed to run on Fuschia, not Linux 2. Go FFI is very inefficient, you can't just "extend" a Go project with native bindings and get the same performance wins 3. Hopefully the gvisor team learned the obvious lesson that Go is not suitable for this kind of work
  - surajrmal 4y ago
    Not everything needs to be molded into a common base that serves the needs of all. Fuchsia has different constraints than the ones gvisor is written for and choosing to not try to morph gvisor into something it doesn't want to be is okay. Optimizing to solve problems should be the goal. Sharing code is nice to have where it makes sense.
Fnoord 4y ago
> Citation required on this one... You mean you'd like to read a source to back up that statement. Nothing is required...

jjtheblunt 4y ago

That's false: you're assuming perhaps reliance on the garbage collector, and overlooking escape analyses (the compiler pass) enabling entire classes of Go programs indistinguishable, after code generation which obviates the garbage collector from user code at least, from optimized C++/Rust.