Hot spot (computer programming): Difference between revisions

Revision as of 16:25, 27 January 2015

Latest revision as of 16:21, 13 January 2024

(5 intermediate revisions by 5 users not shown)

Line 1:

{{Other uses|Hotspot (disambiguation)#Computing}}

{{refimproveMore citations needed|date=May 2009}}

A '''hot spot''' in [[computer science]] 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 stoppedinterrupted randomly, the [[program counter]] (the [[pointer (computer programming)|pointer]] to the next instruction to be executed) is frequently found to contain 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]] [[Programloop loop(computing)|loop]]. This simple technique can actually be used as a method of detectingdetect highly used instructions, although somewhat more -sophisticated methods, such as [[instruction set simulator]]s or [[Profilingprofiling (computer programming)|performance analyzers]], achieve this more accurately and consistently.

==History of hot spot detection==

The [[computer science|computer scientist]] [[Donald Knuth]] described his first encounter with what he refers to as a ''jump trace'' in an interview for ''[[Dr. Dobb's Journal]]'' in 1996, saying:

<blockquote>In the '60s, someone invented the concept of a 'jump trace'. This was a way of altering the [[machine code|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 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 [[Commentcomment (computer programming)|comments]]! The reason was that it was translating from one code system into another into another.<ref>[http://www.ntg.nl/maps/16/14.pdf Jack Woehr: An interview with Donald Knuth, April 1996.]</ref></blockquote>

===Iteration===

The example above serves to illustrate that effective hot spot detection is often an [[Iterationiteration|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 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.

==Instruction set simulation as a hot spot detector==

An [[instruction set simulator]] can be used to count each time a particular instruction is executed and later produce either an on-screen display, 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 is quite useful in itself when tuning an algorithm.

==See also==

* [[Profiling (computer programming)]]

==References==

{{Reflist}}

{{DEFAULTSORT:Hot Spot (Computer Science)}}

[[Category:Software optimization]]