5 ms·
Not for this example. On E5-2680 v2(Ivy Bridge): ./magic_forest_gcc 617 655 606 7.22s user 0.36s system 100% cpu 7.580 total ./magic_forest_icc 617 655 60
by SoapSeller 12y ago
Not for this example. On E5-2680 v2(Ivy Bridge):
./magic_forest_gcc 617 655 606 7.22s user 0.36s system 100% cpu 7.580 total
./magic_forest_icc 617 655 606 7.00s user 0.34s system 100% cpu 7.340 total
./magic_forest_clang 617 655 606 5.73s user 0.25s system 100% cpu 5.980 total
gcc version 4.8.2
icc version 14.0.1
clang version 3.4
(On 3.14 powered arch linux)
It's might be interesting to see what kind of optimisation clang does, but I currently don't have the time to look into it.
- praseodym 12y agoAnd then there's the question of what compiler flags you used. Furthermore, one of the compilers could be really good at profile-guided optimisation (PGO), beating the others.
- SoapSeller 12y agoI've used the same flags like the OP have suggested in the source header comment.
- berkut 12y agoHow big are the binaries? ICC inlines a lot more heavily, it's possible (I've seen it before) the code size has bloated, not fitting into the IC... Having said that, most of ICC's general gains over GCC and LLVM are due to the much faster maths libraries (even more so on Linux), and that doesn't look like that would be useful for these tests...
- SoapSeller 12y agoYep, ICC's output is much bigger: clang 29K gcc 36K icc 89K