4 ms·

I've written a lot of interpreters in C/++ lately, and spent a lot of time profiling and optimizing them. I can't remember -O3 ever being faster than -O2, it's

by codr7 5y ago

I've written a lot of interpreters in C/++ lately, and spent a lot of time profiling and optimizing them. I can't remember -O3 ever being faster than -O2, it's usually slightly slower for me.

nly 5y ago
What about when you factor in PGO? (-fprofile-generate & -fprofile-use)
- mhh__ 5y ago
  This is the rub. the compiler is flying completely blind without PGO. I turned on PGO for the D compiler recently and it compiled it's tests 15% faster. Boom.
- codr7 5y ago
  Haven't really been down that rabbit hole yet, thanks for reminding me.
DannyBee 5y ago
For interpreters, that's highly likely to be true, especially if they are mainly spending time in switch tables or executing basic opcodes.
- infberg 5y ago
  Care to explain? -O3 generates larger code than -O2?
  - pclmulqdq 5y ago
    Yes, -O3 tends to include a lot of features that increase code size, like aggressive loop unrolling. If you are jumping around a large amount of code, -O3 generally performs more poorly than -O2, but if you are running a tight loop (like HPC code), -O3 is better. In the past, at a time when I worked on a very performance sensitive codebase that was also limited in scope, we compiled with -Osize and did all the loop optimizations we wanted manually (and with pragmas). That produced faster code than -O2 or -O3.
    - gnufx 5y ago
      Regarding unrolling, -O3 contains -funroll-and-jam but not -funroll-loops. You may want one or the other, maybe both, depending on circumstances. I don't see much benefit from the available pragmas on HPC-type code unless for OpenMP, and "omp simd" isn't necessary to get vectorization in the places I've seen people say it is. Mileage always varies somewhat, of course. (Before second-guessing anything, use -fopt-info.)
    - jleahy 5y ago
      It’s a shame that Osize can sometimes produce truly awful code. There are a few optimisations in there that trade a byte for a massive slowdown.
      - jhgb 5y ago
        Surely a profile-guided build should be able to only apply -Os to those functions where it doesn't cause a lot of problems.
        pclmulqdq 5y ago
        In the application I referred to, PGO was also used. However, that only applies -Os to cold code, and if what you're doing is very branchy, it can help even in the hot path.
      - userbinator 5y ago
        You asked for minimum size, and that's what you got. I'd say that's working as it should. A more granular control over optimisation would be good, however.
        kevin_thibedeau 5y ago
        You can enable/disable individual optimizations. How much more granular do you need?
        jleahy 5y ago
        Probably just some tweaks to O2 would be enough, after all people are selecting Os over O2 because they see better performance, and that should not be happening.
- gnufx 5y ago
  Python, specifically, is supposed to get most benefit from -fno-semantic-interposition

by codr7 5y ago

I've written a lot of interpreters in C/++ lately, and spent a lot of time profiling and optimizing them. I can't remember -O3 ever being faster than -O2, it's usually slightly slower for me.

nly 5y ago

What about when you factor in PGO? (-fprofile-generate & -fprofile-use)

mhh__ 5y ago
This is the rub. the compiler is flying completely blind without PGO. I turned on PGO for the D compiler recently and it compiled it's tests 15% faster. Boom.
codr7 5y ago
Haven't really been down that rabbit hole yet, thanks for reminding me.

DannyBee 5y ago

For interpreters, that's highly likely to be true, especially if they are mainly spending time in switch tables or executing basic opcodes.

infberg 5y ago
Care to explain? -O3 generates larger code than -O2?
- pclmulqdq 5y ago
  Yes, -O3 tends to include a lot of features that increase code size, like aggressive loop unrolling. If you are jumping around a large amount of code, -O3 generally performs more poorly than -O2, but if you are running a tight loop (like HPC code), -O3 is better. In the past, at a time when I worked on a very performance sensitive codebase that was also limited in scope, we compiled with -Osize and did all the loop optimizations we wanted manually (and with pragmas). That produced faster code than -O2 or -O3.
  - gnufx 5y ago
    Regarding unrolling, -O3 contains -funroll-and-jam but not -funroll-loops. You may want one or the other, maybe both, depending on circumstances. I don't see much benefit from the available pragmas on HPC-type code unless for OpenMP, and "omp simd" isn't necessary to get vectorization in the places I've seen people say it is. Mileage always varies somewhat, of course. (Before second-guessing anything, use -fopt-info.)
  - jleahy 5y ago
    It’s a shame that Osize can sometimes produce truly awful code. There are a few optimisations in there that trade a byte for a massive slowdown.
    - jhgb 5y ago
      Surely a profile-guided build should be able to only apply -Os to those functions where it doesn't cause a lot of problems.
      - pclmulqdq 5y ago
        In the application I referred to, PGO was also used. However, that only applies -Os to cold code, and if what you're doing is very branchy, it can help even in the hot path.
    - userbinator 5y ago
      You asked for minimum size, and that's what you got. I'd say that's working as it should. A more granular control over optimisation would be good, however.
      - kevin_thibedeau 5y ago
        You can enable/disable individual optimizations. How much more granular do you need?
      - jleahy 5y ago
        Probably just some tweaks to O2 would be enough, after all people are selecting Os over O2 because they see better performance, and that should not be happening.
gnufx 5y ago
Python, specifically, is supposed to get most benefit from -fno-semantic-interposition