Editing Dhrystone (section)

==Shortcomings==
Using Dhrystone as a benchmark has pitfalls: 
* It features unusual code that is not usually representative of modern real-life programs.<ref name="Weiss">{{cite web
| url=https://johnloomis.org/NiosII/dhrystone/ECLDhrystoneWhitePaper.pdf
| title=Dhrystone Benchmark: History, Analysis, "Scores" and Recommendations
| first=Alan
| last=Weiss
| url-status=live
| archive-url=https://web.archive.org/web/20110726210001/http://www.johnloomis.org/NiosII/dhrystone/ECLDhrystoneWhitePaper.pdf
| archive-date=2011-07-26
| access-date=2020-04-28}}</ref>
* It is susceptible to compiler optimizations. For example, it does a lot of string copying in an attempt to measure string copying performance. However, the strings in Dhrystone are of known constant length and their starts are aligned on natural boundaries, two characteristics usually absent from real programs. Therefore, an optimizer can replace a string copy with a sequence of word moves without any loops, which will be much faster. This optimization consequently overstates system performance, sometimes by more than 30%.<ref>{{Cite book|last=Franco Zappa|title=Microcontrollers: Hardware and Firmware for 8-bit and 32-bit devices|publisher=Società Editrice Esculapio|year=2017|isbn=978-88-9385-022-3|pages=66}}</ref>
* Dhrystone's small code size may fit in the [[instruction cache]] of a modern CPU, so that [[instruction fetch]] performance is not rigorously tested.<ref name="Weiss" /> Similarly, Dhrystone may also fit completely in the [[data cache]], thus not exercising data cache miss performance.  To counter fits-in-the-cache problem, the [[SPECint]] benchmark was created in 1988 to include a suite of (initially 8) much larger programs (including a compiler) which could not fit into L1 or L2 caches of that era.