> On 29. Oct 2019, at 18:53, Steve Fink <sf...@mozilla.com> wrote: > > On 10/28/19 9:17 PM, Marcos Caceres wrote: >> On Tuesday, October 29, 2019 at 3:27:52 AM UTC+11, smaug wrote: >>> Quite often one has just a laptop. Not compiling tons of Rust stuff all the >>> time would be really nice. >>> (I haven't figured out when stylo decides to recompile itself - it seems to >>> be somewhat random.) >> Probably a gross misunderstanding on my part, but the sccache project page >> states [1]: "It is used as a compiler wrapper and avoids compilation when >> possible, storing a cache in a remote storage using the Amazon Simple Cloud >> Storage Service (S3) API, the Google Cloud Storage (GCS) API, or Redis." >> >> I'm still (possibly naively) imagining that we will leverage the "the >> cloud"™️ to speed up compiles? Or am I totally misreading what the above is >> saying? >> >> [1] https://github.com/mozilla/sccache#sccache---shared-compilation-cache > > My experience with other distributed compilation tools (distcc, icecc) > indicates that cloud resources are going to be of very limited use here. > Compiles are just way too sensitive to network bandwidth and latency, > especially when compiling with debuginfo which tends to be extremely large. > Even if the network transfer takes way less time than the compile, the > sending/receiving scheduling never seems to work out very well and things > collapse down to a trickle. > > Also, I've had very limited luck with using slow local machines. A CPU is not > a CPU -- even on a local gigabit network, farming off compiles to slow > machines is more likely to slow things down than speed them up. Despite the > fancy graphical tools, I was never completely satisfied with my understanding > of exactly why that is. It could be that a lack of parallelism meant that > everything ended up repeatedly waiting on the slow machine to finish the last > file in a directory (or whatever your boundary of parallelism is). Or it > could be network contention, especially when your object files have massive > debuginfo portions. (I always wanted to have a way to generate split > debuginfo, and not block on the debuginfo transfers.) The tools tended to > show things working great for a while, and then slowing down to a snail's > pace.
This research offers some insight: https://www.usenix.org/system/files/atc19-fouladi.pdf / https://github.com/StanfordSNR/gg In particular: > Existing remote compilation systems, including distcc and icecc, send data > between a master node and the workers frequently during the build. These > systems perform best on a local network, and add substantial latency when > building on more remote servers in the cloud. In contrast, gg uploads all the > build input once and executes and exchanges data purely within the cloud, > reducing the effects of network latency. Their system using 8000 AWS Lambdas is 2x faster than an icecc cluster when building Chromium, although that is still a *remote* icecc cluster. Maybe the speedup is less significant with a local cluster like we're running in our offices. -- reuben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
