The IA-32 Execution Layer (IA-32 EL) is a software emulator in the form of a software driver that improves performance of 32-bit applications running on 64-bit Intel Itanium -based systems, particularly those running Linux and Windows Server 2003 (it is included in Windows Server 2003 SP1 and later and in most Linux distributions for Itanium). The IA-32 EL bypasses the slow x86 hardware emulation which is available on pre- Montecito Itanium models.
9-426: The IA-32 EL used a two-phase (later three-phase) approach: initially it quickly translated every piece of code at a basic block level, adding certain instrumentation for detecting hot code ; then hot code was dynamically optimized at a super-block level, and the optimized translated code replaced cold code on the fly. Later interpretation engine was added that allowed to avoid altogether translation of code executed just
18-399: A jump trace in an interview for Dr. Dobb's Journal in 1996, saying: In the '60s, someone invented the concept of a 'jump trace'. This was a way of altering the machine language of a program so it would change the next branch or jump instruction to retain control, so you could execute the program at fairly high speed instead of interpreting each instruction one at a time and record in
27-537: A few times - cold non-optimized translation became thus the second phase, and hot optimized translation became the third phase. IA-32 Execution Layer supported self-modifying code , and could even optimize it quite well. Part of the software is under the LGPL and part is under an Intel proprietary license. This emulation -related article is a stub . You can help Misplaced Pages by expanding it . Hot spot (computer programming) A hot spot in computer science
36-407: A file just where a program diverged from sequentiality. By processing this file you could figure out where the program was spending most of its time. So the first day we had this software running, we applied it to our Fortran compiler supplied by, I suppose it was in those days, Control Data Corporation . We found out it was spending 87 percent of its time reading comments ! The reason was that it
45-408: A printed program listing (with counts and/or percentages of total instruction path length ) or a separate report, showing precisely where the highest number of instructions took place. This only provides a relative view of hot spots (from an instruction step perspective) since most instructions have different timings on many machines. It nevertheless provides a measure of highly used code and one that
54-402: Is most usually defined as a region of a computer program where a high proportion of executed instructions occur or where most time is spent during the program's execution (not necessarily the same thing since some instructions are faster than others). If a program is interrupted randomly, the program counter (the pointer to the next instruction to be executed) is frequently found to contain
63-406: The "genuine" hot spots in the translation. If no hot spot detection had taken place at all, the program may well have consumed vastly more resources than necessary, possibly for many years on numerous machines, without anyone ever being fully aware of this. An instruction set simulator can be used to count each time a particular instruction is executed and later produce either an on-screen display,
72-476: The address of an instruction within a certain range, possibly indicating code that is in need of optimization or even indicating the existence of a 'tight' CPU loop . This simple technique can detect highly used instructions, although more-sophisticated methods, such as instruction set simulators or performance analyzers , achieve this more accurately and consistently. The computer scientist Donald Knuth described his first encounter with what he refers to as
81-446: Was translating from one code system into another into another. The example above serves to illustrate that effective hot spot detection is often an iterative process and perhaps one that should always be carried out (instead of simply accepting that a program is performing reasonably). After eliminating all extraneous processing (just by removing all the embedded comments for instance), a new runtime analysis would more accurately detect
#67932