yea, my feeling is that the remote setting should ...
# development
w
yea, my feeling is that the remote setting should be very high by default. but i could still imagine capping it.
a
why wouldn't the remote execution backend handle this?
w
it would. but the client might still want to be able to cap it.
when i say "high by default", i mean "~1000" probably
such that it wouldn't take effect except in exceptional cases
there are UI concerns as well though.
a
why would the client want to cap it?
w
why would a client want to cap local process executions?
(...they take resources)
hopefully drastically less resources, but.
a
definitely thinking of remote executions here
w
me too
a
why would the client want to cap remote executions? it seems like that's a setting we'd really want the backend to handle by itself
w
discussed offline: the missing piece in my comment above was: "remote process executions still take some amount of local resources"
a
especially shipping protobufs back and forth across grpc streams, that will take time/memory/bandwidth proportional to file digestion at least i think
optimizing this in the future will remain very interesting, and it looks like the bazel remote execution api working group is looking into architecture to improve the performance these kinds of interactions already and that's quite interesting/promising
w
i would not be surprised if we are already the fastest remote execution client in the west =P
a
oh absolutely lol
this is also my evil plan
google loves rust now and is using it more
when they want to speed up skyframe and they look to rust
there is no reason at all why they wouldn't want to just use our engine
google may be big on NIH but it's possible ireland could win but krum gets the snitch