Clojurians Log v2

One source for the purpose of the volatiles is here: https://clojure.atlassian.net/browse/CLJ-1580 Those were a continuation of changes started with this ticket: https://clojure.atlassian.net/browse/CLJ-1498

has anyone done any experiments with the inline classes in Valhalla early access and Clojure’s persistent data structures? 🙂

Maybe @ghadi

He was talking about it from the jvm lang summit

I haven't had a chance to do anything except think about how it could apply within PersistentHashMap

Brian Goetz was strongly encouraging experimentation -- it's ready for that https://wiki.openjdk.java.net/display/valhalla/LW2

yeah, I saw both your talks! 😄

really cool stuff going on with the JVM at the moment

I’m going to try to pair Clojure and the Vector API and see what happens

the Vector API is very exciting for the JVM. I think we'll be able to use the Vector API, but I don't think it will be very performant unless we can write our functions in such a way that a large areas of code have the proper Vector types exposed -- that way the JVM will optimize through it

I'm not sure whether it would work as well with intervening casts to/from Object as with IFn

but I'd be happy to find out @schmee

there is something custom about the Vector inlining that only happens in C2

I guess if you arrange a fat method body using a bunch of macros, where are the locals are typed Vectors that might work

yeah, I think I will have to jump through some major hoops to make it work, but that’s the fun in it! 🙂

candidate inline classes within Clojure are not clear to me yet

I wish we could express SIMD crypto routines with the Vector API, but it's not timing-attack safe to do it within a JIT, unless there was a way to tell hotspot not to do timing-unsafe xforms within a region of code

to be honest I don’t understand how it’s possible to write timing-sensitive code on the JVM at all ¯\(ツ)/¯

you can't 🙂

and yet we have javax.crypto :thinking_face: 😄

I wonder how that's made safe (haven't peeked under the covers)

this is a pretty cool talk by the guy who did the ECC implementation in javax.crypto where he talks about timing-dependence etc: https://www.youtube.com/watch?v=5kj_GT6qvYI

> This relates to my comment that we need a way for the Vector runtime to "crack" the lambdas passed to HOF API points like Vector.reduce. If we had the equivalent of C# expression trees, we could treat chains of vector ops as queries to be optimized, when executing a terminal operation (such as Vector.intoArray or hypothetical Vector.collect). A vector expression could be cooked into some kind of IR, and then instruction-selected into a AVX code.

an old post from John Rose re: vector ops ^

"lambda cracking"

http://cr.openjdk.java.net/~jrose/panama/token-codes.html

more organized ideas around that ^ "metabytecode" 🙂

cool, I’ll check it out! :thumbsup:

it's a Forth-y stack machine embedded into indy bootstrap method arguments

@schmee that talk looks cool, definitely will watch

eventually there will be a second JVM embedded in indy bootstrap methods 😁

Even without using inline classes, I think it might be worth experimenting, at least for Clojure vectors, with trees that have no PersistentVector$Node objects, only Object arrays. It seems there are twice as many levels of indirection as there need to be.

would that make transients harder?

I do not believe so. You would still need the 'edit' fields, but they could be tucked away in an extra array element of the Object arrays, at a fixed index, e.g. index 32.

isn't the length-32 thing special for cache compatibility?

I may do an experiment with this starting from core.rrb-vector's implementation, to see whether it gains any performance.

12 to 16 bytes of Object header at the beginning, plus 32*4 bytes for the 32-element Object array elements themselves, doesn't fit into any cache line sizes I have seen (32 or 64 bytes are common?)

¯\(ツ)/¯

It's an experiment thing, just based on a hunch that following 2 arbitrary pointers per tree level is likely more expensive in the common case, vs. 1 with the changes I have in mind. It probably will not actually improve things by a 2-to-1 factor in the common case, e.g. small arrays.

The Fingerhut Conjecture

Exactly! I will resist the urge to store data in NaN's 🙂

Which I can't resist playing with words to suggest the name: stenanography

that's terrible

I almost wish to apologize for infecting your brain with that word.

get out! 😂

From the Greek 'stenanos' meaning 'covered in IEEE 754 not a numbers'

I don't endorse any of this

Oof

I am pretty sure 32 was a good tradeoff choice - larger would reduce lookup times, but at the cost of increasing assoc/add times.