I wrote Pixie and did a fair amount of benchmarking on it. As it stands
tracing JITs work well on tight loops. That means in a perfect world you
would only have one hot trace through a given set of functions. That's
actually harder to pull off than it sounds.

Take for instance the PersistentHashMap. If you dig into that
implementation you'll see dozens of if statements that are hit in different
conditions. If you're adding a new branch, adding a new leaf, copying nodes
of different types (there are three node types). So simply adding to a
hashmap requires dozens of conditional branches and the result of those
branches changes every time you add a new item.

So what I ended up doing for Pixie is disabling the JIT when digging into
the hashmap implementations. The PHM was implemented in RPython directly
and the JIT wouldn't try to optimize it. However, sometimes the JIT calls
back into user code (equals comparisons, and hashcode calculations), so
then you have to re-enable the JIT in a place where there isn't much of a
loop context.

There's many other locations like that. You may think you have a simple
loop, but then somewhere deep in your code you have a call to update-in,
which creates a lazy seq for the path, then iterates on that while digging
into several hashmaps and boom, the JIT just bails out.


The more I read up on it though, the more I see examples of tracing JITs
working poorly for "application code". That is, normal code you'd run in a
webserver. That sort of stuff just has so many if statements that the JIT
almost always optimizes the wrong thing.

On Mon, Apr 25, 2016 at 3:12 PM, lvh <_...@lvh.io> wrote:

> Hi Tim,
>
> On Apr 25, 2016, at 3:50 PM, Timothy Baldridge <tbaldri...@gmail.com>
> wrote:
>
> A LLVM/C++/RPython based version of Clojure would on a good day come in at
> about 1/10 the speed of Clojure on the JVM for general use cases.
>
>
> Whoa! The RPython one is particularly interesting; are those the figures
> you saw out of your efforts in porting Clojure to PyPy? Did you ever get a
> chance to interact with the PyPy folks when you saw such (IMHO)
> pathological performance figures? (No blame; a genuine question!)
>
>
> lvh
>
>
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke <rao...@gmail.com> wrote:
>
>> > The main motivation would be performance gains.
>>
>> blah? so many impedance mismatches and layers of indirection that i
>> don't think it will gain much? i mean, it would probably be better to
>> spend time tuning gc parameters or something. just a rant / guess.
>> e.g. robovm is for some use cases perfectly fine performance wise
>> believe it or not.
>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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.
>
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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.

Reply via email to