CN107844511B - Game resource caching method and system based on cycle cost - Google Patents
Game resource caching method and system based on cycle cost Download PDFInfo
- Publication number
- CN107844511B CN107844511B CN201710457845.7A CN201710457845A CN107844511B CN 107844511 B CN107844511 B CN 107844511B CN 201710457845 A CN201710457845 A CN 201710457845A CN 107844511 B CN107844511 B CN 107844511B
- Authority
- CN
- China
- Prior art keywords
- page
- cost
- life cycle
- cache
- calculating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
- G06F12/123—Replacement control using replacement algorithms with age lists, e.g. queue, most recently used [MRU] list or least recently used [LRU] list
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
- G06F12/126—Replacement control using replacement algorithms with special data handling, e.g. priority of data or instructions, handling errors or pinning
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/12—Replacement control
- G06F12/121—Replacement control using replacement algorithms
- G06F12/128—Replacement control using replacement algorithms adapted to multidimensional cache systems, e.g. set-associative, multicache, multiset or multilevel
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/10—Providing a specific technical effect
- G06F2212/1016—Performance improvement
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/15—Use in a specific computing environment
- G06F2212/154—Networked environment
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Image Generation (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Abstract
The technical scheme of the invention comprises a game resource caching method and a game resource caching system based on cycle cost, which are used for realizing that: acquiring page data newly added into a cache according to a main memory request, creating a one-dimensional array in each page data, and customizing a first integer variable; recording the corresponding identification in a first integer variable when the page data is used or not used each time, and calculating the life cycle percentage of the page; calculating relative costs of the different types of page data using a second integer variable; and when a newly added page is added, traversing the life cycle percentage and the relative cost of all the pages in the cache, calculating the jitter cost when the page is replaced, and replacing the page with the jitter cost lower than a specified threshold value with the newly added page. The invention has the beneficial effects that: the development cycle of a game system is shortened, the maintainability and reusability of codes are enhanced, and the running stability, the rendering efficiency and the effect expression of the game are enhanced.
Description
Technical Field
The invention relates to a game resource caching method and system based on cycle cost, and belongs to the field of computer game data processing.
Background
Most game software suffers from a lack of memory, and in games with limited memory, custom resource caching is used to expand the amount of scene data while using only a small memory area rather than loading all resources into memory at once. When using a cache system, the most important factors are: when the cache fill reaches its upper limit, the appropriate replacement page is selected to empty. The choice of page replacement algorithm is crucial when cache misses — this choice is directly related to the performance and efficiency of the game's hardware memory usage. Bad algorithms often destroy the performance of the game, and well-implemented algorithms can improve the game quality by times without affecting the performance of the algorithms. Popular cache replacement algorithms work well in their target environment, but they tend to be inefficient in situations where more data is needed to accurately select replacement pages.
When data is requested from main memory, the operating system places the read data into a temporary memory area (called a cache or cache) that can be accessed at a faster rate than main memory. The cache itself has a predefined size that is partitioned into smaller sets of memory called pages. When the memory is accessed, the cache itself is filled, and the operating system must select a page from the cache to store the new page data. This condition is referred to as a cache miss. When the number of pages needed greatly exceeds the size of the buffer (typically 2 times or more), buffer thrashing occurs, i.e. the entire buffer is discarded in order to make room for the entire new data set. Buffer jitter is considered to be the worst case for any buffer algorithm and is also the focus of any buffer replacement performance test.
The memory handler has associated consumption each time it wants to retrieve information from main memory. Typically, the read from cache is less consumed because additional memory chips are employed, close to the processor itself. Thus, in the event of a cache miss, one of the main goals in deciding which page of memory to flush is: a page is selected that does not require a valid slot in the cache. For example, if a page is randomly selected for deletion during the course of a failure, but is needed just immediately after the page is deleted, this will incur another performance overhead of retrieving data from main memory. The goal is to build an algorithm that best describes the ideal pages to delete from the cache to reduce cache misses and performance burden.
In game development, programmers must deal with the caching of the hardware and software layers, especially in the field of gaming machines, and there is a constant effort by programmers to increase game content while also meeting memory constraints. As with many other replacement algorithms tailored to solve a particular problem, some common gaming and graphics systems require a replacement system that is more similar to the memory and usage modes.
Disclosure of Invention
Aiming at the defects of the prior art, the current situation and the caused reasons of the realization of a common game resource cache system are deeply analyzed, and the characteristics of logic and data on which processes are analyzed and which reusable components with small granularity are analyzed.
The technical scheme of the invention comprises a game resource caching method based on cycle cost, which is characterized by comprising the following steps: A. acquiring page data newly added into a cache according to a main memory request, creating a one-dimensional array in each page data, and creating and initializing a corresponding self-defined first integer variable in the array; B. recording the corresponding identification in a first integer variable when the page data is used or not used each time, and calculating the life cycle percentage of the page; C. calculating relative costs of the different types of page data using a second integer variable; D. and when a newly added page is added, traversing the life cycle percentage and the relative cost of all the pages in the cache, calculating the jitter cost when the page is replaced according to the life cycle percentage and the relative cost, and replacing the page with the jitter cost lower than the specified threshold value with the newly added page.
According to the game resource caching method based on the cycle cost, the method further comprises the following steps: the one-dimensional array is stored in the opened cache space, and the cache space can be added and deleted in a user-defined mode.
According to the game resource caching method based on the cycle cost, the method further comprises the following steps: the first integer variable is a 32-bit integer variable, and the second integer variable is a normal variable and is not limited in size.
According to the game resource caching method based on the cycle cost, the step A further comprises the following steps: loading a specified page to a cache space according to a main memory request, recording the type, the size and the loading time of page data, creating a corresponding 32-bit integer variable on the page and initializing the variable to 1, wherein the identification bit is 1.
According to the game resource caching method based on the cycle cost, the step B further includes: s51, shifting the identification bit of the first integer variable to the left at fixed time intervals when the page is used, and recording the new bit as 1, and shifting the identification bit of the first integer variable to the left when the page is not used, and recording the new bit as 0; and S52, calculating the life cycle percentage when the identification position moves left, including obtaining the displacement times and the use times, and calculating the ratio of the use times to the displacement times.
According to the game resource caching method based on the period cost, the relative cost is as follows: the method is obtained by calculating the page data volume corresponding to the game resources and the transmitted page data volume, and correspondingly, the relative cost calculation modes of different game resource data are different.
According to the game resource caching method based on the cycle cost, the step D further comprises the following steps: s71, detecting the life cycle percentage of the game resource data page which is put into the cache and exceeds the preset time quantum, and taking the life cycle percentage as the life cycle percentage cost of each use of the page; s72, creating a temporary storage area for the page exceeding the specified threshold life cycle percentage cost, and executing step S71 in the temporary storage area to check whether the life cycle percentage cost is higher than the specified threshold and the page is not used in a certain time, if so, deleting the corresponding game resource data page.
According to the game resource caching method based on the cycle cost, the step D further comprises the following steps: s81, when a new game resource page is added, acquiring the life cycle percentage cost and the relative cost of all the pages in the cache; s82, calculating the jitter cost generated when replacing the page, when the calculation result is larger than the preset value, keeping the page, if the calculation result is smaller than the preset value, removing the page from the cache, wherein the jitter cost is the product of the life cycle percentage cost and the relative cost; s83, for the pages with the same jitter cost and the jitter cost near the threshold value, preferentially rejecting the pages with the percentage cost of the life cycle.
The technical scheme of the invention also comprises a game resource caching system based on the period cost, which is characterized by comprising the following steps: the page initialization module is used for acquiring page data newly added into the cache according to a main memory request, creating a one-dimensional array in each page data, and creating and initializing a corresponding self-defined first integer variable in the array; the page recording module is used for recording the corresponding identifier in a first integer variable when the page data is used or not used every time, and calculating the life cycle percentage of the page; the cost calculation module is used for calculating the relative cost of the different types of page data by using a second integer variable; and the page replacement module is used for traversing the life cycle percentage and the relative cost of all the pages in the cache when a page is newly added, calculating the jitter cost when the page is replaced according to the life cycle percentage and the relative cost, and replacing the page with the jitter cost lower than the specified threshold value with the newly added page.
The invention has the beneficial effects that: the replacement performance of the cache page is comprehensively increased; lower jitter overhead and cost required to fill the cache; the running stability, the rendering efficiency and the effect performance of the game are enhanced.
Drawings
FIG. 1 illustrates an overall flow diagram according to an embodiment of the invention;
FIG. 2 is a flow chart of texture culling according to an embodiment of the invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention will be described in detail with reference to the accompanying drawings and specific embodiments. The game resource caching method and the game resource caching system with the period cost are suitable for processing game data.
FIG. 1 shows a general flow diagram according to an embodiment of the invention. A. Acquiring page data newly added into a cache according to a main memory request, creating a one-dimensional array in each page data, and creating and initializing a corresponding self-defined first integer variable in the array; B. recording the corresponding identification in a first integer variable when the page data is used or not used each time, and calculating the life cycle percentage of the page; C. calculating relative costs of the different types of page data using a second integer variable; D. and when a newly added page is added, traversing the life cycle percentage and the relative cost of all the pages in the cache, calculating the jitter cost when the page is replaced according to the life cycle percentage and the relative cost, and replacing the page with the jitter cost lower than the specified threshold value with the newly added page.
FIG. 2 is a flow chart of texture culling according to an embodiment of the invention. As shown below
(1) It is convenient to remove old textures, leaving the textures demonstrable that they are needed by the scene. Once this fact is verified, they are retained. Once a lifecycle percentage cost of more than 50% is obtained, it is difficult to free from cache.
(2) A buffer is established. New textures that have not proven to be useful are converted to scratch, which is a good method because new textures tend to be transient and have a higher probability of disappearing in the next frame.
(3) This is a modified recently unused method. In a short time, with higher visible frequency textures, it is easy to jump to 50% of the life cycle percentage cost, but then drop again, and after many frames their life cycle percentage cost slowly drops back. The lifecycle provides a modified representation of the access variables and allows for additional analysis. Thus, if the lifecycle percentage cost is > 60%, but the texture has not been used in the last few frames, then this can be checked and the texture cleared early.
(4) The corresponding old texture is deleted.
The technical scheme of the invention also discloses the following technical characteristics: life cycle and cost index summary, life cycle algorithm and
lifecycle and cost index overview:
when data is requested from main memory, the operating system places the read data into a temporary memory area (called a cache or cache) that can be accessed at a faster rate than main memory. The cache itself has a predefined size that is partitioned into smaller sets of memory called pages. When the memory is accessed, the cache itself is filled, and the operating system must select a page from the cache to store the new page data. This condition is referred to as a cache miss. When the number of pages needed greatly exceeds the size of the buffer (typically 2 times or more), buffer thrashing occurs, i.e. the entire buffer is discarded in order to make room for the entire new data set. Buffer jitter is considered to be the worst case for any buffer algorithm and is also the focus of any buffer replacement performance test.
The memory handler has associated consumption each time it wants to retrieve information from main memory. Typically, the read from cache is less consumed because additional memory chips are employed, close to the processor itself. Thus, in the event of a cache miss, one of the main goals in deciding which page of memory to flush is: a page is selected that does not require a valid slot in the cache. For example, if a page is randomly selected for deletion during the course of a failure, but is needed just immediately after the page is deleted, this will incur another performance overhead of retrieving data from main memory. The goal is to build an algorithm that best describes the ideal pages to delete from the cache to reduce cache misses and performance burden.
In game development, programmers must deal with the caching of the hardware and software layers, especially in the field of gaming machines, and there is a constant effort by programmers to increase game content while also meeting memory constraints. As with many other replacement algorithms tailored to solve a particular problem, some common gaming and graphics systems require a replacement system that is more similar to the memory and usage modes.
The scheme takes a problem faced by most games on the current hardware as an example, and a self-defined texture cache is designed. To do this, the user will keep a static one-dimensional array cache page that can be used to load and unload data. Assuming that the user is using a multi-dimensional texture cache, i.e. the data put in the cache comes from textures, the cache is multi-dimensional because multi-textures of various sizes can be accommodated in a single cache page. For example, if a cache page can accommodate a 256x256 texture, then 4 64x64 textures, 16 32x32 textures, etc. can also be supported, including multiples of each size that can harmoniously exist on the same page.
This simple example shows the basis for the underperformance of the standard replacement function. Considering the case of multidimensional caching, it is necessary to insert a new 256x256 page into a cache that is completely filled with only 32x32 textures. A simple least recently used algorithm scheme does not have the necessary data to properly calculate which cache page is the best replacement page. At the same time, because the access mode is largely more dependent than the time when the page was last replaced, it cannot properly calculate which set of 32x32 textures need to be emptied. Therefore, in this case, in order to better analyze the best replacement page, a new set of replacement indexes is proposed herein.
The life cycle algorithm:
the lifecycle algorithm knows the amount of usage of a page in the cache and replaces the page that will be used the farthest time. Most replacement algorithms emulate this algorithm with various data access patterns as best as possible. To best predict future usage, the lifecycle algorithm models this process by retaining a notion of usage in the previous frames. I.e. it is necessary to know how many times a page has been accessed within a time window. To accomplish this task, each page in the cache holds a 32-bit integer variable that is initialized to the first time a page enters the cache
1(0x00000001)。
For each frame, all active pages in the buffer are shifted left by one bit, marking its depreciation over time. The least significant bit of the life cycle variable is set to 1 if an active page is used in this frame, and to 0 otherwise. This shift and set mode allows a usage assessment to be retained for the past 32 frames.
For example, a page that is used once every two frames will have a life cycle variable OxAAAAAAA (010101010 … 01), while a page that is heavily used at the first load but not used any more later will have a life cycle variable OxFFOOOOOOOOOOOOOOOOO (1111 … 1100000 … 00).
To indicate the change in the life cycle variable over time, consider a page that was used in the first, third, fourth, and eighth frames, in an 8-frame time window. The lifecycle variables will change as follows:
frame 1-00000001 (use)
Frame 2-00000010 (not used)
Frame 3-00000101 (use)
Frame 4 one 00001011 (use)
Frame 5-00010110 (not used)
Frame 6 one 00101100 (not used)
Frame 7 one 01011000 (not used)
Frame 8 one 10110001 (use)
With such a data structure, the lifecycle percentage cost for a given window can be calculated. The average number of frames a page is used and not used is obtained by dividing the number of frames a page is used (number of bits 1) by the total number of frames in the life cycle variable. This data can be compiled and processor heuristically derived without the need for high level code. Although this data can be expressed in its own right, the proposed life cycle percentage cost exists as a single value between (0,1) in unity, as described as part of the "life cycle and cost", which can be a scalar relative to other metrics.
When the life cycle is used to determine the target replacement page, pages that have not been used for a certain period of time, and pages that are generally not used frequently, are selected. For example, a page that is used every frame will have a lifecycle percentage cost of 100% in a time window, which will be almost impossible to replace, while a page with a lifecycle percentage cost of 25% will have a higher chance of being replaced.
Jitter cost:
relative cost is a more important indicator and allows the value to be an integer variable with no upper bound. For example, if texture is continuously transferred from disk to cache, the relative cost value may be the size of the texture divided by the time it takes to continuously transfer a small portion of the texture from the resource. The lifecycle percentage cost is treated as a unitized floating point variable between (0, 1).
The user can combine these two values into a single result, with the lifecycle percentage cost as a scalar to the relative cost, thus making the memory jitter cost the relative cost x lifecycle percentage cost. This is a very good heuristic for identifying appropriate replacement pages. The following are several examples of lifecycle percentage cost/relative cost ratios and descriptions of alternative modes. For the following data, it is assumed that the highest value of relative cost may be 10.
TABLE 1
As seen in table 1 herein, using simple relative cost x lifecycle percentage cost values may result in pages with different lifecycle percentage cost/relative cost values but the same memory jitter cost. This would mean that texture A, which has a lifecycle percent cost/relative cost relationship of 0.5/100, may have the same cost as texture B, which has a lifecycle percent cost/relative cost of 1.0/50. Either of these two pages is a valid target and contains the same potential substitute value weight. Texture a is a relatively high cost and it is more expensive to replace it if it is needed for the next frame. Texture B is lower in cost, but has a 100% life cycle percentage cost value, so there is a high probability that this page will be needed immediately.
Replacing a cost value with a lower life cycle percentage is much more effective when multiple pages return the same value. This is why the life cycle index is to be used. By analyzing usage patterns and costs, it can be seen that while a page is more expensive, it is less used and the probability that it will be erroneously buffered for jitter is lower. In these cases, rescanning the cache to find a page with a higher memory jitter cost and lower life cycle percentage cost value is a good approach.
The technical scheme of the invention further expands the declaration period algorithm and the replacement cost, and specifically comprises the following steps:
extended lifecycle algorithms:
considering two pages (texture a and texture B) loaded into the cache at the same time, texture a is used on 50% of the objects in the scene, while texture B is used on only 10% of the objects. Two pages have the same life cycle percentage cost value, but it can be determined that the two pages have very different numbers of uses. When a replacement page has to be found, it should be taken into account that the fact that texture a is used more times in the current frame increases the probability that it will also be used in the following frame, and therefore the less used texture (texture B) should be replaced. By storing this additional data per frame, additional statistical analysis operations are provided to help determine the best page to purge from cache.
It includes in detail:
(1) the lifecycle percentage cost variable can still be derived from the extended lifecycle algorithm by dividing the number of non-zero frames within the time window by the total number of frames.
(2) Finding the least used page in a given frame window will find the least used page in general, which will help determine the replacement page.
(3) With maximum analysis, the pages that are most visited within the window can be determined to help them avoid being flushed from the cache.
(4) Within the window, finding the average usage is as simple as getting a second simplified variable similar to the percentage cost of the life cycle.
Cost of extended replacement
Most alternative page identification algorithms use only a single heuristic. That is, their algorithms are tailored specifically to the access patterns that result in the fewest cache page misses. For example, the least recently used algorithm retains only the information of the oldest page. However, custom software caches often have a second heuristic involving cache misses — the cost of filling cache pages with new data. For most hardware caches, there is a constant cost. This cost is associated with the memory handler accessing main memory and reading the required data.
However, for gaming software needs, this cost can often fluctuate between pages themselves. Therefore, alternate page identification allows for the performance hit of actually filling a page with a given block of memory to be judicious. This performance consumption (or just consumption) can come from a variety of sources, it can be defined manually with an external data set (e.g., an XML file that defines which textures are actually used), or it can be defined with the actual cost of filling the page.
Larger textures have longer performance times involving putting them into cache because larger textures have more information to transfer from the resource, while smaller or simple textures are only a small fraction of those consumed. In this case, it would be very sensible to consider the costs involved in possibly replacing a page in memory in the replacement page identification process. If the replaced page has a higher associated cost and the next few frames require the page, then unnecessary overhead will result. Conversely, if a lower cost page is replaced, the performance hit of erroneously removing it from the cache is much lower. In summary, let's answer the question "it would be cheaper to clear 5 smaller textures to make 1 large texture free up space? "
The cost may give the user a focus on how reloading a given page into the cache would compromise performance. An extension of this system allows the replacement page identification function to be more concerned about the performance cost of cache misses than the consistency between frames, if desired.
When jitter occurs, the cheapest texture is found and cleared in the buffer. Because there is always one cheap page present, the entire buffer may jitter if the load is large enough. It can leave very expensive pages in the cache indefinitely. This is a good property if something like sky box texture is loaded into the buffer, because the sky box will be active every frame and due to its large size, we are unlikely to want to delete it from the buffer.
By biasing the identification of replacements to the access pattern algorithm with a replacement indicator, the cache is allowed to find a compromise between page replacement requirements and jitter. Furthermore, the identification of access patterns helps to eliminate the problems involved with pure cost indicators, allowing high-cost resources to eventually be purged from the cache when they reach a state where they are no longer needed.
The above description is only a preferred embodiment of the present invention, and the present invention is not limited to the above embodiment, and the present invention shall fall within the protection scope of the present invention as long as the technical effects of the present invention are achieved by the same means. The invention is capable of other modifications and variations in its technical solution and/or its implementation, within the scope of protection of the invention.
Claims (9)
1. A game resource caching method based on cycle cost is characterized by comprising the following steps:
A. acquiring page data newly added into a cache according to a main memory request, creating a one-dimensional array in each page data, and creating and initializing a corresponding self-defined first integer variable in the array;
B. recording the corresponding identification in a first integer variable when the page data is used or not used each time, and calculating the life cycle percentage of the page;
C. calculating relative costs of the different types of page data using a second integer variable;
D. when a page is newly added, traversing the life cycle percentage and the relative cost of all the pages in the cache, calculating the jitter cost when the page is replaced according to the life cycle percentage and the relative cost, and replacing the page with the jitter cost lower than a specified threshold value with the newly added page;
wherein, the step D further comprises:
s71, detecting the life cycle percentage of the game resource data page which is put into the cache and exceeds the preset time quantum, and taking the life cycle percentage as the life cycle percentage cost of each use of the page;
s72, creating a temporary storage area for the page exceeding the specified threshold life cycle percentage cost, and executing step S71 in the temporary storage area to check whether the life cycle percentage cost is higher than the specified threshold and the page is not used in a certain time, if so, deleting the corresponding game resource data page.
2. The periodic cost based game resource caching method according to claim 1, further comprising:
the one-dimensional array is stored in the opened cache space, and the cache space can be added and deleted in a user-defined mode.
3. The periodic cost based game resource caching method according to claim 1, further comprising:
the first integer variable is a 32-bit integer variable, and the second integer variable is a normal variable and is not limited in size.
4. The periodic cost-based game resource caching method according to claim 1 or 3, wherein the step A further comprises:
loading a specified page to a cache space according to a main memory request, recording the type, the size and the loading time of page data, creating a corresponding 32-bit integer variable on the page and initializing the variable to 1, wherein the identification bit is 1.
5. The periodic cost based game resource caching method according to claim 4, wherein the step B further comprises:
s51, shifting the identification bit of the first integer variable to the left at fixed time intervals when the page is used, and recording the new bit as 1, and shifting the identification bit of the first integer variable to the left when the page is not used, and recording the new bit as 0;
and S52, calculating the life cycle percentage when the identification position moves left, including obtaining the displacement times and the use times, and calculating the ratio of the use times to the displacement times.
6. The periodic cost-based game resource caching method according to claim 1, wherein the step B further comprises:
s51, shifting the identification bit of the first integer variable to the left at fixed time intervals when the page is used, and recording the new bit as 1, and shifting the identification bit of the first integer variable to the left when the page is not used, and recording the new bit as 0;
and S52, calculating the life cycle percentage when the identification position moves left, including obtaining the displacement times and the use times, and calculating the ratio of the use times to the displacement times.
7. The periodic cost based game resource caching method according to claim 1, wherein the relative cost is:
the method is obtained by calculating the page data volume corresponding to the game resources and the time for sending the page data volume, and correspondingly, the relative cost calculation modes are different for different game resource data.
8. The periodic cost based game resource caching method according to claim 1, wherein said step D further comprises:
s81, when a new game resource page is added, acquiring the life cycle percentage cost and the relative cost of all the pages in the cache;
s82, calculating the jitter cost generated when replacing the page, when the calculation result is larger than the preset value, keeping the page, if the calculation result is smaller than the preset value, removing the page from the cache, wherein the jitter cost is the product of the life cycle percentage cost and the relative cost;
s83, for the pages with the same jitter cost and the jitter cost near the threshold value, the pages with low percentage cost of life cycle are preferentially rejected.
9. A periodic cost based game resource caching system according to any one of claims 1 to 8, the system comprising:
the page initialization module is used for acquiring page data newly added into the cache according to a main memory request, creating a one-dimensional array in each page data, and creating and initializing a corresponding self-defined first integer variable in the array;
the page recording module is used for recording the corresponding identifier in a first integer variable when the page data is used or not used every time, and calculating the life cycle percentage of the page;
the cost calculation module is used for calculating the relative cost of the different types of page data by using a second integer variable;
and the page replacement module is used for traversing the life cycle percentage and the relative cost of all the pages in the cache when a page is newly added, calculating the jitter cost when the page is replaced according to the life cycle percentage and the relative cost, and replacing the page with the jitter cost lower than the specified threshold value with the newly added page.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710457845.7A CN107844511B (en) | 2017-06-16 | 2017-06-16 | Game resource caching method and system based on cycle cost |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710457845.7A CN107844511B (en) | 2017-06-16 | 2017-06-16 | Game resource caching method and system based on cycle cost |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107844511A CN107844511A (en) | 2018-03-27 |
| CN107844511B true CN107844511B (en) | 2021-08-17 |
Family
ID=61682865
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710457845.7A Active CN107844511B (en) | 2017-06-16 | 2017-06-16 | Game resource caching method and system based on cycle cost |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107844511B (en) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6421766B1 (en) * | 1998-12-16 | 2002-07-16 | Intel Corporation | Method and apparatus for approximated least-recently-used algorithm memory replacement |
| CN1720528A (en) * | 2002-12-03 | 2006-01-11 | R·图利 | Portable Internet access device back page cache |
| CN101398786A (en) * | 2008-09-28 | 2009-04-01 | 东南大学 | Method for implementing controllable cache facing embedded application software |
| CN104715020A (en) * | 2015-02-13 | 2015-06-17 | 腾讯科技（深圳）有限公司 | Cache data deleting method and server |
| CN104822068A (en) * | 2015-04-29 | 2015-08-05 | 四达时代通讯网络技术有限公司 | Streaming media proxy cache replacing method and device |
| CN104991827A (en) * | 2015-06-26 | 2015-10-21 | 季锦诚 | Method for sharing GPU resources in cloud game |
| CN105975402A (en) * | 2016-04-28 | 2016-09-28 | 华中科技大学 | Caching method and system for eliminated data perception in hybrid memory environment |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8943261B2 (en) * | 2011-10-28 | 2015-01-27 | International Business Machines Corporation | Efficient memory management in software caches |
| CN104809237B (en) * | 2015-05-12 | 2018-12-14 | 百度在线网络技术（北京）有限公司 | The optimization method and device of LSM-tree index |
| CN106844075A (en) * | 2015-12-04 | 2017-06-13 | 阿里巴巴集团控股有限公司 | A kind of data transferring method and equipment |
-
2017
- 2017-06-16 CN CN201710457845.7A patent/CN107844511B/en active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6421766B1 (en) * | 1998-12-16 | 2002-07-16 | Intel Corporation | Method and apparatus for approximated least-recently-used algorithm memory replacement |
| CN1720528A (en) * | 2002-12-03 | 2006-01-11 | R·图利 | Portable Internet access device back page cache |
| CN101398786A (en) * | 2008-09-28 | 2009-04-01 | 东南大学 | Method for implementing controllable cache facing embedded application software |
| CN104715020A (en) * | 2015-02-13 | 2015-06-17 | 腾讯科技（深圳）有限公司 | Cache data deleting method and server |
| CN104822068A (en) * | 2015-04-29 | 2015-08-05 | 四达时代通讯网络技术有限公司 | Streaming media proxy cache replacing method and device |
| CN104991827A (en) * | 2015-06-26 | 2015-10-21 | 季锦诚 | Method for sharing GPU resources in cloud game |
| CN105975402A (en) * | 2016-04-28 | 2016-09-28 | 华中科技大学 | Caching method and system for eliminated data perception in hybrid memory environment |
Non-Patent Citations (2)
| Title |
|---|
| Dynamic caching and replacing mechanism for multiple videos over quality of service networks;R.Sivakoumar et al.;《2010 First International Conference on Integrated Intelligent Computing》;IEEE;20100916;296-301 * |
| 最小驻留价值缓存替换算法;刘磊等;《计算机应用》;20130401;第33卷(第4期);1018-1022 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107844511A (en) | 2018-03-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111344684B (en) | Multi-layer cache placement mechanism | |
| CN103440207B (en) | Caching method and caching device | |
| JP4246922B2 (en) | Recent least frequently used replacement method with protection function | |
| US6381676B2 (en) | Cache management for a multi-threaded processor | |
| CN102782683B (en) | Buffer pool extension for database server | |
| US7337201B1 (en) | System and method to increase memory allocation efficiency | |
| US7934058B2 (en) | Predictive caching of assets to improve level load time on a game console | |
| CN108647151A (en) | It is a kind of to dodge system metadata rule method, apparatus, equipment and storage medium entirely | |
| US9971698B2 (en) | Using access-frequency hierarchy for selection of eviction destination | |
| KR101056460B1 (en) | How to Replace Cache Controllers and Cache Blocks | |
| Franey et al. | Tag tables | |
| CN110888600B (en) | Buffer area management method for NAND flash memory | |
| CN110795363B (en) | Hot page prediction method and page scheduling method of storage medium | |
| CN110532200B (en) | Memory system based on hybrid memory architecture | |
| CN103019887A (en) | Data backup method and device | |
| US7752206B2 (en) | Method and data processing system for managing a mass storage system | |
| Ghandeharizadeh et al. | CAMP: A cost adaptive multi-queue eviction policy for key-value stores | |
| CN102542036B (en) | Use the table optimized | |
| CN109144431B (en) | Data block caching method, device, equipment and storage medium | |
| US9336155B2 (en) | Statistical cache promotion | |
| CN106164874B (en) | Method and device for accessing data visitor directory in multi-core system | |
| CN114253458B (en) | Memory page fault exception processing method, device, equipment and storage medium | |
| KR101940382B1 (en) | Prefetching method and apparatus for pages | |
| CN107844511B (en) | Game resource caching method and system based on cycle cost | |
| US20040123039A1 (en) | System and method for adatipvely loading input data into a multi-dimensional clustering table |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address | ||
| CP03 | Change of name, title or address |
Address after: 519000 Room 102, 202, 302 and 402, No. 325, Qiandao Ring Road, Tangjiawan Town, high tech Zone, Zhuhai City, Guangdong Province, Room 102 and 202, No. 327 and Room 302, No. 329 Patentee after: Zhuhai Jinshan Digital Network Technology Co.,Ltd. Patentee after: Guangzhou Xishanju Network Technology Co.,Ltd. Address before: 519000 Jinshan software building, 8 Lanshan lane, Jida Jingshan Hill Road, Zhuhai, Guangdong Patentee before: ZHUHAI KINGSOFT ONLINE GAME TECHNOLOGY Co.,Ltd. Patentee before: GUANGZHOU SEASUN ENTERTAINMENT NETWORK TECHNOLOGY Co.,Ltd. |