This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-30
Channels
- # beginners (23)
- # boot (3)
- # cider (5)
- # clara (12)
- # cljs-dev (15)
- # clojure (18)
- # clojure-spec (24)
- # clojure-uk (23)
- # clojurescript (24)
- # data-science (2)
- # datascript (1)
- # datomic (12)
- # fulcro (51)
- # jobs (1)
- # jobs-discuss (1)
- # leiningen (1)
- # nrepl (1)
- # off-topic (1)
- # onyx (2)
- # re-frame (6)
- # reagent (14)
- # rum (1)
- # shadow-cljs (12)
- # spacemacs (3)
- # specter (1)
- # tools-deps (37)
- # vim (2)
@mfikes do you have any infrastructure for benchmarking cljs patches with all the different js engines or do you just run them locally?
like the benchmarks you provided here https://dev.clojure.org/jira/browse/CLJS-2341
@kommen Yes, use script/benchmark
First set up engines per https://clojurescript.org/community/running-tests
I clear all of the existing tests out of the benchmark/cljs/benchmark_runner.cljs
and add my own.
Then, using a calculator, I calculate speedup numbers per engine.
@mfikes I did some further investigation of that strange behaviour where the bootstrapped cljs.compiler couldn't dispatch to JSValue. It seems that simulating that dispatch works perfectly fine in cljs.analyzer, but consistently fails in cljs.compiler. Here's a minimal commit (doesn't include any other experimentation) that shows the discrepancy with ./scripts/test-self-parity https://github.com/clojure/clojurescript/compare/master...frenchy64:bootstrap-jsvalue
It looks like JSValue is "compiled twice" in self-hosted, with (hash JSValue)
varying over #{16 17}
. In the code above, cljs.analyzer just happens to have methods for both versions (somehow), and cljs.compiler only has a method for the hash 17. New instances seem to always have (hash (type x)) = 16
. I'll try and poke around some more.
@ambrosebs Yes. I see the same. And, at its root, the method table that gets built in cljs.compiler
has the one with hash 17. The double loading of cljs.tagged-literals
is particular bad given the consequence—it is probably a disconnect between the code related to CLOSURE_IMPORT_SCRIPT
in self-parity.test
trying to track things (which really reflects an approach used by JVM-based REPLs), and cljs.js/*loaded*
being the main self-hosted mechanism for the same.
@ambrosebs If you modify self-parity.test/skip-load?
by adding 'cljs.tagged-literals
to the “non-macros” set in that impl, it would fix things. (Arguably, things are a mess in there with respect to loading, but that one spot is where we’ve “hacked” things to keep stuff from being loaded that is already loaded.)
Looks like Planck has this and so does Lumo https://github.com/planck-repl/planck/blob/master/planck-cljs/src/planck/repl.cljs#L838 https://github.com/anmonteiro/lumo/blob/658732fb2b934569507db9cc9a845aea07918f0c/src/cljs/snapshot/lumo/repl.cljs#L145 (FWIW)