ccache on client machines

[NextDesign1]

Hi there,

I was wondering if there was a way to utilize ccache on client (remote) machines. This way, when multiple developers are compiling the same build, it could simply return the files right away. From what I've read, using ccache should be safe with multiple compiler types, versions, and operating systems.

Perhaps an environment variable to prepend to remote commands could facilitate this?

[HenryMiller1]

No. On remote machines icecc runs in a chroot so there is no place to cache any files. Ice-cream also explicitly does not assume that the compiler is the same on all machines. Even if the version is the same you might be testing with a patched compiler that fixes some bug. (although rare I have traced bugs to the compiler more than once)

Run ccache locally if you want it.

-- Henry Miller hank@millerfarm.com

On Wed, Sep 25, 2019, at 8:17 PM, John Mather wrote:

Hi there,

I was wondering if there was a way to utilize ccache on client (remote) machines. This way, when multiple developers are compiling the same build, it could simply return the files right away. From what I've read, using ccache should be safe with multiple compiler types, versions, and operating systems.

Perhaps an environment variable to prepend to remote commands could facilitate this?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/icecc/icecream/issues/504?email_source=notifications&email_token=ACHSQERB2EARAPAVR5VKY2DQLQERNA5CNFSM4I2TWNWKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HNX7ZIQ, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHSQETAME36EPZIQGITSH3QLQERNANCNFSM4I2TWNWA.

[llunak]

Even if this was done somehow, I think it wouldn't really provide any gains. With each node having its own cache, you'd be unlikely to have cache hits, because jobs are distributed at random. And if the cache were to be shared, you can just as well share the one used before icecream.

So closing this.

[ossilator]

i see a lot of invalid assumptions here:

• the compiler can be identified by sha1; that's how envs are already identified, afaik. there is no reliability problem at all if things are done properly.
• with caching being integrated into icecc, the scheduler would know which nodes already have matching artifacts, so this would provide gains in a sufficiently homogeneous environment.
• even a really simple implementation using a central cache would still add value, as "share the [ccache] used before icecream" is often easier said than done (NFS? really??).

somewhat unsurprisingly, this has again overlap with my arguments in favor of distributing include preprocessing (and enabling pch use).

oh, and see https://docs.bazel.build/versions/0.29.1/remote-caching.html - google obviously did consider the feature worthwhile.

[HenryMiller1]

You are talking about server caching here, perhaps with remote storage. This may be useful, but it is very different from just putting ccache on remote machines. If someone does the effort to do it right I'll favor it, but just hacks to run ccache on remote machines is not useful.

-- Henry Miller hank@millerfarm.com

On Thu, Sep 26, 2019, at 3:06 PM, Oswald Buddenhagen wrote:

i see a lot of invalid assumptions here:

• the compiler can be identified by sha1; that's how envs are already identified, afaik. there is no reliability problem at all if things are done properly.
• with caching being integrated into icecc, the scheduler would know which nodes already have matching artifacts, so this would provide gains in a sufficiently homogeneous environment.
• even a really simple implementation using a central cache would still add value, as "share the [ccache] used before icecream" is often easier said than done (NFS? really??). somewhat unsurprisingly, this has again overlap with my arguments in favor of distributing include preprocessing (and enabling pch use) https://github.com/icecc/icecream/issues/138#issuecomment-352272019.

oh, and see https://docs.bazel.build/versions/0.29.1/remote-caching.html - google obviously did consider the feature worthwhile.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/icecc/icecream/issues/504?email_source=notifications&email_token=ACHSQEQ2EGUFAWTN2PMGX5LQLUI5RA5CNFSM4I2TWNWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7WZZ2Q#issuecomment-535665898, or mute the thread https://github.com/notifications/unsubscribe-auth/ACHSQERPSNYQC67JKLSVAFDQLUI5RANCNFSM4I2TWNWA.

[ossilator]

i don't think it's a stretch to extrapolate from a naive user's simplistic idea to something that actually makes sense and then talk about that - after all, what he wants is a solution, not being told why things will not work the way he imagined. the logical consequence of this issue being closed would be creating a spin-off issue (assuming the request isn't covered elsewhere already), which doesn't seem overly helpful to me.

[llunak]

If the local icecream daemon knew where to send a build for it to get a cache hit, a local caching tool can just as well know how to get a cache hit, without all the icecream's overhead of sending the data for a remote build. It doesn't make much sense to add distributed caching to icecream when such tools already exist. And ccache on NFS is not the only way, there's also e.g. Mozilla's sccache, which could very well fit the reporter's needs.

(And as for providing solutions instead of talking, you're ossi of course welcome to put your money where your mouth is.)

[ossilator]

why do you assume that an icecc-integrated solution would have extra overhead? no claims about the used protocols have been made. quite to the contrary, i would expect synergistic effects, as certain operations are duplicated when separate icecc and (s)ccache are stacked.

generally, i find it highly questionable that you close all feature requests which you are not personally interested in implementing.

[coolo]

generally, i find it highly questionable that you close all feature requests which you are not personally interested in implementing.

I in return find this very pragmatic. It's not stopping anyone from commenting here with 'I will give it a try'

[llunak]

why do you assume that an icecc-integrated solution would have extra overhead?

Because there would be the extra overhead of doing the work. I'm unlikely to do it (I'll much rather invest the time into investigating sccache), and apparently there's nobody else to do it either.

no claims about the used protocols have been made. quite to the contrary, i would expect synergistic effects, as certain operations are duplicated when separate icecc and (s)ccache are stacked.

Doesn't really matter as long as it's just a theoretical concept that nobody wants to implement.

generally, i find it highly questionable that you close all feature requests which you are not personally interested in implementing.

I'm the one doing the job (Henry has done a lot of maintenance, but I think he doesn't implement new features, and I'm not aware of anybody else contributing consistently in the recent times).

And, FWIW, according to the statistics you did a total of 7 commits, in 2008-2011, so I find it highly questionable that you comment on how to do a number of features which you are not personally interested in implementing. I'm not stopping you (or anybody else) from doing the work. But wherever I tell you so, you either ignore it or start telling me how to do my work. I find it rather annoying, to be honest.

[ossilator]

Because there would be the extra overhead of doing the work.

your argument clearly meant technical overhead, though.

you either ignore it or start telling me how to do my work

all i'm doing is telling you in which ways your work (to which your actions on this issue tracker belong) is imo suboptimal or incorrect, and what you need to do to make it to be less so. as you're quite aware, that's called peer review, and i'm assuming that by being on github you agree to people participating in that way.

It's not stopping anyone from commenting here with 'I will give it a try'

closing a feature request sends a message: this is not wanted here. it will also inevitably lead to duplicates, because people will often (rightfully) not search closed issues. you can add labels like HelpNeeded or LowPriority instead of just closing issues.

[llunak]

as you're quite aware, that's called peer review

I think this is the reason why we see things differently, as I do not see somebody with 7 commits a decade ago insisting I do things their way as peer review, sorry. I guess I should learn to also (not) act on it if I think something is a waste of time. And I suggest you learn to let go of things when insisting on them doesn't lead to anything (good).

[ossilator]

the validity of anyone's arguments isn't dependent on how many commits they contributed, or when they did. and i'm not insisting that you do things my way, other than that you judge my points based their merit irrespective of whether they fit your current priorities. the way you engage on this public forum now may very well decide over future contributions.