4 ms·
Well, even if money does matter, the tradeoff is often more complex than just the one-time hardware cost. If you are a software engineer whose time is expensive
by cfallin 11y ago
Well, even if money does matter, the tradeoff is often more complex than just the one-time hardware cost. If you are a software engineer whose time is expensive, and a slower workstation processor means you wait an extra 5 seconds for a compilation 100 times a day, then the time costs add up quickly.
I would imagine the same is true for e.g. server response latency when that latency correlates to user experience and thus growth/popularity of your service. People might not notice a few ms, but 100ms vs 300ms is definitely visible.
- uxcn 11y agoCompiling can be more expensive than 5s/compile, but you should still probably lean toward things like ccache/ramdisks/distcc instead of the latest processor. I think the real value is new things like TSX/HLE.
- cfallin 11y agoYup, all those things are useful, but they don't solve everything. I've worked on projects where a single change to a header file would lead to a 20-minute rebuild adventure and where individual .cc files would take 10 minutes to compile. Caching and distcc build farms help somewhat but there's still, fundamentally, the critical path of a single file's (re)compilation, and only a faster CPU will help with that. (And if you say "thin client, distcc, big build farm", then you just need the latest CPUs in the build farm instead.) Of course this is as much an argument for a real module system in C/C++ as anything else... (And, I completely agree that TSX and other architectural stuff is totally awesome, too. Perhaps that'll drive adoption more than incremental perf, but I'm just arguing perf is still often really important.)