Closed Bug 442804 Opened 16 years ago Closed 6 years ago

space/speed tradeoff compiler settings

Categories

(Tamarin Graveyard :: Build Config, defect, P2)

Product:
Tamarin Graveyard
Component:
Build Config
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
Q1 12 - Brannan

People

(Reporter: mohammad.r.haghighat, Unassigned)

References

Details

(Whiteboard: PACMAN) 

This is not a bug, just some measurement results.

In TT configuration on Windows, by replacing the current optimization settings tuple (/Ox, /Os), which favors smaller code size over speed, to (/O2, /Ot) which favors speed, one can achieve good speedups. The binary size is increased by ~13% (407552 -> 460288 : 12.9%) while the average speedup on Sunspider is 13.8%. I’ve not measured the impact on the other platforms, but the results might help in deciding where to put the cutoff line in the space/speed tradeoff. Do we have a rule here?

- moh

C:\tamarin-tracing\test\performance>runtests.py -i 50 sunspider/
Executing tests at 2008-06-30 16:24:10.343000
avm: C:\tamarin-tracing\platform\win32\obj_9\shell\Release\avm_orig.exe
avm2: C:\tamarin-tracing\platform\win32\obj_9\shell\Release\avm2_O2Ot.exe

test                                                   avm    avm2     %sp

sunspider/access-binary-trees.as                     219.0   187.0    14.6
sunspider/access-fannkuch.as                         422.0   360.0    14.7
sunspider/access-nbody.as                            484.0   375.0    22.5
sunspider/access-nsieve.as                           172.0   156.0     9.3
sunspider/bitops-3bit-bits-in-byte.as                 32.0    31.0     3.1
sunspider/bitops-bits-in-byte.as                     109.0    94.0    13.8
sunspider/bitops-bitwise-and.as                      578.0   500.0    13.5
sunspider/bitops-nsieve-bits.as                      172.0   140.0    18.6
sunspider/controlflow-recursive.as                    94.0    78.0    17.0
sunspider/crypto-aes.as                              469.0   406.0    13.4
sunspider/crypto-md5.as                              422.0   360.0    14.7
sunspider/crypto-sha1.as                             110.0    94.0    14.5
sunspider/math-cordic.as                             125.0   110.0    12.0
sunspider/math-partial-sums.as                       640.0   531.0    17.0
sunspider/math-spectral-norm.as                      109.0    94.0    13.8
sunspider/s3d-cube.as                                469.0   406.0    13.4
sunspider/s3d-morph.as                               265.0   250.0     5.7
sunspider/s3d-raytrace.as                            609.0   515.0    15.4
sunspider/string-fasta.as                            359.0   312.0    13.1
sunspider/string-validate-input.as                   812.0   687.0    15.4
Superb.

If we could narrow down the cpp files to apply these settings to, we could get nearly all speedup for nearly none of the size increase. (tastes great, less filling).  VMInterp.cpp and Interpreter.cpp are certian candidates.

Using the x-platform build config, this ought to be straightforward.  with .vcproj file tweaking, its harder.

Also, what about /Ox /Ot  (full optimization, favor time)?  


FWIW, we compile spidermonkey with:

ICC all files: -O2 -ip
GCC jsinterp.cpp: -O3 -fstrict-aliasing
GCC other: -Os -fstrict-aliasing
MSVC jsinterp.cpp: -O2 -GL
MSVC other: -Os
SymTable.cpp, and the String and Unicode-related files are also likely important candidates.
(In reply to comment #1)

I actually started that way (/Ox /Ot). The speed was superior to (/Ox /Os), but the size was 477184 while the size with (/O2 /Ot) was 460288 and its performance was also better than (/Ox /Os). So, (/O2 /Ot) gave a better performance and a smaller size than (/Ox /Ot).
Correction: 

I actually started that way (/Ox /Ot). The speed was superior to (/Ox /Os), but
the size was 477184 while the size with (/O2 /Ot) was 460288 and its
performance was also better than (/Ox /Ot). So, (/O2 /Ot) gave a better
performance and a smaller size than (/Ox /Ot).

(In reply to comment #3)

It seems that the current increase in the total size is affordable. However, for a hyprid configuration (some /Ot some /Os) the following data should be helpful. It is the clockticks spent in each file when TT is run on the entire Sunspider as measured by VTune.

- moh

File_Name       Clockticks%	Cumulative_Clocktics%
interpreter.cpp	     14.62%	14.62%
gc.cpp	             10.15%	24.77%
lir.cpp	              8.25%	33.02%
avmcore.cpp	      4.99%	38.01%
poolobject.cpp	      4.86%	42.87%
avmplushashtable.cpp  4.84%	47.71%
arrayclass.cpp	      4.68%	52.39%
mathutils.cpp	      4.48%	56.87%
stringobjectfw.cpp    3.87%	60.74%
gcalloc.cpp	      3.82%	64.56%
avmpluslist.h	      2.81%	67.37%
traitsenv.cpp	      2.65%	70.02%
assembler.cpp	      2.50%	72.52%
box.h	              2.34%	74.86%
gcalloc.h	      2.31%	77.17%
interp.h	      1.66%	78.83%
methodenv.cpp	      1.66%	80.49%
lir.h	              1.10%	81.59%
nativei386.cpp	      0.89%	82.48%
atom.cpp	      0.88%	83.36%
fops.h	              0.87%	84.23%
gc.h	              0.83%	85.06%
mathutilswin.cpp      0.83%	85.89%
stringutils.cpp	      0.82%	86.71%
fragmento.cpp	      0.76%	87.47%
scriptobject.cpp      0.74%	88.21%
symtable.cpp	      0.72%	88.93%
trace.h	              0.70%	89.63%
regalloc.cpp	      0.70%	90.33%
gcobject.cpp	      0.69%	91.02%
pcre_compile.cpp      0.61%	91.63%
ftol2.asm	      0.61%	92.24%
vminterp.cpp	      0.54%	92.78%
avm.cpp	              0.46%	93.24%
abcparser.cpp	      0.38%	93.62%
assembler.h	      0.36%	93.98%
gcobject.h	      0.34%	94.32%
writebarrier.h	      0.29%	94.61%
stringclassfw.cpp     0.29%	94.90%
secchk.c	      0.25%	95.15%
verifier.cpp	      0.23%	95.38%
pcre_exec.cpp	      0.22%	95.60%
il.cpp	              0.22%	95.82%
lot.h	              0.20%	96.02%
bitset.h	      0.18%	96.20%
gcheap.cpp	      0.14%	96.34%
biginteger.cpp	      0.14%	96.48%
namespace.cpp	      0.14%	96.62%
avmplushashtable.h    0.12%	96.74%
abcenv.cpp	      0.10%	96.84%
gcstack.h	      0.10%	96.94%
methodinfo.cpp	      0.10%	97.04%


triaging bugs.  move to tamarin-tracing-vm.
Component: Build Config → Tracing Virtual Machine
Flags: flashplayer-triage+
QA Contact: build-config → tracing-vm
Summary: space/speed tradeoff in configuring TT → space/speed tradeoff compiler settings
Component: Tracing Virtual Machine → Build Config
QA Contact: tracing-vm → build-config
Transferring comments from bug 442804:

Description From Edwin Smith 2008-05-08 13:43:54 PDT (-) [reply]
With some tinkering, its not hard to make TT siginficantly faster and not very
much bigger, by selecting which files should be optimized for size vs speed. 
WIth more work, we can do this at the function level by moving functions around
to different files.

At the time of this writing for example, on VS2008/Win32 Release
small: 375K
fast:  455K
custom: 390K

custom is nearly the speed as "fast", which is about 20% faster across the
board than "small".  for 15K code increase, its worth it, at least on that
config.

This needs to be a per-configuration choice.
------- Comment #1 From Robert Sayre 2008-05-08 13:49:23 PDT (-) [reply] -------
Has PGO been tried on TT with MSVC? It worked very well on spidermonkey.
------- Comment #2 From Edwin Smith 2008-05-08 13:52:03 PDT (-) [reply] -------
Not as of yet, but I expect it to work well on TT too.
Rather, comments transferred from 432875 to 442804..  resolve dupe 432875.
Target Milestone: --- → Future
Retargeting to Brannan.  Performance measures and tuning should be done on both Intel and ARM for all compilers supported by Flash Player.
Flags: flashplayer-qrb+
Flags: flashplayer-bug-
Priority: -- → P2
Whiteboard: PACMAN
Target Milestone: Future → Q1 12 - Brannan
All of the data here is only regarding Tamarin-Tracing, AFAICT.  I do not know why that information was removed from the in the transition:
  tracing-vm@tamarin.bugs → build-config@tamarin.bugs

(between comment 7 and comment 8 above).

Perhaps the same exercise as was done in this ticket is worth doing again, but its really questionable how much value we'll get keeping this ticket open.
(unless we strongly believe that all the results will just carry over from TT to TR without any need to qualify them, that is.)
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.