User:Bluefoxicy/gcc optimizations

Examining the chart of optimization results (ODS), you might notice immediately that some optimizations make things faster while others make things slower. Eventually I found that -fno-tree-pre made certain code faster without sacrificing much out of other code; #gcc on OFTC says this is because the redundancy analyzer on x86 is "stupid" and so Partial Redundancy Elimination does not work right.

This was actually noticed by contrapositive; it wasn't that -fno-tree-pre made things faster, but -ftree-pre made things slower. -ftree-pre is enabled by default at -O2 but not at -Os; I had a hunch -Os would be faster due to cache limitations, and noticed immediately that nbench gave a much higher "Integer Index" for this.

Some digging through optimizations that -Os turns off and I found that -ftree-pre was enabled by -O2; I switched it on to see what happened in only a couple tests. Later I noticed ALL of those tests suffered significantly on "Integer Index," which is what is slower in -O2. I switched gears and kicked -fno-tree-pre on while building -O2; results were extremely pleasing.

Benchmarking

Nbench

Initial Results

-march=i586 -O2
 
Memory Index:  0.728
Integer Index: 0.693
Floating Point Index:  0.837

Notice that the Integer Index is somewhat low.

-Os Results

-march=i586 -Os
 
Memory Index:  0.719
Integer Index: 0.736
Floating Point Index:  0.804

Good gains on Integer Index, but we lose on everything else.

Final Results

-march-i586 -O2 -fno-tree-pre
 
Memory Index:  0.728
Integer Index: 0.755
Floating Point Index:  0.830

The Memory Index is the same; but we get a 0.062 increase in Integer Index, giving a performance increase of (0.062/0.693) or 8.95%.

The Floating Point Index drops by 0.007, giving a performance decrease of (0.007/0.837) or 0.836%.

POVbench

I tried out POVRAY rendering povbench to test these on a realistic workload. The actual INI and POV files from the POVRAY site are used.

Please note that these tests take about a day to run each. The CPU gets hot enough to almost burn your hand if you touch it for an extended period; but just barely, and only on parts where your skin is very thin (like fingertips).

On the Athlon 64 with -O2 and -march=pentiumpro, -fno-tree-pre slows things down. I am testing on the Geode itself, which may or may not behave differently. Note the slowdown was about 17%, which is theoretically impossible based on the nbench results on Geode. This shows that either nbench is a horrible benchmark or the Geode doesn't respond the same way performance wise to the code changes. For now I am going to assume that nbench is crappy and go ahead with a povbench test.

-O2 and PentiumPro

This test is the baseline test. It uses -O2 optimization and PentiumPro architecture, as well as enabling 3DNow. MMX is enabled by default for the PentiumPro but we enable it anyway. The build was as follows:

 $ MYCFLAGS="-march=pentiumpro -m3dnow -mmmx -O2"
 $ make CFLAGS="$MYCFLAGS" CXXFLAGS="$MYCXXFLAGS"

Test results:

 0:00:34 Parsing 1040K tokens
Building mesh2: 
  - vertex_vectors
 0:00:37 Parsing 1255K tokens
  - normal_vectors
 0:00:40 Parsing 1435K tokens
  - uv_vectors
 0:00:42 Parsing 1575K tokens
  - face_indices
 0:00:51 Parsing 2290K tokens
 0:00:55 Creating bounding slabs
 0:00:55 Creating vista buffer
 0:00:55 Creating light buffers 2299K tokens

Other Thoughts

Note that this isn't actual FPU or Integer operation performance; but rather operations based on such operations. I have no real clue HOW nbench comes up with these numbers, so I am taking it as just general code flow. It appears, then, that some code goes up in performance by 8.95%, while other code goes down by 0.836%.

Exact implications I am unable to measure. Somebody should decode a JPEG image and render a complex Web page and play an Ogg Vorbis file with -O2 and -O2 -fno-tree-pre being used to compile ALL code involved along the way. The benchmark for these operations will be precisely how much real time they take, which is measurable with the 'time' utility (as long as you complete each operation in series and then exit immediately when finished). Hand-written assembly code does not count, it doesn't get optimized by these, so disable it when taking any such measurements.

Tuning

Vladimir Makarov has created a gcc patch for the Geode and posted it to the mailing list. His patch enables MMX, 3DNow, 3DNow-A, and SSE Prefix insns. AMD's data book doesn't give specific tuning information; however, his patch does perform just as good as PentiumPro and produce smaller code by 5-7%.

The Geode GX handles the SSE prefetch instructions PREFETCHNTA, PREFETCHT0, PREFETCHT1, PREFETCHT2; but gcc doesn't know this without Makarov's patch. Geode GX doesn't handle any other SSE insns.

I have not examined gcc to see if it makes any decisions based on the size of cache or the number of TLB entries. If it does, it should know there's 16KiB I1 and 16KiB D1 4-way set associative 32-byte cacheline L1, no L2, 8 ITLB and 8 DTLB L1 TLB entries, and 64 L2 TLB entries.

The Geode processor core itself is derived from the Cyrix MediaGX processor, and so it may be possible to tune the code for that processor and have better performance than simple PentiumPro tuned code. Makarov has tuned the Geode GX target somewhat, but has stated that there is not enough documentation to do detailed tuning.