Cross-level prefetch for shared multi-level libraries

In embodiments, apparatuses, methods and storage media (transitory and non-transitory) are described that are associated with receiving a call from an application at a shared library, accessing a first resource based at least in part on the first call, and storing a prefetch entry in a prefetch engine based at least in part on an address of a second resource in preparation to service a second call to the shared library that requires traversal of a plurality of stages at the shared library. A prefetch request may be performed based at least in part on the second call, and the second resource may be accessed based at least in part on a result of the prefetch request. In embodiments, the shared library may be a Message Passing Interface (MPI) library. Other embodiments may be described and/or claimed.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a national phase entry under 35 U.S.C. § 371 of International Application No. PCT/RU2015/000180, filed Mar. 26, 2015, entitled “CROSS-LEVEL PREFETCH FOR SHARED MULTILEVEL LIBRARIES”, which designated, among the various States, the United States of America. The specification of the PCT/RU2015/000180 Application is hereby fully incorporated by reference.

TECHNICAL FIELD

The present disclosure relates to the field of data processing, in particular, to prefetching data resources into a cache.

BACKGROUND

Moving from one level to another of a shared library using a multi-level software stack, such as the Message Passing Interface (MPI) library, may cost CPU cycles, especially when required data is not in the CPU's cache. This may be particularly the case for small message transfer path performance which is sensitive to memory access latency. Existing schemes for prefetching typically operate on one particular level of a multi-level library by prefetching a far part of data while working on a closer part of the data from the same level. This technique does not function optimally for small messages.

DETAILED DESCRIPTION

As used herein, the term “logic” and “module” may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. The term “module” may refer to software, firmware and/or circuitry that is/are configured to perform or cause the performance of one or more operations consistent with the present disclosure. Software may be embodied as a software package, code, instructions, instruction sets and/or data recorded on non-transitory computer readable storage mediums. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in memory devices. “Circuitry”, as used in any embodiment herein, may comprise, for example, singly or in any combination, hardwired circuitry, programmable circuitry such as computer processors comprising one or more individual instruction processing cores, state machine circuitry, software and/or firmware that stores instructions executed by programmable circuitry. The modules may collectively or individually be embodied as circuitry that forms a part of a computing device. As used herein, the term “processor” may be a processor core.

Referring now toFIG. 1, a network environment100, including a computing device102having a shared multi-level library and prefetch teaching of the present disclosure, in accordance with various embodiments, is illustrated. The computing device102may be in data communication with computing nodes104,106over a network108. As shown, computing device102may include a number of components110-148, including a processor110, an integrated cache112, an external cache114, a system memory116, an execution environment118, a library module120, a prefetch engine122, and a network interface card (NIC)124that may be coupled together and configured to cooperate with each other to prefetch resources from the system memory116or another location to a cache such as the integrated cache112or the external cache114using the prefetch engine122. In embodiments, the processor110may include multiple processors or processor cores. In embodiments, the integrated cache112or the external cache114may have more than one cache level. For example, the integrated cache112may have a Level 1 (L1) cache and a Level 2 (L2) cache in various embodiments.

The system memory116may include a plurality of resources, such as a first resource126, a second resource128, and a third resource130that may be non-transitory, or transitory such as during execution of an application program by the processor110, for example. In embodiments, the execution environment118may include the library module120which may be a shared library module in various embodiments. In embodiments, the library module120may include a software stack132that includes a plurality of layers or logic stages. The library module120may be a Message Passing Interface (MPI) library in various embodiments.

In embodiments, the software stack132may include a first logic stage134, a second logic stage136, a third logic stage138, a fourth logic stage140, and a fifth logic stage142. The first logic stage134may be an entry level of an MPI library and the second logic stage136may be a transport level such as an MPI library level with access to hardware resources or resources stored in memory, in embodiments. The third logic stage138, fourth logic stage140, and fifth logic stage142may be layers of the software stack, in stack order, that are between the first logic stage134and the second logic stage136. In embodiments, the software stack132may include levels of an MPI library corresponding to an MPI standard, such as MPI standard Version 2.0 (MPI-2), or 3.0 (MPI-3), for example. Levels of the software stack132may include an abstract device interface, such as a third generation of the abstract device interface (ADI3), a channel interface, such as the third version of the channel interface (CH3), and a communications layer, such as Nemesis (which may function as a low-level communication subsystem layer and act as a CH3 channel in some MPI implementations), in various embodiments. ADI3 may be a layer that uses the CH3 to implement communication channels that provide routines to send data between MPI processes and provide other capabilities in various embodiments. In embodiments, each level or interface of the software stack132may correspond to one or more of the first logic stage134, the second logic stage136, the third logic stage138, the fourth logic stage140, the fifth logic stage142, or other logic stages if present in the software stack132. In embodiments, the software stack may have a different number of logic stages.

In embodiments, a lower level of the software stack132, such as the second logic stage136, for example, may provide access to intra-node resources, such as a shared memory resource. Access to the shared memory resource may be by using CH3 or Nemesis, for example. In embodiments, the shared memory resource may correspond to the first resource126, the second resource128, and the third resource130. The shared memory resources may be structured in different manners, depending on the application, such as a buffer, array, or linked list, for example, in various embodiments. In embodiments, a lower level of the software stack132, such as the second logic stage, may provide access to inter-node resources, such as by using a network communications fabric through Nemesis or another communications layer. Internode resources may be accessed using interfaces or drivers provided by a technology such as InfiniBand, iWarp, Dolphin, Qlogic, Intel® True Scale, Myrinet, or Ethernet, for example. In embodiments, intermediate stages such as Direct Access Programming Library (DAPL), OpenFabrics alliance (OFA) interfaces, OpenFabrics Enterprise Distribution (OFED™) verbs, Remote Direct Memory Access (RDMA), Tag Matching Interface (TMI), sockets, or other technologies may be used in accessing the inter-node resources or intra-node resources. In embodiments, the computing device102may access inter-node resources such as registered memory on the node104or the node106over the network108by communicating over the NIC124, for example.

In embodiments, the prefetch engine122may include a prefetch table144that may include a parameter corresponding to a resource to be prefetched. In embodiments, the prefetch table144may include a pointer to an address of a resource, a prefetch type, and a prefetch depth. In embodiments, the prefetch type may include a parameter that may correspond to a cache level, such as L1, L2, or Level 3 (L3) for example, to which the resource is to be prefetched or requested to be prefetched. In embodiments, the prefetch depth may include a parameter that corresponds to a number of cache lines to be prefetched. In embodiments, the cache line size may be 64 bytes. The prefetch table144may include only a parameter corresponding to a resource to be prefetched in embodiments, and the prefetch engine122may include a predefined prefetch type or a predefined prefetch depth in various embodiments, or may use a default prefetch type or default prefetch depth when not specified in the prefetch table144. For example, the predefined prefetch type may be prefetch to L1 cache and the predefined prefetch depth may be two cache lines, in an embodiment. Generally, in embodiments, the prefetch table may include entries such as the following:

prefetch_engine_control[(prefetch_entry_index)].type=(type_); and

In embodiments, the prefetch type may be MM_HINT_T0, MM_HINT_T1, or MM_HINT_T2, for example. The prefetch type may also specify prefetching into more than one level of cache in various embodiments.

The execution environment118may also include other modules146and/or storage148in various embodiments. The execution environment118may also include an operating system (OS) operated by the processor110. In embodiments, the execution environment may include an application, such as an MPI application that when executed by the processor110cause one or more processes to call the library module120. In embodiments, each process may have its own prefetch engine such that multiple instances of the prefetch engine122may be present while the processes are being executed by the processor110. In embodiments, the application may be included in other modules146. The node104or the node106may be structured in a similar manner or include similar components to the computing device102in various embodiments.

FIG. 2depicts an example process200for prefetching resources that may be implemented by the computing device102in accordance with various embodiments. In various embodiments, the process200may be performed by the library module120, including the prefetch engine122and the prefetch table144. In other embodiments, the process200may be performed with more or less modules and/or with some operations in different order. As shown, for embodiments, the process200may start at a decision block202where it may be determined whether a call to a library such as the library120has been received. If a call has not been received at the library, the process may wait at the decision block202in various embodiments.

If, at the decision block202, a call is received at the library, the process200may proceed to a block204where a first logic stage, such as the first logic stage134may be entered. This may occur by the processor110operating the library module120, and receiving a call, such as an MPI_Send call from an MPI application, to the library. An MPI context may then be entered, and a rank parameter and a communicator parameter from the MPI application may be used to map the MPI_Send call to an internal connection/rank related structure that may be referred to as a virtual connection in various embodiments. Other parameters, such as an MPI tag parameter, may also be used.

At a decision block206, it may be determined whether the received call is a call type that results in a prefetch request. In embodiments, it may be determined at the decision block206, whether the received call is within a communication call type category that may include a plurality of call types. For example, the communication call type category may include calls such as MPI_Send, MPI_Sendrecv, and MPI_Put, in various embodiments. In embodiments, it may be determined whether the received call is a specific call type, such as an MPI_Send call, for example, or whether the received call belongs to a set of specific call types.

If, at the decision block206, it is determined that the received call is a prefetch call type, the process200may proceed to a block208where a prefetch engine table, such as the prefetch engine table144may be checked. The prefetch engine table may be checked from an entry level of the library, such as the first logic stage134, in embodiments. The prefetch engine table may be checked from a level of the library lower than the entry level, such as the third logic stage138, that may still be above a transport level of the library used to access resources, in various embodiments. Generally, cross-level prefetch may be performed in various embodiments, with the prefetch engine table being checked at a level of the library higher than a low level transport layer of the library that is used to access resources.

At a decision block210, it may be determined whether the checked prefetch table is null. If, at the decision block210, it is determined that the prefetch table is null (such as may occur on an initial iteration of the process200), a software stack, such as the software stack132, for example, may be traversed at the block212. If, at the decision block206, it is determined that the received call is not a prefetch call type, the process200may also proceed to the block212where the software stack may be traversed without performing a check of the prefetch engine table.

At operation214, a resource, such as the first resource126(during an initial iteration of the process200) the second resource128, or the third resource130(during subsequent iterations), may be accessed. If the resource has not been prefetched in a previous iteration of the process200or otherwise stored in a cache location, the resource may be accessed in a memory such as the memory116, for example. If the resource was prefetched in a previous iteration of the process200, the resource may be accessed in a cache, such as the cache112or the external cache114, in various embodiments. In embodiments, the resource may be accessed by a low level transport logic stage of a software stack in the library, such as the second logic stage136in the software stack132of the library module120, for example. When the resource is an intra-node resource such as may be stored in a shared memory location, a low level logic stage such as CH3 or Nemesis may be used to access the resource. When the resource is an inter-node resource, such as may be stored on node104or node106and accessed from computing device102, a technology such as InfiniBand may be used to access the resource, with a communications layer such as Nemesis acting as a low level communications logic stage in the software stack that may act through an interface such as DAPL or OFA which may be a part of or external to the software stack in various embodiments.

At a decision block216, it may be determined whether the received call is a prefetch call type in a similar manner as that discussed with respect to the decision block206. If the received call is a prefetch call type, such as an MPI_Send call, for example, a next resource address may be determined at a block218. For example, if a first resource, such as the first resource126is accessed at operation214, the next resource address may correspond to the second resource128. In embodiments, a transport level of the library, such as the second logic stage136, may have registered shared memory in a first in first out (FIFO) manner, and the next resource address may be determined based at least in part on this information.

In subsequent iterations of the process200, the accessed resource and the next resource address may change, with the next resource from the previous iteration becoming the accessed resource in the current iteration. For example, the second resource128may become the accessed resource and the third resource130may be the next resource on the second iteration of the process200. At a block220, the prefetch engine table, such as the prefetch table144, may be updated based at least in part on the determined next resource address. In embodiments, the prefetch table may be updated with a pointer to the determined next resource address. In embodiments, the prefetch table may be updated with another parameter corresponding to the determined next resource address, such as a virtual memory address identifier or a physical memory address, for example. The prefetch table may be updated with a prefetch depth and a prefetch type in various embodiments, such as described with respect to the prefetch table144, for example. In embodiments, the prefetch engine table may be updated at the lowest transport level or logic stage in the software stack of the library called by the application.

If, at the decision block210, it is determined that the prefetch engine table is not null, the process200may proceed to a block222where a prefetch request may be sent. This may occur by the prefetch engine122sending a prefetch request based at least in part on an entry in the prefetch engine table that was updated in a previous iteration of the process200, for example. The computing device102may prefetch the next resource, such as the second resource128, for example into a cache such as integrated cache112or external cache114, in various embodiments. The prefetch request may be sent from an entry level of an MPI library in various embodiments. The prefetch request may be sent as a suggestion or hint in various embodiments that may be followed depending on other constraints affecting the application, processor, or cache occupancy levels. In embodiments, the prefetch request may be sent as a command that will be followed rather than a suggestion or hint that may be followed. In embodiments, an_mm_prefetch compiler intrinsic may be used to generate a central processing unit (CPU) prefetch instruction. Generally, the prefetch request may be sent in a cross-level manner such that it is sent from a logic stage of the library that is higher than a logic stage used to access the prefetched resource. The process200may then proceed to traverse the software stack at the block212. For example, the process may traverse ADI3 and CH3 levels of the MPI library. The process200may then continue at operation214as discussed above.

Referring now toFIG. 3, an example computer300suitable to practice the present disclosure as earlier described with reference toFIGS. 1-2is illustrated in accordance with various embodiments. As shown, computer300may include one or more processors or processor cores302, and system memory304. For the purpose of this application, including the claims, the terms “processor” and “processor cores” may be considered synonymous, unless the context clearly requires otherwise. Additionally, computer300may include one or more graphics processors305, mass storage devices306(such as diskette, hard drive, compact disc read only memory (CD-ROM) and so forth), input/output devices308(such as display, keyboard, cursor control, remote control, gaming controller, image capture device, and so forth), sensor hub309, and communication interfaces310(such as network interface cards, modems, infrared receivers, radio receivers (e.g., Bluetooth), and so forth). The elements may be coupled to each other via system bus312, which may represent one or more buses. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown).

Each of these elements may perform its conventional functions known in the art. In particular, system memory304and mass storage devices306may be employed to store a working copy and a permanent copy of the programming instructions implementing the operations associated with the computing device102, e.g., operations described for library modules120and other modules146, shown inFIG. 1, or operations shown in process200ofFIG. 2, collectively denoted as computational logic322. The system memory304and mass storage devices306may also be employed to store a working copy and a permanent copy of the programming instructions implementing the operations associated with an OS running on the computing device102. The system memory304and mass storage devices306may also be employed to store the data or local resources in various embodiments. The various elements may be implemented by assembler instructions supported by processor(s)302or high-level languages, such as, for example, C, that can be compiled into such instructions.

The permanent copy of the programming instructions may be placed into mass storage devices306in the factory, or in the field, through, for example, a distribution medium (not shown), such as a compact disc (CD), or through communication interface310(from a distribution server (not shown)). That is, one or more distribution media having an implementation of the agent program may be employed to distribute the agent and program various computing devices.

The number, capability and/or capacity of these elements308-312may vary, depending on whether computer300is a stationary computing device, such as a server, high performance computing node, set-top box or desktop computer, a mobile computing device such as a tablet computing device, laptop computer or smartphone, or an embedded computing device. Their constitutions are otherwise known, and accordingly will not be further described. In various embodiments, different elements or a subset of the elements shown inFIG. 3may be used. For example, some devices may not include the graphics processor305, may use a unified memory that serves as both memory and storage, or may couple sensors without using a sensor hub.

FIG. 4illustrates an example of at least one non-transitory computer-readable storage medium402having instructions configured to practice all or selected ones of the operations associated with the computing device102, earlier described, in accordance with various embodiments. As illustrated, at least one non-transitory computer-readable storage medium402may include a number of programming instructions404. The storage medium402may represent a broad range of persistent storage medium known in the art, including but not limited to flash memory, dynamic random access memory, static random access memory, an optical disk, a magnetic disk, etc. Programming instructions404may be configured to enable a device, e.g., computer300or computing device102, in response to execution of the programming instructions404, to perform, e.g., but not limited to, various operations described for library module120and other modules146, shown inFIG. 1, or operations of process200ofFIG. 2. In alternate embodiments, programming instructions404may be disposed on multiple computer-readable storage media402. In alternate embodiment, storage medium402may be transitory, e.g., signals encoded with programming instructions404.

Referring back toFIG. 3, for an embodiment, at least one of processors302may be packaged together with memory having computational logic322configured to practice aspects described for library modules120and other modules146, shown inFIG. 1, or operations of process200ofFIG. 2. For an embodiment, at least one of processors302may be packaged together with memory having computational logic322configured to practice aspects described for library module120and other modules146shown inFIG. 1, or operations of process200ofFIG. 1to form a System in Package (SiP). For an embodiment, at least one of processors302may be integrated on the same die with memory having computational logic322configured to practice aspects described for library module120and other modules146, shown inFIG. 1, or operations of process200ofFIG. 2. For an embodiment, at least one of processors302may be packaged together with memory having computational logic322configured to practice aspects of library module120and other modules146shown inFIG. 1, or process200ofFIG. 2to form a System on Chip (SoC). For at least one embodiment, the SoC may be utilized in, e.g., but not limited to, a mobile computing device such as a wearable device and/or a smartphone.

Machine-readable media (including non-transitory machine-readable media, such as machine-readable storage media), methods, systems and devices for performing the above-described techniques are illustrative examples of embodiments disclosed herein. Additionally, other devices in the above-described interactions may be configured to perform various disclosed techniques.

EXAMPLES

Example 1 may include a computing device for executing applications, comprising: one or more processors; a library module, including a prefetch engine to prefetch resources, operated by the one or more processors to: receive a first call to the library module from an application; access a first resource based at least in part on the first call; and store a first prefetch entry in the prefetch engine based at least in part on an address of a second resource, in preparation to service a second call to the library module from the application that requires traversal of a plurality of stages at the library module.

Example 2 may include the subject matter of Example 1, wherein the computing device further comprises a cache integrated with a processor of the one or more processors, wherein the library module is further operated by the one or more processors to: receive the second call from the application; enter a first logic stage of the library module based at least in part on the second call; perform a first prefetch request based at least in part on the first prefetch entry; enter a second logic stage of the library module lower than the first logic stage; and access, from the second logic stage, the second resource in the cache based at least in part on a result of the first prefetch request.

Example 3 may include the subject matter of any one of Examples 1-2, wherein the library module is a Message Passing Interface (MPI) library module.

Example 4 may include the subject matter of any one of Examples 1-3, wherein the first call is a communication call type, and wherein the second call is a communication call type.

Example 5 may include the subject matter of any one of Examples 1-4, wherein the first call is a first MPI_Send call, and wherein the second call is a second MPI_Send call.

Example 6 may include the subject matter of any one of Examples 2-5, wherein the first prefetch entry includes a pointer to the address of the second resource, a distance value, and a prefetch type, and wherein performing the first prefetch request is based at least in part on the pointer to the address of the second resource, the distance value, and the prefetch type.

Example 7 may include the subject matter of Example 6, wherein the library module is further operated by the one or more processors to: determine an address of a third resource; and store a second prefetch entry in the prefetch engine based at least in part on the address of the third resource, the distance value, and the prefetch type, in preparation to service a third call to the library module from the application that requires traversal of the plurality of stages at the library module.

Example 8 may include the subject matter of of Example 7, further comprising a shared memory, wherein the library module is further operated by the one or more processors to: receive the third call from the application; enter the first logic stage based at least in part on the third call; call the prefetch engine based at least in part on the third call; perform a second prefetch request based at least in part on the second prefetch entry; traverse a third logic stage between the first logic stage and the second logic stage; enter the second logic stage after the third logic stage; and access, from the second logic stage, the third resource in the cache based at least in part on the second prefetch request, wherein the address of the third resource corresponds to a region of the shared memory.

Example 9 may include a computer implemented method for executing applications comprising: receiving, by a computing device, a first call from an application at a shared library; accessing, by the computing device, a first resource based at least in part on the first call; and storing, by the computing device, a first prefetch entry in a prefetch engine based at least in part on an address of a second resource, in preparation to service a second call to the shared library that requires traversal of a plurality of stages at the shared library.

Example 10 may include the subject matter of Example 9, further comprising: receiving, by the computing device, the second call from the application at the shared library; entering, by the computing device, a first logic stage of the shared library based at least in part on the second call; performing, by the computing device, a first prefetch request based at least in part on the first prefetch entry; entering, by the computing device, a second logic stage of the shared library; and accessing, by the computing device from the second logic stage, the second resource in a cache integrated with a processor of the computing device based at least in part on a result of the first prefetch request.

Example 11 may include the subject matter of any one of Examples 9-10, wherein the shared library is a Message Passing Interface (MPI) shared library.

Example 12 may include the subject matter of any one of Examples 9-11, wherein the first call is a communication call type, and wherein the second call is a communication call type.

Example 13 may include the subject matter of any one of Examples 9-12, wherein the first call is an MPI_Send call, and wherein the second call is an MPI_Send call.

Example 14 may include the subject matter of any one of Examples 10-13, wherein the first prefetch entry includes a pointer to the address of the second resource, a prefetch type, and a distance value, and wherein performing the first prefetch request is based at least in part on the pointer to the address of the second resource, the prefetch type, and the distance value.

Example 15 may include the subject matter of Example 14, further comprising: determining, by the computing device, an address of a third resource; and storing, by the computing device, a second prefetch entry in the prefetch engine based at least in part on the address of the third resource, the distance value, and the prefetch type, in preparation to service a third call to the shared library from the application that requires traversal of the plurality of stages at the shared library.

Example 16 may include the subject matter of Example 15, further comprising: receiving, by the computing device, the third call from the application at the shared library; entering, by the computing device, the first logic stage based at least in part on the third call; calling, by the computing device, the prefetch engine based at least in part on the third call; performing, by the computing device, a second prefetch request based at least in part on the second prefetch entry; traversing, by the computing device, a third logic stage between the first logic stage and the second logic stage; entering, by the computing device, the second logic stage after the third logic stage; and accessing, by the computing device from the second logic stage, the third resource in the cache based at least in part on the second prefetch request, wherein the address of the third resource corresponds to a region of shared memory.

Example 17 may include at least one non-transitory computer-readable medium comprising instructions stored thereon that, in response to execution of the instructions by a computing device, cause the computing device to: receive a first call from an application at a shared library; access a first resource based at least in part on the first call; and store a first prefetch entry in a prefetch engine based at least in part on an address of a second resource, in preparation to service a second call to the shared library that requires traversal of a plurality of stages at the shared library.

Example 18 may include the subject matter of Example 17, wherein the computing device is further caused to: receive the second call from the application at the shared library; enter a first logic stage of the shared library based at least in part on the second call; perform a first prefetch request based at least in part on the first prefetch entry; enter a second logic stage of the shared library; and access, from the second logic stage, the second resource in a cache integrated with a processor of the computing device based at least in part on a result of the first prefetch request.

Example 19 may include the subject matter of any one of Examples 17-18, wherein the shared library is a Message Passing Interface (MPI) shared library.

Example 20 may include the subject matter of any one of Examples 17-19, wherein the first call is a communication call type, and wherein the second call is a communication call type.

Example 21 may include the subject matter of any one of Examples 17-20, wherein the first call is an MPI_Send call, and wherein the second call is an MPI_Send call.

Example 22 may include the subject matter of any one of Examples 18-21, wherein the first prefetch entry includes a pointer to the address of the second resource, a prefetch type, and a distance value, and wherein the computing device is caused to perform the first prefetch request is based at least in part on the pointer to the address of the second resource, the prefetch type, and the distance value.

Example 23 may include the subject matter of Example 22, wherein the computing device is further caused to: determine an address of a third resource; and store a second prefetch entry in the prefetch engine based at least in part on the address of the third resource, the distance value, and the prefetch type, in preparation to service a third call to the shared library from the application that requires traversal of the plurality of stages at the shared library.

Example 24 may include the subject matter of Example 23, wherein the computing device is further caused to: receive the third call from the application at the shared library; enter the first logic stage based at least in part on the third call; call the prefetch engine based at least in part on the third call; perform a second prefetch request based at least in part on the second prefetch entry; traverse a third logic stage between the first logic stage and the second logic stage; enter the second logic stage after the third logic stage; and access, from the second logic stage, the third resource in the cache based at least in part on the second prefetch request, wherein the address of the third resource corresponds to a region of shared memory.

Example 25 may include a computing device for executing applications comprising: means for receiving a first call from an application at a shared library; means for accessing a first resource based at least in part on the first call; and means for storing a first prefetch entry in a prefetch engine based at least in part on an address of a second resource, in preparation to service a second call to the shared library that requires traversal of a plurality of stages at the shared library.

Example 26 may include the subject matter of Example 25, further comprising: means for receiving the second call from the application at the shared library; means for entering a first logic stage of the shared library based at least in part on the second call; means for performing a first prefetch request based at least in part on the first prefetch entry; means for entering a second logic stage of the shared library; and means for accessing, from the second logic stage, the second resource in a cache integrated with a processor of the computing device based at least in part on a result of the first prefetch request.

Example 27 may include the subject matter of any one of Examples 25-26, wherein the shared library is a Message Passing Interface (MPI) shared library.

Example 28 may include the subject matter of any one of Examples 25-27, wherein the first call is a communication call type, and wherein the second call is a communication call type.

Example 29 may include the subject matter of any one of Examples 25-28, wherein the first call is an MPI_Send call, and wherein the second call is an MPI_Send call.

Example 30 may include the subject matter of any one of Examples 26-29, wherein the first prefetch entry includes a pointer to the address of the second resource, a prefetch type, and a distance value, and wherein performing the first prefetch request is based at least in part on the pointer to the address of the second resource, the prefetch type, and the distance value.

Example 31 may include the subject matter of Example 30, further comprising: means for determining an address of a third resource; and means for storing a second prefetch entry in the prefetch engine based at least in part on the address of the third resource, the distance value, and the prefetch type, in preparation to service a third call to the shared library from the application that requires traversal of the plurality of stages at the shared library.

Example 32 may include the subject matter of Example 31, further comprising: means for receiving a third call from the application at the shared library; means for entering the first logic stage based at least in part on the third call; means for calling the prefetch engine based at least in part on the third call; means for performing a second prefetch request based at least in part on the second prefetch entry; means for traversing a third logic stage between the first logic stage and the second logic stage; means for entering the second logic stage after the third logic stage; and means for accessing, from the second logic stage, the third resource in the cache based at least in part on the second prefetch request, wherein the address of the third resource corresponds to a region of shared memory.