Hacker News Reader

Comment by exceptione | Hacker News Reader

  > The goal is to transparently replace dedicated developer workstation

Isn't there a less convoluted way of making the best engineers leave? I am half serious here. If you want your software to run slow, IT could equally well install corporate security software on developer laptops. Oops, I did it again. Oh well, in all seriousness, I have never seen any performance problem being solved by running it on Azure's virtualization. I am afraid you are replacing the hardware layer by a software layer with ungodly complexity, which you are sure of will be functionally incomplete.

Are you sure they don't have to fix the build pipeline first? Tens of thousands of vCPUs for a single compilation run, or to accommodate 100 developers who try to compile their own changes?

View on HN

> I have never seen any performance problem being solved by running it on Azure's virtualization

Sorry, I wasn't clear. I am not virtualizing the workspace. I'm using `recc` which is like `distcc` or `ccache` in that it wraps the compiler job. Every developer keeps their workstation. It just routes the actual `clang` or `gcc` calls to a Kubernetes cluster which provides distributed build and cache.

> Isn't there a less convoluted way of making the best engineers leave?

We have 7000+ compiler jobs in a clean build because it is a big codebase. People are waiting hours for CI.

I'm sure that drives attrition and bringing that down to minutes will help retain talent.

> Tens of thousands of vCPUs for a single compilation run, or to accommodate 100 developers who try to compile their own changes?

Because it uses remote execution, it will ideally do both. My belief is that an individual developer launching 6000 compiler jobs because they changed a header will smooth out over 300 developers that generally do incremental builds. Likewise, this'll eliminate redundant recompilation when git pulling since this also serves as a cache.

This makes absolutely no sense to me. Are you really recompiling 6000 things each time a dev in the company needs to add a line somewhere in the codebase? Have you thought about splitting that giant thing in smaller chunks?

> Are you really recompiling 6000 things each time a dev in the company needs to add a line somewhere in the codebase?

It happens when someone modifies a widely included header file. Which there are a lot of thanks to our use of templates. And this is just our small team of 300 people.

> Have you thought about splitting that giant thing in smaller chunks?

Yes. We've tried but it's not scaling. Unfortunately, we've banned tactics like pImpl and dynamic linking that would split a codebase unless they're profiled not to be on a hot path. Speed is important because I'm writing tests for a semiconductor fab and test time is more expensive than any other kind of factory on Earth.

I tried stuff like precompiled headers but the fact only one can be used per compilation job meant it didn't scale to our codebase.

Thanks for the detailed breakdown. The template header cascade problem makes total sense, I underestimated how bad it gets at scale with heavy template usage. The semiconductor fab constraint is interesting too. When test time costs that much per minute, banning pImpl on hot paths is a pretty obvious call, even if it makes compile times painful. Appreciate the real-world context.

Thanks for expanding on it, now it's more clear what you want to achieve. If I see things like this, it seems Linus was up to something for banning C++. That sounds like a nasty compilation scheme, but I guess the org has painted itself too deep into that corner to get out of it.

Reply on news.ycombinator.com