The "easiest" way to obtain JIT-produced native code without having to sift
through mountains of it is to use JMH[1] in -perfasm mode[2]. Here's an
article on how to use JMH from Clojure[3].
However, if you start to spend so much time optimizing primitive operations
in Clojure (and this
Yes, there a bunch of jvm options to show you when it’s jit-ing, and even the
rewritten code.
You can google for that stuff like LogCompilation. Occasionally I have found
that useful.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
Is there any way to inspect what the jit does to it?
On Wednesday, January 30, 2019 at 10:07:38 PM UTC-8, Alex Miller wrote:
>
>
>
> On Wed, Jan 30, 2019 at 11:07 PM Brian Craft > wrote:
>
>> With much experimentation, I ended up with this:
>>
>> (let [a 1
>> b (.longValue ^Long (:foo
On Wed, Jan 30, 2019 at 11:07 PM Brian Craft wrote:
> With much experimentation, I ended up with this:
>
> (let [a 1
> b (.longValue ^Long (:foo {:foo 3}))
> c (if (< a b) a b)])
>
> which seems to avoid the longCast call:
>
> Object o;
> if (_thunk__0__ == (o =
With much experimentation, I ended up with this:
(let [a 1
b (.longValue ^Long (:foo {:foo 3}))
c (if (< a b) a b)])
which seems to avoid the longCast call:
Object o;
if (_thunk__0__ == (o = _thunk__0__.get(const__3))) {
o = (__thunk__0__ =
The full context is large. But, for example, in this code:
(let [a 1
b (:foo {:foo 3})
c (if (< a b) a b)])
b and c are Object (if the disassembly is to be believed) which leads to
casts where c is used later. Also, the compare is calling Numbers.lt, which
is going to do a
It would really help to see a full function of code context. From that I
could probably talk a little more about what I would expect the compiler to
understand and how you might be able to influence it.
On Wed, Jan 30, 2019 at 8:50 PM Brian Craft wrote:
> If there is unnecessary casting or
If there is unnecessary casting or boxing, how do you avoid it? hinting and
casting affect it, but not in ways I understand, or can predict.
On Wednesday, January 30, 2019 at 6:06:37 PM UTC-8, Alex Miller wrote:
>
> Sometimes the insertion of profiling instrumentation magnifies the cost of
>
That is why I used 'unchecked-long' instead of 'long'.
(unchecked-long (unchecked-byte 5))
Not
(long (byte 5))
On Wed, Jan 30, 2019, 5:55 PM Brian Craft I haven't tried much. I'm getting the java via clj-java-decompiler.core
> 'decompile' macro.
>
> A long cast does drop the cast (which is
Sometimes the insertion of profiling instrumentation magnifies the cost of
things in a hot loop or provides misleading hot spot info. If you're using
a tracing profiler, you might try sampling instead as it's less prone to
this.
Or, this sounds silly, but you can manually sample by just doing a
I haven't tried much. I'm getting the java via clj-java-decompiler.core
'decompile' macro.
A long cast does drop the cast (which is really counter-intuitive:
explicitly invoke 'long', which calls longCast, in order to avoid calling
longCast).
Amusingly this doesn't reduce the total run-time,
What have you tried? And how are you getting that Java? I would prefer to
look at bytecode (via javap) to verify what you're saying.
Have you tried an explicit long cast?
(aget flat-dict (bit-and 0xff (long (aget arr j
Are you running this hot enough for the JIT to kick in? Usually this
does doing an unchecked cast of the return value of the aget on the byte
array change things?
(defn test-fn
[]
(let [obj-ary (object-array 10)
byte-data (byte-array (range 10))]
(doseq [idx (range 10)]
(let [idx (int idx)]
(aget
Profiling is showing a lot of time spent in RT.longCast, in places like
this:
(aget flat-dict (bit-and 0xff (aget arr j)))
arr is hinted as ^bytes, and flat-dict as ^objects.
which compiles to this:
Object code2 = RT.aget((Object[])flat_dict, RT.intCast(0xFFL &
14 matches
Mail list logo
