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__ = __site__0__.fault(const__3)).get(const__3);
}
final long b = (long)o;
final long c = (a < b) ? a : b;
I don't know if this is advisable. Does anyone do this?
Also just noted this is another case where explicitly calling something
seems to make it disappear. :-p
On Wednesday, January 30, 2019 at 8:41:49 PM UTC-8, Brian Craft wrote:
>
> 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 <[email protected]> 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 <[email protected]> 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 [email protected]
>>>>> Note that posts from new members are moderated - please be patient
>>>>> with your first post.
>>>>> To unsubscribe from this group, send email to
>>>>> [email protected]
>>>>> 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
>>>>> [email protected].
>>>>> 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 [email protected]
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> [email protected]
>>> 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
>>> [email protected].
>>> 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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
