Crash Course In Modern Hardware
in [Java Help]
|
Prev: Code and Creation 04972
Next: Create grid
From: Roedy Green on 18 Jan 2010 23:41 On Mon, 18 Jan 2010 18:44:45 -0800, Patricia Shanahan <pats(a)acm.org> wrote, quoted or indirectly quoted someone who said : >How would you implement an interpreter to avoid executing a totally >unpredictable branch for each instruction? In my Forth interpreter, I arranged things so that branches fell through on the usual case. Think in terms of FORTH chips, that have the interpreter in hardware. They can do things like maintain branch history, and overlap RET on any instruction. A Java Byte code machine with most of the interpreter in hardware might be a better architecture since the code is so much more compact. -- Roedy Green Canadian Mind Products http://mindprod.com I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one�s contributions to computer science. ~ Donald Ervin Knuth (born: 1938-01-10 age: 72)
From: Roedy Green on 19 Jan 2010 00:01 On 18 Jan 2010 22:10:36 GMT, Thomas Pornin <pornin(a)bolet.org> wrote, quoted or indirectly quoted someone who said : >L1 cache is more in the 32-64KB range. Basically 32 KB for a Core2 >Intel, 64 KB for the AMD equivalent. That's for code; you have the >same amount in data. This suggests the CPU makers should make simpler CPUs, and turn the real estate over to a bigger cache, or focus all the smarts in the CPU on carrying on while a load is stalled. Perhaps it is a marketing problem. People don't realised the value of extra static RAM cache. They go for incremental Ghz numbers. -- Roedy Green Canadian Mind Products http://mindprod.com I decry the current tendency to seek patents on algorithms. There are better ways to earn a living than to prevent other people from making use of one�s contributions to computer science. ~ Donald Ervin Knuth (born: 1938-01-10 age: 72)
From: Lew on 19 Jan 2010 00:22 Roedy Green wrote: > It has to do some pretty fancy footwork. It has to UN-inline all that > code, turn it back into byte code, then rejit it. > ... > I love to see a webinar on how they pulled this off. Perhaps the JIT > machine code is quite constrained to make this possible. They never lose the bytecode, so they don't have to "turn it back" at all; it's already there. The clever thing they did was let it happen in mid-stroke on the stack, that is, even in the midst of a loop it can jump back to the interpreted version or to a newly-compiled version. If the latter, the new compilation occurs in the background from the never-erased and therefore never-needs-to-be-reconstructed bytecode just like the original one did. The same quick-jump trick moves execution from the interpreted or previously-compiled version to the new one. The links I provided upthread touch on this feature. -- Lew
From: Dacong Yan on 19 Jan 2010 00:26 Lew wrote: > Lew wrote: >>> Hotspot runs bytecode altogether, at first (JNI excluded from >>> consideration here). Based on actual runtime heuristics, it might >>> convert some parts to native code and run the compiled version. As >>> execution progresses, Hotspot may revert compiled parts back to >>> interpreted bytecode, depending on runtime situations. > > Arne Vajhøj wrote: >> Nothing in any spec prevents it from doing so, but I am skeptical >> about whether any implementations would do so. > > Well, either Sun is a bunch of big, fat liars, or you can set your > skepticism aside: > <http://java.sun.com/products/hotspot/whitepaper.html#dynamic> > "Both the Java HotSpot Client and Server compilers fully support dynamic > deoptimization." > >> If it actually has spend time JIT compiling why should it go >> back to interpreting? > > Some of the reasoning is explained in > <http://java.sun.com/products/hotspot/whitepaper.html#3> > > There's more detail in > <http://java.sun.com/products/hotspot/docs/general/hs2.html> > "The Java HotSpot Server VM can revert to using the interpreter whenever > compiler deoptimizations are called for because of dynamic class > loading. When a class is loaded dynamically, HotSpot checks to ensure > that the inter-class dependecies [sic] of inlined methods have not been > altered. If any dependencies are affected by dynamically loaded class > [sic], HotSpot can back out affected inlined code, revert to > interpreting for a while, and re-optimize later based on the new class > dependencies." > > One of my favorite experts, Brian Goetz, wrote about this back in 2004: > <http://www.ibm.com/developerworks/library/j-jtp12214/> > "[T]he JVM continues profiling, and may recompile the code again later > with a higher level of optimization if it decides the code path is > particularly hot or future profiling data suggests opportunities for > additional optimization. The JVM may recompile the same bytecodes many > times in a single application execution." > > and later, discussing inlining, > "... the JVM can figure this out, and will invalidate the generated code > that is based on the now-invalid assumption and revert to interpretation > (or recompile the invalidated code path)." > > Despite your skepticism, not only has one (in fact, the) implementation > done dynamic reversion to interpreted bytecode, but it's been doing so > for quite some years. > The Brian Goetz article is quite good. I really learned something from it. Thanks, Lew! And btw, besides Brian Goetz, what other experts do you have in mind can help people understand JIT compiling? Tony
From: Peter Duniho on 19 Jan 2010 03:16
Arne Vajh�j wrote: > SMT capability is obviously not as fast as full cores. It's not even close. > But given that most of the major server CPU's (Xeon, Power and SPARC) > uses the technique, then there seems to be agreement that it is a good > thing. No one is going to say "you know, that 10% improvement in performance you're offering for free, I won't take it". My point is that hyperthreading requires careful usage, and is not a defense against locality issues. I never said it couldn't be useful. Pete |