Strategy for implementing INLINE

[kchanqvq]

I did some manual inlining, and I believe that we are only one INLINE of arrayp/vectorp away from getting sequence operations in the same performance ball park as native JavaScript forEach etc.

My question is what's the right way to do it? I see two possibilities:

1. use JavaScript toString(). This need some bootstrap shenanigan for the host to save JS compilation result. This also require adding a syntax to codegen.lisp to splice in raw JS string. My real concern is if in the future we implement more non-trivial optimizations in the compiler, it might be very hard to work with the serialized JS string function bodies. In every other compiler, inlining is supposed to enable more optimization.
2. save the Lisp source (high level), codegen S-expr (low level), or maybe macroexpanded Lisp source (I believe this is the right thing, although requiring non-trivial implementation effort). In the future these will be easier to optimize. The problem is this might increase the bundle size. But if we only inline a few performance critical small functions, it might be acceptable.

Thoughts?

[davazp]

I haven't thought about it.

But I am not sure if it is worth the complexity. The underlying JS engine will already do its own inlining. We might as well try to improve the compiler output first instead, to make it smaller and more friendlier to the JS compilers.

[davazp]

Now I believe underlying JS engine cannot inline at all, because we have an fvalue indirection, and this is a mutable property.

I don't know. JS compilers are known to do speculative optimizations. They might still inline it speculatively with a guard in the inlined code if the reference has changed But we'd need to check more carefully the inlining capabilities. It would make sense because it is not much different from inlining any other JS method.

I knew in the past at least, try/catch disabled many optimizations. But I think this limitation was lifted as well.

But I haven't checked in a while. We'd need to have a look.

[kchanqvq]

More data:
Defining them in functions, the different between VECTORP inline/notinline disappears is still there (first time I mistyped):

CL-USER> (defun foo-1 (x) (let ((c 0)) (dotimes (i 1000000) (when (vectorp x) (incf c))) c))
FOO-1
CL-USER> (defun foo-2 (x) (let ((c 0)) (dotimes (i 1000000) (when (and (jscl::storage-vector-p x) (not (and (jscl::in "dimensions" x) (listp (jscl::oget x "dimensions"))))) (incf c))) c))
FOO-2
... omit some warmup runs ...
CL-USER> (time (foo-1 (make-array 1)))
Execution took 0.24 seconds.
1000000
CL-USER> (time (foo-2 (make-array 1)))
Execution took 0.13 seconds.
1000000

The difference is also quite big for AREF (which is what I really care):

CL-USER> (defun foo-1 (x) (let ((c 0)) (dotimes (i 1000000) (incf c (if (vectorp x) (jscl::storage-vector-ref x 0) (error "unreachable")))) c))
FOO-1
CL-USER> (defun foo-2 (x) (let ((c 0)) (dotimes (i 1000000) (incf c (if (and (jscl::storage-vector-p x) (not (and (jscl::in "dimensions" x) (listp (jscl::oget x "dimensions"))))) (jscl::storage-vector-ref x 0) (error "unreachable")))) c))
FOO-2
... warmup runs ...
CL-USER> (time (foo-1 (make-array 1 :initial-element 1)))
Execution took 0.255 seconds.
1000000
CL-USER> (time (foo-2 (make-array 1 :initial-element 1)))
Execution took 0.123 seconds.
1000000

What I think must have happened is even if JS engine is able to perform inlining, it might hinder some later optimization (but this shouldn't be the case for sufficiently smart compiler?). Either this, or our functions are quite verbose so the engine is reluctant to do inlining in some cases.

Where I try a statement-based compiler (instead of expression based, removing the need fo rselfcall), and a more serious compiler with optimizations with a IR, with more rich control with labels and decompilation.

Wow, this is really impressive. Did you get performance improvement back then? Do you think it's worth it to port to current version?

[kchanqvq]

I see traces like this from --trace-turbo-inlining:

Inlining 0x31d88ca8 {0x248c4d4e87a9 <SharedFunctionInfo JSCL_USER_VECTORP>} into 0x31d888c8 {0x12b2410a3839 <SharedFunctionInfo>}

If that SharedFunctionInfo is in fact foo-1 (I don't know why it doesn't show JS_USER_FOO), then we know v8 does inline VECTORP, but for some reason its result is slower than if we inline from Lisp side.

Update: a few megabytes of --trace-turbo JSON confirmed this is indeed foo-1.

Update2: Some (but not all) of the performance gap between foo-1 and foo-2 can be explained by extra internals.checkArgs and FUNC.fname = ....

[kchanqvq]

Another discovery: our satisfies-test-p is too large:

Cannot consider 0x7526c0058e28 {0x1232f6942221 <SharedFunctionInfo JSCL_USER_SATISFIESTESTP>} for inlining (reason: 5)

Update: fixed this in f5400c8. Now our sequence functions (except subseq) run at most 1x slower than WASM CLISP/ECL on vectors, and ours (except subseq) run faster than them on lists (!). Not quite fast yet, but finally acceptable I can say!

About list, I have some microoptimization idea as well. Basically, write faster car/cdr in JS.

[davazp]

Wow, this is really impressive. Did you get performance improvement back then? Do you think it's worth it to port to current version?

I don't remember the conclusions unfortunately. I think I stopped due to some distractions in life and the effort it would take, not that the approach was a dead-end.

I do remember though that jscl was a lot slower then, and it got faster just thanks to the improvements to the JS engines themselves :-)