<div dir="auto">Tobias,<div dir="auto"><br></div><div dir="auto">That's excellent to know... I wasn't aware that this was being looked at.  Something that's been in the back of my mind for a while is trying to measure JIT performance vs. JIT code cache size, architecture being run on, and workload.  As I understand it, the JIT code cache is a fixed size (~1meg iirc) which doesn't make a lot of sense to me given the variance in CPU cache size (generally in the range of 512k-4m depending on whether you're running on Intel/AMD/ARM, desktop/server, low/high end, HT enabled/disabled, and oddball/extreme CPU configurations like the Intel 5775C with it's 128meg LLC) and then there's the cost of potentially thrashing the JIT cache vs maintaining a larger cache despite the fact that it might exceed the capacity of the CPU cache. (However to measure this I think a few new VM params would be needed: a r/w JIT cache size, JIT cache code evictions (since last full gc?), JIT cache code additions (since last full gc?), Avg cache code size... the current machine code method/compaction counts are a good start but a bit coarse). Just thought I'd throw this out there since it seemed apropos...</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Phil</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018, 5:02 AM Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank" rel="noreferrer">Das.Linux@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Hi Todd,<br>
<br>
> On 20.09.2018, at 10:28, Todd Blanchard <<a href="mailto:tblanchard@mac.com" rel="noreferrer noreferrer" target="_blank">tblanchard@mac.com</a>> wrote:<br>
> <br>
> <br>
> I'm curious if anyone has seen this writeup on VM performance<br>
> <br>
> <a href="https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_our_vms_part_2.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_our_vms_part_2.html</a><br>
> <br>
> I found the article very insightful and was curious how we stacked up.<br>
> <br>
> Have written the author to ask about including us in future research.<br>
> <br>
> Cheers.<br>
> -Todd Blanchard<br>
> <br>
<br>
I know the author  and share similar concerns.<br>
In fact, for stuff we do here with RSqueak/VM and GraalSqueak, we pay attention to at least some of the concerns Laurie mentions.<br>
<br>
Have a look at SMark, which tries to give a reasonable benchmark set set.<br>
<br>
<a href="http://smalltalkhub.com/#!/~StefanMarr/SMark" rel="noreferrer noreferrer noreferrer" target="_blank">http://smalltalkhub.com/#!/~StefanMarr/SMark</a><br>
<br>
also, there's our benchmark runner that builds on SMark<br>
<br>
<a href="http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/BenchmarkRunner.html" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/BenchmarkRunner.html</a><br>
<br>
<br>
We also have a codespeed up here: <a href="http://speed.squeak.org/" rel="noreferrer noreferrer noreferrer" target="_blank">http://speed.squeak.org/</a><br>
<br>
Yea that does not all address the authors issues, but we try :D<br>
<br>
Best regards<br>
        -Tobias<br>
<br>
</blockquote></div>