Difference between revisions of "Scratchpad"
m (a few spelling fixes) | m (more direct links to spill & fill) | ||
| Line 8: | Line 8: | ||
Just as the number of belt locations the size of the scratchpad is [[specification|family member]] dependent. It is used purely for temporary [[frame]] local values. In fact the [[specializer]] must explicitly reserve the amount of store positions needed by every frame. If the size of the scratchpad is exceeded anyway during operation, the [[spiller]] transparently manages the shuffling of those values into the spill buffer and eventually into system memory, into the specially protected spiller [[turf]] if needed. This doesn't pollute the caches and preserves value [[metadata]]. It is also much more efficient than the normal caches, since the lifetime and usage of those values is normally completely and statically determined at compile time. The normal caches are built to deal with more unpredictable access patterns. | Just as the number of belt locations the size of the scratchpad is [[specification|family member]] dependent. It is used purely for temporary [[frame]] local values. In fact the [[specializer]] must explicitly reserve the amount of store positions needed by every frame. If the size of the scratchpad is exceeded anyway during operation, the [[spiller]] transparently manages the shuffling of those values into the spill buffer and eventually into system memory, into the specially protected spiller [[turf]] if needed. This doesn't pollute the caches and preserves value [[metadata]]. It is also much more efficient than the normal caches, since the lifetime and usage of those values is normally completely and statically determined at compile time. The normal caches are built to deal with more unpredictable access patterns. | ||
| − | The operation for putting a value into the scratchpad is called [[ | + | The operation for putting a value into the scratchpad is called [[Instruction_Set/spill|spill]], and the instruction to retrieve it again is called [[Instruction_Set/fill|fill]]. |
All three operations mentioned here are on the [[flow]] side of processing [[Slot|slots]], and they are also only known to the [[specializer]] for the final machine code. The compilers have no use for it, since they don't know the final machine configurations the code will run on, and these operation only make sense and can be used at all if you have and know the exact hardware limits. It must be the specializer that decides on a case by case basis whether to promote or to spill and fill a value. The case for normal load and store is more clear cut, those are more permanent or more complex data structures. | All three operations mentioned here are on the [[flow]] side of processing [[Slot|slots]], and they are also only known to the [[specializer]] for the final machine code. The compilers have no use for it, since they don't know the final machine configurations the code will run on, and these operation only make sense and can be used at all if you have and know the exact hardware limits. It must be the specializer that decides on a case by case basis whether to promote or to spill and fill a value. The case for normal load and store is more clear cut, those are more permanent or more complex data structures. | ||
This was one of the main motivation behind creating the scratchpad, too: to make most memory accesses for temporary data obsolete. | This was one of the main motivation behind creating the scratchpad, too: to make most memory accesses for temporary data obsolete. | ||
Revision as of 20:02, 9 June 2015
The scratchpad is an on chip overflow buffer for values that need to be readily accessible, but would fall off the end of the belt.
As has been described in the belt page, values on the belt are immutable and fall off the end as new values are added to the front. Not always, i.e. in 5-10% of the cases the value produced in some operation can not be immediately used as an operand for the next operation, or sometimes it needs to be used again in the near future.
In that situation there are several things you can do:
You can do a normal store to memory, going through the cache hierarchy and then do a load again later, but this is kind of a waste, potentially very slow and is one of the major sources of cache pollution in on traditional processory. It also loses all metadata information of the value.
You could just move the value to the front of the belt again to give it some additional life, when it really is just a short delay. In fact such a facility exists with promote operation.
Or you could cache the value for a brief time in a dedicated buffer. And this buffer is called Scratchpad.
Just as the number of belt locations the size of the scratchpad is family member dependent. It is used purely for temporary frame local values. In fact the specializer must explicitly reserve the amount of store positions needed by every frame. If the size of the scratchpad is exceeded anyway during operation, the spiller transparently manages the shuffling of those values into the spill buffer and eventually into system memory, into the specially protected spiller turf if needed. This doesn't pollute the caches and preserves value metadata. It is also much more efficient than the normal caches, since the lifetime and usage of those values is normally completely and statically determined at compile time. The normal caches are built to deal with more unpredictable access patterns. The operation for putting a value into the scratchpad is called spill, and the instruction to retrieve it again is called fill.
All three operations mentioned here are on the flow side of processing slots, and they are also only known to the specializer for the final machine code. The compilers have no use for it, since they don't know the final machine configurations the code will run on, and these operation only make sense and can be used at all if you have and know the exact hardware limits. It must be the specializer that decides on a case by case basis whether to promote or to spill and fill a value. The case for normal load and store is more clear cut, those are more permanent or more complex data structures.
This was one of the main motivation behind creating the scratchpad, too: to make most memory accesses for temporary data obsolete.
