Fork me on GitHub
#babashka
<
2020-02-20
>
sogaiu00:02:46

all tests passed here 👍

teodorlu08:02:43

Question: what's the difference between resources/BABASHKA_RELEASED_VERSION and resources/BABASHKA_VERSION? I'm asking because I re-ran the install script to get the new version, but I found I got 0.0.70 again.

borkdude08:02:37

@teodorlu should be fixed now

teodorlu08:02:30

$ bb --version
babashka v0.0.71
🎉

jeroenvandijk09:02:39

@borkdude Out of curiousity, did you consider implementing the Sci interpreter with protocols? I wonder how much of a performance difference that would make (on dispatching). The maps in analyzer.cljc ( {:sci.impl/op :var-value} ) would have to be replaced with (deftype ..) and the dispatch code in the interpreter.cljc would have to be adapted

borkdude09:02:18

haven't considered it so far

borkdude09:02:18

maybe worth an experiment and some benchmarks, go ahead

jeroenvandijk09:02:25

I'll leave it for a bit later, need to have some performance issues first. I was wondering if you already had thought about it and found issues with it. Thanks!

borkdude09:02:10

I don't use protocols a lot in my daily code. Maybe I should, it just doesn't cross my mind 😉

jeroenvandijk09:02:31

yeah makes sense

jeroenvandijk09:02:52

I use protocols mostly for abstracting interfaces. I like that a lot. I have once seen a huge performance increase in a Hadoop project (long time ago), but for the rest don't use it for performance reasons. I also like it to organize my code and it's less forgiving than map dispatching so it catches errors quicker. Reloading code is not as nice with protocols though, you need to be more careful

borkdude09:02:50

that wouldn't be an issue for me, I test a lot of programs with one-off invocations anyway

borkdude09:02:25

like:

$ lein run "(+ 1 2 3)"
6
in the sci repo

borkdude09:02:28

so I'm open to the change.

jeroenvandijk09:02:18

Ok now I'm thinking about it a protocol implementation could be gradually added (due to the open extention possibility). So I could already start this with minimal effort. Do you have an (automated) performance suite somewhere to see improvements or regressions easily?

jeroenvandijk09:02:38

One other potential feature would be that protocols make the language open for extension (e.g. custom optimizations)

borkdude09:02:00

so, with the latest change to reader conditionals weavejester/medley and lambdaisland/regal can just be ran from their original repos without any changes

hobosarefriends09:02:54

cool now I just have to find an excuse to use them 😄

borkdude09:02:56

@nate_clojurians You expressed/asked about this idea before: so it's now implemented, no more duplication of the :clj branch for :bb

jeroenvandijk09:02:52

Works for the jvm test suite, but let's wait for the js suite

borkdude09:02:43

it fails for node, probably because Object isn't a thing there? :default works in CLJS I think

jeroenvandijk09:02:58

yeah i was too lazy to look it up, but probably

jeroenvandijk09:02:30

I'll look at it later. Had an urge to just test this 🙈

jeroenvandijk09:02:32

Ok js is more complicated. Extending object works, but I get lot's of other errors (number is not an object apparantly). So a bit more work hehe. To be continued

jeroenvandijk09:02:09

My guess is that this already a huge performance boost metal

borkdude09:02:07

could be, but to measure is better than to guess 🙂

jeroenvandijk09:02:38

for sure, so I'll leave that to someone who has benchmarked Sci before 😎

borkdude10:02:10

simple test:

time ./sci "(loop [val 0 cnt 1000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val))"

borkdude10:02:18

where sci is the result of script/compile

jeroenvandijk10:02:20

If it's not faster I'll continue until it's faster, my promise

borkdude10:02:09

I think the identity implementations should just be umbrella'd under Object or :default

jeroenvandijk10:02:51

could be, I'm not a cljs (protocol) guru

jeroenvandijk10:02:00

Right now I think the current implementation is more optimal because Object follows the heavier eval path now. So maybe better to add later

borkdude10:02:15

probaby analyzer.cljc should emit deftyped objects that implement IInterpret.

borkdude10:02:59

I'll try the performance of the current branch

jeroenvandijk10:02:03

how do I get the ./sci binary? I'm using script/perf now

borkdude10:02:08

no, script/compile

jeroenvandijk10:02:30

ah yeah ok, I'll update my Graal setup

jeroenvandijk10:02:57

for what it's worth the script/perf doesn't say it's faster

jeroenvandijk10:02:56

ok not there yet 🙂

➜  sci git:(features/protocol-interpreter) ✗ time ./sci "(loop [val 0 cnt 1000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val))"
1000000
./sci   1.92s user 0.08s system 99% cpu 2.016 total
➜  sci git:(features/protocol-interpreter) ✗ time ./sci-master "(loop [val 0 cnt 1000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val))"
1000000
./sci-master   1.67s user 0.08s system 99% cpu 1.767 total

borkdude10:02:27

it seems to be slower

borkdude10:02:36

than master

borkdude10:02:46

$ time ./sci "(loop [val 0 cnt 1000000] (if (pos? cnt) (recur (inc val) (dec cnt)) val))"
1000000
./sci    1.83s  user 0.08s system 99% cpu 1.919 total
master is around 1.5-1.6s

jeroenvandijk10:02:24

Ok challenge accepted 🙂

borkdude10:02:49

you can also try to measure "bigger" programs like the one with spartan.spec and s/?

jeroenvandijk10:02:57

I'll start with optimizing loop

jeroenvandijk10:02:48

I'll stop promising and start delivering 🙂 Talk to you later

hobosarefriends13:02:13

makes me kinda want to try it, but I also want to use cider 😮

borkdude13:02:17

for bb on emacs you can use inf-clojure to connect to a socket repl

borkdude13:02:37

I don't use much editor tooling for bb myself, because the scripts already start so fast, but it's cool that it's there for those who want it

jeroenvandijk18:02:31

No luck on the protocol test 😞 All my trials were slower or broke the functionality

borkdude19:02:40

That's also a valid outcome of an experiment

jeroenvandijk20:02:05

true 🙂 I think i would have to understand the analyzer part better and probably make some (big) changes there to make it work with protocols. Maybe I'll try later again

borkdude20:02:34

how it works in general: edamame is parsing code directly into sexprs. these sexprs have metadata attached to it: line and column. then the analyzer analyzes the sexprs and also expands macros and attaches more metadata if interpretation is needed. everything that goes into the interpreter are annotated sexprs that either have an operation attached to it (interpret as a function call, interpret as interop, etc) or it's just a string, number etc that does not have metadata. if it doesn't have metadata, you also don't have to interpret it

borkdude20:02:49

so it's sexprs from parsing -> analyzer -> interpreter using metadata to determine what to do with it

borkdude20:02:11

I think there was a talk about metadata during IN/Clojure who was also going to mention sci as an example using metadata as a central tool

borkdude20:02:18

but it's not up yet