Performance of tamarin-tracing interpreter

Edwin Smith edwsmith at adobe.com
Thu Jan 17 13:39:32 PST 2008


Several reasons, as a matter of fact

1. even if tt had the same interpreter as tc, it would be slower because
of a bunch of other things done in tt to reduce memory usage and
footprint.
(strings are Utf8 vs utf16, arrays, xml, and several other builtins
rewritten
in actionscript instead of c++, Traits/MethodInfo object graph is gone,
replaced
by a few caches of the same information).  these saved a lot of
code/memory but
cost some speed.  (speed which we expect to recover as the project
progresses)

2. tt's interpreter is a forth interpreter and ABC opcodes are
dispatched to
forth subroutines, so tt does a lot more bytecode dispatching than tc
does.
this was done to reduce code footprint and to enable tracing.  

a core concept in tracing is that you trace the common path, and if code
flow
takes an un-traced branch, you revert to the interpreter.  if the ABC
interpreter
was written in C++, then we would have to interpret & trace x86
instructions.
in theory that's possible but we felt it was too low level.

tt's interpreter is not re-entrant, and many opcodes can contain
implicit
calls.  (e.g. x+"a" can invoke x.toString().  x[i] can invoke an
object-specific
accessor depending on whether x is Object, Array, XML, etc).

writing things in forth enabled us to be able to trace all these
implicit
steps, using primitives that are high level enough to enable
language-aware
optimizations but low level enough to not have to do re-entrant things
in C
and low level enough to expose enough redundancy to the trace optimizer.

what we are doing about it

* several outstanding tasks to analyze/optimize the forth code by hand
* superwords are used to compile common sequences of forth into a slab
of
  faster C, without losing the ability to trace the sequence.
* planning to use the tracer in all but the most severely constrained
  embeddings (anything with, say, 8M or more could support tracing)
* when compiled with GCC, the interpreter uses computed goto's like any
  self respecting threaded interpreter should, but there is likely more
  tweaking to make the interpreter itself faster. (many papers on vmgen
  and gnu forth on the subject).
* theres grab bags of things TC optimizes for, that TT doesn't, things
  that just got tossed out during the engine rebuild.  many should be
  added back in without impacting memory/footprint.

where we especially don't want to lose too much speed is initialization
code
that only runs once.  such code will never be traced and you want the
interpreter
to be as fast as possible for that kind of code.

-----Original Message-----
From: tamarin-devel-bounces at mozilla.org
[mailto:tamarin-devel-bounces at mozilla.org] On Behalf Of Zbynek Winkler
Sent: Thursday, January 17, 2008 3:53 PM
To: tamarin-devel at mozilla.org
Subject: Performance of tamarin-tracing interpreter

Hello,

is there a specific reason why tamarin-tracing in interpreter mode is
so much slower (up to about 25 times) than tamarin-central?

Zbynek

tc:
/home/zbynek/hg.mozilla.org/tamarin-central/objdir-release/shell/avmshel
l
-Dinterp
tt:
/home/zbynek/hg.mozilla.org/tamarin-tracing/objdir-release/shell/avmshel
l
-interp


test                                                    tc      tt

untyped/sunspider-bitops-bits-in-byte.as               429    1675
untyped/sunspider-crypto-aes.as                        695   19870
untyped/sunspider-s3d-raytrace.as                      634    9780
untyped/sunspider-bitops-nsieve-bits.as                854   16352
untyped/sunspider-string-validate-input.as             410   13882
untyped/sunspider-access-binary-trees.as               195    1292
untyped/sunspider-controlflow-recursive.as             206    1595
untyped/sunspider-bitops-3bit-bits-in-byte.as          189    1362
untyped/sunspider-string-fasta.as                      489    9198
untyped/sunspider-s3d-cube.as                          518    9257
untyped/sunspider-bitops-bitwise-and.as                633    8287
untyped/sunspider-math-partial-sums.as                 678    6129
untyped/sunspider-s3d-morph.as                         684    6101
untyped/sunspider-access-fannkuch.as                  1499   40799
untyped/sunspider-math-cordic.as                       522    5885
untyped/sunspider-access-nbody.as                      648    4118
untyped/sunspider-crypto-sha1.as                       320    3716
untyped/sunspider-crypto-md5.as                        307    5446
untyped/sunspider-access-nsieve.as                    1000   12212
untyped/sunspider-math-spectral-norm.as                413    3803
typed/sunspider-bitops-bits-in-byte.as                 327    1555
typed/sunspider-crypto-aes.as                          713   19242
typed/sunspider-s3d-raytrace.as                        411    6089
typed/sunspider-bitops-nsieve-bits.as                  893   15816
typed/sunspider-string-validate-input.as               401   13737
typed/sunspider-access-binary-trees.as                 198    1377
typed/sunspider-controlflow-recursive.as               247    1685
typed/sunspider-bitops-3bit-bits-in-byte.as            215    1540
typed/sunspider-string-fasta.as                        514    9203
typed/sunspider-s3d-cube.as                            528    9232
typed/sunspider-bitops-bitwise-and.as                  155     423
typed/sunspider-math-partial-sums.as                   414    2829
typed/sunspider-s3d-morph.as                           671    6080
typed/sunspider-access-fannkuch.as                    1555   40612
typed/sunspider-math-cordic.as                         574    5962
typed/sunspider-access-nbody.as                        667    4099
typed/sunspider-crypto-sha1.as                         399    3871
typed/sunspider-crypto-md5.as                          398    5152
typed/sunspider-access-nsieve.as                       996   11856
typed/sunspider-math-spectral-norm.as                  338    3722


-- 
http://robotika.cz/
_______________________________________________
Tamarin-devel mailing list
Tamarin-devel at mozilla.org
https://mail.mozilla.org/listinfo/tamarin-devel


More information about the Tamarin-devel mailing list