Hiphop JIT
93 views
Skip to first unread message
Remi Forax
Nov 30, 2012, 3:12:09 AM11/30/12
to jvm-la...@googlegroups.com
There is a nice article about the JIT that Facebook uses in his HipHop VM.
https://www.facebook.com/notes/facebook-engineering/speeding-up-php-based-development-with-hiphop-vm/10151170460698920
They have an inline cache with several guards and they found that it was
better from the perf point of view to link the guard by putting the
older first instead of putting the newer first. I wonder if there is the
same effect for other languages, I will test with Java + a dedicated
indy logic with week end.
R�mi
https://www.facebook.com/notes/facebook-engineering/speeding-up-php-based-development-with-hiphop-vm/10151170460698920
They have an inline cache with several guards and they found that it was
better from the perf point of view to link the guard by putting the
older first instead of putting the newer first. I wonder if there is the
same effect for other languages, I will test with Java + a dedicated
indy logic with week end.
R�mi
MacGregor, Duncan (GE Energy Management)
Dec 21, 2012, 10:07:55 AM12/21/12
to jvm-la...@googlegroups.com
Did you ever get a result from this? I haven't got round to
instrumentation for our gwt chains that finely, but I'm curious what
results you got.
>Rémi
>
>--
>You received this message because you are subscribed to the Google Groups
>"JVM Languages" group.
>To post to this group, send email to jvm-la...@googlegroups.com.
>To unsubscribe from this group, send email to
>jvm-language...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/jvm-languages?hl=en.
>
instrumentation for our gwt chains that finely, but I'm curious what
results you got.
>
>--
>You received this message because you are subscribed to the Google Groups
>"JVM Languages" group.
>To post to this group, send email to jvm-la...@googlegroups.com.
>To unsubscribe from this group, send email to
>jvm-language...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/jvm-languages?hl=en.
>
Remi Forax
Dec 21, 2012, 10:37:49 AM12/21/12
to jvm-la...@googlegroups.com
On 12/21/2012 04:07 PM, MacGregor, Duncan (GE Energy Management) wrote:
> Did you ever get a result from this? I haven't got round to
> instrumentation for our gwt chains that finely, but I'm curious what
> results you got.
It's still on my TODO list, Java lambda stuff claim most of my time
> Did you ever get a result from this? I haven't got round to
> instrumentation for our gwt chains that finely, but I'm curious what
> results you got.
devoted to OpenJDK ...
R�mi
>
> On 30/11/2012 08:12, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>
>> There is a nice article about the JIT that Facebook uses in his HipHop VM.
>> https://www.facebook.com/notes/facebook-engineering/speeding-up-php-based-
>> development-with-hiphop-vm/10151170460698920
>>
>> They have an inline cache with several guards and they found that it was
>> better from the perf point of view to link the guard by putting the
>> older first instead of putting the newer first. I wonder if there is the
>> same effect for other languages, I will test with Java + a dedicated
>> indy logic with week end.
>>
MacGregor, Duncan (GE Energy Management)
Dec 21, 2012, 12:40:57 PM12/21/12
to jvm-la...@googlegroups.com
That's okay, I've implemented the instrumentation and produced some stats
now. :-)
On average the oldest targets are called significantly more frequently
than later ones, with the average chain position remaining below 1.5 (0
being the oldest target) up to our standard maximum gwt chain length.
I then significantly increased the maximum length of our chains un to 20,
and the average chain position remains below 3 up to a chain length of 15,
and only starts going significantly above 3 when we hit a length of 18.
Increasing the chain length to 50 (!) showed that even then the average
chain position was approximately 16, so there's still a fairly strong bias
towards older targets.
These figures almost certainly do not cover the bootstrap process as I had
to reset the counts as part of call site invalidation, so some bootstrap
processes will have wiped out the earliest stats.
This suggests that in our case it would be well worth ensuring the oldest
target is always first in the chain, and that chain may be worth keeping
in place even once we've passed our the limit for inlining further targets.
It is worth noting that this is all based on a very basic initial cut of
the stats. I'd need to output the raw data and do some number crunching to
check variances etc. on the individual call sites.
On 21/12/2012 15:37, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>On 12/21/2012 04:07 PM, MacGregor, Duncan (GE Energy Management) wrote:
>> Did you ever get a result from this? I haven't got round to
>> instrumentation for our gwt chains that finely, but I'm curious what
>> results you got.
>
>It's still on my TODO list, Java lambda stuff claim most of my time
>devoted to OpenJDK ...
>
>Rémi
now. :-)
On average the oldest targets are called significantly more frequently
than later ones, with the average chain position remaining below 1.5 (0
being the oldest target) up to our standard maximum gwt chain length.
I then significantly increased the maximum length of our chains un to 20,
and the average chain position remains below 3 up to a chain length of 15,
and only starts going significantly above 3 when we hit a length of 18.
Increasing the chain length to 50 (!) showed that even then the average
chain position was approximately 16, so there's still a fairly strong bias
towards older targets.
These figures almost certainly do not cover the bootstrap process as I had
to reset the counts as part of call site invalidation, so some bootstrap
processes will have wiped out the earliest stats.
This suggests that in our case it would be well worth ensuring the oldest
target is always first in the chain, and that chain may be worth keeping
in place even once we've passed our the limit for inlining further targets.
It is worth noting that this is all based on a very basic initial cut of
the stats. I'd need to output the raw data and do some number crunching to
check variances etc. on the individual call sites.
On 21/12/2012 15:37, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>On 12/21/2012 04:07 PM, MacGregor, Duncan (GE Energy Management) wrote:
>> Did you ever get a result from this? I haven't got round to
>> instrumentation for our gwt chains that finely, but I'm curious what
>> results you got.
>
>It's still on my TODO list, Java lambda stuff claim most of my time
>devoted to OpenJDK ...
>
>
>>
>> On 30/11/2012 08:12, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>>
>>> There is a nice article about the JIT that Facebook uses in his HipHop
>>>VM.
>>>
>>>https://www.facebook.com/notes/facebook-engineering/speeding-up-php-base
>>>d-
>>> development-with-hiphop-vm/10151170460698920
>>>
>>> They have an inline cache with several guards and they found that it
>>>was
>>> better from the perf point of view to link the guard by putting the
>>> older first instead of putting the newer first. I wonder if there is
>>>the
>>> same effect for other languages, I will test with Java + a dedicated
>>> indy logic with week end.
>>>
>>> Rémi
>>
>> On 30/11/2012 08:12, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>>
>>> There is a nice article about the JIT that Facebook uses in his HipHop
>>>VM.
>>>
>>>https://www.facebook.com/notes/facebook-engineering/speeding-up-php-base
>>>d-
>>> development-with-hiphop-vm/10151170460698920
>>>
>>> They have an inline cache with several guards and they found that it
>>>was
>>> better from the perf point of view to link the guard by putting the
>>> older first instead of putting the newer first. I wonder if there is
>>>the
>>> same effect for other languages, I will test with Java + a dedicated
>>> indy logic with week end.
>>>
MacGregor, Duncan (GE Energy Management)
Dec 21, 2012, 12:52:26 PM12/21/12
to jvm-la...@googlegroups.com
Oh, and this is all stats for our language, Magik, running a single
application, but most of the code is core to many other apps so the
results should hold true.
On 21/12/2012 17:40, "MacGregor, Duncan (GE Energy Management)"
application, but most of the code is core to many other apps so the
results should hold true.
On 21/12/2012 17:40, "MacGregor, Duncan (GE Energy Management)"
MacGregor, Duncan (GE Energy Management)
Dec 23, 2012, 1:05:43 PM12/23/12
to jvm-la...@googlegroups.com
So based on the stats I gathered I've turned round the cache ordering of
normal call sites and set our max_chain length to 3 (and made it settable
via a system property). This has made several benchmarks involving core
arrays classes over twice as fast. I do see a little slowdown on tests
that push many classes through call sites with equal probability, but
that's to be expected since I'm now keeping the PIC in place.
Overall it's made the benchmark suite 8% faster, and seems to have
improved had a small but good effect on some application performance tests.
I'd better add some instrumentation to our binary operator call sites,
they may also benefit from oldest first ordering on the PIC.
normal call sites and set our max_chain length to 3 (and made it settable
via a system property). This has made several benchmarks involving core
arrays classes over twice as fast. I do see a little slowdown on tests
that push many classes through call sites with equal probability, but
that's to be expected since I'm now keeping the PIC in place.
Overall it's made the benchmark suite 8% faster, and seems to have
improved had a small but good effect on some application performance tests.
I'd better add some instrumentation to our binary operator call sites,
they may also benefit from oldest first ordering on the PIC.
>On 12/21/2012 04:07 PM, MacGregor, Duncan (GE Energy Management) wrote:
>> Did you ever get a result from this? I haven't got round to
>> instrumentation for our gwt chains that finely, but I'm curious what
>> results you got.
>
>It's still on my TODO list, Java lambda stuff claim most of my time
>devoted to OpenJDK ...
>
>Rémi
>> Did you ever get a result from this? I haven't got round to
>> instrumentation for our gwt chains that finely, but I'm curious what
>> results you got.
>
>It's still on my TODO list, Java lambda stuff claim most of my time
>devoted to OpenJDK ...
>
>
>>
>> On 30/11/2012 08:12, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>>
>>> There is a nice article about the JIT that Facebook uses in his HipHop
>>>VM.
>>>
>>>https://www.facebook.com/notes/facebook-engineering/speeding-up-php-base
>>>d-
>>> development-with-hiphop-vm/10151170460698920
>>>
>>> They have an inline cache with several guards and they found that it
>>>was
>>> better from the perf point of view to link the guard by putting the
>>> older first instead of putting the newer first. I wonder if there is
>>>the
>>> same effect for other languages, I will test with Java + a dedicated
>>> indy logic with week end.
>>>
>>> Rémi
>>
>> On 30/11/2012 08:12, "Remi Forax" <fo...@univ-mlv.fr> wrote:
>>
>>> There is a nice article about the JIT that Facebook uses in his HipHop
>>>VM.
>>>
>>>https://www.facebook.com/notes/facebook-engineering/speeding-up-php-base
>>>d-
>>> development-with-hiphop-vm/10151170460698920
>>>
>>> They have an inline cache with several guards and they found that it
>>>was
>>> better from the perf point of view to link the guard by putting the
>>> older first instead of putting the newer first. I wonder if there is
>>>the
>>> same effect for other languages, I will test with Java + a dedicated
>>> indy logic with week end.
>>>
Reply all
Reply to author
Forward
0 new messages