<br><br><div class="gmail_quote">On Thu, Feb 9, 2012 at 8:32 AM, Lawson English <span dir="ltr">&lt;<a href="mailto:lenglish5@cox.net">lenglish5@cox.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 <br>
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    On 2/8/12 5:41 PM, Eliot Miranda wrote:
    <blockquote type="cite">
      <pre> </pre>
      <br>
      <fieldset></fieldset>
      <br>
      <div>this is well written, relatively short, and extremely
        informative.</div>
      <div><br>
      </div>
      <a href="http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time" target="_blank">http://tratt.net/laurie/tech_articles/articles/fast_enough_vms_in_fast_enough_time</a><br clear="all">
      <div><br>
      </div>
      <div>thanks to Bob  Westergaard for pointing it out to me. </div>
      <div>-- <br>
      </div>
    </blockquote>
    <br>
    Eliot, do you have plans to recreate the functionality of RPython to
    auto-generate JITs for other languages?<br></div></blockquote><div><br></div><div>No.  This article confirmed David Simmons&#39; conclusions as to the potential performance of tracing JITs, i.e. that they produce excellent performance for micro-benchmarks but overall perform poorly.  Here are some key quotes:</div>
<div><br></div><div>&quot;<span class="Apple-style-span" style="font-family:Times;font-size:medium">It&#39;s clear that, in general, an RPython VM won&#39;t reach the performance of something like HotSpot, which has several advantages: the overall better performance of method-based JITs; the fact that it&#39;s hand-coded for one specific class of languages; and the sheer amount of effort put into it. But I&#39;d certainly expect RPython VMs to get to comfortably within an order of magnitude performance levels as HotSpot. Time will tell, and as people write RPython VMs for languages like Java, we&#39;ll have better points of comparison.&quot;</span></div>
<div><br></div><div>&quot;<span class="Apple-style-span" style="font-family:Times;font-size:medium">Tracing JITs are relatively new and have some limitations, at least based on what we currently know. Mozilla, for example, <a href="http://blog.mozilla.com/nnethercote/2011/11/23/memshrink-progress-report-week-23/">removed their tracing JIT</a> a few months back, because <a href="http://blog.mozilla.com/nnethercote/2011/05/31/you-lose-more-when-slow-than-you-gain-when-fast/">while it&#39;s sometimes blazingly fast, it&#39;s sometimes rather slow</a>. This is due to a tracing JIT optimising a single code-path at a time: if a guard fails, execution falls back to the (very slow) tracing interpreter for the remainder of that bytecode (which could be quite long), and then back to the language interpreter for subsequent bytecodes. Code which tends to take the same path time after time benefits hugely from tracing; code which tends to branch unpredictably can take considerable time to derive noticeable benefits from the JIT.&quot;</span></div>
<div><br></div><div>My own preferred direction remains to add adaptive optimization to Cog, after improving the object representation.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
    <br>
    L.<br>
  </div>

<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>