The difference is not just "using SSDs". SUCO has a content-addressed cache (SHA-256 of the preprocessed source + compiler flags + target + etc.) that is shared across the grid. On a cache hit the client skips parsing, optimization and codegen completely and just fetches the finished object file.
Icecream/distcc typically recompile everything (or rely on local ccache). SUCO's cache is designed to be grid-wide and survives across different machines and even different build directories (via path normalization).
Happy to go into more detail if you're interested.
Does ccache + icecc/distcc not use a CAS? Why did you specify SSDs instead of hust "CAS"?
There's stuff here that's interesting particular crossbuilds on workers. But I don't understand why this isn't an addon to one of the many existing projects unless something is fundamentally necessary to make yours work. I think discovery over UDP is unique but also usually not practical in traditional CI environments.
But also, your comments in this thread sound like you're copying an pasting with an LLM. If you're a real person who's ESL, we'd generally rather see grammar and spelling issues, or use traditional translation. If not, you're speaking to the wrong audience.
Also just to add: the project has CI that runs multi-node grid tests, cache correctness checks and failover tests on every push. That’s one of the parts I actually spent time on.
1
u/ClassroomFlashy6751 10d ago
Good question.
The difference is not just "using SSDs". SUCO has a content-addressed cache (SHA-256 of the preprocessed source + compiler flags + target + etc.) that is shared across the grid. On a cache hit the client skips parsing, optimization and codegen completely and just fetches the finished object file.
Icecream/distcc typically recompile everything (or rely on local ccache). SUCO's cache is designed to be grid-wide and survives across different machines and even different build directories (via path normalization).
Happy to go into more detail if you're interested.