Message passing system between local memory based master and slave cores

Abstract

The application discloses a message passing system between master cores and slave cores based on local memories. The system provides a general message passing programming interface on different platforms such as x86 microprocessors, SW26010 processors, heterogeneous fusion accelerators for E-class computing, and the like. Compared with traditional programming based on unique interfaces of domestic high-performance many-core processors, the following advantages are achieved: a simple programming model is easy to learn, and programming difficulty is reduced; application software can be quickly migrated on different types of domestic high-performance microprocessors by only modifying a compiler configuration; and in terms of software development methods, high-performance computing software can be firstly developed and debugged based on an x86 platform, and then the application software is transplanted to a domestic high-performance many-core processor, so that the development difficulty can be effectively reduced. These characteristics can effectively improve the efficiency of development and migration of domestic high-performance computing software.

Description

Technical Field

[0001] This invention relates to the field of many-core processors, and more specifically to a message passing system between a master core and slave cores based on local memory. Background Technology

[0002] (1) Architecture of domestic many-core processors

[0003] like Figure 1 As shown, a single SW26010 microprocessor (Haohuan FU, Junfeng LIAO. The SunwayTaihu Light supercomputer: system and applications[J]. Science China Information Sciences, 2016, 59(7):1-16) contains four heterogeneous clusters. Each heterogeneous cluster consists of a master core and a cluster of 64 slave cores, with a clock speed of 1.5 GHz. Figure 2 As shown. Each heterogeneous cluster has the same memory hierarchy, consisting of a heterogeneous cluster memory (8GB) and slave core local memory. The master core has a 32KB L1 data cache and a 256KB L2 cache (data and instructions). Each slave core has 64KB of local memory and 16KB of instruction storage, supporting a 256-bit SIMD instruction set. Slave cores can access master memory via direct access or DMA.

[0004] The accelerator chip for exascale high-performance computing (Liu Sheng, Lu Kai, Guo Yang, Liu Zhong, Chen Haiyan, Lei Yuanwu, Sun Haiyan, Yang Qianming, Chen Xiaowen, Chen Shenggang, Liu Biwei, Lu Jianzhuang. A Self-Designed Heterogeneous Accelerator for Exascale High Performance Computing[J]. Journal of Computer Research and Development, 2021, 58(6):1234-1237.) adopts a heterogeneous fusion architecture of CPU+GPDSP, consisting of a multi-core CPU and 4 GPDSP_Clusters, such as... Figure 3As shown, the multi-core CPU comprises 16 FT-C662 CPU cores. Each GPDSP_Cluster contains 6 DSP nodes (each DSP node contains 4 DSP cores). The multi-core CPU uses hardware-maintained cache coherency and includes 16MB of L2 cache. The GPDSP cluster employs a three-tier storage structure: 80MB of private memory, 24MB of global shared memory, and 32GB of HBM memory. Each DSP core includes 64KB of private scalar memory (SM) and 768KB of private vector memory (AM). The DSP cores utilize Very Long Instruction Word (VLIW) technology and a scalar-vector fusion structure. The vector unit consists of 16 homogeneous VPE arrays, supporting up to 1024-bit SIMD instruction operations.

[0005] (2) Abstraction of the architecture of domestic many-core processors

[0006] Taking the SW26010, an accelerator chip designed for exascale high-performance computing, as an example, domestically produced many-core high-performance microprocessors have the following characteristics:

[0007] 1. They all adopt an asymmetric structure, including a small number of complex main cores and a large number of relatively simple computing cores. The main processor is responsible for handling complex logic control tasks, while the coprocessor is responsible for handling large-scale data parallel tasks with high computational density and simple logical branches.

[0008] 2. Each computing core has its own independent local memory space, and these memory spaces do not have cache coherence. Programmers need to control the data exchange between the main system memory and the memory of each computing core through explicit program control.

[0009] 3. There are two methods for data exchange between the master core and the slave core: 1) The slave core directly accesses the master core's memory space, which has a long latency and is only suitable for transmitting control information; 2) The DMA process initiated by the slave core can transfer large amounts of data.

[0010] 4. Supports SIMD instructions at the core level; the width of SIMD varies across different processors.

[0011] 5. The slave core does not have operating system support for multiple processes (threads); it only supports one thread running on the slave core. Different processors have different slave core thread programming interfaces.

[0012] It can be used Figure 4The abstract structure described above illustrates these two different types of many-core processors. A complete processor cluster consists of one master core and N slave cores. The master core accesses main memory via an on-chip cache. Slave cores have local memory and do not support cache coherence protocols; data exchange between the master core's memory and slave cores is handled by DMA. Each slave core has a SIMD instruction set. The data width of SIMD varies across different processors. Table 1 shows the main architectural parameters of the SW26010 and the heterogeneous converged accelerator for exascale computing.

[0013] (3) Existing multi-core processor programming models

[0014] OpenMP (DE SUPINSKI BR, SCOGLAND TRW, DURANA, et al. The ongoing evolution of openmp[J]. Proceedings of the IEEE, 2018, 106(11): 2004-2019.) is a common multithreaded programming interface on current symmetric multiprocessor systems and is widely supported. Applications developed based on this standard have good portability.

[0015] Cilk (Leiserson, Charles E.; Plaat, Aske (1998). "Programming parallel applications in Cilk". SIAM News. 31.) is a task-based multithreaded parallel programming extension. Building upon this, Cilk++ (Leiserson C E. The Cilk++ concurrency platform[J]. The Journal of Supercomputing, 2010, 51(3): 244-257.) uses the keywords _Cilk_for, _Cilk_spawn, and _Cilk_sync to extend C / C++ in a parallel manner. At runtime, a divide-and-conquer approach is used to schedule tasks among worker threads to ensure load balancing across multiple threads.

[0016] Intel introduced the open-source threading building block library TBB (Threading Building Blocks) (Anonymous "Intel threading building blocks; outfitting C++ for multi-core processor parallelism," SciTech Book News, vol. 32, (3), 2008. / / REINDERS J. Intel threading building blocks: Outfitting C++ for multi-core processor parallelism 1st edition). TBB uses tasks as the scheduling unit and is portable to POSIX and Windows thread libraries. In 2018, Intel also announced the OneAPI software programming framework. OneAPI aims to provide a unified programming model and application interface for CPUs, GPUs, FPGAs, neural network processors, or other hardware accelerators. The core of OneAPI is the programming language Data Parallel C++ (DPC++) (James Reinders et al. Data Parallel C++ [M]. Apress, Berkeley, CA, 2021. Gerhard R. Joubert, Hugh Leather, Mark Parsons, Frans Peters, Mark Sawyer, Ruyman Reyes, Victor Lomüller. SYCL: Single-source C++ accelerator programming [J]. Advances in Parallel Computing, 2016, 27.). DPC++ is essentially an extension of C++, adding support for the SYCL programming model. It can support data parallelism and heterogeneous programming across CPUs and accelerators to simplify programming and improve code reusability on different hardware, while also being able to be tuned for specific accelerators.

[0017] Taking the SW26010, a heterogeneous converged accelerator for exascale computing, as an example, the SW26010 many-core processor provides an Athread function library for creating and managing threads, with each thread bound to a slave core. In Athread, the master core interface is responsible for controlling thread creation and recycling, thread scheduling, interrupt and exception management, and asynchronous mask support. The slave core interface is responsible for initiating data transmission, performing core computations, thread identification, and interrupt sending.

[0018] The heterogeneous fusion accelerator for exascale computing utilizes the hthread multithreaded programming interface. This interface includes a host-side programming interface and a slave-side device-side programming interface. The host-side programming interface mainly includes device management, image management, thread management, device-side memory management, and device-side shared resource management. The device-side programming interface mainly includes a parallel management interface, a DSP on-chip memory management interface, synchronization management, a terminal / exception handling function interface, and a vectorized function interface.

[0019] In summary, improving the portability of application software across different hardware platforms has become a major focus of international high-performance software programming models. However, the architecture and operating system of domestically produced high-performance many-core microprocessors have their own unique characteristics, making it difficult to directly use existing programming models, and they are not interchangeable, seriously hindering the development of domestic high-performance software. At the same time, current SIMD programming models also have some problems. For example, OpenMP and Cilk++ require compiler version support; MAL only supports some macros in the ISA and cannot be used on domestic many-core processors; the VC library and gSIMD method encapsulate SIMD instructions, meaning users do not directly manipulate vector instructions, but the library fills the vector width, and its supported instruction set is also very limited. Summary of the Invention

[0020] my country's independently developed high-performance many-core processors, such as the SW26010 and heterogeneous fusion accelerators for exascale computing, employ a small number of master cores and multiple slave cores. The slave cores use local memory without cache coherence, which differs significantly from traditional SMP (Symmetric Multiprocessor) and CC-UMA (Cache-Coherent Unified Memory Access) architectures. Furthermore, the interfaces for thread usage and local memory data transfer on slave cores are unique to each processor and differ considerably from common international standards. This directly leads to two problems: 1) Software development for domestically produced high-performance many-core processors requires direct use of the lowest-level interfaces, and debugging is generally only possible remotely at supercomputing centers, making software development quite difficult; 2) Domestically developed software is not interchangeable across different high-performance many-core processors, further fragmenting the already weak domestic software development capabilities and resulting in much repetitive development work.

[0021] This invention proposes a message-passing system between master and slave cores based on local memory. It presents a general method for message passing between master and slave cores, providing a universal message-passing programming interface on different platforms such as x86 microprocessors, SW26010 processors, and heterogeneous fusion accelerators for exascale computing. Compared with traditional programming based on proprietary interfaces of domestically produced high-performance many-core processors, it has the following advantages: 1) The programming model is simple and easy to learn, reducing programming difficulty; 2) Application software can be quickly migrated to different types of domestically produced high-performance microprocessors with only compiler configuration modifications; 3) In terms of software development methodology, high-performance computing software can be developed and debugged first using a model based on the x86 platform, and then the application software can be ported to domestically produced high-performance many-core processors, effectively reducing development difficulty. These features will effectively improve the efficiency of developing and migrating domestically produced high-performance computing software.

[0022] The objective of this invention is achieved by at least one of the following technical solutions.

[0023] A message passing system between master and slave cores based on local memory, including a set of master cores M, denoted as m1,…,m |M| Where |M| represents the number of master cores in the master core set M; master core m i Corresponding to one or more kernel sets S a And satisfy |S a |=|S b |,|S a | indicates that from the kernel set S a The number of slave cores in the array, 1≤a,b≤M;

[0024] Through the core thread management interface, a main core m i It can manage the kernel set S i , 1≤i≤|M|;

[0025] Among them, in creating the i-th main core m i up to the i-th kernel set S i The j-th kernel s i,j The k-th message queue q i,j,k At that time, s i,j ∈S i , 1≤j≤|S i |, 1≤k, can utilize the calling interface on the main core m i and from the core i,j Create the corresponding message queue q in memory. i,j,k All main cores m i From the core i,j message queue q i,j,k This forms the set Q, q i,j,k ∈Q, complete the main kernel mi and from the core i,j The connection between them;

[0026] main core m i Or from the core i,j Through the message sending mechanism, a series of messages r x Transmitted to message queue q i,j,k In this process, a message sequence set R is obtained, and the messages in the set are sent in an ordered manner, where 1 ≤ x, r x ∈R;

[0027] From the core i,j or main core m i According to message queue q i,j,k The relevant information is used to select the corresponding message r from the message sequence R. x , where r x ∈R, 1≤x≤|R|, user obtains message r x Complete the custom message r x After processing, message queue q i,j,k Release the message r x Memory used;

[0028] From the core i,j After processing the data, log out of the slave core. i,j The cache, main core m i The running thread is recycled from the core. i,j The thread continues to process the main core m i The remaining tasks, if there are no tasks, then the main core m i Unregister the cache, and the program will terminate in parallel using multiple threads.

[0029] Furthermore, to create a message queue on the main core, the following parameters need to be specified:

[0030] The message queue name (qName) is a string, the slave ID is the connection number, the message size is msgSize, the number of messages the message queue can hold on the master core is mSize, the number of messages it can hold on the slave core is sSize, the starting address of the master core message queue is mQaddr, the type of memory occupied by the message queue on the slave core is sType, and the direction of the message queue is direction; a handle number will be returned upon successful call.

[0031] The master core identifies a queue entity using either (slave core number, handle number) or (slave core number, queue name); the slave core uses either the handle number or the queue name as the unique identifier of the queue to determine the unique queue entity; the handle of the same queue is the same on the master core and the slave core.

[0032] Message queues are used solely for communication between the master and slave cores. Users can specify the slave ID of the slave core where the queue resides; multiple different message queues can be set between a pair of master and slave cores.

[0033] The size of each message in the message queue is no greater than msgSize bytes;

[0034] A message queue is distributed in the main core memory and the local memory of the slave core, and the number of messages it can hold is mSize and sSize, respectively;

[0035] The starting address of the message queue in the main core memory is a contiguous memory space specified by the application, with the starting address being mQaddr;

[0036] If the local memory on the kernel has different types, the type of local memory occupied by the message queue can be specified by the kernel memory type sType;

[0037] The message queue is unidirectional, with two directions: master core write / slave core read and slave core write / master core read, specified by the direction parameter.

[0038] The master core can create multiple message queues between the master core and one slave core. The message queues between the master core and all slave cores constitute a message queue set.

[0039] The master core controls the slave core threads according to the slave core thread management interface. This mainly involves creating and starting slave core thread groups, waiting for thread groups to terminate, closing thread groups, and loading image files to the device by the master core.

[0040] Furthermore, a message queue has a contiguous storage space in both the master core and slave core to store message content. The number of messages that the two can hold is divided into mSize and sSize, and the memory capacity occupied is mSize×msgSize bytes and sSize×msgSize bytes, respectively. The capacity of the message queue slave core is limited by the capacity of the local memory.

[0041] The control information layout for each message queue is divided into two parts: a status list and a position index;

[0042] The location indices are divided into: IMTran, IMReady, IMLocked, and IMIdle, which are related to the master core location; and ISTran, ISReady, IMLocked, and ISIdle, which are related to the slave core location. The design varies depending on the message queue direction. In the message queue control information layout from the master core to the slave core, IMLocked and IMIdle are stored in the master core address region; IMTran, IMReady, and the other four location indices are located in the slave core's local memory. Conversely, in the message queue control information layout from the slave core to the master core, IMReady, IMLocked, and IMIdle are stored in the master core address region; IMTran and the other four location indices are located in the slave core's local memory.

[0043] IMTran indicates the message position index of the first message block in the main core space that is in transit; IMReady indicates the message position index of the first message block in the main core space that is ready; IMLocked indicates the message position index of the first message block in the main core space that is locked; IMIdle indicates the message position index of the first message block in the main core space that is idle.

[0044] ISTran indicates the index of the first message block in the kernel space that is in transit; ISReady indicates the index of the first message block in the kernel space that is ready; ISLocked indicates the index of the first message block in the kernel space that is locked; ISIdle indicates the index of the first message block in the kernel space that is idle.

[0045] Each state in the state list corresponds one-to-one with each message block in the circular message block data area; the message block state list of the master core and the message block state list of the slave core are denoted as MState and SState, respectively, and are located in the master core address area and the slave core local memory, respectively.

[0046] A message queue is divided into a master core part and a slave core part;

[0047] When the message queue is created, the number of messages that the main core and the slave core can hold are already determined.

[0048] The position index in the message queue control information layout will have different designs depending on the direction of the message queue. Storing unnecessary variables of the main core in the slave core can reduce the access of slave core code to main core variables, thereby improving the performance of the model.

[0049] Furthermore, in the message queue from the master core to the slave core, the state of a message block in the master core includes: MasterIdle, MasterLocked, MasterReady, MTransferring; the state of a message block in the slave core includes: SlaveIdle, STransferring, SlaveReady, SlaveLocked; the state information of each message block is stored in its respective memory.

[0050] After the message queue is created, all message blocks in the master core are in the MasterIdle state, and all message blocks in the slave core are in the SlaveIdle state.

[0051] MasterIdle indicates that the message block in the master core is in an idle and allocable state; MasterLocked indicates that the message block in the master core is in a locked state; MasterReady indicates that the message block in the master core is ready to be used; and MTransferring indicates that the message block in the master core is in a transfer state.

[0052] SlaveIdle indicates that the message block in the slave core is idle and available for allocation; STransferring indicates that the message block in the slave core is in transit; SlaveReady indicates that the message block in the slave core is ready to be used; SlaveLocked indicates that the message block in the slave core is locked.

[0053] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0054] M1 and mAllocateMsg() obtain the address of a message block in the message queue main core.

[0055] M2 and mSendMsg() initiate the master core to send messages to the slave core;

[0056] M3 and mRecvMsg() receive a message sent from the core;

[0057] M4 and mReleaseMsg() release a message in the main core.

[0058] The message queuing system provides the following interfaces to kernel applications:

[0059] S1, sRecvMsg(), receives a message sent by the main core;

[0060] S2, sReleaseMsg(), releases a message from the kernel;

[0061] S3 and sAllocateMsg() retrieve the address of a message block from the kernel in the message queue.

[0062] S4 and sSendMsg() initiate the transmission of messages from the slave core to the master core.

[0063] In the above interfaces, M1, M2, S1 and S2 are used for the master core to pass messages to the slave core, and M3, M4, S3 and S4 are used for the slave core to pass messages to the master core.

[0064] Furthermore, the operation sequence for sending a message from the master core to the slave core includes:

[0065] a1. The main core application calls mAllocateMsg(); the message passing system between the main core and slave cores based on local memory allocates a free message block pointed to by the position index IMIdle in the main core part of the message queue, sets the block to the MasterLocked state, moves IMIdle in a loop, and returns the block address MasterMsg to the main core application.

[0066] a2. The main application sets the message to be sent in the idle message block pointed to by MasterMsg;

[0067] a3. The main core application calls mSendMsg() to obtain the first message block MasterMsg pointed to by the position index IMLocked. The message passing system between the main core and the slave core based on local memory will set the message block MasterMsg to the MasterReady state and move IMLocked in a loop.

[0068] a4. The message passing system between the master and slave cores based on local memory allocates a free message block message storage space SlaveMsg, pointed to by the location index ISIdle, in the slave core at a set time for the message block to be transferred, and cyclically moves ISIdle; it starts DMA to transfer the message block in MasterMsg to SlaveMsg, obtains the first message block MasterMsg pointed to by the location index IMReady, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the message passing system between the master and slave cores based on local memory sets the message block SlaveMsg pointed to by the slave core message block location index ISTran to the SlaveReady state, and sets the message block MasterMsg pointed to by the master core message block location index IMTran to the MasterIdle state;

[0069] a5. Call sRecvMsg() from the kernel application; The message queue returns the message block SlaveMsg, which is already in the slave part, pointed to by the position index ISReady, and sets it to SlaveLocked;

[0070] a6. Read the contents of SlaveMsg from the kernel application;

[0071] a7. Call sReleaseMsg() from the kernel application; the message queue will set the kernel message block SlaveMsg to the SlaveIdle state.

[0072] The sequence of operations for sending a message from the core to the master core includes:

[0073] b1. The kernel application calls sAllocateMsg(); the message passing system between the master and slave kernels based on local memory allocates an idle message block pointed to by the position index ISIdle in the slave kernel part of the message queue, sets the block to the SlaveLocked state, moves ISIdle in a loop, and returns the block address SlaveMsg to the master kernel application.

[0074] b2. The kernel application sets the message to be sent in the idle message block pointed to by SlaveMsg;

[0075] b3. Call sSendMsg() from the application; retrieve the first message block SlaveMsg pointed to by the position index ISLocked; the message passing system between the master and slave cores based on local memory will set the message block SlaveMsg to the SlaveReady state; cyclically move ISLocked;

[0076] b4. When the local memory-based message passing system between the master and slave cores is set up, it allocates a free message block message storage space, MasterMsg, pointed to by the location index IMIdle, in the slave core for the message block to be transmitted; it starts DMA to transfer the message block in SlaveMsg to MasterMsg, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the local memory-based message passing system between the master and slave cores sets the MasterMsg pointed to by the message block location index IMTran in the master core to the MasterReady state, and sets the SlaveMsg pointed to by the message block location index ISTran in the slave core to the SlaveIdle state.

[0077] b5. The main application calls mRecvMsg(); the message queue returns to the main application a message block address MasterMsg, which is already in the main part of the main application and is pointed to by the position index IMReady.

[0078] b6. The main core application reads the contents of MasterMsg;

[0079] b7. The main core application calls mReleaseMsg(); the message queue sets the main core message block MasterMsg to the MasterIdle state.

[0080] Applications on the master or slave cores can directly read and write message blocks within the memory area managed by the message queue, without having to move the message content to other memory spaces. This reduces both the overhead of moving message content and the usage of local memory on the slave core.

[0081] The master or slave application only initiates message transmission or reception, without needing to consider the specific implementation of message transmission between the master and slave cores; the message transmission is implemented by the message passing system between the master and slave cores based on local memory; this simplifies application design and also makes the application more portable.

[0082] Furthermore, the blocking message transmission process between the master core and the slave core is as follows:

[0083] Each message queue will maintain a DMA request set DMAreqs; this set is initialized to an empty set.

[0084] During the process of the master core sending a message / the slave core receiving a message, the application calls the interface sRecvMsg(); within sRecvMsg(), the following steps are executed:

[0085] A1. Determine if the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step A2; otherwise, proceed to step A3.

[0086] A2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveReady, set the status of req.MMsg to MasterIdle, and remove the req from DMAreqs.

[0087] A3. Determine whether the slave core can obtain the message block SMsg in the SlaveIdle state and whether the master core can obtain the message block MMsg in the MasterReady state. If yes, proceed to step A4; otherwise, proceed directly to step A5.

[0088] A4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req = {MMsg, SMsg}, add req to DMAreqs, and execute step A3 again.

[0089] A5. If any message in the kernel part of the message is in the SlaveReady state, then set the earliest SlaveReady state message Msg to the SlaveLocked state and return Msg to the end of the application; otherwise, execute step A1.

[0090] The DMA request set DMAreqs is initialized to empty.

[0091] During the process of sending a message from the kernel / receiving a message from the master kernel, the kernel application calls the interface sSendMsg(); within sSendMsg(), the following steps are executed:

[0092] B1. Determine if the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step B2; otherwise, proceed to step B3.

[0093] B2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveIdle, set the status of req.MMsg to MasterReady, and remove the req from DMAreqs.

[0094] B3. Determine whether the slave core can obtain the message block SMsg in the SlaveReady state and whether the master core can obtain the message block MMsg in the MasterIdle state. If yes, proceed to step B4; otherwise, proceed directly to step B5.

[0095] B4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req = {MMsg, SMsg}, add req to DMAreqs, and execute step B3 again.

[0096] B5. If the message sent by the core is in the SlaveLocked state, set the SlaveLocked message Msg to the SlaveReady state and return Msg to the end of the application; otherwise, proceed to step B1.

[0097] The DMA request set DMAreqs is initialized to empty.

[0098] Furthermore, there are two different ways to access the main core's memory space from the kernel: direct access and asynchronous DMA transfer. Direct access is less efficient and suitable for accessing small amounts of data. Asynchronous DMA transfer consists of two steps: starting the DMA transfer process and querying the DMA result. After starting the DMA transfer, the software system can complete other tasks without waiting for the DMA to finish, and can know whether the DMA has been completed by querying the DMA result.

[0099] During the blocking process of the master core sending a message / the slave core receiving a message, it will only return after the slave core receives the message from the master core; otherwise, it will wait indefinitely for the master core to send a message.

[0100] When the slave core receives a message, it will initiate the DMA transfer process for the message that is already in the MasterReady state in the master core. When the slave core has two or more message blocks and the master core sends messages at a rate higher than the slave core uses messages, the slave application can read messages and the DMA transfer process can be completed in parallel.

[0101] Furthermore, the message queue is created by the master core, generating a new queue handle (handle) on both the master and slave cores. On the master core, handles are partitioned according to different slave core numbers. On the slave cores, the handle number (handle) or the queue name (qName) can uniquely identify the queue entity. The handle of the same queue on the master core includes the handle on the slave core; that is, the queue corresponding to (SlaveID, handle) on the master core and the queue with handle (handle) on the SlaveID slave core are the same queue entity. The status of a specific message queue can be queried through the message queue identifier (handle), which mainly includes whether the queue exists, its direction, the size of the message, and the number of messages in the current queue.

[0102] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0103] M5, mQueryQueue(), checks if the message queue exists;

[0104] M6, mQueueDirection(), get the queue direction of the message queue;

[0105] M7 and mQueueMsgNumInMaster() retrieve the number of messages that the control core of the message queue can hold.

[0106] M8 and mQueueMsgNumInSlave() retrieve the number of messages that the computational core of the message queue can hold.

[0107] M9 and mQueueMsgSize() get the maximum number of bytes per message in the message queue.

[0108] M10 and mQueueMsgSlaveMemType() retrieve the memory type of the slave portion of the message queue.

[0109] M11 and mQueueMsgNumStatus() are used to retrieve dynamic information about the message queue.

[0110] M12, mCreateQueue(), creates a message queue;

[0111] The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications:

[0112] S5, sQueryQueue(), checks if the message queue exists;

[0113] S6, sQueueDirection(), gets the queue direction of the message queue;

[0114] S7, sQueueMsgNumInMaster(), gets the number of messages that the control core of the message queue can hold;

[0115] S8, sQueueMsgNumInSlave(), get the number of messages that the computational core of the message queue can hold;

[0116] S9, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue;

[0117] S10, sQueueMsgSlaveMemType(), retrieves the memory type of the slave portion of the message queue;

[0118] S11, sQueueMsgNumStatus(), retrieve dynamic information about the message queue;

[0119] Interfaces M5-M12 are used to query relevant message queue information on the master core, and interfaces S5-S11 are used to query relevant message queue information on the slave core.

[0120] Furthermore, when a user creates a message queue, a unique message queue handle is generated, which can be obtained by the handle number or the queue name;

[0121] Both the master and slave cores can obtain the corresponding status information of the message queue; since the master core needs to communicate with multiple slave cores, (slave core number, handle number) or (slave core number, queue name) can identify a unique queue entity; on the slave core side, the handle number handle or the queue name qName can identify a unique queue entity.

[0122] Furthermore, the following interfaces are set up for use on different high-performance many-core processors, covering the steps required for communication between the master core and slave cores, including the slave core management mechanism on the master core. Using these interfaces allows the code to be quickly ported to a variety of high-performance many-core processors while completing the corresponding functions. When porting to a new platform, you only need to recompile the code and specify the compilation options for the corresponding platform during compilation.

[0123] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0124] M13, mHaltDevice: Exit the operating environment of the acceleration device;

[0125] M14, mHMessQueueInit: The initialization method for controlling the core cache.

[0126] M15, mHMessQueueQuit: Controls the unregistration method of the core cache;

[0127] M16, mLoadDatFile: Loads the image file to the device; only MT3 requires this function.

[0128] M17, mUnloadDatFile: Unloads the image file to the device; only MT3 requires this function.

[0129] M18, mGetSlaveCoreNum: Get the number of computing cores; Controls the unregistering method of the core cache.

[0130] M19, mGetMemSize: Get the storage size of the control core and compute core, in bytes.

[0131] M20, mGetSlaveSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core.

[0132] M21, mInitDevice: Loads the runtime environment of the acceleration device.

[0133] M22, mGetInitThreadID: Retrieves the initialized thread data structure.

[0134] M23, mStartSlaveThreads: Creates and starts thread groups that bind to computing cores.

[0135] M24, mWaitSlaveThreads: Waiting for the thread group to terminate.

[0136] M25, mDestroySlaveThreads: Close the thread group

[0137] M26, mSlaveThreadActive: Get whether the threads of the computing core are active.

[0138] The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications:

[0139] S12, sHMessQueueInit(): The message queue is initialized from the core;

[0140] S13, sHMessQueueQuit: Calculates the unregistering method of the core cache, and obtains the queue direction of the message queue;

[0141] S14, sGetSlaveNum: Get the number of computing cores(), which is the number of messages that the control core of the message queue can hold.

[0142] S15, sGetSlaveID: Get the current computing core number (), and get the number of messages that the computing core part of the message queue can hold;

[0143] S16, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue;

[0144] S17, sSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core (), and get the memory type of the slave part in the message queue;

[0145] In the above interfaces, M13-M20 are used to query relevant message queue information on the main core, M21-M26 are used to manage slave core threads on the main core, and S12-S20 are used to query relevant message queue information on the slave core.

[0146] The aforementioned interfaces cover the functions required by various high-performance many-core processors, and the provided interface set I consists of the underlying interfaces L for different high-performance many-core processors. i The union of the sets, 1≤i, i.e., I={L1∪L2…;}, if a function i in the interface set I is called on a processor L1 that does not have the corresponding function function, i.e., i∈I, The code will not have any negative impact;

[0147] Macro-based programming allows different predefined macros to be used on different processors. These predefined macros are set at compile time, and the same effect can be achieved by calling the same interface on different high-performance many-core processors. This encapsulates the differences in the underlying libraries between different many-core processors.

[0148] Compared with the prior art, the advantages of the present invention are:

[0149] This invention addresses the issue of inconsistent thread programming libraries in domestically produced high-performance many-core processors by providing a slave-core thread management mechanism for controlling threads across multiple platforms. Furthermore, to address the problem of each slave core using an independent memory space lacking cache coherency and requiring explicit program control over data exchange between the main system memory and the individual computing core memories, this model provides a message queue.

[0150] Supported by this programming model, high-performance computing software can be developed and debugged first using a model based on the x86 platform, and then the application software can be ported to domestically produced high-performance many-core processors. This not only effectively reduces development difficulty, but also allows the same software to be quickly migrated between two different types of domestically produced high-performance microprocessors, significantly improving the efficiency of developing and migrating domestically produced high-performance computing software. Attached Figure Description

[0151] Figure 1 This is a diagram of a single heterogeneous cluster architecture in the SW26011 processor.

[0152] Figure 2 This is a schematic diagram of an accelerator chip structure designed for exascale high-performance computing.

[0153] Figure 3 This is an abstract schematic diagram of the architecture of a domestically produced high-performance heterogeneous processor.

[0154] Figure 4 This is a schematic diagram of the memory structure of the message queue and the status of messages in an embodiment of the present invention.

[0155] Figure 5 This is a schematic diagram of the control information layout of the message queue from the master core to the slave core in an embodiment of the present invention.

[0156] Figure 6 This is a flowchart illustrating the implementation of a message passing system between the master and slave cores based on local memory in this invention.

[0157] Figure 7 This is a performance diagram of the password guessing program in an embodiment of the present invention. Detailed Implementation

[0158] To make the objectives, technical solutions, and advantages of the present invention clearer, the specific implementation of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0159] Example:

[0160] A message passing system between master and slave cores based on local memory, including a set of master cores M, denoted as m1,…,m |M| Where |M| represents the number of master cores in the master core set M; master core m i Corresponding to one or more kernel sets S a And satisfy |S a |=|S b |,|S a | indicates that from the kernel set S a The number of slave cores in the array, 1≤a,b≤M;

[0161] Through the core thread management interface, a main core m i It can manage the kernel set S i , 1≤i≤|M|;

[0162] Among them, in creating the i-th main core m i up to the i-th kernel set S i The j-th kernel s i,j The k-th message queue q i,j,k At that time, s i,j ∈S i , 1≤j≤|S i |, 1≤k, can utilize the calling interface on the main core m i and from the core i,j Create the corresponding message queue q in memory. i,j,k All main cores m i From the core i,j message queue qi,j,k This forms the set Q, q i,j,k ∈Q, complete the main kernel m i and from the core i,j The connection between them;

[0163] main core m i Or from the core i,j Through the message sending mechanism, a series of messages r x Transmitted to message queue q i,j,k In this process, a message sequence set R is obtained, and the messages in the set are sent in an ordered manner, where 1 ≤ x, r x ∈R;

[0164] From the core i,j or main core m i According to message queue q i,j,k The relevant information is used to select the corresponding message r from the message sequence R. x , where r x ∈R, 1≤x≤|R|, user obtains message r x Complete the custom message r x After processing, message queue q i,j,k Release the message r x Memory used;

[0165] From the core i,j After processing the data, log out of the slave core. i,j The cache, main core m i The running thread is recycled from the core. i,j The thread continues to process the main core m i The remaining tasks, if there are no tasks, then the main core m i Unregister the cache, and the program will terminate in parallel using multiple threads.

[0166] Furthermore, to create a message queue on the main core, the following parameters need to be specified:

[0167] The message queue name (qName) is a string, the slave ID is the connection number, the message size is msgSize, the number of messages the message queue can hold on the master core is mSize, the number of messages it can hold on the slave core is sSize, the starting address of the master core message queue is mQaddr, the type of memory occupied by the message queue on the slave core is sType, and the direction of the message queue is direction; a handle number will be returned upon successful call.

[0168] The master core identifies a queue entity using either (slave core number, handle number) or (slave core number, queue name); the slave core uses either the handle number or the queue name as the unique identifier of the queue to determine the unique queue entity; the handle of the same queue is the same on the master core and the slave core.

[0169] Message queues are used solely for communication between the master and slave cores. Users can specify the slave ID of the slave core where the queue resides; multiple different message queues can be set between a pair of master and slave cores.

[0170] The size of each message in the message queue is no greater than msgSize bytes;

[0171] A message queue is distributed in the main core memory and the local memory of the slave core, and the number of messages it can hold is mSize and sSize, respectively;

[0172] The starting address of the message queue in the main core memory is a contiguous memory space specified by the application, with the starting address being mQaddr;

[0173] If the local memory on the kernel has different types, the type of local memory occupied by the message queue can be specified by the kernel memory type sType;

[0174] The message queue is unidirectional, with two directions: master core write / slave core read and slave core write / master core read, specified by the direction parameter.

[0175] The master core can create multiple message queues between the master core and one slave core. The message queues between the master core and all slave cores constitute a message queue set.

[0176] The master core controls the slave core threads according to the slave core thread management interface. This mainly involves creating and starting slave core thread groups, waiting for thread groups to terminate, closing thread groups, and loading image files to the device by the master core.

[0177] Furthermore, a message queue has a contiguous storage space for storing message content in both the master and slave cores. The number of messages it can hold is divided into mSize and sSize, occupying memory capacities of mSize × msgSize bytes and sSize × msgSize bytes respectively. Figure 4 As shown; the capacity of the message queue from the core is limited by the capacity of the local memory;

[0178] The control information layout for each message queue is divided into two parts: a status list and a position index;

[0179] The location indices are divided into: IMTran, IMReady, IMLocked, and IMIdle, which are related to the master core location; and ISTran, ISReady, IMLocked, and ISIdle, which are related to the slave core location. The design varies depending on the message queue direction. In the message queue control information layout from the master core to the slave core, IMLocked and IMIdle are stored in the master core address region; IMTran, IMReady, and the other four location indices are located in the slave core's local memory. Conversely, in the message queue control information layout from the slave core to the master core, IMReady, IMLocked, and IMIdle are stored in the master core address region; IMTran and the other four location indices are located in the slave core's local memory.

[0180] IMTran indicates the message position index of the first message block in the main core space that is in transit; IMReady indicates the message position index of the first message block in the main core space that is ready; IMLocked indicates the message position index of the first message block in the main core space that is locked; IMIdle indicates the message position index of the first message block in the main core space that is idle.

[0181] ISTran indicates the index of the first message block in the kernel space that is in transit; ISReady indicates the index of the first message block in the kernel space that is ready; ISLocked indicates the index of the first message block in the kernel space that is locked; ISIdle indicates the index of the first message block in the kernel space that is idle.

[0182] Each state in the state list corresponds one-to-one with each message block in the circular message block data area; the message block state list of the master core and the message block state list of the slave core are denoted as MState and SState, respectively, and are located in the master core address area and the slave core local memory, respectively.

[0183] A message queue is divided into a master core part and a slave core part;

[0184] When the message queue is created, the number of messages that the main core and the slave core can hold are already determined.

[0185] The position index in the message queue control information layout will have different designs depending on the direction of the message queue. Storing unnecessary variables of the main core in the slave core can reduce the access of slave core code to main core variables, thereby improving the performance of the model.

[0186] Furthermore, in the message queue from the master core to the slave core, the state of a message block in the master core includes: MasterIdle, MasterLocked, MasterReady, MTransferring; the state of a message block in the slave core includes: SlaveIdle, STransferring, SlaveReady, SlaveLocked; the state information of each message block is stored in its respective memory.

[0187] After the message queue is created, all message blocks in the master core are in the MasterIdle state, and all message blocks in the slave core are in the SlaveIdle state.

[0188] MasterIdle indicates that the message block in the master core is in an idle and allocable state; MasterLocked indicates that the message block in the master core is in a locked state; MasterReady indicates that the message block in the master core is ready to be used; and MTransferring indicates that the message block in the master core is in a transfer state.

[0189] SlaveIdle indicates that the message block in the slave core is idle and available for allocation; STransferring indicates that the message block in the slave core is in transit; SlaveReady indicates that the message block in the slave core is ready to be used; SlaveLocked indicates that the message block in the slave core is locked.

[0190] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0191] M1 and mAllocateMsg() obtain the address of a message block in the message queue main core.

[0192] M2 and mSendMsg() initiate the master core to send messages to the slave core;

[0193] M3 and mRecvMsg() receive a message sent from the core;

[0194] M4 and mReleaseMsg() release a message in the main core.

[0195] The message queuing system provides the following interfaces to kernel applications:

[0196] S1, sRecvMsg(), receives a message sent by the main core;

[0197] S2, sReleaseMsg(), releases a message from the kernel;

[0198] S3 and sAllocateMsg() retrieve the address of a message block from the kernel in the message queue.

[0199] S4 and sSendMsg() initiate the transmission of messages from the slave core to the master core.

[0200] In the above interfaces, M1, M2, S1 and S2 are used for the master core to pass messages to the slave core, and M3, M4, S3 and S4 are used for the slave core to pass messages to the master core.

[0201] Furthermore, the operation sequence for sending a message from the master core to the slave core includes:

[0202] a1. The main core application calls mAllocateMsg(); the message passing system between the main core and slave cores based on local memory allocates a free message block pointed to by the position index IMIdle in the main core part of the message queue, sets the block to the MasterLocked state, moves IMIdle in a loop, and returns the block address MasterMsg to the main core application.

[0203] a2. The main application sets the message to be sent in the idle message block pointed to by MasterMsg;

[0204] a3. The main core application calls mSendMsg() to obtain the first message block MasterMsg pointed to by the position index IMLocked. The message passing system between the main core and the slave core based on local memory will set the message block MasterMsg to the MasterReady state and move IMLocked in a loop.

[0205] a4. The message passing system between the master and slave cores based on local memory allocates a free message block message storage space SlaveMsg, pointed to by the location index ISIdle, in the slave core at a set time for the message block to be transferred, and cyclically moves ISIdle; it starts DMA to transfer the message block in MasterMsg to SlaveMsg, obtains the first message block MasterMsg pointed to by the location index IMReady, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the message passing system between the master and slave cores based on local memory sets the message block SlaveMsg pointed to by the slave core message block location index ISTran to the SlaveReady state, and sets the message block MasterMsg pointed to by the master core message block location index IMTran to the MasterIdle state;

[0206] a5. Call sRecvMsg() from the kernel application; The message queue returns the message block SlaveMsg, which is already in the slave part, pointed to by the position index ISReady, and sets it to SlaveLocked;

[0207] a6. Read the contents of SlaveMsg from the kernel application;

[0208] a7. Call sReleaseMsg() from the kernel application; the message queue will set the kernel message block SlaveMsg to the SlaveIdle state.

[0209] The sequence of operations for sending a message from the core to the master core includes:

[0210] b1. The kernel application calls sAllocateMsg(); the message passing system between the master and slave kernels based on local memory allocates an idle message block pointed to by the position index ISIdle in the slave kernel part of the message queue, sets the block to the SlaveLocked state, moves ISIdle in a loop, and returns the block address SlaveMsg to the master kernel application.

[0211] b2. The kernel application sets the message to be sent in the idle message block pointed to by SlaveMsg;

[0212] b3. Call sSendMsg() from the application; retrieve the first message block SlaveMsg pointed to by the position index ISLocked; the message passing system between the master and slave cores based on local memory will set the message block SlaveMsg to the SlaveReady state; cyclically move ISLocked;

[0213] b4. When the local memory-based message passing system between the master and slave cores is set up, it allocates a free message block message storage space, MasterMsg, pointed to by the location index IMIdle, in the slave core for the message block to be transmitted; it starts DMA to transfer the message block in SlaveMsg to MasterMsg, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the local memory-based message passing system between the master and slave cores sets the MasterMsg pointed to by the message block location index IMTran in the master core to the MasterReady state, and sets the SlaveMsg pointed to by the message block location index ISTran in the slave core to the SlaveIdle state.

[0214] b5. The main application calls mRecvMsg(); the message queue returns to the main application a message block address MasterMsg, which is already in the main part of the main application and is pointed to by the position index IMReady.

[0215] b6. The main core application reads the contents of MasterMsg;

[0216] b7. The main core application calls mReleaseMsg(); the message queue sets the main core message block MasterMsg to the MasterIdle state.

[0217] Applications on the master or slave cores can directly read and write message blocks within the memory area managed by the message queue, without having to move the message content to other memory spaces. This reduces both the overhead of moving message content and the usage of local memory on the slave core.

[0218] The master or slave application only initiates message transmission or reception, without needing to consider the specific implementation of message transmission between the master and slave cores; the message transmission is implemented by the message passing system between the master and slave cores based on local memory; this simplifies application design and also makes the application more portable.

[0219] Furthermore, the blocking message transmission process between the master core and the slave core is as follows:

[0220] Each message queue will maintain a DMA request set DMAreqs; this set is initialized to an empty set.

[0221] During the process of the master core sending a message / the slave core receiving a message, the application calls the interface sRecvMsg(); within sRecvMsg(), the following steps are executed:

[0222] A1. Determine if the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step A2; otherwise, proceed to step A3.

[0223] A2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveReady, set the status of req.MMsg to MasterIdle, and remove the req from DMAreqs.

[0224] A3. Determine whether the slave core can obtain the message block SMsg in the SlaveIdle state and whether the master core can obtain the message block MMsg in the MasterReady state. If yes, proceed to step A4; otherwise, proceed directly to step A5.

[0225] A4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req = {MMsg, SMsg}, add req to DMAreqs, and execute step A3 again.

[0226] A5. If any message in the kernel part of the message is in the SlaveReady state, then set the earliest SlaveReady state message Msg to the SlaveLocked state and return Msg to the end of the application; otherwise, execute step A1.

[0227] The DMA request set DMAreqs is initialized to empty.

[0228] During the process of sending a message from the kernel / receiving a message from the master kernel, the kernel application calls the interface sSendMsg(); within sSendMsg(), the following steps are executed:

[0229] B1. Determine if the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step B2; otherwise, proceed to step B3.

[0230] B2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveIdle, set the status of req.MMsg to MasterReady, and remove the req from DMAreqs.

[0231] B3. Determine whether the slave core can obtain the message block SMsg in the SlaveReady state and whether the master core can obtain the message block MMsg in the MasterIdle state. If yes, proceed to step B4; otherwise, proceed directly to step B5.

[0232] B4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req = {MMsg, SMsg}, add req to DMAreqs, and execute step B3 again.

[0233] B5. If the message sent by the core is in the SlaveLocked state, set the SlaveLocked message Msg to the SlaveReady state and return Msg to the end of the application; otherwise, proceed to step B1.

[0234] The DMA request set DMAreqs is initialized to empty.

[0235] Furthermore, there are two different ways to access the main core's memory space from the kernel: direct access and asynchronous DMA transfer. Direct access is less efficient and suitable for accessing small amounts of data. Asynchronous DMA transfer consists of two steps: starting the DMA transfer process and querying the DMA result. After starting the DMA transfer, the software system can complete other tasks without waiting for the DMA to finish, and can know whether the DMA has been completed by querying the DMA result.

[0236] During the blocking process of the master core sending a message / the slave core receiving a message, it will only return after the slave core receives the message from the master core; otherwise, it will wait indefinitely for the master core to send a message.

[0237] When the slave core receives a message, it will initiate the DMA transfer process for the message that is already in the MasterReady state in the master core. When the slave core has two or more message blocks and the master core sends messages at a rate higher than the slave core uses messages, the slave application can read messages and the DMA transfer process can be completed in parallel.

[0238] Furthermore, the message queue is created by the master core, generating a new queue handle (handle) on both the master and slave cores. On the master core, handles are partitioned according to different slave core numbers. On the slave cores, the handle number (handle) or the queue name (qName) can uniquely identify the queue entity. The handle of the same queue on the master core includes the handle on the slave core; that is, the queue corresponding to (SlaveID, handle) on the master core and the queue with handle (handle) on the SlaveID slave core are the same queue entity. The status of a specific message queue can be queried through the message queue identifier (handle), which mainly includes whether the queue exists, its direction, the size of the message, and the number of messages in the current queue.

[0239] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0240] M5, mQueryQueue(), checks if the message queue exists;

[0241] M6, mQueueDirection(), get the queue direction of the message queue;

[0242] M7 and mQueueMsgNumInMaster() retrieve the number of messages that the control core of the message queue can hold.

[0243] M8 and mQueueMsgNumInSlave() retrieve the number of messages that the computational core of the message queue can hold.

[0244] M9 and mQueueMsgSize() get the maximum number of bytes per message in the message queue.

[0245] M10 and mQueueMsgSlaveMemType() retrieve the memory type of the slave portion of the message queue.

[0246] M11 and mQueueMsgNumStatus() are used to retrieve dynamic information about the message queue.

[0247] M12, mCreateQueue(), creates a message queue;

[0248] The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications:

[0249] S5, sQueryQueue(), checks if the message queue exists;

[0250] S6, sQueueDirection(), gets the queue direction of the message queue;

[0251] S7, sQueueMsgNumInMaster(), gets the number of messages that the control core of the message queue can hold;

[0252] S8, sQueueMsgNumInSlave(), get the number of messages that the computational core of the message queue can hold;

[0253] S9, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue;

[0254] S10, sQueueMsgSlaveMemType(), retrieves the memory type of the slave portion of the message queue;

[0255] S11, sQueueMsgNumStatus(), retrieve dynamic information about the message queue;

[0256] Interfaces M5-M12 are used to query relevant message queue information on the master core, and interfaces S5-S11 are used to query relevant message queue information on the slave core.

[0257] Furthermore, when a user creates a message queue, a unique message queue handle is generated, which can be obtained by the handle number or the queue name;

[0258] Both the master and slave cores can obtain the corresponding status information of the message queue; since the master core needs to communicate with multiple slave cores, (slave core number, handle number) or (slave core number, queue name) can identify a unique queue entity; on the slave core side, the handle number handle or the queue name qName can identify a unique queue entity.

[0259] Furthermore, the following interfaces are set up for use on different high-performance many-core processors, covering the steps required for communication between the master core and slave cores, including the slave core management mechanism on the master core. Using these interfaces allows the code to be quickly ported to a variety of high-performance many-core processors while completing the corresponding functions. When porting to a new platform, you only need to recompile the code and specify the compilation options for the corresponding platform during compilation.

[0260] The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application:

[0261] M13, mHaltDevice: Exit the operating environment of the acceleration device;

[0262] M14, mHMessQueueInit: The initialization method for controlling the core cache.

[0263] M15, mHMessQueueQuit: Controls the unregistration method of the core cache;

[0264] M16, mLoadDatFile: Loads the image file to the device; only MT3 requires this function.

[0265] M17, mUnloadDatFile: Unloads the image file to the device; only MT3 requires this function.

[0266] M18, mGetSlaveCoreNum: Get the number of computing cores; Controls the unregistering method of the core cache.

[0267] M19, mGetMemSize: Get the storage size of the control core and compute core, in bytes.

[0268] M20, mGetSlaveSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core.

[0269] M21, mInitDevice: Loads the runtime environment of the acceleration device.

[0270] M22, mGetInitThreadID: Retrieves the initialized thread data structure.

[0271] M23, mStartSlaveThreads: Creates and starts thread groups that bind to computing cores.

[0272] M24, mWaitSlaveThreads: Waiting for the thread group to terminate.

[0273] M25, mDestroySlaveThreads: Close the thread group

[0274] M26, mSlaveThreadActive: Get whether the threads of the computing core are active.

[0275] The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications:

[0276] S12, sHMessQueueInit(): The message queue is initialized from the core;

[0277] S13, sHMessQueueQuit: Calculates the unregistering method of the core cache, and obtains the queue direction of the message queue;

[0278] S14, sGetSlaveNum: Get the number of computing cores(), which is the number of messages that the control core of the message queue can hold.

[0279] S15, sGetSlaveID: Get the current computing core number (), and get the number of messages that the computing core part of the message queue can hold;

[0280] S16, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue;

[0281] S17, sSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core (), and get the memory type of the slave part in the message queue;

[0282] In the above interfaces, M13-M20 are used to query relevant message queue information on the main core, M21-M26 are used to manage slave core threads on the main core, and S12-S20 are used to query relevant message queue information on the slave core.

[0283] The aforementioned interfaces cover the functions required by various high-performance many-core processors, and the provided interface set I consists of the underlying interfaces L for different high-performance many-core processors. i The union of the sets, 1≤i, i.e., I={L1∪L2…;}, if a function i in the interface set I is called on a processor L1 that does not have the corresponding function function, i.e., i∈I, The code will not have any negative impact;

[0284] Macro-based programming allows different predefined macros to be used on different processors. These predefined macros are set at compile time, and the same effect can be achieved by calling the same interface on different high-performance many-core processors. This encapsulates the differences in the underlying libraries between different many-core processors.

[0285] In a specific embodiment, the message passing system between the master and slave cores based on local memory is implemented as follows: Figure 6 This includes the following steps:

[0286] Step 1: Determine the platform t1 to be run;

[0287] Step 2, the programming model will be implemented on the main core m i With the corresponding kernel set S i Each from the kernel s i,j Initialize using the initialization mechanism and enable the kernel thread management mechanism respectively, where s i,j ∈S i A main core m i It can manage the kernel set S i ;;

[0288] Step 3: For platform t1 where the code runs, on the main core m i According to the message passing interface of the present invention, a corresponding message queue set Q is created in memory, and the connection between the master core and the slave core is created using the queue interface;

[0289] Step 4: The master / slave core uses the message mechanism of this invention to transmit message r to message queue q. i Among them, q i ∈Q, the message sequence R is obtained and the message r is sent in an ordered manner.

[0290] Step 5: The slave / master core selects the corresponding message r from R based on the relevant information of the queue. i r i ∈R, 1≤i≤|R|, release the memory used by the message in the message queue; after receiving the data from the kernel, perform the corresponding processing;

[0291] Step 6, from the core s i,j After processing the data, unregister the cache of this core, and the main core m i Recycle threads i,j Then check if there are any more tasks. If not, the main core unregisters the cache and the program terminates in parallel with multiple threads.

[0292] Step 7: Port the program to another platform t2 and recompile it. Specify the compilation options for the corresponding platform during compilation, and the code can be run.

[0293] In one specific embodiment, in various high-performance many-core processors that employ a small number of master cores and multiple slave cores, where the slave cores use local memory without cache coherency, master-slave core communication programming is required. This invention can effectively improve the portability of application software and enhance the development capabilities of high-performance computing software.

[0294] In one specific embodiment, a high-performance many-core processor is used for the password guessing program, as follows:

[0295] In this embodiment, a password guessing program targeting MD5 is included, which needs to run on multiple many-core processors. The ciphertext used in the experiment is: 25d55ad283aa400af464c76d713c07ad, and its corresponding password is 12345678. The multiple many-core processors employ different organizational structures. Without this invention, the code would need to be refactored twice for each processor. Based on this invention, two queues can be established on the main processor and slave cores 1 to N of the many-core processors, named "plain" and "result" respectively. Then, a multi-threaded model is used for communication, allowing direct portability and execution on multiple many-core processors. The resulting handles are shown in Table 1 below.

[0296]

[0297] Table 1

[0298] like Figure 6 As shown, the three test methods—basic algorithm guessing, algorithm guessing based on this invention, and algorithm guessing without using this invention—generally show the same trend, and their performance is comparable to that of code without this invention. This invention does not affect program performance while increasing portability.

Claims

1. A message passing system between a master core and a slave core based on local memory, characterized in that, Including the main core set M , respectively denoted as m 1,…, m |M| , among which | M | Represents the set of main cores M The number of master cores; master cores m i For one or more slave kernel sets, and satisfying | S a |=| S b |,| S a | indicates from the kernel set S a The number of slave cores in the | S b | indicates from the kernel set S b The number of kernels in the middle, S a 、S b All are sets of kernels, 1≤ a,b ≤| M |; A main core can manage threads through the core thread management interface. m i Capable of managing the kernel set S i ,1≤ i ≤| M |; Among them, in creating the first i Each main core m i To the i A set of kernels S i The first in j From the core s i,j The k message queues q i,j,k At that time, among them, s i,j ∈ S i ,1≤ j ≤| S i |,1≤ k Using the API call on the main core m i and from the core s i,j Create the corresponding message queue in memory q i,j,k ， All main cores m i From the nuclear s i,j message queue q i,j,k It constitutes a set Q , q i,j,k ∈ Q Complete the main core m i and from the core s i,j The connection between them; Main core m i Or from the core s i,j Through the message sending mechanism, a series of messages are sent. r x , Transmitted to message queue q i,j,k From this, a set of message sequences is obtained. R The messages are sent in an orderly manner, 1≤ x , r x ∈ R ; From the nuclear s i,j or main core m i According to message queue q i,j,k From the message sequence R Select the corresponding message r x ,in r x ∈ R ,1≤ x ≤| R |, User gets message r x Complete the custom message handling r x After processing, the message queue q i,j,k The message was released in China. r x Memory used; When creating a message queue on the main core, the following parameters need to be specified: The message queue name (qName) is a string, the slave ID is the connection number, the message size is msgSize, the number of messages the message queue can hold on the master core is mSize, the number of messages it can hold on the slave core is sSize, the starting address of the master core message queue is mQaddr, the type of memory occupied by the message queue on the slave core is sType, and the direction of the message queue is direction; a handle number will be returned upon successful call. The master core identifies a queue entity using either (slave core number, handle number) or (slave core number, queue name); the slave core uses either the handle number or the queue name as the unique identifier of the queue to determine the unique queue entity; the handle of the same queue is the same on the master core and the slave core. Message queues are used only for communication between the master and slave cores. Users can specify the slave ID where the queue resides. Multiple different message queues can be set up between a pair of master and slave cores. From the nuclear s i,j Log off the slave core after processing the data. s i,j cache, main core m i The running thread is recycled from the core. s i,j The thread continues to process the main core. m i The remaining tasks, if there are no tasks, then the main core. m i Unregister the cache, and the program will terminate in parallel using multiple threads.

2. The message passing system between the master and slave cores based on local memory according to claim 1, characterized in that, The size of each message in the message queue is no greater than msgSize bytes; A message queue is distributed in the main core memory and the local memory of the slave core, and the number of messages it can hold is mSize and sSize, respectively. The starting address of the message queue in the main core memory is a contiguous memory space specified by the application, with the starting address being mQaddr; If the local memory on the kernel has different types, the type of local memory occupied by the message queue can be specified by the kernel memory type sType; The message queue is unidirectional, with two directions: master core write / slave core read and slave core write / master core read, specified by the direction parameter. The master core can create multiple message queues between the master core and one slave core. The message queues between the master core and all slave cores constitute a message queue set. The master core controls the slave core threads according to the slave core thread management interface. This mainly involves creating and starting slave core thread groups, waiting for thread groups to terminate, closing thread groups, and loading image files to the device by the master core.

3. The message passing system between the master and slave cores based on local memory according to claim 2, characterized in that, A message queue has a contiguous storage space in both the master core and slave core to store message content. The number of messages that the master core and slave core can hold are mSize and sSize, respectively, and the memory capacity they occupy is mSize×msgSize bytes and sSize×msgSize bytes, respectively. The capacity of the message queue in the slave core is limited by the capacity of the local memory. The control information layout for each message queue is divided into two parts: a status list and a position index; The location indices are divided into: IMTran, IMReady, IMLocked, and IMIdle, which are related to the master core location; and ISTran, ISReady, IMLocked, and ISIdle, which are related to the slave core location. In the message queue control information layout from the master core to the slave core, IMLocked and IMIdle are stored in the master core address region; IMTran, IMReady, and the other four location indices are all located in the slave core local memory. In the message queue control information layout from the slave core to the master core, IMReady, IMLocked, and IMIdle are stored in the master core address region; IMTran and the other four location indices are all located in the slave core local memory. IMTran indicates the message position index of the first message block in the main core space that is in transit; IMReady indicates the message position index of the first message block in the main core space that is ready; IMLocked indicates the message position index of the first message block in the main core space that is locked; IMIdle indicates the message position index of the first message block in the main core space that is idle. ISTran indicates the index of the first message block in the kernel space that is in transit; ISReady indicates the index of the first message block in the kernel space that is ready; ISLocked indicates the index of the first message block in the kernel space that is locked; ISIdle indicates the index of the first message block in the kernel space that is idle. Each state in the state list corresponds one-to-one with each message block in the circular message block data area; the message block state list of the master core and the message block state list of the slave core are denoted as MState and SState, respectively, and are located in the master core address area and the slave core local memory, respectively. A message queue is divided into a master core part and a slave core part; When a message queue is created, the number of messages that the master core and slave core can hold is already determined.

4. The message passing system between the master and slave cores based on local memory according to claim 3, characterized in that, In the message queue from the master core to the slave core, the state of a message block in the master core includes: MasterIdle, MasterLocked, MasterReady, MTransferring; the state of a message block in the slave core includes: SlaveIdle, STransferring, SlaveReady, SlaveLocked; the state information of each message block is stored in its own memory. After the message queue is created, all message blocks in the master core are in the MasterIdle state, and all message blocks in the slave core are in the SlaveIdle state. MasterIdle indicates that the message block in the master core is in an idle and allocable state; MasterLocked indicates that the message block in the master core is in a locked state; MasterReady indicates that the message block in the master core is ready to be used; and MTransferring indicates that the message block in the master core is in a transfer state. SlaveIdle indicates that the message block in the slave core is idle and available for allocation; STransferring indicates that the message block in the slave core is in transit; SlaveReady indicates that the message block in the slave core is ready to be used; SlaveLocked indicates that the message block in the slave core is locked. The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application: M1 and mAllocateMsg() obtain the address of a message block in the message queue main core. M2 and mSendMsg() initiate the master core to send messages to the slave core; M3 and mRecvMsg() receive a message sent from the core; M4 and mReleaseMsg() release a message in the main core. The message queue provides the following interfaces to the kernel application: S1, sRecvMsg(), receives a message sent by the main core; S2, sReleaseMsg(), releases a message from the kernel; S3 and sAllocateMsg() retrieve the address of a message block from the kernel in the message queue. S4 and sSendMsg() initiate the transmission of messages from the slave core to the master core. In the above interfaces, M1, M2, S1 and S2 are used for the master core to pass messages to the slave core, and M3, M4, S3 and S4 are used for the slave core to pass messages to the master core.

5. The message passing system between the master and slave cores based on local memory according to claim 4, characterized in that, The sequence of operations for sending a message from the master core to the slave core includes: a1. The main core application calls mAllocateMsg(); the message passing system between the main core and slave cores based on local memory allocates a free message block pointed to by the position index IMIdle in the main core part of the message queue, sets the block to the MasterLocked state, moves IMIdle in a loop, and returns the block address MasterMsg to the main core application. a2. The main application sets the message to be sent in the idle message block pointed to by MasterMsg; a3. The main core application calls mSendMsg() to obtain the first message block MasterMsg pointed to by the position index IMLocked. The message passing system between the main core and the slave core based on local memory will set the message block MasterMsg to the MasterReady state and move IMLocked in a loop. a4. The message passing system between the master and slave cores based on local memory allocates a free message block message storage space SlaveMsg, pointed to by the location index ISIdle, in the slave core at a set time for the message block to be transferred, and cyclically moves ISIdle; it starts DMA to transfer the message block in MasterMsg to SlaveMsg, obtains the first message block MasterMsg pointed to by the location index IMReady, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the message passing system between the master and slave cores based on local memory sets the message block SlaveMsg pointed to by the slave core message block location index ISTran to the SlaveReady state, and sets the message block MasterMsg pointed to by the master core message block location index IMTran to the MasterIdle state; a5. The slave application calls sRecvMsg(); the message queue returns the message block SlaveMsg, which is already in the slave part, pointed to by the position index ISReady, and sets it to SlaveLocked; a6. Read the contents of SlaveMsg from the kernel application; a7. Call sReleaseMsg() from the kernel application; the message queue will set the kernel message block SlaveMsg to the SlaveIdle state. The sequence of operations for sending a message from the core to the master core includes: b1. The kernel application calls sAllocateMsg(); the message passing system between the master and slave kernels based on local memory allocates an idle message block pointed to by the position index ISIdle in the slave kernel part of the message queue, sets the block to the SlaveLocked state, moves ISIdle in a loop, and returns the block address SlaveMsg to the master kernel application. b2. The kernel application sets the message to be sent in the idle message block pointed to by SlaveMsg; b3. Call sSendMsg() from the application; retrieve the first message block SlaveMsg pointed to by the position index ISLocked; the message passing system between the master and slave cores based on local memory will set the message block SlaveMsg to the SlaveReady state; cyclically move ISLocked; b4. When the local memory-based message passing system between the master and slave cores is set up, it allocates a free message block message storage space, MasterMsg, pointed to by the location index IMIdle, in the slave core for the message block to be transmitted; it starts DMA to transfer the message block in SlaveMsg to MasterMsg, and sets the message block MasterMsg to the MTransferring state and SlaveMsg to the STransferring state; when the DMA transfer is completed, the local memory-based message passing system between the master and slave cores sets the MasterMsg pointed to by the message block location index IMTran in the master core to the MasterReady state, and sets the SlaveMsg pointed to by the message block location index ISTran in the slave core to the SlaveIdle state. b5. The main application calls mRecvMsg(); the message queue returns to the main application a message block address MasterMsg, which is already in the main core region, pointed to by the position index IMReady. b6. The main core application reads the contents of MasterMsg; b7. The main application calls mReleaseMsg(); the message queue sets the main message block MasterMsg to the MasterIdle state.

6. The message passing system between the master and slave cores based on local memory according to claim 4, characterized in that, The blocking message transmission process between the master core and the slave core is as follows: Each message queue will maintain a DMA request set DMAreqs; this set is initialized to an empty set. During the process of the master core sending a message / the slave core receiving a message, the application calls the interface sRecvMsg(); within sRecvMsg(), the following steps are executed: A1. Determine if the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step A2; otherwise, proceed to step A3. A2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveReady, set the status of req.MMsg to MasterIdle, and remove the req from DMAreqs. A3. Determine whether the slave core can obtain the message block SMsg in the SlaveIdle state and the master core can obtain the message block MMsg in the MasterReady state. If yes, proceed to step A4; otherwise, proceed directly to step A5. A4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req={MMsg, SMsg}, add req to DMAreqs, and execute step A3 again. A5. If any message in the kernel part of the message is in the SlaveReady state, then set the earliest SlaveReady state message Msg to the SlaveLocked state and return Msg to the end of the application; otherwise, execute step A1. The DMA request set DMAreqs is initialized to empty. During the process of sending a message from the kernel / receiving a message from the master kernel, the kernel application calls the interface sSendMsg(); within sSendMsg(), the following steps are executed: B1. Determine whether the DMA request set DMAreqs of this message queue is empty. If it is, proceed to step B2; otherwise, proceed to step B3. B2. Check each request req in DMAreqs in turn to see if the request req has completed DMA. If it has not completed, ignore it. If it has completed, set the status of req.SMsg to SlaveIdle, set the status of req.MMsg to MasterReady, and remove the req from DMAreqs. B3. Determine whether the slave core can obtain the message block SMsg in the SlaveReady state and the master core can obtain the message block MMsg in the MasterIdle state. If yes, proceed to step B4; otherwise, proceed directly to step B5. B4. Set the state of the message block corresponding to MMsg to MTransferring state, set the state of the message block corresponding to SMsg to STransferring state, start an asynchronous DMA request from MMsg to SMsg with a length of MsgSize bytes, req={MMsg, SMsg}, add req to DMAreqs, and execute step B3 again. B5. If the message sent by the kernel is in the SlaveLocked state, set the SlaveLocked message Msg to the SlaveReady state and return Msg to the end of the application; otherwise, proceed to step B1. The DMA request set DMAreqs is initialized to empty.

7. The message passing system between the master and slave cores based on local memory according to claim 6, characterized in that, Accessing the main core's memory space from the kernel can be done in two ways: direct access and asynchronous DMA transfer. The asynchronous DMA transfer method consists of two steps: initiating the DMA transfer process and querying the DMA result. After initiating the DMA transfer, the software system can complete other tasks without waiting for the DMA to finish, and can determine whether the DMA has been completed by querying the DMA result. During the blocking process of the master core sending a message / the slave core receiving a message, it will only return after the slave core receives the message from the master core; otherwise, it will wait indefinitely for the master core to send a message. When the slave core receives a message, it will initiate the DMA transfer process for the message that is already in the MasterReady state in the master core. When the slave core has two or more message blocks and the master core sends messages at a rate higher than the slave core uses messages, the slave application can read messages and the DMA transfer process can be completed in parallel.

8. The message passing system between the master and slave cores based on local memory according to claim 1, characterized in that, Message queues are created by the master core, generating a new queue handle (handle) on both the master and slave cores. On the master core, handles are partitioned according to different slave core numbers. On the slave cores, the handle number (handle) or the queue name (qName) can uniquely identify the queue entity. The handle of the same queue on the master core includes the handle on the slave core; that is, the queue corresponding to (SlaveID, handle) on the master core and the queue with handle (handle) on the SlaveID-th slave core are the same queue entity. The status of a specific message queue can be queried through the message queue identifier (handle), which mainly includes whether the queue exists, its direction, the size of the message, and the number of messages in the current queue. The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application: M5, mQueryQueue(), checks if the message queue exists; M6, mQueueDirection(), gets the queue direction of the message queue; M7, mQueueMsgNumInMaster(), get the number of messages that the control core of the message queue can hold; M8 and mQueueMsgNumInSlave() are used to get the number of messages that the computational core of the message queue can hold. M9 and mQueueMsgSize() get the maximum number of bytes per message in the message queue. M10, mQueueMsgSlaveMemType(), retrieves the memory type of the slave portion of the message queue; M11 and mQueueMsgNumStatus() are used to retrieve dynamic information about the message queue. M12, mCreateQueue(), creates a message queue; The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications: S5, sQueryQueue(), checks if the message queue exists; S6, sQueueDirection(), gets the queue direction of the message queue; S7, sQueueMsgNumInMaster(), gets the number of messages that the control core of the message queue can hold; S8, sQueueMsgNumInSlave(), gets the number of messages that the computational core of the message queue can hold; S9, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue; S10, sQueueMsgSlaveMemType(), retrieves the memory type of the slave portion of the message queue; S11, sQueueMsgNumStatus(), retrieve dynamic information about the message queue; Interfaces M5-M12 are used to query relevant message queue information on the master core, and interfaces S5-S11 are used to query relevant message queue information on the slave core.

9. The message passing system between the master and slave cores based on local memory according to claim 1, characterized in that, When a user creates a message queue, a unique message queue handle is generated, which can be obtained by the handle number or the queue name; Both the master and slave cores can obtain the corresponding status information of the message queue; because the master core needs to communicate with multiple slave cores, (slave core number, handle number) or (slave core number, queue name) can identify a unique queue entity; on the slave core side, the handle number handle or the queue name qName can identify a unique queue entity.

10. The message passing system between the master and slave cores based on local memory according to claim 1, characterized in that, The following interfaces are configured for use on different high-performance many-core processors; The message passing system between the master and slave cores based on local memory provides the following interfaces for the master core application: M13, mHaltDevice: Exit the operating environment of the acceleration device; M14, mHMessQueueInit: Controls the initialization method of the core cache; M15, mHMessQueueQuit: Controls the unregistering methods for the core cache; M16, mLoadDatFile: Loads the image file to the device; only required for MT3. M17, mUnloadDatFile: Unloads the image file to the device; only required for MT3. M18, mGetSlaveCoreNum: Get the number of computing cores; Controls the unregistering method for the core cache. M19, mGetMemSize: Get the storage size of the control core and computing core, in bytes; M20, mGetSlaveSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core; M21, mInitDevice: Load the runtime environment of the acceleration device; M22, mGetInitThreadID: Retrieves the initialized thread data structure; M23, mStartSlaveThreads: Creates and starts thread groups that bind to computing cores; M24, mWaitSlaveThreads: Waiting for the thread group to terminate; M25, mDestroySlaveThreads: Close the thread group; M26, mSlaveThreadActive: Get whether the threads of the computing core are active; The message passing system between the master and slave cores based on local memory provides the following interfaces for slave core applications: S12, sHMessQueueInit(): The message queue is initialized from the core; S13, sHMessQueueQuit: Calculates the unregistration method of the core cache and obtains the queue direction of the message queue; S14, sGetSlaveNum: Get the number of computing cores, and the number of messages that the control core of the message queue can hold; S15, sGetSlaveID: Get the current computing core number and the number of messages that the computing core part of the message queue can hold; S16, sQueueMsgSize(), gets the maximum number of bytes per message in the message queue; S17, sSIMDLanes: Get the number of channels for parallel processing of SIMD instructions in the computing core, and get the memory type of the slave part in the message queue; In the above interfaces, M13-M20 are used to query relevant message queue information on the main core, M21-M26 are used to manage slave core threads on the main core, and S12-S17 are used to query relevant message queue information on the slave core.

Images