3 ms·

If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? What is this test really try

by Steltek 13y ago

If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? What is this test really trying to determine? How the performance of the core of each compiler impacts productivity? Shouldn't the test parameters be adjusted to real world conditions, as seen by the test creator, then? Like most benchmarks, you could fabricate scenarios that favor one or the other all day long. Some closer to reality, some completely synthetic.

masklinn 13y ago
> If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? 250MB of output adding 5mn of compile time would mean 800KiB/s. That's about what a 5400RPM HDD gets on random writes. Possible, but means GCC has an utterly terrible I/O architecture and flushes to disk after more or less every write call. > What is this test really trying to determine? Nothing? It's just trying to infirm or confirm the initial off-hand remark: https://twitter.com/icculus/status/448281959538888704 https://twitter.com/icculus/status/448281959538888704 > Like most benchmarks, you could fabricate scenarios that favor one or the other all day long. Some closer to reality, some completely synthetic. I'm not sure how you can get closer to reality than "I spend my days compiling Goat Simulator with Clang and GCC, let's compile Goat Simulator with Clang and GCC".
azakai 13y ago
> If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? Very possibly IO, yes. And it is twice as big for a debug build, whereas a non-debug build is smaller in gcc - 69 MB vs 74 MB in clang. Perhaps more importantly, not all debug builds are equal, so the comparison is not apples-to-apples without saying whether the gcc debug builds contain more useful information. gcc also has various levels of debug info, perhaps a different one would provide less info for a smaller binary that would be more of a parallel to clang.

by Steltek 13y ago

masklinn 13y ago

> If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? 250MB of output adding 5mn of compile time would mean 800KiB/s. That's about what a 5400RPM HDD gets on random writes. Possible, but means GCC has an utterly terrible I/O architecture and flushes to disk after more or less every write call. > What is this test really trying to determine? Nothing? It's just trying to infirm or confirm the initial off-hand remark: https://twitter.com/icculus/status/448281959538888704 https://twitter.com/icculus/status/448281959538888704 > Like most benchmarks, you could fabricate scenarios that favor one or the other all day long. Some closer to reality, some completely synthetic. I'm not sure how you can get closer to reality than "I spend my days compiling Goat Simulator with Clang and GCC, let's compile Goat Simulator with Clang and GCC".

azakai 13y ago

> If gcc is producing a final binary that's twice the size of clang's, wouldn't that point to IO being a big factor in compile time? Very possibly IO, yes. And it is twice as big for a debug build, whereas a non-debug build is smaller in gcc - 69 MB vs 74 MB in clang. Perhaps more importantly, not all debug builds are equal, so the comparison is not apples-to-apples without saying whether the gcc debug builds contain more useful information. gcc also has various levels of debug info, perhaps a different one would provide less info for a smaller binary that would be more of a parallel to clang.