WO2011123991A1 - 并行计算的内存访问方法 - Google Patents

并行计算的内存访问方法 Download PDF

Info

Publication number
WO2011123991A1
WO2011123991A1 PCT/CN2010/000481 CN2010000481W WO2011123991A1 WO 2011123991 A1 WO2011123991 A1 WO 2011123991A1 CN 2010000481 W CN2010000481 W CN 2010000481W WO 2011123991 A1 WO2011123991 A1 WO 2011123991A1
Authority
WO
WIPO (PCT)
Prior art keywords
execution module
thread
execution
threads
memory access
Prior art date
Application number
PCT/CN2010/000481
Other languages
English (en)
French (fr)
Inventor
熊雨前
林芝
Original Assignee
福州福昕软件开发有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 福州福昕软件开发有限公司 filed Critical 福州福昕软件开发有限公司
Priority to US13/638,974 priority Critical patent/US9448857B2/en
Publication of WO2011123991A1 publication Critical patent/WO2011123991A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Definitions

  • the present invention relates to computer technology, and more particularly to memory access control in multi-threaded PDF file operations; and a memory access strategy and a method for improving operational efficiency in multi-thread parallel computing. Background technique
  • the digitization of physical resources such as books, pictures, and files is usually done by scanning __ to identify one-to-one extraction.
  • the document is first scanned into a PDF format, and then the document module and text are identified, and the identified information is extracted for documentation and provision to the search engine for indexing.
  • system resources including CPU and memory resources
  • various methods have been selected, especially in recent years, with the maturity of multi-core processor technology, running multiple threads simultaneously on multiple CPUs is one of the preferred ways to increase the calculation speed.
  • each application is loaded into a separate process, and a private memory space is specified for each process, and the memory space cannot be accessed between processes.
  • an application process runs, it creates multiple entities, that is, threads, and multiple threads belonging to the same process share the resources of the process.
  • Patent Authorization Announcement No.: CN100487660C a Chinese invention patent entitled “A Multi-Threaded Processor Dynamic Memory Management System and Method” discloses a multi-thread processor dynamic memory management method, see FIG.
  • the method includes the following Step:
  • the master kernel thread requests a memory from the system memory as a memory pool (step 101); all kernel threads send an application memory message to the master kernel thread, and the master kernel thread receives the application memory message, Allocating free memory in the memory pool to the kernel thread applying for memory, and sending a memory allocation message to the kernel thread applying for memory (step 102);
  • the master kernel thread queries the memory usage of the kernel thread that has been applied for, periodically Sending a reclaimed memory message (step 103); after receiving the reclaimed memory message, the kernel thread returns the memory and sends a release memory message to the main control kernel thread (step 104).
  • This method solves the memory release problem of the kernel thread to a certain extent, and can avoid an idle kernel thread occupying too much free memory at a certain moment.
  • the hardware arbiter is replaced by the master kernel thread, and the message mechanism is used to improve the allocation efficiency of memory among the kernel threads.
  • this method cannot solve the problem that multiple threads sharing a memory pool request a large memory space and must wait in line. And to apply this method, to change the memory management code, it is not suitable for direct porting of the code. Summary of the invention
  • the object of the present invention is to provide a new memory access when the same execution module is called for multiple threads, because the same memory pool must be shared, and the memory pool cannot provide sufficient resources and the memory access waiting time is too long.
  • the more important goal is to simply port single-threaded code to a multi-threaded environment without changing or seldom changing the module code, especially without changing memory management. And let the advantages of multi-core multi-threading get the most out.
  • the memory access method of the parallel computing of the present invention is used for the case where there are n 2 parallel threads calling the same original execution module, and the method comprises the following steps:
  • each thread invokes an execution module according to the mapping policy F, and each execution module accesses and only accesses its private memory pool;
  • the number of the image execution modules is k, which may be changed with time. Alternatively, the number k of the image execution modules may also be fixed during thread execution.
  • the number of threads of the same execution module can be called at the same time to determine the number of image execution modules.
  • the number k of the image execution modules is one.
  • the number k of the image execution modules is n-1.
  • mapping policy F may be: Each thread respectively calls a different execution module, and the threads have a one-to-one correspondence with the execution modules.
  • the mapping policy F may be a static policy, one thread refers only to one execution module called by it, and one execution module is called by one or more threads.
  • the mapping policy F is configured to exclusively execute an execution module, and configure a thread with a lower frequency of calling the execution module as a shared execution module.
  • the mapping policy F is a "multi-window queuing" mechanism of a dynamic policy, and in the policy F, two states of "idle” and “busy” are defined for each execution module, and all of them are The idle execution module is queued, and the thread that needs to call the execution module selects one from the idle execution module queue, and waits if there is no idle; the execution module is marked as busy when the thread calls the execution module, and after the execution is completed, the thread Release the execution module and mark it as idle.
  • Applying the method of the present invention can make the efficiency of parallel computing grow linearly with the increase of the number of cores, and is not limited by the memory access bottleneck. Applicable to a variety of operating systems. And, when using static methods, you can port a single-threaded program directly to a multi-threaded environment without adding code.
  • the flexible dynamic mode and the dynamic mapping strategy enable the present invention to significantly improve efficiency while occupying less than a large amount of system resources, with less effort.
  • 2 is a schematic diagram of memory access when multiple threads call the same execution module
  • FIG. 3 is a schematic diagram of memory access when creating respective execution modules for multiple threads;
  • FIG. 4 is a schematic flowchart of a preferred embodiment of the memory access method of the present invention.
  • Figure 5 is a schematic diagram 1 showing comparison of thread performance when using the method of the present invention and other measures
  • Figure 6 is a schematic diagram 2 showing comparison of thread performance when using the method of the present invention and other measures
  • Figure 7 is a method and use of the present invention. The thread performance comparison of other measures is shown in Figure 3. detailed description
  • the object of the present invention is to change the memory access mode without changing the memory management of the operating system.
  • a general memory management method will be described first.
  • execution modules are isolated, and each execution module is allocated a separate memory pool space.
  • the execution module can be regarded as a data structure established by the system in the memory to manage program code, data and resources loaded into the memory at runtime.
  • Each execution module acts as a unit of allocation for system resources, enjoying its own memory pool, and multiple functions in the execution module share the memory pool of the execution module.
  • the execution module may be an executable program under Windows or a dynamic link library (dll) that is loaded into the process after running.
  • the same execution module no matter how many threads are called, will only be loaded once, all threads opened by the same process, and its memory pool is shared for the same execution module.
  • the execution module can have other forms depending on the type of operating system. As is well known to those skilled in the art, different operating systems have different memory management modes, but there will be such a specific unit, which is composed of a collection of data and code, expressed in the form of programs, functions, and the like, and For this combination of code, the operating system allocates a private (private) memory space (both logical or physical) for its access.
  • an execution module can also be understood as a set of codes and data for which a separate memory pool is allocated for a given operating system, depending on the default memory management mode of the operating system.
  • Figure 2 shows the memory access situation when multiple threads use the same execution module.
  • the process 1 ( 21 1 ), the process 2 ( 212 ) ... the process n ( 213 ), etc. are multiple parallel threads of an application, both of which need to call an execution module 220, and the execution module 220 accesses the memory. Pool 230.
  • Fig. 3 is a diagram showing the memory access when the present invention creates a respective execution module for each thread in order to solve the above problem.
  • a thread as an example ("Natural Number")
  • the system has only one original execution module 1 (321), and in the present invention, an additional w-1 images are created according to the number of processes.
  • the execution module that is, execution module 2 (322) to the execution module "(323), so that the total number of execution modules is equal to the total number of threads.
  • the image execution module can be copied from the original execution module 1 and has the same function as the original execution module.
  • each execution module since each execution module is assigned a separate memory pool by default, each execution module separately accesses a different memory pool without interfering with each other.
  • the execution module 1 (321) shown in FIG. 3 accesses the memory pool 1 (331)
  • the execution module 2 (322) accesses the memory pool 2 (332)
  • ...--. and the execution module "(323) accesses the memory pool 3 ( 333).
  • This allows each thread to have a separate memory pool without changing the operating system and memory management code. In this way, when a memory operation is required, each thread does not need to preempt the same memory pool, and there is no need to wait.
  • the present invention implements independent memory pool management for each thread under multithreading by copying the execution module. Making shared resources an exclusive resource, swapping space for time, avoids waiting for memory access violations between threads.
  • This embodiment is the most typical example of space-changing time.
  • the solution does not change or rarely change the module code, especially the simple migration of single-threaded code to a multi-threaded environment without changing the memory management at all, can be said to be a versatile method to solve the parallel computing efficiency problem. .
  • the embodiment shown in Fig. 3 is a preferred embodiment for the purpose of reducing the queue waiting time for thread memory access, and is not intended to limit the embodiments of the present invention.
  • the creation of the image execution module of the present invention can be divided into two types: dynamic mode and static mode.
  • the static mode means that the corresponding topology mapping strategy between the thread and each execution module is fixed in the life cycle of the thread during the execution of the program; in the dynamic mode, the number of image execution modules refers to the thread.
  • the mapping strategy with each execution module can vary.
  • the process from start to finish can be the beginning and the end of an application; it can also be a process such as the life cycle of a group of threads that need to call the same original execution module. It can be selected according to the application of the present invention, and those skilled in the art can make their own choice according to different applications, and do not constitute a limitation of the present invention.
  • t e [0, r] is used hereinafter to indicate any point in time from the beginning to the end
  • the execution module includes a raw execution module and an image execution module.
  • the image execution module performs the same function as the original execution module, but is assigned different system resources (such as CPU and memory space).
  • step 430 is executed to determine the number of image execution modules to be newly created:
  • A: is a natural number and preferably, w-l > t > l.
  • w-l > t > l is a natural number and preferably, w-l > t > l.
  • Figure 3 is equivalent to maximizing the time efficiency in exchange for the maximum space.
  • the choice between other values is the result of a compromise between space and time.
  • Those skilled in the art can make selections according to the actual application environment under the teaching of the present invention. For example, when there are too many threads in parallel and the total memory space is limited, if you create too many image execution modules, it will affect the operation of other programs or significantly reduce the overall performance of the system. Even the memory space is not enough to build so many images.
  • the number of image execution modules may be determined according to the probability that the thread simultaneously calls the same execution module, and when the probability is large, more image execution modules are created; and the statistics of the number of threads calling the same execution module according to the same time ( For example, maximum, median, or mathematical expectation) to determine the number of execution modules.
  • a t is constant at t e [o,r].
  • the disadvantage is that when the frequency of the execution module fluctuates greatly during the execution of the process, if you choose a large > straight, it may cause a waste of memory space, and choosing a smaller value may cause a frequent call. A wait for a memory access has occurred.
  • Dynamic mode is more flexible.
  • ( ⁇ In [0,7 is variable, depending on the frequency of the execution of the module during the execution of the process, t can be set as a piecewise function. When multiple threads are performing frequent modules, select a larger t value, In the relatively speaking period when the execution module is called less, the smaller tt value is selected.
  • the flexible change during the execution of the process releases the resources in time to avoid waste of memory space.
  • the disadvantage of the dynamic mode is that Access control is a bit more complicated, and there will be problems such as parameter passing, and additional code is needed, which is not conducive to the direct migration of single-threaded programs to multi-threaded programs.
  • a mapping strategy F between the n threads and the original execution module and the k image execution modules is determined.
  • mapping policy F mainly reflects a unidirectional relationship such as which execution module is called by which thread.
  • mapping policy F is also divided into static and dynamic strategies. Among them, for a static policy, one thread only points to one execution module called by it, and one execution module can be called by one or more threads. And this call relationship remains unchanged for the time period t e [o, r]. Static policies are simple to execute without excessive extra code.
  • the execution module can be configured to exclusively execute one execution module, and the thread that has relatively few execution execution modules is configured as a shared execution module.
  • mapping policy F can also be segmented in accordance with the dynamic mode of the image execution module, and the time [ ⁇ , ⁇ ] is divided into several time segments, and the static strategy is used in each time segment. Or you can take a different approach like the "multi-window queuing" mechanism.
  • two states “idle” and “busy” are defined for each execution module, respectively, corresponding to different invocation states. All idle execution modules are queued, the first thread that needs to call the execution module calls the first one of the idle execution module queue; whenever a new thread calls the execution module, it is called to call the next one in the idle execution module queue. , if not available.
  • the execution module is marked as busy while the thread is calling the execution module. After execution, the thread releases the execution module and marks it as idle.
  • This queuing mechanism is that you can make the most of the resources, especially In the case of k ⁇ n-l, it can save memory resources as a whole, and can effectively avoid the situation that memory access waits when resources are idle. It is especially suitable for the case where there are many threads, and the call of the thread to the execution module is relatively random. With the method of the embodiment, the memory image module can be used to achieve a significant improvement in efficiency.
  • mapping policy F can be combined to form various flexible memory access control strategies.
  • the steps of the specific implementation can be realized by those skilled in the art under the teachings of the above description of the present invention. It is to be noted that any combination and variation of the invention may be made without departing from the spirit and scope of the invention.
  • step 450 to create an image execution module and assign a separate memory pool to it.
  • the memory allocation is actually controlled by the operating system and does not require application intervention.
  • step 460 executing the parallel "threads" and causing them to invoke the execution module in accordance with the call mapping policy F.
  • each execution module accesses and only accesses its private memory pool.
  • step 470 after the thread finishes running, all created image execution modules are deleted, and the resources allocated for the image execution module are released.
  • Figures 5 through 7 show the performance of the memory access control in accordance with the method of the present invention as compared to when the present invention is not used, as exemplified by the following examples. It is to be noted that the following examples are merely illustrative of the effects of the present invention and are not intended to limit the scope of the present invention.
  • Test environment Software environment Windows XP professional SP2 32 bit, hardware environment Core 2 Quad Q6600 2.4GHz (4 core) 3.25GB memory.
  • Test tool Use ifilttst.exe test tool program ifilttst.exe in platform sdk released by Microsoft. This program only performs a complete extraction of the file, and does not perform more checking work.
  • the test tool is a commonly used one in the field. For details, refer to the instructions at http://msdn.microsoft.com/en-us/librarv/ms692580 (28VS.85).aspx.
  • Ifilttst.exe can create a different number of threads.
  • each thread will call an execution module example.dll.
  • the abscissas 1, 2, 3, 4 in Figures 5 through 7 represent the number of threads, corresponding to the operation using a plurality of different processor cores.
  • the ordinate uses the performance index represented by the file processing speed.
  • the different curves represent the implementations for the method of using the invention and when not in use, respectively.
  • sample 1 is 219 files with a total size of 1.54 GB.
  • sample 2 is 351 files with a total size of 1.16 GB, and the number of files and the size of each file are relatively average.
  • the sample 3 in Figure 7 is 1274 files with a total size of 925MB, a large number of files and a small volume.
  • curve L1 is the implementation of ifilttst.exe using the method of the present invention
  • curve L2 is the operation of ifilttst.exe before the acceleration method of the present invention is used.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multi Processors (AREA)

Description

并行计算的内存访问方法 技术领域
本发明涉及计算机技术， 特别是涉及多线程的 PDF格式文件操作中的内存 访问控制； 以及由此引申出来的多线程并行计算时的内存访问策略和提高运行 效率的方法。 背景技术
图书、 图片、 文件等实体资源的数字化通常是采用扫描 _ _识别一一提取 的方式。 先将文档扫描为 PDF格式， 再进行文档模块和文字的识别， 之后提取 识别后的信息， 供编档和供给搜索引擎以供建立索引。 现有技术中， 对大量的 PDF格式的文档进行操作时，往往需要大量的系统资源， 包括 CPU和内存资源， 并且对 PDF格式文档的处理速度也较慢。 为了提高处理速度， 各种方式被选用， 特别是近年来随着多核处理器技术的成熟， 在多个 CPU上同时运行多个线程成 为提高计算速度的首选方式之一。
然而， 实际操作中， 却往往出现速度提高有限， 而同时 CPU却不能被完全 利用的情况。 例如， 如果充分利用 CPU, 那么在多核机器上， 例如 4核 CPU上 测试， 开 4个线程， 做压力测试的时候， 每个线程占用一个 CPU, 理论上 CPU 占用率应该是接近 100%的。 但是在实际的测试中发现， CPU 占用率远低于 100%, 甚至很多时候， CPU 占用率只达到 25%。 这说明， 并非每个 CPU都在 工作， 这里应该是有线程等待。 CPU并没有得到充分的利用。
本案发明人结合自身多年业内工作经验和实验结果对此现象的成因进行了 分析和研究， 并最终得出该情况的发生主要在于对内存操作工程中， 无论是内 存的分配和释放都需要线程保护， 且所有的线程共享一个内存池， 从而导致了 访问等待， 使 CPU无法被充分利用。 而 PDF操作对内存是非常频繁的操作， 所 以引起了大量的线程等待。
关于内存访问， 在传统操作系统的内存管理中， 多是将每个应用程序加载 到一个单独的进程， 并为每一进程指定私有的内存空间， 内存空间在进程间不 能互访。 一般来说， 一个应用程序进程运行时会创建多个实体， 即线程， 同属 一个进程的多个线程共享该进程的资源。
随着计算技术和硬件的发展， 特别是近年来多核处理器的广泛应用， 线程 的并发执行 （并行计算） 越来越普遍。 在多个线程并行时， 考虑到数据安全, 其对共享内存的访问往往是逐一进行而不能同时访问， 即便允许同时访问也经 常会有分配的内存池容量不够多个线程之用的情况， 这就造成了内存访问的等 待。 特别是在使用多 CPU, 每个 CPU运行一个线程的情况， 当 CPU处理所需 时间小于内存访问和等待时间时， 内存访问就成了计算速度的瓶颈， 使得 CPU 资源无法得到充分的利用， 妨碍了计算速度的进一步提高。
为了改善内存访问， 本领域技术人员提出了多种方法。 例如， 专利授权公 告号： CN100487660C, 名为 "一种多线程处理器动态内存管理系统及方法" 的 中国发明专利公开了一种多线程处理器动态内存管理方法， 参见图 1 , 该方法包 括以下步骤： 主控内核线程从系统内存中申请一段内存作为内存池（步骤 101 ) ; 所有内核线程向所述主控内核线程发送申请内存消息， 主控内核线程收到所述 申请内存消息后， 从所述内存池中分配空闲的内存给申请内存的内核线程， 并 向申请内存的内核线程发送分配内存消息（步骤 102 )； 所述主控内核线程查询 内核线程已申请的内存的使用情况， 定期发送回收内存消息（步骤 103 )； 内核 线程收到所述回收内存消息后， 对内存进行归还， 并向主控内核线程发送释放 内存消息 （步骤 104 ) 。
该方法在一定程度上解决了内核线程的内存释放问题， 能够避免某一时刻 某一空闲的内核线程占用过多的空闲内存。 由主控内核线程取代硬件仲裁器， 利用消息机制， 提高了内存在各个内核线程间的分配使用效率。 但是该方法却 无法解决共享一个内存池的多个线程均请求较大内存空间而必须排队等候的问 题。 并且应用此方法， 要改变内存管理代码， 并不适合代码的直接移植。 发明内容
本发明的目的在于， 针对多个线程调用同一个执行模块时， 由于必须共享 同一内存池， 且该内存池无法提供足够资源而导致内存访问等待时间过长的问 题， 提供一种新的内存访问策略， 以缩短甚或消除并行计算时的内存访问等待 时间， 使单个线程能够拥有独立的内存池。
更重要的目的是， 要能在不改变或很少改变模块代码特别是完全不改变内 存管理的情况下， 将单线程代码， 简单移植到多线程环境中。 并让多核多线程 的优势得到充分发挥。 本发明的并行计算的内存访问方法， 用于存在调用同一原始执行模块的 n 2个并行线程的情况， 其特征在于， 包括以下步骤：
51 )根据线程数 n确定需创建的映像执行模块的个数 k， n-l > k > l ;
52 )确定该 n个线程与原始执行模块及 k个映像执行模块之间的映射策略 F;
53 )创建 k个映像执行模块， 并为其分配各自私有的内存池；
54 )执行所述并行的 n个线程， 令各个线程按照所述映射策略 F调用执行 模块， 每个执行模块访问且仅访问其私有的内存池；
55 ) 线程运行完成后删除创建的映像执行模块， 释放资源。
其中， 所述映像执行模块的个数为 k可以是随时间变化的。 或者， 所述映 像执行模块的个数 k在线程执行期间也可是固定不变的。
较佳地， 可根据同一时间调用同一执行模块的线程个数的统计值来确定映 像执行模块的数量。
根据本发明的一实施例， 所述映像执行模块的个数 k为 1个。
根据本发明的另一实施例， 所述映像执行模块的个数 k为 n-1个。
其中， 当所述映像执行模块的个数 k为 n-1个时， 所述映射策略 F可为： 每个线程分别调用一个不同的执行模块， 线程与执行模块是一一对应的。
根据本发明的再一实施例， 所述映射策略 F 可为静态策略， 一个线程仅指 向一个被它调用的执行模块， 而一个执行模块被一个或一个以上的线程调用。
较佳地， 所述映射策略 F 为将调用执行模块频繁的线程， 配置为独享一个 执行模块， 将相对调用执行模块频率较低的线程， 配置为共享执行模块。
根据本发明的又一实施例， 所述映射策略 F 为动态策略的 "多窗口排队" 机制， 该策略 F 中， 为每个执行模块定义 "空闲" 、 "繁忙" 两个状态， 将所 有的空闲执行模块排队， 需要调用执行模块的线程从空闲执行模块队列中择一 调用， 若没有空闲的则等待； 在线程对执行模块的调用进行中将该执行模块标 记为繁忙， 执行完毕后， 线程释放该执行模块， 将其标记为空闲。
应用本发明的方法可令并行计算的效率随核心数增加而呈线性增长， 而不 受内存访问瓶颈的限制。 对各种操作系统均可适用。 并且， 使用静态方式时， 甚至无需增加代码， 即可将单线程的程序直接移植到多线程环境。 而灵活的动 态方式和动态映射策略， 则可使本发明在占用不是那么多的系统资源的情况下 显著提高效率， 事半功倍。 附图说明
图 1是现有技术的一种内存管理方法的流程图；
图 2是多个线程均调用同一执行模块时的内存访问示意图；
图 3是为多个线程分别创建各自的执行模块时的内存访问示意图； 图 4是本发明的内存访问方法优选实施例的流程示意图；
图 5是使用本发明的方法与使用其它措施时的线程性能比较示意图一； 图 6是使用本发明的方法与使用其它措施时的线程性能比较示意图二； 图 7是使用本发明的方法与使用其它措施时的线程性能比较示意图三。 具体实施方式
本发明目的在于在不改变操作系统的内存管理的前提下改变内存访问方 式。 为对便于对本发明进行更好的理解， 首先对一般的内存管理方式进行说明。
内存管理的特点之一是执行模块是隔离的， 每一个执行模块被分配独立的内存 池空间。 其中， 执行模块可视为是系统在内存中建立的一个个数据结构， 用于管理 运行时加载到内存中的程序代码， 数据以及资源。 每个执行模块作为一个系统资源 的分配单位， 享有其独自的内存池， 执行模块中的多个函数将共享该执行模块的内 存池。
所述执行模块可以是运行后被加载到进程中的一个 windows下的可执行程 序程序或一个动态链接库 (dll)等。 同一个执行模块， 不论多少个线程在调用， 只 会被加载一次， 由同一个进程开启的所有线程， 对于同一执行模块， 它的内存 池是共享的。 依操作系统类型的不同， 执行模块还可有其它形式。 按照本领域 技术人员的公知， 不同的操作系统的内存管理模式会有区别， 但是均会存在这 样一种特定的单元， 其由一些数据和代码的集合构成， 表现为程序、 函数等形 式， 并且对该种代码组合操作系统会分配私有的（ private ) 内存空间 （包括逻辑 的或物理的） 以供其访问。 因此， 在本发明中， 执行模块也可理解为在给定操 作系统下， 依据该操作系统的默认内存管理方式而为其分配单独的内存池的一 组代码和数据的集合。
图 2 示出了多个线程用到了同一个执行模块情况下的内存访问情况。 其中 进程 1 ( 21 1 ) ， 进程 2 ( 212 ) ... ...进程 n ( 213 )等为某一应用程序的多个并行 线程， 它们均需要调用一执行模块 220， 执行模块 220访问内存池 230。 在此类多线程环境下，当多个线程（21 1到 213 )同时调用一个执行模块（ 220 ) 的时候， 如果在执行模块中多个线程同时需要对内存进行操作 （例如申请和释 放） ， 即同时对同一个内存池操作， 则线程对内存的访问需要排队， 从而由内 存引起了线程的等待， 导致无法充分利用 CPU资源。 这也正是本发明意欲解决 的问题所在。
图 3 显示了本发明为解决上述问题而为每个线程分别创建各自的执行模块 时的内存访问示意图。 以《个线程为例（《为自然数），默认情况下（参见图 2 )， 系统只有一个原始执行模块 1 ( 321 ) , 而在本发明中， 根据进程数量， 额外创 建了 w-1个映像执行模块， 即执行模块 2 ( 322 ) 到执行模块《 ( 323 ) , 从而使 执行模块的总数量与线程总数相等。 其中， 映像执行模块可以由原始执行模块 1 复制而得， 功能与原执行模块相同。 此时， 对于操作系统而言， 由于其默认地 会为每个执行模块分配单独的内存池， 因此各个执行模块分别访问各自不同的 内存池， 互不干扰。 例如图 3所示的执行模块 1 ( 321 )访问内存池 1 ( 331 ) , 执行模块 2 ( 322 )访问内存池 2 ( 332 ) , …- -.， 执行模块《 ( 323 )访问内存池 3 ( 333 ) 。 从而在不改变操作系统和内存管理代码的前提下， 实现了使每个线 程拥有单独的内存池。 这样， 在需要内存操作的时候， 各个线程不需要抢占同 一个内存池， 也就无需等待。
简而言之， 本发明通过复制执行模块的方法实现多线程下每个线程使用独 立的内存池管理。 使共享资源变成了独享资源， 以空间换取时间， 避免了由线 程间内存访问沖突带来的等待。
本实施例以空间换时间的最典型例子。 该解决方法在不改变或很少改变模 块代码， 特别是能在完全不改变内存管理的情况下， 将单线程代码简单的移植 到多线程环境中， 可以说是解决并行计算效率问题的万能方法。
要强调的是， 对《个线程而言， 创建的映像执行模块的数量不一定要是《- 1 个， 其可以是从 1到 - 1之间的任意数量。 因为， 从上面的分析可以明确， 映像 执行模块的目的在于緩解内存访问的排队现象。 这就好比在服务窗口排队的情 形， 当 《 个顾客只能通过一个窗口获得服务时时， 效率低， 等待时间的数学期 望长； 而再增加一个窗口（k= l )即可使整个排队等待时间的显著降低； 创建《-1 个映像执行模块则可使期望排队时间降为 0。可见图 3所示的实施例是以减小线 程内存访问的排队等待时间为目的时的一个优选实施例， 而不能作为对本发明 实施方式的限制。 下面结合具体的图 4 的具体流程， 对本发明的方法进行进一步的说明。 总 体上说， 本发明的映像执行模块的创建可以分为动态方式和静态方式两类。 其 中， 静态方式是指线程与各个执行模块之间的对应拓朴映射策略在整个程序执 行过程中该线程的生命周期内是固定不变的； 而动态方式中， 映像执行模块的 数量提及线程与各个执行模块之间的映射策略可以改变。
图 4 是本发明的内存访问方法优选实施例的流程示意图。 其中， 从开始到 结束的过程可以是代表一个应用程序的始末； 也可以是表示一组需调用同一原 始执行模块的线程的生命周期等执行过程。 其可依本发明的应用场合而定， 本 领域技术人员可自行根据不同的应用做出选择， 并不构成对本发明的限制。 为 叙述方便， 下文中以 t e [0, r]来表示从开始到结束过程中的任意时间点， t=0为开 始， t=T为结束。作为统称， 执行模块包括原始执行模块和映像执行模块。 其中， 所述映像执行模块与原始执行模块执行相同的功能， 但被分配使用不同的系统 资源 （例如 CPU和内存空间） 。
首先， 在步骤 410获取需调用同一原始执行模块的并行的线程的数量 n, n 为自然数。 然后， 在步骤 420， 对《进行判断， 在《=1时， 只有一个线程， 该线 程与执行模块是唯一对应的， 不会发生由排队导致的内存访问等待， 转到步骤 460直接执行该线程即可。 当《 > 2时， 代表可能会发生等待， 需要创建映像 执行模块来改善内存访问。 一般来说， 线程的数量 "的设置与计算设备 CPU的 核心数有关。
接下来， 执行步骤 430， 确定需新创建的映像执行模块数 ：， A:为自然数且 优选地， w- l > t > l。 其中， 创建 w- 1个映像执行模块的情况参见图 3所示， 此 时相当于以最大的空间来换取最高的时间效率。 而在其它数值之间选择， 则是 空间和时间二者折衷的结果。 本领域技术人员可以在本发明的教导下根据实际 的应用环境进行选择。 例如， 当并行的线程数量太多， 而总的内存空间有限， 如果创建过多的映像执行模块将影响其它程序的运行或显著降低系统的整体效 能， 甚至是内存空间根本不够建立那么多的映像执行模块时， 都需要减少映像 执行模块的数量。 再比如， 可根据线程同时调用同一执行模块的概率来确定映 像执行模块的数量， 所述概率大时创建较多的映像执行模块； 以及根据同一时 间调用同一执行模块的线程个数的统计值 （例如最大值、 中值或数学期望） 来 确定执行模块的数量。 选择静态方式一种简捷的实施方式。 其中， 为固定值， A t 在 t e [o,r]是 保持不变的。 静态方式的好处在于， 程序执行简单， 占用内存空间固定， 利于 稳定执行。 不足之处是当进程执行过程中对执行模块的调动频率波动较大时， 如果选择大的 >Η直可能会造成内存空间的浪费，而选择较小的 值义可能会导致 在调用频繁的时段发生内存访问的等待。
动态方式则较为灵活。 (^ 在 [0，7 是可变的， 根据进程执行过程中对执 行模块的调动频率， t 可以设为分段函数。 在多个线程对执行模块频繁的时 段， 选择较大的 t 值， 而在相对来说调用执行模块较少的时段， 则选择较 小的 t t 值。 在进程的执行过程中灵活改变， 从而及时释放资源， 避免造成 内存空间的浪费。 但是动态方式的不足之处在于访问控制稍嫌复杂， 并且会存 在参数传递等问题， 需要另外增加代码， 不利于单线程程序向多线程程序的直 接移植。
在步骤 440,确定该 n个线程与原始执行模块及 k个映像执行模块之间的映 射策略 F。
所述映射策略 F主要体现的是哪一个线程调用哪一个执行模块这样的单向 关系。 同样， 映射策略 F也分为静态策略和动态策略。 其中， 对于静态策略， 一个线程仅指向一个被它调用的执行模块， 而一个执行模块可被一个或一个以 上的线程调用。 且这种调用关系在 t e [o,r]时间段内保持不变。 静态策略执行简 单， 无需过多的额外代码。
进一步较佳的是， 对于那些调用执行模块频繁的线程， 可以配置为独享一 个执行模块， 而对相对调用执行模块较少的线程， 配置为共享执行模块。
而对于动态策略， 线程可以并不固定指向某一个执行模块。 例如可以配合 映像执行模块的动态方式而将映射策略 F也做分段设置， 将时间 [Ο,Γ]分成几 个时间段， 在每个时间段中使用静态策略。 或者还可以采取一种类似 "多窗口 排队" 的机制等多种不同的方式。
根据本发明的一实施例， 为每个执行模块定义 "空闲" 和 "繁忙" 两个状 态分别对应不同的调用状态。 将所有的空闲执行模块排队， 第一个需要调用执 行模块的线程调用空闲执行模块队列的第一个； 每当有新的线程要调用执行模 块时， 令其调用空闲执行模块队列中的下一个， 若没有空闲。 在线程对执行模 块的调用进行中将该执行模块标记为繁忙， 执行完毕后， 线程释放该执行模块， 将其标记为空闲。 这种排队机制的好处是可以最大限度的充分利用资源， 特别 是对 k<n- l 的情况， 既能从总体上节约内存资源， 又能有效避免有资源闲置情 况下却发生内存访问等待的情况。 特别适用于线程较多， 而且线程对执行模块 的调用随机性较强的情况， 用本实施例的方法可以用较少的内存映像模块来实 现效率的大幅提高。
显然， 各种映像模块的静态方式和动态方式与映射策略 F 的静态策略和动 态策略可以相互组合而构成各种灵活的内存访问控制策略。 其具体实施的步骤， 在上述本发明内容的教导下， 本领域技术人员当可自行实现。 要注意的是， 无 论怎样的组合和变换， 只要未脱离本发明的精神实质， 均将落入所附权利要求 书所限定的范围。
之后进行步骤 450，创建 A个映像执行模块，并为其分配各自独立的内存池。 这一步中， 映像执行模块创建之后， 内存分配实际上是由操作系统控制完成的， 并不需要应用程序的干预。
在映像执行模块完成之后， 接着进行步骤 460， 执行所述并行的《个线程， 并令其按照所述调用映射策略 F调用执行模块。 在执行过程中， 每个执行模块 访问且仅访问其私有的内存池。
最后是步骤 470, 线程运行完成后删除所有创建的映像执行模块， 释放为映 像执行模块分配的资源。
图 5到图 7显示了依据本发明的方法进行内存访问控制后的性能与不使用 本发明时的比较， 通过以下示例体现。 要说明的是， 以下示例仅是为了说明本 发明的效果， 而非对本发明的实施条件进行限制。
以 windows操作系统为例， 通过对 pdf文件进行简单文字提取来进行测试。 测试环境： 软件环境 Windows XP professional SP2 32 bit, 硬件环境 Core 2 Quad Q6600 2.4GHz (4 core) 3.25GB内存。
测试工具： 使用微软公司发布的 platform sdk中的 ifilttst.exe测试工具程序 ifilttst.exe, 该程序仅仅对文件进行一次完整提取， 并不进行更多的检查性工作。 关于该测试工具为本领域公知常用的一种， 关于其详细资料， 可参考 http://msdn.microsoft.com/en-us/librarv/ms692580 ( 28VS.85 ) .aspx上的说明。
ifilttst.exe可对应创建不同数量的线程， 在运行中， 各个线程会调用一执行 模块 example.dll。 在图 5到图 7中的横坐标 1， 2, 3 , 4表示线程数， 对应的使 用多个不同的处理器核心运行。 纵坐标用文件处理速度表示的性能指数。 不同 的曲线分别表示针对使用本发明的方法和不使用时的执行情况。 其中， 本发明 的方法的实施方式为： 对不同的线程数 n， 分别创建 k=n- l个映射执行模块， 且 釆用静态方式下的静态映射策略。 即每个线程指向一个执行模块， 且在整个执 行过程中保持不变。
图 5的实施例中， 样本 1为 219个文件， 总大小 1.54GB , 特点： 文件较大， 文件个数较少。
图 6的实施例中， 样本 2为 351个文件， 总大小 1.16GB , 文件数目和每个 文件的大小较为平均。
图 7中的样本 3为 1274个文件， 总大小 925MB，文件数目多而且体积较小。 在图 5-7中， 曲线 L1为 ifilttst.exe使用本发明方法时的执行情况； 曲线 L2 为 ifilttst.exe未使用本发明加速方法前的运行情况。
从图 5到图 7可以看到， 测试工具程序 ifilttst.exe的单线程性能虽然没有提 高， 但是多线程的性能正真得到了释放， 每个核心都被利用了起来， 1到 4线程 时， 性能呈线性增长。 而未采用本发明加速方法的曲线 L2， 虽然随着 CPU核心 的增加性能也有所改进， 却无法将 CPU性能发挥到最佳， 性能始终受到限制。 以上对本发明的描述是说明性的， 而非限制性的， 本专业技术人员理解， 在权 利要求限定的精神与范围之内可对其进行许多修改、 变化或等效， 但是它们都 将落入本发明的保护范围内。

Claims

权利要求
1、 一种并行计算的内存访问方法， 用于存在调用同一原始执行模块的 n 2个并行线程的情况， 其特征在于， 包括以下步骤：
51 )根据线程数 n确定需创建的映像执行模块的个数 k， n-l > k > l ;
52 )确定该 n个线程与原始执行模块及 k个映像执行模块之间的映射策略 F; S3 ) 创建 k个映像执行模块， 并为其分配各自私有的内存池；
S4 )执行所述并行的 n个线程， 令各个线程按照所述映射策略 F调用执行 模块， 每个执行模块访问且仅访问其私有的内存池；
S5 ) 线程运行完成后删除创建的映像执行模块， 释放资源。
2、 根据权利要求 1所述的并行计算的内存访问方法， 其特征在于， 所述映 像执行模块的个数为 k是随时间变化的。
3、 根据权利要求 1所述的并行计算的内存访问方法， 其特征在于， 所述映 像执行模块的个数 k在线程执行期间是固定不变的。
4、 根据权利要求 3所述的并行计算的内存访问方法， 其特征在于， 根据同 一时间调用同一执行模块的线程个数的统计值来确定映像执行模块的数量 k。
5、 根据权利要求 3所述的并行计算的内存访问方法， 其特征在于， 所述映 像执行模块的个数 k为 1个。
6、 根据权利要求 3所述的并行计算的内存访问方法， 其特征在于， 所述映 像执行模块的个数 k为 n-1个。
7、 根据权利要求 6所述的并行计算的内存访问方法， 其特征在于， 所述映 射策略 F为： 每个线程分别调用一个不同的执行模块， 线程与执行模块是一一 对应的。
8、 根据权利要求 1所述的并行计算的内存访问方法， 其特征在于， 所述映 射策略 F 为静态策略， 一个线程仅指向一个被它调用的执行模块， 而一个执行 模块被一个或一个以上的线程调用。
9、 根据权利要求 8所述的并行计算的内存访问方法， 其特征在于， 所述映 射策略 F 为将调用执行模块频繁的线程， 配置为独享一个执行模块， 将相对调 用执行模块频率较低的线程， 配置为共享执行模块。
10、 根据权利要求 1 所述的并行计算的内存访问方法， 其特征在于， 所述 映射策略 F为动态策略的 "多窗口排队" 机制， 该策略 F中， 为每个执行模块 定义 "空闲" 、 "繁忙" 两个状态， 将所有的空闲执行模块排队， 需要调用执 行模块的线程从空闲执行模块队列中择一调用， 若没有空闲的则等待； 在线程 对执行模块的调用进行中将该执行模块标记为繁忙， 执行完毕后， 线程释放该 执行模块， 将其标记为空闲。
PCT/CN2010/000481 2010-04-07 2010-04-12 并行计算的内存访问方法 WO2011123991A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/638,974 US9448857B2 (en) 2010-04-07 2010-04-12 Memory access method for parallel computing

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010140502.6 2010-04-07
CN2010101405026A CN101799773B (zh) 2010-04-07 2010-04-07 并行计算的内存访问方法

Publications (1)

Publication Number Publication Date
WO2011123991A1 true WO2011123991A1 (zh) 2011-10-13

Family

ID=42595457

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/000481 WO2011123991A1 (zh) 2010-04-07 2010-04-12 并行计算的内存访问方法

Country Status (3)

Country Link
US (1) US9448857B2 (zh)
CN (1) CN101799773B (zh)
WO (1) WO2011123991A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115686870A (zh) * 2022-12-29 2023-02-03 深圳开鸿数字产业发展有限公司 并行计算方法、终端及计算机可读存储介质

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102231121B (zh) * 2011-07-25 2013-02-27 北方工业大学 基于内存映射的大数据文件快速并行提取方法
CN102955817A (zh) * 2011-08-30 2013-03-06 腾讯数码（深圳）有限公司 一种基于共享内存的对象管理与恢复方法及系统
CN103218360B (zh) * 2012-01-18 2016-08-03 中国石油天然气集团公司 工业实时数据库采用内存池技术实现动态内存管理的方法
CN103399825B (zh) * 2013-08-05 2015-12-23 武汉邮电科学研究院 一种无锁化内存申请释放方法
WO2015180668A1 (en) * 2014-05-28 2015-12-03 Mediatek Inc. Memory pool management method for sharing memory pool among different computing units and related machine readable medium and memory pool management apparatus
CN104881258A (zh) * 2015-06-10 2015-09-02 北京金山安全软件有限公司 缓冲区并发访问方法及装置
CN105094992B (zh) * 2015-09-25 2018-11-02 浪潮(北京)电子信息产业有限公司 一种处理文件请求的方法与系统
CN108595259B (zh) * 2017-03-16 2021-08-20 哈尔滨英赛克信息技术有限公司 一种基于全局管理的内存池管理方法
CN110162395B (zh) * 2018-02-12 2021-07-20 杭州宏杉科技股份有限公司 一种内存分配的方法及装置
CN109783242A (zh) * 2018-12-12 2019-05-21 平安科技（深圳）有限公司 海外控股估值流程控制方法、装置、计算机设备及存储介质
CN109684085B (zh) * 2018-12-14 2019-11-12 北京中科寒武纪科技有限公司 内存访问方法及相关产品
CN111290890B (zh) * 2019-01-28 2023-02-24 紫光展讯通信(惠州)有限公司 芯片筛选方法及装置
CN109921895A (zh) * 2019-02-26 2019-06-21 成都国科微电子有限公司 一种数据Hash值的计算方法及系统
CN112214304A (zh) * 2019-07-09 2021-01-12 中科寒武纪科技股份有限公司 内存调度方法及装置
CN111309289B (zh) * 2019-11-19 2023-04-25 上海金融期货信息技术有限公司 一种内存池管理组件
CN113296962B (zh) * 2021-07-26 2022-01-11 阿里云计算有限公司 内存管理方法、装置、设备及存储介质
CN116166566A (zh) * 2023-04-23 2023-05-26 成都华兴汇明科技有限公司 一种测试用例多线程调度方法、系统及测试管理装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083252A1 (en) * 2000-12-27 2002-06-27 International Business Machines Corporation Technique for using shared resources on a multi-threaded processor
CN101477458A (zh) * 2008-12-15 2009-07-08 浙江大学 基于处理器和fpga混合架构的硬件线程执行方法
CN101604263A (zh) * 2009-07-13 2009-12-16 浪潮电子信息产业股份有限公司 一种实现操作系统核心代码段多副本运行的方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7234144B2 (en) * 2002-01-04 2007-06-19 Microsoft Corporation Methods and system for managing computational resources of a coprocessor in a computing system
US20050050310A1 (en) * 2003-07-15 2005-03-03 Bailey Daniel W. Method, system, and apparatus for improving multi-core processor performance
US8144149B2 (en) * 2005-10-14 2012-03-27 Via Technologies, Inc. System and method for dynamically load balancing multiple shader stages in a shared pool of processing units
CN100487660C (zh) 2007-05-28 2009-05-13 中兴通讯股份有限公司 一种多线程处理器动态内存管理系统及方法
CN101493787B (zh) * 2009-02-18 2011-05-11 中兴通讯股份有限公司 一种内存操作的管理方法及系统
US9354944B2 (en) * 2009-07-27 2016-05-31 Advanced Micro Devices, Inc. Mapping processing logic having data-parallel threads across processors

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083252A1 (en) * 2000-12-27 2002-06-27 International Business Machines Corporation Technique for using shared resources on a multi-threaded processor
CN101477458A (zh) * 2008-12-15 2009-07-08 浙江大学 基于处理器和fpga混合架构的硬件线程执行方法
CN101604263A (zh) * 2009-07-13 2009-12-16 浪潮电子信息产业股份有限公司 一种实现操作系统核心代码段多副本运行的方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115686870A (zh) * 2022-12-29 2023-02-03 深圳开鸿数字产业发展有限公司 并行计算方法、终端及计算机可读存储介质
CN115686870B (zh) * 2022-12-29 2023-05-16 深圳开鸿数字产业发展有限公司 并行计算方法、终端及计算机可读存储介质

Also Published As

Publication number Publication date
US9448857B2 (en) 2016-09-20
US20130061018A1 (en) 2013-03-07
CN101799773B (zh) 2013-04-17
CN101799773A (zh) 2010-08-11

Similar Documents

Publication Publication Date Title
WO2011123991A1 (zh) 并行计算的内存访问方法
EP3425502B1 (en) Task scheduling method and device
US11010199B2 (en) Efficient critical thread scheduling for non-privileged thread requests
US9858241B2 (en) System and method for supporting optimized buffer utilization for packet processing in a networking device
WO2023082560A1 (zh) 一种任务处理方法、装置、设备及介质
WO2022247105A1 (zh) 一种任务调度方法、装置、计算机设备和存储介质
CA2697155A1 (en) Allocating network adapter resources among logical partitions
US20080229319A1 (en) Global Resource Allocation Control
WO2013044829A1 (zh) 用于非一致性内存访问的数据预取方法和装置
WO2021022964A1 (zh) 一种基于多核系统的任务处理方法、装置及计算机可读存储介质
US8291426B2 (en) Memory allocators corresponding to processor resources
US10579416B2 (en) Thread interrupt offload re-prioritization
US9400692B2 (en) System and method for managing the allocating and freeing of objects in a multi-threaded system
US10289306B1 (en) Data storage system with core-affined thread processing of data movement requests
CN113312323A (zh) 并行文件系统中降低访问延迟的io请求调度方法及系统
Li et al. Improving spark performance with zero-copy buffer management and RDMA
CN112114967B (zh) 一种基于服务优先级的gpu资源预留方法
CN111124691A (zh) 多进程共享的gpu调度方法、系统及电子设备
EP3066568A1 (en) System and method for supporting efficient packet processing model and optimized buffer utilization for packet processing in a network environment
WO2024001851A1 (zh) 一种资源调度方法、装置及系统
WO2023116910A1 (zh) 一种计算资源和缓存资源调度方法、装置及系统
US9489327B2 (en) System and method for supporting an efficient packet processing model in a network environment
Zeng et al. Enabling Efficient Spatio-Temporal GPU Sharing for Network Function Virtualization
CN117707425A (zh) 适应cpu多核的io流水线智能分组方法及系统
WO2021120841A1 (zh) 虚拟机创建及cpu资源分配方法、装置、设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10849231

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 13638974

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 10849231

Country of ref document: EP

Kind code of ref document: A1