On 2013/10/30 08:19:10, Sven Panne wrote:
https://codereview.chromium.org/50563003/diff/80001/src/math.js
File src/math.js (right):
https://codereview.chromium.org/50563003/diff/80001/src/math.js#newcode207
src/math.js:207: var MathSinImpl = function(x) {
On 2013/10/30 08:04:44, Jakob wrote:
> The thinking was that trigonometric functions are not important enough
to
> warrant the snapshot/binary size increase. FWIW, Math.exp also follows
the
> pattern of initializing the lookup table on first use. A potential
follow-up
CL
> is to entirely skip using lookup tables when FLAG_optimize_for_size,
e.g. by
> using direct uncached library calls.
Hmmm, are we really already at the point where saving 32kB is important
compared
to increased code complexity? I somehow doubt that. And even if this was
the
case, using the common polynomial approximation (used e.g. in
http://www.netlib.org/fdlibm/k_sin.c) would remove the need for any table
and
any kind of interpolation.
Another point is: How can we assure that the sin/cos/... call sites are
still
monomorphic with the "lazy eval" approach in this CL? Perhaps there is
some
magic, but I fail to see it...
Loading from the context and loading constants from two immediates are
roughly
equally fast, there is no point in preferring one to the other, and the
current
way is easier on the eye imo.
Call sites are monomorphic because, as Jakob mentioned offline, we have a
premonomorphic state prior to monomorphic.
If we pre-calculate the table and include it in the snapshot, we eagerly
pay for
it during deserialization of the snapshot.
https://codereview.chromium.org/50563003/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
