Oliver said:
mei said:
Oliver Wong a écrit :
[...]
additionally, it also knows the exact behaviour of the user using the
program. Because it's performing the translation while the user is using
it!
Waow, this machine learning thing sounds pretty interesting.
Do you have pointers to additional documentations about that?
Do you know about the payload of those functionalities?
Calling it "machine learning" is a bit of a stretch. I don't have any
specifications handy, but if you're really interested, google for "Java
hotspot". Here's a relevant snippet from the Wikipedia article:
http://en.wikipedia.org/wiki/HotSpot
<quote>
Its name derives from the fact that as it runs Java byte-code, it
continually analyzes the program's performance for "hot spots" which are
frequently or repeatedly executed. These are then targeted for optimization,
leading to high performance execution with a minimum of overhead for less
performance-critical code. HotSpot is widely acclaimed as providing the best
performance in its class of JVM. In theory, though rarely in practice, it is
possible for adaptive optimization of a JVM to exceed hand coded C++ or
assembly language.
</quote>
"it is possible for adaptive optimization of a JVM to exceed hand coded
C++ or assembly language."
If Wikipedia says it, it must be true.
For human values of "hand-coded", it is at least anecdotally true. I
think I have already mentioned that Horstmann and Cornell report that a
straightforward Java Bitset implementation of the Sieve of Eratosthenes
ran faster than an apparently equivalent C++ version, even when they
hand-optimized the C++ Bitset template.
On modern, highly pipelined architectures, it is harder and harder for
humans to write truly optimized assembler. (The entire RISC concept
started from the assumption that no one /does/ write assembler, apart
from boot code, first-level interrupt handlers and the like.)
There is one other advantage of HotSpot and similar designs. Although
architectures nowadays last much longer than they did in the 1944-1964
era, they are not stable in another sense. The zArchitecture, for
example, still contains all the problem-state instructions of the S/360,
but, with the exception of the packed-decimal instructions (of which
there are fewer than a dozen), nearly every one of the original S/360
instructions has a replacement -- or two or three or four -- available,
to implement 64-bit mode, to implement IEEE floating point, to handle
Unicode, and to point the architecture in a more RISC-like direction.
Every year or two, new instructions turn up in the Principle of
Operations manual. As a result, the current z/OS PL/I compiler (for
example) includes a compiler switch for eight different architectural
levels, /all/ of which apply to machines no older than the mid-90's. In
fact, it has two separate options: the minimum architecture needed to
run the program, and the architecture to be optimized for, which, of
course, must not be less than the minimum architecture. That's 36
possible combinations! The zSeries may be an extreme case, but it is not
alone; no architecture remains the same for long.
But this need not be a problem for an engine of the HotSpot type,
because it always knows what architecture to use and to optimize for. I
don't know whether HotSpot currently takes advantage of this, but it could.
