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 bunch of casting & dispatch.
Adding a :long hint on b, b is still Object, and the compare becomes
if (a < RT.longCast(b)) {
num = Numbers.num(a);
}
with a long cast that doesn't seem necessary. Also, c is still Object.
Casting the lookup to long, like (long (:foo {:foo 3})), b and c are now
long, but there's now a cast on the return of the lookup
Object x;
if (_thunk__0__ == (x = _thunk__0__.get(const__4))) {
x = (__thunk__0__ = __site__0__.fault(const__4)).get(const__4);
}
final long b = RT.longCast(x);
final long c = (a < b) ? a : b;
which is going to hit the RT.longCast(Object) method, and start probing for
the class so it can pick a method.
On Wednesday, January 30, 2019 at 6:58:07 PM UTC-8, Alex Miller wrote:
>
> 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 <craft...@gmail.com
> <javascript:>> wrote:
>
>> 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 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 few
>>> thread dumps while it's running (either ctrl-\ or externally with kill -3)
>>> and see what's at the top. If there really is a hot spot, this is a
>>> surprisingly effective way to see it.
>>>
>>> For this kind of code, there is no substitute for actually reading the
>>> bytecode and thinking carefully about where there is unnecessary casting or
>>> boxing.
>>>
>>>
>>>
>>> On Wed, Jan 30, 2019 at 6:55 PM Brian Craft <craft...@gmail.com> wrote:
>>>
>>>> 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, though longCast drops
>>>> out of the hotspot list. :-p There must be some other limiting step that
>>>> I'm missing in the profiler.
>>>>
>>>> I'm calling it around 1.2M times, so hopefully that engages the jit.
>>>>
>>>> On Wednesday, January 30, 2019 at 3:39:41 PM UTC-8, Alex Miller wrote:
>>>>>
>>>>> 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
>>>>> is the kind of thing it's good at, but it might take 10k invocations
>>>>> before
>>>>> it does.
>>>>>
>>>>>
>>>>> On Wednesday, January 30, 2019 at 4:03:43 PM UTC-6, Brian Craft wrote:
>>>>>>
>>>>>> 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 &
>>>>>> RT.longCast((Object)RT.aget((byte[])arr2, RT.intCast(k)))))
>>>>>>
>>>>>> Is there any way to avoid that RT.longCast? There is an aget method
>>>>>> in RT.java that returns a byte, and a longCast for byte, but I suspect
>>>>>> the
>>>>>> cast to Object is causing it to hit the longCast for Object, which does
>>>>>> a
>>>>>> bunch of reflection.
>>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "Clojure" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/clojure/vXJFuOujTaw/unsubscribe.
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> clojure+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> <javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/vXJFuOujTaw/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
