<div class="gmail_quote"><div class="im"><div>Oops, forgot to reply-to-all. This was a minor clarification on Wren's behalf (he can correct me if I'm wrong). But I agree with Bryan that it's time for the thread to die:</div>
<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
> Do bear in mind that Java doesn't optimize ---that's the JIT's job<br><br></div>What are we supposed to make of that?<br><br>Why write that and not -- Do bear in mind that Smalltalk doesn't optimize that's the JIT's job -- or -- Do bear in mind that C doesn't optimize that's the compiler's job.<br>
</blockquote><div><br></div></div><div>I believe this was referring to the fact that javac isn't an aggressive optimizing compiler on the way from source to bytecode, i.e. it's the bytecode->asm leg where the optimization effort is focused. </div>
<div><br></div><div>As an outsider to things Java that's something I've had trouble understanding, actually. It doesn't seem like an either-or choice to me...</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div> -Ryan</div><div><br></div></font></span></div><br><div class="gmail_quote">On Wed, May 23, 2012 at 4:26 PM, Isaac Gouy <span dir="ltr"><<a href="mailto:igouy2@yahoo.com" target="_blank">igouy2@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> From: wren ng thornton <<a href="mailto:wren@freegeek.org">wren@freegeek.org</a>><br>
<br>
</div>> Sent: Tuesday, May 22, 2012 9:30 PM<br>
<br>
-snip-<br>
<div class="im">> FWIW, that matches my expectations pretty well. Naive/standard Java performing<br>
> slower than Smalltalk; highly tweaked Java using non-standard data types<br>
> performing on-par with or somewhat faster than Smalltalk.<br>
<br>
</div>I have no difficulty believing that if you are talking about a 1996 Java reference implementation and a 1996 Smalltalk JIT VM.<br>
<br>
I could believe that if you are comparing a naive Java program with a highly tweaked Smalltalk program.<br>
<div class="im"><br>
<br>
> That C is 7x faster is a bit on the high end, but for something like tsort I could imagine it'd be possible.<br>
<br>
</div>It's possible because it's possible to write a Java program to be slower than it need be :-)<br>
<div class="im"><br>
<br>
> Do bear in mind that Java doesn't optimize ---that's the JIT's job<br>
<br>
</div>What are we supposed to make of that?<br>
<br>
Why write that and not -- Do bear in mind that Smalltalk doesn't optimize that's the JIT's job -- or -- Do bear in mind that C doesn't optimize that's the compiler's job.<br>
<br>
<br>
-snip-<br>
<div class="im">> But even still, in my experience of using Smalltalk, the standard data<br>
> structures are much better done and so they will be on-par with what you'd<br>
> get from hand-tuning for Java. I've spent a lot of time trying to get decent<br>
> performance out of Java, not so much with Smalltalk; but the performance with<br>
> Smalltalk was sufficient that it wasn't needed so badly.<br>
<br>
</div>Do you have a specific example that you can share?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>