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.br...@gmail.com> 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 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 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+unsubscr...@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 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.
