Simulator startup acceleration method, device, equipment and storage medium

Abstract

The present application belongs to the field of computer technology and discloses a simulator startup acceleration method, device, equipment and storage medium. The method includes: obtaining a pre-read block set; prioritizing each data block according to an access frequency label to obtain a pre-read block sequence; extracting a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset; performing a pre-read operation on the target pre-read block subset to obtain preloaded data; storing the preloaded data in a cache to generate a preload cache; responding to a simulator startup instruction, reading the preload cache to obtain startup data; initializing the simulator according to the startup data to obtain an initialized simulator environment; and executing a simulator startup process using the initialized simulator environment. The present application can improve the startup speed of the simulator while meeting the user's personalized needs for simulation accuracy.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a simulator startup acceleration method, device, equipment and storage medium. Background Art

[0002] An emulator is a tool that simulates the hardware environment through software, allowing a computer or other device to run game programs from other platforms. It is commonly used in cross-platform porting scenarios. The emulator simulates the hardware processor functions and instruction system of the original platform (such as a game console) through software, allowing the target device (such as a PC or mobile phone) to run the game program without native support.

[0003] The core technical problem faced by the simulator during the startup process is how to achieve fast and efficient startup with limited system resources. Traditional startup methods often require reading a large amount of data from the disk, resulting in large I / O overhead and long startup time, which seriously affects the user experience. At the same time, the simulator startup involves many modules and data, which leads to a contradiction between its simulation accuracy and startup speed. Improving the simulation accuracy often increases the startup burden, and different users have different usage habits and scenarios. How to determine the key data that supports user usage habits or scenarios and prioritize loading is also a major challenge. Therefore, the technical problem solved by this application is how to improve the startup speed of the simulator while meeting the personalized needs of different users for the simulation accuracy of the simulator. Summary of the Invention

[0004] The present application provides a simulator startup acceleration method, device, equipment and storage medium, which can improve the startup speed of the simulator while meeting the user's personalized needs for simulation accuracy.

[0005] In a first aspect, an embodiment of the present application provides a simulator startup acceleration method, comprising:

[0006] Obtain a pre-read block set; the pre-read block set includes multiple data blocks and corresponding access frequency tags;

[0007] Prioritize each data block according to the access frequency label to obtain a pre-read block sequence;

[0008] Extracting a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset;

[0009] Perform a pre-read operation on the target pre-read block subset to obtain pre-loaded data;

[0010] Store the preloaded data into the cache to generate a preloaded cache;

[0011] Respond to the simulator startup instruction, read the preload cache, and obtain the startup data;

[0012] Initialize the simulator according to the startup data to obtain the initialized simulator environment;

[0013] Use the initialized simulator environment to execute the simulator startup process.

[0014] Furthermore, the method further comprises:

[0015] Get the simulator's historical startup logs through the disk access monitoring hook;

[0016] Determine multiple data blocks based on various disk read operations in the historical boot log;

[0017] Merge and deduplicate data blocks based on logical address ranges;

[0018] Calculate the access frequency of each remaining data block and use it as the corresponding access frequency label;

[0019] At least one data block is placed into a pre-read block set according to the access frequency tag.

[0020] Furthermore, the method further comprises:

[0021] Use compiler tools to parse the simulator's binary file to obtain the simulator's startup dependency graph; the startup dependency graph includes multiple data blocks and the dependency relationships between each data block;

[0022] Get the initialization path of the simulator;

[0023] Determine at least one required data block in the startup dependency graph according to the initialization path;

[0024] Obtain the simulator's historical startup logs and train a user behavior prediction model based on the historical startup logs;

[0025] Input the most recent simulator startup log into the user behavior prediction model to obtain the prediction data block;

[0026] Put the predicted data blocks and required data blocks into the pre-read block set.

[0027] Furthermore, the data block includes a timestamp and a logical address range;

[0028] The logical address range is the file path plus the offset or disk sector LBA range.

[0029] Furthermore, the above-mentioned priority sorting of each data block according to the access frequency label is performed to obtain a pre-read block sequence, including:

[0030] Extract basic feature data of data blocks;

[0031] Get the historical startup data of the data block;

[0032] Calculate the startup time increment of the removed data block based on the historical startup data of the data block;

[0033] forming a feature vector according to the startup time increment and the basic feature data;

[0034] Input the feature vector of each data block into the criticality prediction model to obtain the corresponding criticality score;

[0035] The data blocks in the pre-read block set are sorted based on the criticality score.

[0036] Furthermore, the basic feature data includes the size ratio of the data block and the frequency level corresponding to the access frequency label;

[0037] The basic feature data of the extracted data block includes:

[0038] Convert the access frequency label of the data block into a numerical frequency value;

[0039] Normalize the frequency values ​​to obtain the frequency level;

[0040] Calculate the ratio of the size of the data block to the size of the pre-read block set;

[0041] Normalize the ratio to get the size ratio of the data block.

[0042] Furthermore, the method further comprises:

[0043] After the simulator startup process is completed, the latest startup data is obtained;

[0044] The criticality prediction model is incrementally learned based on the latest startup data.

[0045] Furthermore, the method further comprises:

[0046] Before inputting the feature vectors of each data block into the criticality prediction model, the equipment load is obtained;

[0047] Determine whether the equipment load exceeds a preset load threshold; if so, adjust the weight parameters of the processing units with the largest and smallest proportions in the criticality prediction model according to the equipment load.

[0048] Furthermore, the method further comprises:

[0049] Determine the high-frequency startup time based on the simulator's historical startup logs;

[0050] Determine whether to start pre-reading based on the high-frequency startup time and current device status;

[0051] If so, a pre-read operation is performed on the target pre-read block subset to obtain pre-loaded data.

[0052] Furthermore, the above-mentioned pre-read operation is performed on the target pre-read block subset to obtain preloaded data, including:

[0053] Mapping each data block in the target pre-read block subset from disk to memory through a memory mapping interface;

[0054] During the mapping process, the posix_madvise function is used to make system calls to each data block.

[0055] Furthermore, the above-mentioned storing of preloaded data into a cache to generate a preloaded cache includes:

[0056] Sort the preloaded data by key points of the corresponding data blocks and store them in the first-level cache and the second-level cache in sequence;

[0057] If the preloaded data exceeds the cache capacity of the first-level cache, the blocks in the first-level cache that have not been accessed for more than the preset time period are cleared;

[0058] If the preloaded data exceeds the cache capacity of the L2 cache, the block with the longest interval between the two most recent accesses in the L2 cache is cleared.

[0059] Furthermore, the method further comprises:

[0060] Before storing the preloaded data in the cache, perform a CRC32 check on the preloaded data;

[0061] If the verification fails, the original data block corresponding to the preloaded data is re-read from the disk.

[0062] Furthermore, the method further comprises:

[0063] If a miss event occurs when reading the preload cache, the corresponding miss data block is obtained;

[0064] Start real-time disk reads based on missed data blocks;

[0065] Obtaining adjacent data blocks of the missed data block in the pre-read block sequence;

[0066] Perform pre-read operations on adjacent data blocks and load them into the cache.

[0067] Furthermore, the latest startup data obtained after the simulator startup process is completed includes the actual startup time, the data block loading order and the missed data blocks.

[0068] In a second aspect, an embodiment of the present application provides a simulator startup acceleration device, comprising:

[0069] An acquisition module is used to acquire a pre-read block set; the pre-read block set includes multiple data blocks and corresponding access frequency tags;

[0070] A sorting module is used to prioritize each data block according to the access frequency label to obtain a pre-read block sequence;

[0071] an extraction module, configured to extract a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset;

[0072] A pre-read module is used to perform a pre-read operation on a target pre-read block subset to obtain pre-loaded data;

[0073] A cache module, used to store preloaded data into a cache and generate a preloaded cache;

[0074] The reading module is used to respond to the simulator startup instruction, read the preload cache, and obtain the startup data;

[0075] The initialization module is used to initialize the simulator according to the startup data to obtain the initialized simulator environment;

[0076] The startup module is used to use the initialized simulator environment to execute the simulator startup process.

[0077] Furthermore, the device also includes a pre-reading generation module; the pre-reading generation module is used to:

[0078] Get the simulator's historical startup logs through the disk access monitoring hook;

[0079] Determine multiple data blocks based on various disk read operations in the historical boot log;

[0080] Merge and deduplicate data blocks based on logical address ranges;

[0081] Calculate the access frequency of each remaining data block and use it as the corresponding access frequency label;

[0082] At least one data block is placed into a pre-read block set according to the access frequency tag.

[0083] Furthermore, the device also includes a pre-reading generation module; the pre-reading generation module is used to:

[0084] Use compiler tools to parse the simulator's binary file to obtain the simulator's startup dependency graph; the startup dependency graph includes multiple data blocks and the dependency relationships between each data block;

[0085] Get the initialization path of the simulator;

[0086] Determine at least one required data block in the startup dependency graph according to the initialization path;

[0087] Obtain the simulator's historical startup logs and train a user behavior prediction model based on the historical startup logs;

[0088] Input the most recent simulator startup log into the user behavior prediction model to obtain the prediction data block;

[0089] Put the predicted data blocks and required data blocks into the pre-read block set.

[0090] Furthermore, the sorting module is specifically used to:

[0091] Extract basic feature data of data blocks; obtain historical startup data of data blocks;

[0092] Calculate the startup time increment of the removed data block based on the historical startup data of the data block;

[0093] forming a feature vector according to the startup time increment and the basic feature data;

[0094] Input the feature vector of each data block into the criticality prediction model to obtain the corresponding criticality score;

[0095] The data blocks in the pre-read block set are sorted based on the criticality score.

[0096] In a third aspect, an embodiment of the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the steps of the simulator startup acceleration method of any of the above embodiments are performed.

[0097] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of the simulator startup acceleration method as described in any of the above embodiments are implemented.

[0098] In summary, compared with the prior art, the technical solutions provided by the embodiments of the present application have at least the following beneficial effects:

[0099] An embodiment of the present application provides a simulator startup acceleration method. First, facing the many data required for simulator startup, the present application determines which data blocks are key data blocks supporting the current user's usage habits or scenarios based on the current user's access frequency labels for different data blocks, and uses this to construct a target pre-read block subset, and then performs a pre-read operation on the target pre-read block subset to pre-store the preloaded data in the cache. When the user starts the simulator, part of the required data will be read directly from the preload cache, reducing the amount of data that needs to be read from the disk when the simulator starts, thereby shortening the simulator startup time and the instantaneous overhead of disk I / O at startup; at the same time, since the preloaded data in the preload cache are determined based on the user's access habits, not only is the hit rate extremely high, but from the user's perspective, it can also quickly meet the requirements of usage habits or usage scenarios, thereby achieving improved simulator startup speed while meeting the user's personalized needs for simulation accuracy. BRIEF DESCRIPTION OF THE DRAWINGS

[0100] Figure 1 A flowchart of a simulator startup acceleration method provided by an exemplary embodiment of the present application.

[0101] Figure 2 A flowchart of the prioritization steps provided for an exemplary embodiment of the present application.

[0102] Figure 3 A flowchart of the steps of obtaining a pre-read block set is provided for an exemplary embodiment of the present application.

[0103] Figure 4 A flowchart of steps for obtaining a set of pre-read blocks is provided for another exemplary embodiment of the present application.

[0104] Figure 5 A structural diagram of a simulator startup acceleration device provided as an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0105] The technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0106] Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making any creative work shall fall within the scope of protection of this application.

[0107] See Figure 1 , an embodiment of the present application provides a simulator startup acceleration method, comprising:

[0108] Step S11 , obtaining a pre-read block set; the pre-read block set includes multiple data blocks and corresponding access frequency tags.

[0109] Step S12: Prioritize each data block according to the access frequency label to obtain a pre-read block sequence.

[0110] Specifically, see Figure 2 The steps of obtaining the pre-read block sequence by priority sorting include:

[0111] Step S121: extract basic feature data of the data block.

[0112] The basic feature data includes the size ratio of the data block and the frequency level corresponding to the access frequency label.

[0113] Specifically, the basic feature data of the extracted data block includes:

[0114] Step S1211: Convert the access frequency tag of the data block into a numerical frequency value.

[0115] Step S1212: normalize the frequency value to obtain the frequency level.

[0116] For the access frequency feature F, the access frequency label obtained in step S11 is directly converted into a numerical type, that is, a frequency value, and normalized to the interval [0, 1]. For example, 0.8-1.0 is mapped to level H, 0.5-0.8 is mapped to level M, and 0-0.5 is mapped to level L.

[0117] Step S1213: Calculate the ratio of the size of the data block to the size of the pre-read block set.

[0118] Step S1214: normalize the ratio to obtain the size ratio of the data block.

[0119] For the data block size feature S, the ratio of the block size to the total size of the pre-read block set is calculated and normalized to [0, 1] to prevent a single large file from occupying too much memory. In addition, a penalty factor is set: the ratio of data blocks larger than 10MB is multiplied by 0.9.

[0120] Step S122: Acquire historical startup data of the data block.

[0121] Step S123: Calculate the startup time increment of the removed data block according to the historical startup data of the data block.

[0122] Specifically, we use code instrumentation to embed probes into the simulator startup process and measure the increase in startup time after removing a data block. For example, if removing data block A increases startup time by 100ms, we normalize 100 to the range [0, 1] to obtain the startup time increment. For the first startup of a block with no historical data, the default startup time increment is 0.5, assuming medium criticality.

[0123] Step S124: forming a feature vector according to the startup time increment and the basic feature data.

[0124] Specifically, feature fusion generates a feature vector X = [F, I, S] as the input of the criticality prediction model.

[0125] Step S125 : Input the feature vector of each data block into the criticality prediction model to obtain the corresponding criticality score.

[0126] Training the launch criticality prediction model first requires data annotation and sample set construction. This data annotation method manually labels the first 20% of the most impactful data blocks in historical launches as "high criticality" (labeled 1), the next 30% as "low criticality" (labeled 0), and the intermediate as "medium criticality" (labeled 0.5). The sample set contains feature vectors and annotated labels for at least 1,000 historical data blocks, divided into training and validation sets in an 8:2 ratio. Next, model selection and training are performed, using a GBDT (gradient boosted decision tree) model with a tree depth of 5 to avoid overfitting, a learning rate of 0.1, and 100 iterations. The training objective is to minimize the mean squared error (MSE) and output a criticality score for each data block.

[0127] Furthermore, the method further comprises:

[0128] Step S1251 : Before inputting the feature vector of each data block into the criticality prediction model, obtain the equipment load.

[0129] Step S1252 , determining whether the equipment load exceeds a preset load threshold; if so, adjusting the weight parameters of the processing units of large and small proportions in the criticality prediction model according to the equipment load.

[0130] Specifically, if the device load exceeds a preset load threshold, the weight parameter of the processing unit with the largest or smallest size in the criticality prediction model is multiplied by the load weight (load weight = 1 - device load), where device load is a percentage. This allows the criticality prediction model to prioritize large blocks and prioritize loading small blocks when outputting a criticality score.

[0131] Step S126 , sorting the data blocks in the pre-read block set based on the criticality score.

[0132] Step S13 : extracting a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset.

[0133] Specifically, the sorting is generally from large to small, so starting from the first ranked data block (i.e., the data block with the highest criticality score) and extracting downwards until a preset number, is equivalent to taking the data blocks before the preset number as high-priority data blocks.

[0134] Furthermore, it is also possible to call the system interface, such as calling the GlobalMemoryStatusEx() API in Windows to obtain the amount of free physical memory, so as to dynamically determine the upper limit of the size of the target pre-read block subset (that is, the preset number) max_size = free physical memory × preset weight, and the preset weight defaults to 0.4 to avoid occupying too much memory and affecting other processes; if the hit rate of the target pre-read block subset last time (obtained through log statistics in the S16 process) is lower than 50%, the preset weight will be reduced to 0.3 at the next startup; if the device is in high-performance mode (such as connected to a power source and the CPU frequency is increased), the preset weight is increased to 0.5. This application supports a dynamic mechanism to adjust the size of the target pre-read block subset, that is, the size of the preset number.

[0135] In addition, you can also use Dependency Walker-like tools to parse the simulator binary file and generate a module-data block dependency graph. The module-data block dependency graph records which core modules each data block depends on; then use a greedy algorithm to filter. If a data block is dependent on any core module, no matter where it is ranked, it is directly placed in the target pre-read block subset. If the upper limit of the target pre-read block subset is not filled after filtering, the remaining data blocks are further sorted according to their criticality scores and placed in the target pre-read block subset in sequence until the size of the target pre-read block subset reaches its upper limit.

[0136] It is worth noting that the core of step S13 is to screen out the "minimum necessary and most efficient" target pre-read block subset based on the sorting of criticality scores and combined with memory limitations to ensure that the preloaded data that is subsequently quickly started meets the user's usage habits. The fast screening achieved through a lightweight greedy algorithm can ensure that key blocks are not missed, which is more suitable for mobile devices.

[0137] Step S14: performing a pre-read operation on the target pre-read block subset to obtain pre-loaded data.

[0138] Specifically, performing the pre-read operation on the target pre-read block subset to obtain pre-loaded data includes:

[0139] Each data block in the target pre-read block subset is mapped from disk to memory through a memory mapping interface; during the mapping process, a posix_madvise function is used to make a system call to each data block.

[0140] Disk data blocks are directly mapped to shared memory areas using the memory mapping interface provided by the operating system (such as Linux's mmap and Windows' CreateFileMapping), avoiding repeated data copying between user space and kernel space. Simultaneously, a posix_madvise system call (with the parameter set to MADV_WILLNEED) is performed for each data block to alert the kernel that the data is about to be accessed, triggering prefetch optimization. For very large data blocks (e.g., blocks larger than 100MB) within the target prefetch block subset, asynchronous block reads are implemented, launching independent low-priority threads to load non-dependent data segments in parallel, reducing main thread blocking. If disk I / O is detected to be busy during the prefetch process, for example, if disk utilization exceeds 80% as monitored by iostat, the prefetch task is automatically delayed by 5-10 seconds, and the thread priority is dynamically adjusted to reduce CPU usage by the prefetch thread.

[0141] Furthermore, the method further comprises:

[0142] The high-frequency startup time is determined according to the historical startup log of the simulator; whether to start pre-reading is determined according to the high-frequency startup time and the current device status; if so, a pre-reading operation is performed on the target pre-read block subset to obtain preloaded data.

[0143] It can be considered that this application can determine the pre-reading timing by monitoring the device status and user behavior, and parse the user's historical startup logs. For example, it can identify high-frequency startup periods through the device calendar application and simulator startup time records, such as 9:00 on weekdays and 20:30 in the evening, and automatically trigger scheduled pre-reading 10 minutes before the target time.

[0144] Step S15: storing the preloaded data in a cache to generate a preloaded cache.

[0145] Specifically, the above-mentioned storing the preloaded data into the cache to generate the preloaded cache includes:

[0146] The preloaded data is sorted by the key points of the corresponding data blocks and stored in the first-level cache and the second-level cache in sequence; if the preloaded data exceeds the cache capacity of the first-level cache, the blocks in the first-level cache that have not been accessed for more than a preset time are cleared; if the preloaded data exceeds the cache capacity of the second-level cache, the block with the longest interval between the two most recent accesses is cleared from the second-level cache.

[0147] During implementation, the first step is to dynamically partition the L1 and L2 caches based on the total size of the target pre-read block subset and the device's memory capacity. The L1 cache utilizes a lock-free ring buffer structure, with a capacity set to 20% of the total pre-read data (or no more than 100MB). This is used to store the top 20% of high-frequency, core data blocks (such as simulator kernel configurations and startup critical path dependency files), ensuring nanosecond-level low-latency access. The L2 cache utilizes a bidirectional linked list combined with a hash table structure, accounting for the remaining 80% of the capacity, and is used to store medium-frequency data blocks and high-frequency, non-core blocks.

[0148] The preloaded data is then written into the L1 ring buffer in the order of the corresponding data blocks. During this process, memory alignment technology can be used to reduce the CPU cache miss overhead. When the L1 cache is filled to its allocated capacity and it is determined that there are no blocks that can be eliminated, the remaining preloaded data is written into the L2 cache. This process can use memory compression technology to losslessly compress blocks larger than 10MB. The compression ratio threshold is set to 2:1. If it exceeds, compression is abandoned to avoid CPU overhead.

[0149] When the L1 cache is full, only blocks that have not been accessed for more than 10 minutes are eliminated to further expand capacity, preventing the accidental deletion of core data. When the L2 cache is full, the LRU-K (K=2) algorithm is used to eliminate the data block with the longest interval between the two most recent accesses. If the cache capacity is still insufficient after elimination, the cache capacity is automatically expanded to 45% of the available memory.

[0150] Step S16, responding to the simulator startup instruction, reading the preload cache, and obtaining startup data.

[0151] Specifically, when the user triggers the simulator startup instruction (such as clicking a desktop icon or calling the command line), the preloaded cache is first mapped to the virtual address space of the simulator process through the operating system memory management interface (such as Linux's mmap and Windows' MapViewOfFile) to establish a direct memory access channel, avoiding the overhead of traditional file I / O system calls.

[0152] Step S17: Initialize the simulator according to the startup data to obtain an initialized simulator environment.

[0153] Step S18: Using the initialized simulator environment, execute the simulator startup process.

[0154] The present application also includes step S19, after the simulator startup process is completed, obtaining the latest startup data of this time; and allowing the criticality prediction model to perform incremental learning based on the latest startup data.

[0155] The latest startup data obtained after the simulator startup process is completed includes the actual startup time, data block loading order, and missed data blocks; specifically, the latest startup data includes:

[0156] Detailed information about the data block that missed the cache, including its file path, size, etc.

[0157] User behavior data, by collecting user interface interaction events, monitors the user's operating behavior after the simulator is started, such as whether a specific game is opened immediately, whether certain specific functional modules are used, etc.

[0158] Device status data records the hardware status of the device during the boot process, such as CPU usage, memory usage, and disk I / O load. You can use system monitoring tools or APIs to obtain this data. For example, in Linux, you can use commands such as top and vmstat, and in Windows, you can use Task Manager or related APIs.

[0159] The latest startup data collected is then analyzed in depth to calculate a series of key metrics, including:

[0160] The startup acceleration rate is calculated by calculating the difference between the current startup time and the average startup time without the pre-reading strategy, and then dividing it by the average startup time without the pre-reading strategy. This metric reflects the effectiveness of the pre-reading strategy in improving startup speed.

[0161] The cache hit rate is calculated by dividing the number of cache hits by the total number of data reads. A higher cache hit rate indicates that the pre-read strategy can accurately predict the data required for simulator startup, reducing the time to read data from disk.

[0162] Resource utilization: Analyze device CPU usage, memory usage, and other data to calculate resource utilization. Evaluate the impact of pre-reading on device resources by comparing resource utilization before and after adopting the pre-reading policy.

[0163] If these indicators all meet the threshold requirements of incremental learning, the corresponding latest startup data will be put into the new sample set. When the startup data in the new sample set reaches 10, the new sample set will be used to perform incremental training on the criticality prediction model.

[0164] A simulator startup acceleration method provided in the above embodiment first faces the many data required for simulator startup. This application determines which data blocks are key data blocks supporting the current user's usage habits or scenarios based on the current user's access frequency labels for different data blocks, and uses this to construct a target pre-read block subset. Then, a pre-read operation is performed on the target pre-read block subset, and the pre-loaded data is pre-stored in the cache. When the user starts the simulator, part of the required data will be read directly from the pre-load cache, reducing the amount of data that needs to be read from the disk when the simulator starts, thereby shortening the simulator startup time and the instantaneous overhead of disk I / O at startup; at the same time, since the pre-loaded data in the pre-load cache are determined based on the user's access habits, not only is the hit rate extremely high, but from the user's perspective, it can also quickly meet the requirements of usage habits or usage scenarios, thereby achieving improved simulator startup speed while meeting the user's personalized needs for simulation accuracy.

[0165] In some embodiments, see Figure 3 , the method further comprises:

[0166] Step S011, obtaining the historical startup log of the simulator through the disk access monitoring hook.

[0167] Specifically, a disk access monitoring hook is implanted to intercept all disk read operations at the operating system layer or within the simulator process, including system call operations such as read, mmap, and open as the simulator startup log.

[0168] Step S012: determining a plurality of data blocks according to each disk read operation in the historical startup log.

[0169] The data block includes a timestamp and a logical address range.

[0170] The logical address range is the file path plus the offset or disk sector LBA range.

[0171] Step S013: Merge and deduplicate the data blocks based on the logical address range.

[0172] Specifically, continuous data blocks are merged. If the interval between adjacent accessed block addresses is ≤ 8 sectors, it is determined to be a typical disk IO unit and merged into one continuous data block to reduce redundant records.

[0173] The deduplication rule is to deduplicate by logical address range, retaining the latest access time and the highest frequency count.

[0174] Step S014: Calculate the access frequency of each remaining data block and use it as the corresponding access frequency label.

[0175] Specifically, the access frequency can be calculated using sliding window statistics, with a set statistical period, such as the most recent 30 startups, to calculate the number of accesses to each data block and introduce a time decay factor, such as records from 15 days ago decaying by 0.9^n.

[0176] Step S015: putting at least one data block into a pre-read block set according to the access frequency tag.

[0177] Data blocks whose access frequency exceeds a certain threshold are placed into the pre-read block set.

[0178] In some embodiments, see Figure 4 , the method further comprises:

[0179] Step S021 , using a compiler tool to parse the binary file of the simulator to obtain a startup dependency graph of the simulator; the startup dependency graph includes multiple data blocks and dependency relationships between the data blocks.

[0180] Step S022: Obtain the initialization path of the simulator.

[0181] Step S023: determining at least one mandatory data block in the startup dependency graph according to the initialization path.

[0182] Among them, the initialization path is the data block that must be loaded during the simulator initialization process, such as memory address space configuration, CPU instruction set definition, etc. These data blocks are regarded as mandatory data blocks.

[0183] Step S024: Obtain historical startup logs of the simulator, and train a user behavior prediction model based on the historical startup logs.

[0184] Step S025 , inputting the most recent simulator startup log into the user behavior prediction model to obtain a prediction data block.

[0185] When training the user behavior prediction model, the data input includes user startup time, commonly used functional modules, device parameters, data block access sequence, etc. from historical startup logs. The model uses an LSTM neural network or a gradient boosted tree (GBDT) to output the access probability (0-1) of each data block at the next startup.

[0186] Step S026: putting the predicted data blocks and the required data blocks into a pre-read block set.

[0187] The above embodiments solve the problem of the pre-reading data method adapting to the high-frequency data differences of different users. The dynamic collection method based on historical startup logs or the prediction method based on static dependency analysis and machine learning can realize the generation of pre-reading sets for thousands of people through dynamic collection or intelligent prediction, thereby significantly improving the pre-reading efficiency.

[0188] In some embodiments, the method further includes: performing a CRC32 check on the preloaded data before storing the preloaded data in the cache; if the check fails, re-reading the original data block corresponding to the preloaded data from the disk.

[0189] Specifically, after pre-reading is complete, the integrity of each data block is verified through hashing to ensure that the pre-loaded data is consistent with the original data on disk. For core module data blocks with complex dependencies (such as simulator kernel configuration files), additional metadata (such as version numbers and dependent module signatures) is checked to avoid startup errors caused by data inconsistencies. After verification, the pre-read data is stored in a memory buffer in priority order to prepare for subsequent cache storage. If the verification fails, it is re-read from disk. For cross-process access scenarios, memory barrier technology can be used to ensure the visibility and consistency of cached data.

[0190] In some embodiments, the method further includes: if a miss event occurs when reading the preload cache, obtaining the corresponding miss data block; starting real-time reading of the disk based on the miss data block; obtaining adjacent data blocks of the miss data block in the pre-read block sequence; performing a pre-read operation on the adjacent data blocks and loading them into the cache.

[0191] Specifically, if the required data block does not hit the preload cache, real-time disk reading is triggered immediately, and adjacent data blocks in the pre-read block sequence are called through the readahead system, and the preload cache is updated with the adjacent data blocks.

[0192] It is understandable that a missed data block may not exist in the target pre-read block subset, but must be in the pre-read block sequence; therefore, when the present application finds that a certain data block has not been loaded into the pre-load cache but is needed during the startup process, it quickly performs a pre-read operation on the adjacent data block in the pre-read block sequence that is not placed in the pre-load data and loads it into the cache, so as to reduce the probability of subsequent misses and further improve the pre-reading efficiency and startup efficiency.

[0193] See Figure 5 Another embodiment of the present application provides a simulator startup acceleration device, comprising:

[0194] The acquisition module 101 is configured to acquire a pre-read block set; the pre-read block set includes a plurality of data blocks and corresponding access frequency tags.

[0195] The sorting module 102 is configured to prioritize each data block according to the access frequency tag to obtain a pre-read block sequence.

[0196] The extraction module 103 is configured to extract a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset.

[0197] The pre-reading module 104 is configured to perform a pre-reading operation on the target pre-read block subset to obtain pre-loaded data.

[0198] The cache module 105 is configured to store the preloaded data in a cache to generate a preloaded cache.

[0199] The reading module 106 is used to respond to the simulator startup instruction, read the preload cache, and obtain the startup data.

[0200] The initialization module 107 is used to initialize the simulator according to the startup data to obtain an initialized simulator environment.

[0201] The startup module 108 is used to use the initialized simulator environment to execute the simulator startup process.

[0202] Furthermore, the device also includes a pre-read generation module; the pre-read generation module is used to obtain the historical startup log of the simulator through a disk access monitoring hook; determine multiple data blocks based on each disk read operation in the historical startup log; merge and deduplicate each data block based on the logical address range; calculate the access frequency of each remaining data block and use it as the corresponding access frequency label; and put at least one data block into a pre-read block set according to the access frequency label.

[0203] Furthermore, the device also includes a pre-reading generation module.

[0204] The pre-read generation module is used to use the compiler tool to parse the binary file of the simulator to obtain the startup dependency graph of the simulator; the startup dependency graph includes multiple data blocks and the dependency relationship between each data block; obtain the initialization path of the simulator; determine at least one required data block in the startup dependency graph based on the initialization path; obtain the historical startup log of the simulator, and obtain a user behavior prediction model based on the historical startup log training; input the most recent simulator startup log into the user behavior prediction model to obtain a predicted data block; and put the predicted data block and the required data block into the pre-read block set.

[0205] Furthermore, the sorting module is specifically used to extract basic feature data of the data block; obtain historical startup data of the data block; calculate the startup time increment of the removed data block based on the historical startup data of the data block; form a feature vector based on the startup time increment and the basic feature data; input the feature vector of each data block into the criticality prediction model to obtain the corresponding criticality score; and sort each data block in the pre-read block set based on the criticality score.

[0206] In some embodiments, the sorting module is specifically used to convert the access frequency label of the data block into a numerical frequency value; normalize the frequency value to obtain the frequency level; calculate the ratio of the size of the data block and the size of the pre-read block set; normalize the ratio to obtain the size ratio of the data block.

[0207] Furthermore, the device also includes an incremental training module for obtaining the latest startup data after the simulator startup process is completed; and allowing the criticality prediction model to perform incremental learning based on the latest startup data.

[0208] Furthermore, the device also includes a model adjustment module, which is used to obtain the equipment load before inputting the feature vector of each data block into the criticality prediction model; determine whether the equipment load exceeds the preset load threshold; if so, adjust the weight parameters of the processing units with different sizes in the criticality prediction model according to the equipment load.

[0209] Furthermore, the device also includes a pre-reading judgment module, which is used to determine the high-frequency startup time based on the historical startup log of the simulator; determine whether to start pre-reading based on the high-frequency startup time and the current device status; if so, perform a pre-reading operation on the target pre-read block subset to obtain preloaded data.

[0210] Furthermore, the device also includes a verification module for performing a CRC32 check on the preloaded data before storing the preloaded data in the cache; if the check fails, the original data block corresponding to the preloaded data is re-read from the disk.

[0211] Furthermore, the device also includes a miss processing module, which is used to obtain the corresponding miss data block when a miss event occurs when reading the preload cache; start real-time reading of the disk based on the miss data block; obtain the adjacent data blocks of the miss data block in the pre-read block sequence; perform a pre-read operation on the adjacent data blocks and load them into the cache.

[0212] For the specific definition of a simulator startup acceleration device provided in this embodiment, please refer to the above embodiment of a simulator startup acceleration method, which will not be repeated here.

[0213] Each module in the aforementioned simulator startup acceleration device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a memory in the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0214] An embodiment of the present application provides a computer device, which may include a processor, a memory, a network interface, and a database connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the processor executes the steps of a simulator startup acceleration method as described in any of the above embodiments.

[0215] The working process, working details and technical effects of the computer device provided in this embodiment can be found in the above embodiment of an emulator startup acceleration method, which will not be described in detail here.

[0216] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of a simulator startup acceleration method as in any of the above embodiments are implemented. Wherein, the computer-readable storage medium refers to a carrier for storing data, which may include but is not limited to a floppy disk, an optical disk, a hard disk, a flash memory, a USB flash drive and / or a memory stick (Memory Stick), etc., and the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The working process, working details and technical effects of the computer-readable storage medium provided in this embodiment can be found in the above embodiment of a simulator startup acceleration method, which will not be repeated here.

[0217] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0218] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0219] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art could make various modifications and improvements without departing from the spirit of the present application, all of which fall within the scope of protection of the present application. Therefore, the scope of protection of the present patent application shall be determined by the appended claims.

Claims

1. A simulator startup acceleration method, characterized in that: include: Use compiler tools to parse the simulator's binary file to obtain the simulator's startup dependency graph; The startup dependency graph includes multiple data blocks and dependency relationships between the data blocks; Get the initialization path of the simulator; Determining at least one mandatory data block in the startup dependency graph according to the initialization path; Obtain historical startup logs of the simulator, and train a user behavior prediction model based on the historical startup logs; Input the most recent simulator startup log into the user behavior prediction model to obtain the prediction data block; Putting the predicted data block and the required data block into a pre-read block set; Acquire the pre-read block set; the pre-read block set includes multiple data blocks and corresponding access frequency tags; Prioritizing each of the data blocks according to the access frequency labels to obtain a pre-read block sequence; Extracting a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset; Performing a pre-read operation on the target pre-read block subset to obtain pre-loaded data; Storing the preloaded data in a cache to generate a preloaded cache; Responding to the simulator startup instruction, reading the preload cache to obtain startup data; Initialize the simulator according to the startup data to obtain an initialized simulator environment; Use the initialized simulator environment to execute the simulator startup process.

2. The simulator startup acceleration method according to claim 1, characterized in that: Also includes: Get the simulator's historical startup logs through the disk access monitoring hook; Determining a plurality of data blocks according to each disk read operation in the historical boot log; Merging and deduplicating each of the data blocks based on a logical address range; Calculating the access frequency of each of the remaining data blocks and using it as the corresponding access frequency label; At least one of the data blocks is placed into a pre-read block set according to the access frequency label.

3. The simulator startup acceleration method according to claim 1, characterized in that: The data block includes a timestamp and a logical address range; the logical address range is the file path plus an offset or a disk sector LBA range.

4. The simulator startup acceleration method according to claim 1, characterized in that: The step of prioritizing the data blocks according to the access frequency labels to obtain a pre-read block sequence includes: Extracting basic feature data of the data block; Obtaining historical startup data of the data block; Calculate the startup time increment for removing the data block according to the historical startup data of the data block; forming a feature vector according to the startup time increment and the basic feature data; Inputting the feature vector of each data block into a criticality prediction model to obtain a corresponding criticality score; The data blocks in the pre-read block set are sorted based on the criticality scores.

5. The simulator startup acceleration method according to claim 4, characterized in that: The basic feature data includes the size ratio of the data block and the frequency level corresponding to the access frequency label; The extracting basic feature data of the data block includes: Converting the access frequency label of the data block into a numerical frequency value; Normalizing the frequency value to obtain the frequency level; Calculating a ratio of the size of the data block to the size of the pre-read block set; The ratio is normalized to obtain the size ratio of the data block.

6. The simulator startup acceleration method according to claim 5, characterized in that: Also includes: After the simulator startup process is completed, the latest startup data is obtained; The criticality prediction model is enabled to perform incremental learning based on the latest startup data.

7. The simulator startup acceleration method according to claim 5, characterized in that: Also includes: Before inputting the feature vectors of each data block into the criticality prediction model, obtaining the equipment load; Determining whether the device load exceeds a preset load threshold; If so, the weight parameters of the processing units of the size ratio in the criticality prediction model are adjusted according to the equipment load.

8. The simulator startup acceleration method according to claim 1, characterized in that: Also includes: Determine the high-frequency startup time based on the simulator's historical startup logs; Determine whether to start pre-reading based on the high-frequency startup time and current device status; If so, a pre-read operation is performed on the target pre-read block subset to obtain pre-loaded data.

9. The simulator startup acceleration method according to claim 1, characterized in that: The performing a pre-read operation on the target pre-read block subset to obtain pre-loaded data includes: Mapping each of the data blocks in the target pre-read block subset from the disk to the memory through a memory mapping interface; During the mapping process, the posix_madvise function is used to perform a system call on each of the data blocks.

10. The simulator startup acceleration method according to claim 4, characterized in that: Storing the preloaded data in a cache to generate a preloaded cache includes: Sort the preloaded data by key points of the corresponding data blocks and store them in the first-level cache and the second-level cache in sequence; If the preloaded data exceeds the cache capacity of the first-level cache, the blocks in the first-level cache that have not been accessed for more than the preset time period are cleared; If the preloaded data exceeds the cache capacity of the L2 cache, the block with the longest interval between the two most recent accesses in the L2 cache is cleared.

11. The simulator startup acceleration method according to claim 10, characterized in that: Also includes: Before storing the preloaded data in the cache, performing a CRC32 check on the preloaded data; If the verification fails, the original data block corresponding to the preloaded data is re-read from the disk.

12. The simulator startup acceleration method according to claim 6, characterized in that: Also includes: If a miss event occurs when reading the preload cache, obtaining a corresponding miss data block; Initiate real-time reading of the disk according to the missed data block; Acquire adjacent data blocks of the missed data block in the pre-read block sequence; A pre-read operation is performed on the adjacent data blocks and loaded into a cache.

13. The simulator startup acceleration method according to claim 12, characterized in that: The latest startup data obtained after the simulator startup process is completed includes the actual startup time, the data block loading order and the missed data blocks.

14. A simulator startup acceleration device, characterized in that: include: A pre-reading generation module is used to parse the binary file of the simulator using a compiler tool to obtain a startup dependency graph of the simulator; the startup dependency graph includes multiple data blocks and dependency relationships between the data blocks; Get the initialization path of the simulator; Determining at least one mandatory data block in a startup dependency graph according to the initialization path; Obtain historical simulator startup logs, and train a user behavior prediction model based on the historical startup logs; input the most recent simulator startup log into the user behavior prediction model to obtain a prediction data block; Put the predicted data block and the required data block into a pre-read block set; An acquisition module is used to acquire a pre-read block set; the pre-read block set includes a plurality of data blocks and corresponding access frequency labels; A sorting module, configured to prioritize each data block according to the access frequency label to obtain a pre-read block sequence; an extraction module, configured to extract a preset number of high-priority data blocks from the pre-read block sequence to generate a target pre-read block subset; A pre-reading module, configured to perform a pre-reading operation on the target pre-read block subset to obtain pre-loaded data; A cache module, configured to store the preloaded data in a cache to generate a preloaded cache; A reading module, configured to respond to a simulator startup instruction, read the preload cache, and obtain startup data; An initialization module, configured to initialize the simulator according to the startup data to obtain an initialized simulator environment; The startup module is used to use the initialized simulator environment to execute the simulator startup process.

15. The simulator startup acceleration device according to claim 14, characterized in that: The pre-reading generation module is also used for: Get the simulator's historical startup logs through the disk access monitoring hook; Determining a plurality of data blocks according to each disk read operation in the historical boot log; Merging and deduplicating each of the data blocks based on a logical address range; Calculating the access frequency of each of the remaining data blocks and using it as the corresponding access frequency label; At least one of the data blocks is placed into a pre-read block set according to the access frequency label.

16. The simulator startup acceleration device according to claim 14, characterized in that: The sorting module is specifically used for: Extracting basic feature data of the data block; obtaining historical startup data of the data block; Calculate the startup time increment for removing the data block according to the historical startup data of the data block; forming a feature vector according to the startup time increment and the basic feature data; Inputting the feature vector of each data block into a criticality prediction model to obtain a corresponding criticality score; The data blocks in the pre-read block set are sorted based on the criticality scores.

17. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the steps of the simulator startup acceleration method according to any one of claims 1 to 13 are implemented.

18. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the simulator startup acceleration method according to any one of claims 1 to 13 are implemented.

Images