4 ms·

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 perform

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.
    - saurik 4y ago
      The context here was that gVisor was a suboptimal way to solve the problem and they know that... so I am not sure in what point you are trying to make by saying people can optimize to solve problems unless you actually mean people can optimize to not solve problems.
  - orf 4y ago
    Why?
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...

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.
  - saurik 4y ago
    The context here was that gVisor was a suboptimal way to solve the problem and they know that... so I am not sure in what point you are trying to make by saying people can optimize to solve problems unless you actually mean people can optimize to not solve problems.
- orf 4y ago
  Why?

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...