Comment by nkurz | Hacker News Reader

Comment by nkurz | Hacker News Reader

I realize it's not the focus of his test, but as someone who thinks often about how to take advantage of advanced vectorization techniques on modern processors, I was surprised by statements like this:

Moreover GCC -O2 defaults are (in my opinion unfortunately) still not enabling vectorization and unrolling which may have noticeable effects on benchmarks.

This led to enabling AVX and since the global constructor now gets some code auto-vectorized the binary crashed on invalid instruction during the build (my testing machine has no AVX).

No AVX? He wants to better take advantage of vectorization, but he's doing the testing on a processor that is 3 generations behind in vectorization support. AVX (128-bit) come out in 2011, and has been followed by AVX2 (256-bit) and (still limited release) AVX-512.

Clock speeds have been fairly flat, and most of the improvements to recent processors have been microarchitectural. A lot of the optimization done by compilers ends up being architecture specific. Seeing which brand-new compiler best targets old hardware seems like it might produce misleading results.

I realize that not everyone has (or can have) the most recent hardware, but this seems like a case where it would be strongly in AMD and Intel's interest to make sure that people like Jan have better access to the improvements made in the last few years.

Intel still disables AVX instructions on their low-end Core architecture chips for market segmentation purposes. It is also entirely absent to begin with from their Atom and Celeron chips. AMD did not have AVX support until Ryzen, but they are still selling Piledriver based CPUs on their AM4 platform.

Firefox can't blindly use AVX without checking for its presence or it will crash on these types of systems.

That doesn't explain GCC's side of the story though

EDIT: I should have clarified, the way the author of the article phrased it at first, I got the impression Clang did better auto-vectorization with Firefox code than GCC.

The author is trying to figure out why GCC underperforms Clang for Firefox builds. Seems inappropriate to worry about cutting-edge features that probably are available to 10% or so of computers that run Firefox (or a competing browser.)

Are you suggesting that 10% is a reasonable estimate of the percentage of Firefox instances running on hardware that supports AVX? I'm not sure of the real numbers but this strikes me as an extremely low estimate.

The closest I can find is Valve's hardware survey, which says that 87% of users are running on computers that support AVX. https://store.steampowered.com/hwsurvey (click on "Other Settings" on the bottom to expand).

Firefox is presumably lower than this, although I don't know by how much. Does Mozilla collect statistics on the capabilities of the computers that Firefox is being run on?

You can look at https://data.firefox.com/dashboard/hardware for similar numbers. CPU models are not broken out, but you can get a sense of what sort of CPUs are in use by looking at the GPU model: Intel powers 60%+ of the sampled population.

Well, the author also wrote:

> Moreover GCC -O2 defaults are (in my opinion unfortunately) still not enabling vectorization and unrolling which may have noticeable effects on benchmarks.

... which makes it sound like Clang does a better job at this with Firefox code.

AMD Bulldozer and later arch supports AVX, what Ryzen adds is AVX2 instructions.

You're right, and this is a little confusing. The article says he's using a "AMD Opteron 6272", which seems like it should support AVX: http://www.cpu-world.com/CPUs/Bulldozer/AMD-Opteron%206272%2.... So maybe the GCC bug he encountered is actually because he lacks AVX2 support? Or an incompatibility between early AMD and Intel support for AVX?

There are several independent things

- first how you set -O2 defaults in your compiler. This is a delicate problem since you need to find right balance of code size, compile time, robustness of generated code (do not trigger undefined effect in super evil ways) and of course runtime. In benchmarks I have found that Clang has bit of edge for runtime which is mostly vectorization (on x86-64)

- selection of minimal ISA you support. For GCC x86-64 is still the original Opteron, but distributions can easily (and some do) decide for better. Indeed AVX is big win, but for general purpose distribution this is still too agressive. You can provide AVX optimized libraries where it depends

- selection of CPU tunning (i.e. generic/intel)

So I consider it mistake that GCC traded vectorization over compile time speed+reliablity for -O2 because it can make important difference in common workloads this days (not 10 years ago, say).

It is also clearly a bug for GCC to produce AVX instruction when not explicitly asked for :)

I also do testing on Zen, Core and some PowerPC. For the firefox machine I use Buldozer box because I don't care it spends long nights running builds & benchmarks and I think this particular problem is not very CPU specific.

Firefox still treats SSE2 as its SIMD assumed-present baseline. Does GCC introduce multiversioned AVX functions on its own initiative?

Does GCC introduce multiversioned AVX functions on its own initiative?

Yes, this seems like one reasonable approach. The current approach of compiling to a "least common denominator" and then updating this denominator every decade or so seems insufficient. Instead of interpreting the absence of a "-march=" flag to mean optimize for nothing, maybe it can mean that multiple optimizations are automatically compiled and the appropriate one is selected at runtime. Alternatively, maybe we need to move away from the idea of compiling a single binary that runs on all platforms, and encourage greater use of platform specific compilations.

You need to explicitly ask for it via attribute, no automatic multiversioning is done (yet) and it would be more for -Ofast than usual -O2 builds I guess.

Performance improvements have diminishing returns though, and for a consumer product like Firefox, a large number of users will be on older hardware. Ceteris paribus, it would be much better to get say a 10% improvement for the users on below-median hardware than for the users on above-median hardware since it will matter a good deal more for the former group.

AVX is 256-bit (float×8 and double×4 vectors), AVX2 is the same size but adds integer operations (and many other things).

You're right, sorry. I concentrate on integer operations, which are mostly restricted to 128-bit on AVX, and had forgotten that it also supported 256-bit floating point. I'm not sure which (if either) would be most relevant to a web browser. I hope this error doesn't distract too much from my overall point.

AVX does not add anything to integer operation, like SSE. 128-bit integer is SSE2, which is part of amd64.

Well, AVX does explicitly add 256-bit integer loads and stores: https://software.intel.com/sites/landingpage/IntrinsicsGuide....

And some of the Boolean operations can be quite useful on integers. So even for integers, I was definitely wrong to characterize AVX as 128-bit.

Also AVX has shuffles which are interesting for integer code.

I'm surprised that the GCC doesn't add some autodetection mechanism in it.

This leads to issues like you have on Mac: When using safari, the lower consumption is super low. With Chrome you don't get nearly the runtime (when playing video or listing to music).

I'm surprised that the GCC doesn't add some autodetection mechanism in it.

As 'hubicka' mentions in another comment, GCC does have "multi-versioning" capability, but it doesn't use it by default. Instead, one needs to mark individual functions with GCC specific attributes, asking for versions with different capabilities to be created: https://lwn.net/Articles/691932/. This isn't necessarily a bad approach, but the fact that it seems be used rarely makes me wonder if some other more default approach that works with unmodified code might be an improvement.

I'm late to reading this article, but @hubicka already updated the article with Skylake benchmarks. GCC's lead is similar, if not higher.

Reply on news.ycombinator.com