On Thu, Sep 25, 2014 at 12:47 AM, Ian Lance Taylor <i...@google.com> wrote: > Is that true even when TMPDIR is on a ram disk? There's no obvious > reason that it should be true in a parallel build. Using -pipe > effectively constrains communication between the compiler and the > assembler to work in PIPE_BUF blocks. Using TMPDIR introduces no such > constraints, and in a big program a parallel build should obscure the > fact that the compiler and assembler are serialized for each > individual compilation unit.
As an aside, I think what matters is the capacity of the pipe rather than PIPE_BUF. PIPE_BUF is the largest chunk that can be written atomically, but since we don't have a case of multiple processes writing to the same pipe(???), it doesn't matter. On a typical x86(-64) Linux system, PIPE_BUF is 4k while the capacity is by default 64k (can be increased with fcntl(fd, F_SETPIPE_SZ, ...), perhaps worth trying to see if it makes any difference?). Still, it seems to me that making -pipe the default would make sense, if the tradeoff appears to be a small loss in case when /tmp is a tmpfs vs. a much larger gain when /tmp is a normal fs. -- Janne Blomqvist
