Daytripper: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
* No Length-Changing Prefix penalties, as the pre-decode stage has already been passed | * No Length-Changing Prefix penalties, as the pre-decode stage has already been passed | ||
* Reduced front end power consumption, because the instruction cache, BPU and predecode unit can be idle | * Reduced front end power consumption, because the instruction cache, BPU and predecode unit can be idle | ||
Source code can be found at http://github.com/dankamongmen/wdp/tree/master/cs8803dc-project/. | Source code can be found at http://github.com/dankamongmen/wdp/tree/master/cs8803dc-project/. An initial writeup is available [[media:Cs8803dcproject.pdf|here]]. | ||
==Loop Stream Detector== | ==Loop Stream Detector== | ||
| Line 14: | Line 14: | ||
* LSD.UOPS: [[Performance Counters|performance counter]] providing the number of μops delivered by the LSD (introduced on Core i7) | * LSD.UOPS: [[Performance Counters|performance counter]] providing the number of μops delivered by the LSD (introduced on Core i7) | ||
* David Kanter had some [http://realworldtech.com/page.cfm?ArticleID=RWT040208182719 excellent insight]:<blockquote>One of the most interesting things to note about Nehalem is that the LSD is conceptually very similar to a trace cache. The goal of the trace cache was to store decoded uops in dynamic program order, instead of the static compiler ordered x86 instructions stored in the instruction cache, thereby removing the decoder and branch predictor from the critical path and enabling multiple basic blocks to be fetched at once. The problem with the trace cache in the P4 was that it was extremely fragile; when the trace cache missed, it would decode instructions one by one. The hit rate for a normal instruction cache is well above 90%. The trace cache hit rate was extraordinarily low by those standards, rarely exceeding 80% and easily getting as low as 50-60%. In other words, 40-50% of the time, the P4 was behaving exactly like a single issue microprocessor, rather than taking full advantage of [its] execution resources. The LSD buffer achieves almost all the same goals as a trace cache, and when it doesn’t work (i.e. the loop is too big) there are no extremely painful downsides as there were with the P4's trace cache.</blockquote> | * David Kanter had some [http://realworldtech.com/page.cfm?ArticleID=RWT040208182719 excellent insight]:<blockquote>One of the most interesting things to note about Nehalem is that the LSD is conceptually very similar to a trace cache. The goal of the trace cache was to store decoded uops in dynamic program order, instead of the static compiler ordered x86 instructions stored in the instruction cache, thereby removing the decoder and branch predictor from the critical path and enabling multiple basic blocks to be fetched at once. The problem with the trace cache in the P4 was that it was extremely fragile; when the trace cache missed, it would decode instructions one by one. The hit rate for a normal instruction cache is well above 90%. The trace cache hit rate was extraordinarily low by those standards, rarely exceeding 80% and easily getting as low as 50-60%. In other words, 40-50% of the time, the P4 was behaving exactly like a single issue microprocessor, rather than taking full advantage of [its] execution resources. The LSD buffer achieves almost all the same goals as a trace cache, and when it doesn’t work (i.e. the loop is too big) there are no extremely painful downsides as there were with the P4's trace cache.</blockquote> | ||
* [[Ivy Bridge]] allows one logical core to use the full 56-μops cache if the other core is inactive | |||
===Constraints=== | ===Constraints=== | ||
The Loop Stream Detector requires a number of properties from any loop hoping to be cached... | The Loop Stream Detector requires a number of properties from any loop hoping to be cached... | ||
| Line 55: | Line 56: | ||
==History== | ==History== | ||
* daytripper began as a project for Nate Clark's spring 2010 CS8803DC, "Dynamic Translation and Virtual Runtimes" at the Georgia Institute of Technology. | * daytripper began as a project for Nate Clark's spring 2010 CS8803DC, "Dynamic Translation and Virtual Runtimes" at the Georgia Institute of Technology. | ||
** [[media:Cs8803dcproject.pdf|Final project submission]] | |||
* some early notes on [[CybOregonizer|binary translation]] | * some early notes on [[CybOregonizer|binary translation]] | ||