Apparatus and method for reused-data cache

Abstract

An apparatus and method for a reused-data cache. For example, a processor comprises: a plurality of processing cores; a first cache of a cache level shared by the plurality of processing cores, the first cache to store cache lines associated with data that is not specifically identified as data likely to be reused; a second cache of the cache level coupled to the plurality of processing cores, the second cache to store cache lines associated with data that is specifically identified as data likely to be reused; a cache controller configured to: receive an address associated with a load operation for first data; perform a lookup in at least one of the first cache and the second cache using the address; read the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively; load the first data from the memory if the lookup results in a miss in the first cache and the second cache; store the first data in one or more cache lines of the first cache if the first data is not specifically identified as data likely to be reused; and store the first data in one or more cache lines of the second cache if the first data is specifically identified as data likely to be reused.

Description

APPARATUS AND METHOD FOR REUSED-DATA CACHEBACKGROUNDField of the InventionThis invention relates generally to the field of computer processors. More particularly, the invention relates to an apparatus and method for a reused-data cache to improve cache performance for multiprocessors.Description of the Related ArtOn the front of artificial intelligence (AI) and deep learning (DL) , there has been an increasing demand from major cloud solution providers (CSPs) to minimize the cache miss rate on critical static data for DL inference operations, including Recommendation, natural language processing (NLP) and cross-validation (CV) related models.In addition, big data analytics demonstrates rather limited performance benefits from greatly enlarged unified caches. Performance studies have confirmed that throughput performance of online analytical processing (OLAP) workloads is insensitive to cache capacities, where the capacity change is proportional to the associativity change.Brief Description of the DrawingsA better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:A better understanding of the present invention can be obtained from the following detailed description in conjunction with the following drawings, in which:FIG. 1 illustrates an example computer system architecture;FIG. 2 illustrates a processor comprising a plurality of cores;FIG. 3 (A) illustrates a plurality of stages of a processing pipeline;FIG. 3 (B) illustrates details of one embodiment of a core;FIG. 4 illustrates execution circuitry in accordance with one embodiment;FIG. 5 illustrates one embodiment of a register architecture;FIG. 6 illustrates one example of an instruction format;FIG. 7 illustrates addressing techniques in accordance with one embodiment;FIG. 8 illustrates one embodiment of an instruction prefix;FIGS. 9 (A) -(D) illustrate embodiments of how the R, X, and B fields of the prefix are used;FIGS. 10 (A) - (B) illustrate examples of a second instruction prefix;FIG. 11 illustrates payload bytes of one embodiment of an instruction prefix;FIG. 12 illustrates instruction conversion and binary translation implementations;FIG. 13 illustrates an example of a plurality of hash join operations implemented on a plurality of worker nodes;FIG. 14 illustrates another example of a plurality of hash join operations implemented on a plurality of worker nodes;FIG. 15 illustrates example pseudocode;FIG. 16 illustrates example pseudocode including a data reuse hint;FIG. 17 illustrates fields associated with different cache management policies;FIG. 18 illustrates a method for maintaining likely to be used data in a cache in accordance with a new load instruction;FIG. 19 illustrates a core architecture including a reused-data cache;FIG. 20 illustrates a cache architecture including a reused-data cache in accordance with some embodiments;FIG. 21 illustrates an example of a processor architecture with a reused-data cache;FIGS. 22A-C illustrate common characteristics of ResNet-50 with BF16;FIGS. 23A-B illustrate results with SPR6459C to estimate performance;FIG. 24 illustrates cache miss behavior for certain workloads;FIG. 25 illustrates weak-scaling throughput for certain model types;FIG. 26 illustrates a graph of misses per instruction with different caches;FIG. 27 illustrates a portion of a directed acyclic graph;FIG. 28 illustrates a portion of a directed acyclic graph with a plurality of broadcast hash join (BHJ) operations;FIG. 29 illustrates cache sensitivity as payload size increase for different types of workloads; andFIG. 30 illustrates an example of BHJ execution, including three steps.Detailed DescriptionIn the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the invention described below. It will be apparent, however, to one skilled in the art that the embodiments of the invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the embodiments of the invention.Exemplary Computer ArchitecturesDetailed below are describes of exemplary computer architectures. Other system designs and configurations known in the arts for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs) , graphics devices, video game devices, set-top boxes, micro controllers, cell phones, portable media players, hand held devices, and various other electronic devices, are also suitable. In general, a huge variety of systems or electronic devices capable of incorporating a processor and / or other execution logic as disclosed herein are generally suitable.FIG. 1 illustrates embodiments of an exemplary system. Multiprocessor system 100 is a point-to-point interconnect system and includes a plurality of processors including a first processor 170 and a second processor 180 coupled via a point-to-point interconnect 150. In some embodiments, the first processor 170 and the second processor 180 are homogeneous. In some embodiments, first processor 170 and the second processor 180 are heterogenous.Processors 170 and 180 are shown including integrated memory controller (IMC) units circuitry 172 and 182, respectively. Processor 170 also includes as part of its interconnect controller units point-to-point (P-P) interfaces 176 and 178; similarly, second processor 180 includes P-P interfaces 186 and 188. Processors 170, 180 may exchange information via the point-to-point (P-P) interconnect 150 using P-P interface circuits 178, 188. IMCs 172 and 182 couple the processors 170, 180 to respective memories, namely a memory 132 and a memory 134, which may be portions of main memory locally attached to the respective processors.Processors 170, 180 may each exchange information with a chipset 190 via individual P-P interconnects 152, 154 using point to point interface circuits 176, 194, 186, 198. Chipset 190 may optionally exchange information with a coprocessor 138 via a high-performance interface 192. In some embodiments, the coprocessor 138 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor, or the like.A shared cache (not shown) may be included in either processor 170, 180 or outside of both processors, yet connected with the processors via P-P interconnect, such that either or both processors’ local cache information may be stored in the shared cache if a processor is placed into a low power mode.Chipset 190 may be coupled to a first interconnect 116 via an interface 196. In some embodiments, first interconnect 116 may be a Peripheral Component Interconnect (PCI) interconnect, or an interconnect such as a PCI Express interconnect or another I / O interconnect. In some embodiments, one of the interconnects couples to a power control unit (PCU) 117, which may include circuitry, software, and / or firmware to perform power management operations with regard to the processors 170, 180 and / or co-processor 138. PCU 117 provides control information to a voltage regulator to cause the voltage regulator to generate the appropriate regulated voltage. PCU 117 also provides control information to control the operating voltage generated. In various embodiments, PCU 117 may include a variety of power management logic units (circuitry) to perform hardware-based power management. Such power management may be wholly processor controlled (e.g., by various processor hardware, and which may be triggered by workload and / or power, thermal or other processor constraints) and / or the power management may be performed responsive to external sources (such as a platform or power management source or system software) .PCU 117 is illustrated as being present as logic separate from the processor 170 and / or processor 180. In other cases, PCU 117 may execute on a given one or more of cores (not shown) of processor 170 or 180. In some cases, PCU 117 may be implemented as a microcontroller (dedicated or general-purpose) or other control logic configured to execute its own dedicated power management code, sometimes referred to as P-code. In yet other embodiments, power management operations to be performed by PCU 117 may be implemented externally to a processor, such as by way of a separate power management integrated circuit (PMIC) or another component external to the processor. In yet other embodiments, power management operations to be performed by PCU 117 may be implemented within BIOS or other system software.Various I / O devices 114 may be coupled to first interconnect 116, along with an interconnect (bus) bridge 118 which couples first interconnect 116 to a second interconnect 120. In some embodiments, one or more additional processor (s) 115, such as coprocessors, high-throughput MIC processors, GPGPU’s , accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units) , field programmable gate arrays (FPGAs) , or any other processor, are coupled to first interconnect 116. In some embodiments, second interconnect 120 may be a low pin count (LPC) interconnect. Various devices may be coupled to second interconnect 120 including, for example, a keyboard and / or mouse 122, communication devices 127 and a storage unit circuitry 128. Storage unit circuitry 128 may be a disk drive or other mass storage device which may include instructions / code and data 130, in some embodiments. Further, an audio I / O 124 may be coupled to second interconnect 120. Note that other architectures than the point-to-point architecture described above are possible. For example, instead of the point-to-point architecture, a system such as multiprocessor system 100 may implement a multi-drop interconnect or other such architecture.Exemplary Core Architectures, Processors, and Computer ArchitecturesProcessor cores may be implemented in different ways, for different purposes, and in different processors. For instance, implementations of such cores may include: 1) a general purpose in-order core intended for general-purpose computing; 2) a high performance general purpose out-of-order core intended for general-purpose computing; 3) a special purpose core intended primarily for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU including one or more general purpose in-order cores intended for general-purpose computing and / or one or more general purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor including one or more special purpose cores intended primarily for graphics and / or scientific (throughput) . Such different processors lead to different computer system architectures, which may include: 1) the coprocessor on a separate chip from the CPU; 2) the coprocessor on a separate die in the same package as a CPU; 3) the coprocessor on the same die as a CPU (in which case, such a coprocessor is sometimes referred to as special purpose logic, such as integrated graphics and / or scientific (throughput) logic, or as special purpose cores) ; and 4) a system on a chip that may include on the same die as the described CPU (sometimes referred to as the application core (s) or application processor (s) ) , the above described coprocessor, and additional functionality. Exemplary core architectures are described next, followed by descriptions of exemplary processors and computer architectures.FIG. 2 illustrates a block diagram of embodiments of a processor 200 that may have more than one core, may have an integrated memory controller, and may have integrated graphics. The solid lined boxes illustrate a processor 200 with a single core 202A, a system agent 210, a set of one or more interconnect controller units circuitry 216, while the optional addition of the dashed lined boxes illustrates an alternative processor 200 with multiple cores 202 (A) - (N) , a set of one or more integrated memory controller unit (s) circuitry 214 in the system agent unit circuitry 210, and special purpose logic 208, as well as a set of one or more interconnect controller units circuitry 216. Note that the processor 200 may be one of the processors 170 or 180, or co-processor 138 or 115 of FIG. 1.Thus, different implementations of the processor 200 may include: 1) a CPU with the special purpose logic 208 being integrated graphics and / or scientific (throughput) logic (which may include one or more cores, not shown) , and the cores 202 (A) - (N) being one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, or a combination of the two) ; 2) a coprocessor with the cores 202 (A) - (N) being a large number of special purpose cores intended primarily for graphics and / or scientific (throughput) ; and 3) a coprocessor with the cores 202 (A) -(N) being a large number of general purpose in-order cores. Thus, the processor 200 may be a general-purpose processor, coprocessor or special-purpose processor, such as, for example, a network or communication processor, compression engine, graphics processor, GPGPU (general purpose graphics processing unit circuitry) , a high-throughput many integrated core (MIC) coprocessor (including 30 or more cores) , embedded processor, or the like. The processor may be implemented on one or more chips. The processor 200 may be a part of and / or may be implemented on one or more substrates using any of a number of process technologies, such as, for example, BiCMOS, CMOS, or NMOS.A memory hierarchy includes one or more levels of cache unit (s) circuitry 204 (A) - (N) within the cores 202 (A) - (N) , a set of one or more shared cache units circuitry 206, and external memory (not shown) coupled to the set of integrated memory controller units circuitry 214. The set of one or more shared cache units circuitry 206 may include one or more mid-level caches, such as level 2 (L2) , level 3 (L3) , level 4 (L4) , or other levels of cache, such as a last level cache (LLC) , and / or combinations thereof. While in some embodiments ring-based interconnect network circuitry 212 interconnects the special purpose logic 208 (e.g., integrated graphics logic) , the set of shared cache units circuitry 206, and the system agent unit circuitry 210, alternative embodiments use any number of well-known techniques for interconnecting such units. In some embodiments, coherency is maintained between one or more of the shared cache units circuitry 206 and cores 202 (A) - (N) .In some embodiments, one or more of the cores 202 (A) - (N) are capable of multi-threading. The system agent unit circuitry 210 includes those components coordinating and operating cores 202 (A) - (N) . The system agent unit circuitry 210 may include, for example, power control unit (PCU) circuitry and / or display unit circuitry (not shown) . The PCU may be or may include logic and components needed for regulating the power state of the cores 202 (A) - (N) and / or the special purpose logic 208 (e.g., integrated graphics logic) . The display unit circuitry is for driving one or more externally connected displays.The cores 202 (A) - (N) may be homogenous or heterogeneous in terms of architecture instruction set; that is, two or more of the cores 202 (A) - (N) may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of that instruction set or a different instruction set.Exemplary Core ArchitecturesIn-order and out-of-order core block diagramFIG. 3 (A) is a block diagram illustrating both an exemplary in-order pipeline and an exemplary register renaming, out-of-order issue / execution pipeline according to embodiments of the invention. FIG. 3 (B) is a block diagram illustrating both an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor according to embodiments of the invention. The solid lined boxes in FIGS. 3 (A) - (B) illustrate the in-order pipeline and in-order core, while the optional addition of the dashed lined boxes illustrates the register renaming, out-of-order issue / execution pipeline and core. Given that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.In FIG. 3 (A) , a processor pipeline 300 includes a fetch stage 302, an optional length decode stage 304, a decode stage 306, an optional allocation stage 308, an optional renaming stage 310, a scheduling (also known as a dispatch or issue) stage 312, an optional register read / memory read stage 314, an execute stage 316, a write back / memory write stage 318, an optional exception handling stage 322, and an optional commit stage 324. One or more operations can be performed in each of these processor pipeline stages. For example, during the fetch stage 302, one or more instructions are fetched from instruction memory, during the decode stage 306, the one or more fetched instructions may be decoded, addresses (e.g., load store unit (LSU) addresses) using forwarded register ports may be generated, and branch forwarding (e.g., immediate offset or an link register (LR) ) may be performed. In one embodiment, the decode stage 306 and the register read / memory read stage 314 may be combined into one pipeline stage. In one embodiment, during the execute stage 316, the decoded instructions may be executed, LSU address / data pipelining to an Advanced Microcontroller Bus (AHB) interface may be performed, multiply and add operations may be performed, arithmetic operations with branch results may be performed, etc.By way of example, the exemplary register renaming, out-of-order issue / execution core architecture may implement the pipeline 300 as follows: 1) the instruction fetch 338 performs the fetch and length decoding stages 302 and 304; 2) the decode unit circuitry 340 performs the decode stage 306; 3) the rename / allocator unit circuitry 352 performs the allocation stage 308 and renaming stage 310; 4) the scheduler unit (s) circuitry 356 performs the schedule stage 312; 5) the physical register file (s) unit (s) circuitry 358 and the memory unit circuitry 370 perform the register read / memory read stage 314; the execution cluster 360 perform the execute stage 316; 6) the memory unit circuitry 370 and the physical register file (s) unit (s) circuitry 358 perform the write back / memory write stage 318; 7) various units (unit circuitry) may be involved in the exception handling stage 322; and 8) the retirement unit circuitry 354 and the physical register file (s) unit (s) circuitry 358 perform the commit stage 324.FIG. 3 (B) shows processor core 390 including front-end unit circuitry 330 coupled to an execution engine unit circuitry 350, and both are coupled to a memory unit circuitry 370. The core 390 may be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As yet another option, the core 390 may be a special-purpose core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like.The front end unit circuitry 330 may include branch prediction unit circuitry 332 coupled to an instruction cache unit circuitry 334, which is coupled to an instruction translation lookaside buffer (TLB) 336, which is coupled to instruction fetch unit circuitry 338, which is coupled to decode unit circuitry 340. In one embodiment, the instruction cache unit circuitry 334 is included in the memory unit circuitry 370 rather than the front-end unit circuitry 330. The decode unit circuitry 340 (or decoder) may decode instructions, and generate as an output one or more micro-operations, micro-code entry points, microinstructions, other instructions, or other control signals, which are decoded from, or which otherwise reflect, or are derived from, the original instructions. The decode unit circuitry 340 may further include an address generation unit circuitry (AGU, not shown) . In one embodiment, the AGU generates an LSU address using forwarded register ports, and may further perform branch forwarding (e.g., immediate offset branch forwarding, LR register branch forwarding, etc. ) . The decode unit circuitry 340 may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, programmable logic arrays (PLAs) , microcode read only memories (ROMs) , etc. In one embodiment, the core 390 includes a microcode ROM (not shown) or other medium that stores microcode for certain macroinstructions (e.g., in decode unit circuitry 340 or otherwise within the front end unit circuitry 330) . In one embodiment, the decode unit circuitry 340 includes a micro-operation (micro-op) or operation cache (not shown) to hold / cache decoded operations, micro-tags, or micro-operations generated during the decode or other stages of the processor pipeline 300. The decode unit circuitry 340 may be coupled to rename / allocator unit circuitry 352 in the execution engine unit circuitry 350.The execution engine circuitry 350 includes the rename / allocator unit circuitry 352 coupled to a retirement unit circuitry 354 and a set of one or more scheduler (s) circuitry 356. The scheduler (s) circuitry 356 represents any number of different schedulers, including reservations stations, central instruction window, etc. In some embodiments, the scheduler (s) circuitry 356 can include arithmetic logic unit (ALU) scheduler / scheduling circuitry, ALU queues, arithmetic generation unit (AGU) scheduler / scheduling circuitry, AGU queues, etc. The scheduler (s) circuitry 356 is coupled to the physical register file (s) circuitry 358. Each of the physical register file (s) circuitry 358 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integer, scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point, status (e.g., an instruction pointer that is the address of the next instruction to be executed) , etc. In one embodiment, the physical register file (s) unit circuitry 358 includes vector registers unit circuitry, writemask registers unit circuitry, and scalar register unit circuitry. These register units may provide architectural vector registers, vector mask registers, general-purpose registers, etc. The physical register file (s) unit (s) circuitry 358 is overlapped by the retirement unit circuitry 354 (also known as a retire queue or a retirement queue) to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using a reorder buffer (s) (ROB (s) ) and a retirement register file (s) ; using a future file (s) , a history buffer (s) , and a retirement register file (s) ; using a register maps and a pool of registers; etc. ) . The retirement unit circuitry 354 and the physical register file (s) circuitry 358 are coupled to the execution cluster (s) 360. The execution cluster (s) 360 includes a set of one or more execution units circuitry 362 and a set of one or more memory access circuitry 364. The execution units circuitry 362 may perform various arithmetic, logic, floating-point or other types of operations (e.g., shifts, addition, subtraction, multiplication) and on various types of data (e.g., scalar floating-point, packed integer, packed floating-point, vector integer, vector floating-point) . While some embodiments may include a number of execution units or execution unit circuitry dedicated to specific functions or sets of functions, other embodiments may include only one execution unit circuitry or multiple execution units / execution unit circuitry that all perform all functions. The scheduler (s) circuitry 356, physical register file (s) unit (s) circuitry 358, and execution cluster (s) 360 are shown as being possibly plural because certain embodiments create separate pipelines for certain types of data / operations (e.g., a scalar integer pipeline, a scalar floating-point / packed integer / packed floating-point / vector integer / vector floating-point pipeline, and / or a memory access pipeline that each have their own scheduler circuitry, physical register file (s) unit circuitry, and / or execution cluster –and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of this pipeline has the memory access unit (s) circuitry 364) . It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution and the rest in-order.In some embodiments, the execution engine unit circuitry 350 may perform load store unit (LSU) address / data pipelining to an Advanced Microcontroller Bus (AHB) interface (not shown) , and address phase and writeback, data phase load, store, and branches.The set of memory access circuitry 364 is coupled to the memory unit circuitry 370, which includes data TLB unit circuitry 372 coupled to a data cache circuitry 374 coupled to a level 2 (L2) cache circuitry 376. In one exemplary embodiment, the memory access units circuitry 364 may include a load unit circuitry, a store address unit circuit, and a store data unit circuitry, each of which is coupled to the data TLB circuitry 372 in the memory unit circuitry 370. The instruction cache circuitry 334 is further coupled to a level 2 (L2) cache unit circuitry 376 in the memory unit circuitry 370. In one embodiment, the instruction cache 334 and the data cache 374 are combined into a single instruction and data cache (not shown) in L2 cache unit circuitry 376, a level 3 (L3) cache unit circuitry (not shown) , and / or main memory. The L2 cache unit circuitry 376 is coupled to one or more other levels of cache and eventually to a main memory.The core 390 may support one or more instructions sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions) ; the MIPS instruction set; the ARM instruction set (with optional additional extensions such as NEON) ) , including the instruction (s) described herein. In one embodiment, the core 390 includes logic to support a packed data instruction set extension (e.g., AVX1, AVX2) , thereby allowing the operations used by many multimedia applications to be performed using packed data.Exemplary Execution Unit (s) CircuitryFIG. 4 illustrates embodiments of execution unit (s) circuitry, such as execution unit (s) circuitry 362 of FIG. 3 (B) . As illustrated, execution unit (s) circuity 362 may include one or more ALU circuits 401, vector / SIMD unit circuits 403, load / store unit circuits 405, and / or branch / jump unit circuits 407. ALU circuits 401 perform integer arithmetic and / or Boolean operations. Vector / SIMD unit circuits 403 perform vector / SIMD operations on packed data (such as SIMD / vector registers) . Load / store unit circuits 405 execute load and store instructions to load data from memory into registers or store from registers to memory. Load / store unit circuits 405 may also generate addresses. Branch / jump unit circuits 407 cause a branch or jump to a memory address depending on the instruction. Floating-point unit (FPU) circuits 409 perform floating-point arithmetic. The width of the execution unit (s) circuitry 362 varies depending upon the embodiment and can range from 16-bit to 1, 024-bit. In some embodiments, two or more smaller execution units are logically combined to form a larger execution unit (e.g., two 128-bit execution units are logically combined to form a 256-bit execution unit) .Exemplary Register ArchitectureFIG. 5 is a block diagram of a register architecture 500 according to some embodiments. As illustrated, there are vector / SIMD registers 510 that vary from 128-bit to 1, 024 bits width. In some embodiments, the vector / SIMD registers 510 are physically 512-bits and, depending upon the mapping, only some of the lower bits are used. For example, in some embodiments, the vector / SIMD registers 510 are ZMM registers which are 512 bits: the lower 256 bits are used for YMM registers and the lower 128 bits are used for XMM registers. As such, there is an overlay of registers. In some embodiments, a vector length field selects between a maximum length and one or more other shorter lengths, where each such shorter length is half the length of the preceding length. Scalar operations are operations performed on the lowest order data element position in a ZMM / YMM / XMM register; the higher order data element positions are either left the same as they were prior to the instruction or zeroed depending on the embodiment.In some embodiments, the register architecture 500 includes writemask / predicate registers 515. For example, in some embodiments, there are 8 writemask / predicate registers (sometimes called k0 through k7) that are each 16-bit, 32-bit, 64-bit, or 128-bit in size. Writemask / predicate registers 515 may allow for merging (e.g., allowing any set of elements in the destination to be protected from updates during the execution of any operation) and / or zeroing (e.g., zeroing vector masks allow any set of elements in the destination to be zeroed during the execution of any operation) . In some embodiments, each data element position in a given writemask / predicate register 515 corresponds to a data element position of the destination. In other embodiments, the writemask / predicate registers 515 are scalable and consists of a set number of enable bits for a given vector element (e.g., 8 enable bits per 64-bit vector element) .The register architecture 500 includes a plurality of general-purpose registers 525. These registers may be 16-bit, 32-bit, 64-bit, etc. and can be used for scalar operations. In some embodiments, these registers are referenced by the names RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP, and R8 through R15.In some embodiments, the register architecture 500 includes scalar floating-point register 545 which is used for scalar floating-point operations on 32 / 64 / 80-bit floating-point data using the x87 instruction set extension or as MMX registers to perform operations on 64-bit packed integer data, as well as to hold operands for some operations performed between the MMX and XMM registers.One or more flag registers 540 (e.g., EFLAGS, RFLAGS, etc. ) store status and control information for arithmetic, compare, and system operations. For example, the one or more flag registers 540 may store condition code information such as carry, parity, auxiliary carry, zero, sign, and overflow. In some embodiments, the one or more flag registers 540 are called program status and control registers.Segment registers 520 contain segment points for use in accessing memory. In some embodiments, these registers are referenced by the names CS, DS, SS, ES, FS, and GS.Machine specific registers (MSRs) 535 control and report on processor performance. Most MSRs 535 handle system-related functions and are not accessible to an application program. Machine check registers 560 consist of control, status, and error reporting MSRs that are used to detect and report on hardware errors.One or more instruction pointer register (s) 530 store an instruction pointer value. Control register (s) 555 (e.g., CR0-CR4) determine the operating mode of a processor (e.g., processor 170, 180, 138, 115, and / or 200) and the characteristics of a currently executing task. Debug registers 550 control and allow for the monitoring of a processor or core’s debugging operations.Memory management registers 565 specify the locations of data structures used in protected mode memory management. These registers may include a GDTR, IDRT, task register, and a LDTR register.Alternative embodiments of the invention may use wider or narrower registers. Additionally, alternative embodiments of the invention may use more, less, or different register files and registers.Instruction SetsAn instruction set architecture (ISA) may include one or more instruction formats. A given instruction format may define various fields (e.g., number of bits, location of bits) to specify, among other things, the operation to be performed (e.g., opcode) and the operand (s) on which that operation is to be performed and / or other data field (s) (e.g., mask) . Some instruction formats are further broken down though the definition of instruction templates (or sub-formats) . For example, the instruction templates of a given instruction format may be defined to have different subsets of the instruction format’s fields (the included fields are typically in the same order, but at least some have different bit positions because there are less fields included) and / or defined to have a given field interpreted differently. Thus, each instruction of an ISA is expressed using a given instruction format (and, if defined, in a given one of the instruction templates of that instruction format) and includes fields for specifying the operation and the operands. For example, an exemplary ADD instruction has a specific opcode and an instruction format that includes an opcode field to specify that opcode and operand fields to select operands (source1 / destination and source2) ; and an occurrence of this ADD instruction in an instruction stream will have specific contents in the operand fields that select specific operands.Exemplary Instruction FormatsEmbodiments of the instruction (s) described herein may be embodied in different formats. Additionally, exemplary systems, architectures, and pipelines are detailed below. Embodiments of the instruction (s) may be executed on such systems, architectures, and pipelines, but are not limited to those detailed.FIG. 6 illustrates embodiments of an instruction format. As illustrated, an instruction may include multiple components including, but not limited to, one or more fields for: one or more prefixes 601, an opcode 603, addressing information 605 (e.g., register identifiers, memory addressing information, etc. ) , a displacement value 607, and / or an immediate 609. Note that some instructions utilize some or all of the fields of the format whereas others may only use the field for the opcode 603. In some embodiments, the order illustrated is the order in which these fields are to be encoded, however, it should be appreciated that in other embodiments these fields may be encoded in a different order, combined, etc.The prefix (es) field (s) 601, when used, modifies an instruction. In some embodiments, one or more prefixes are used to repeat string instructions (e.g., 0xF0, 0xF2, 0xF3, etc. ) , to provide section overrides (e.g., 0x2E, 0x36, 0x3E, 0x26, 0x64, 0x65, 0x2E, 0x3E, etc. ) , to perform bus lock operations, and / or to change operand (e.g., 0x66) and address sizes (e.g., 0x67) . Certain instructions require a mandatory prefix (e.g., 0x66, 0xF2, 0xF3, etc. ) . Certain of these prefixes may be considered “legacy” prefixes. Other prefixes, one or more examples of which are detailed herein, indicate, and / or provide further capability, such as specifying particular registers, etc. The other prefixes typically follow the “legacy” prefixes.The opcode field 603 is used to at least partially define the operation to be performed upon a decoding of the instruction. In some embodiments, a primary opcode encoded in the opcode field 603 is 1, 2, or 3 bytes in length. In other embodiments, a primary opcode can be a different length. An additional 3-bit opcode field is sometimes encoded in another field.The addressing field 605 is used to address one or more operands of the instruction, such as a location in memory or one or more registers. FIG. 7 illustrates embodiments of the addressing field 605. In this illustration, an optional ModR / M byte 702 and an optional Scale, Index, Base (SIB) byte 704 are shown. The ModR / M byte 702 and the SIB byte 704 are used to encode up to two operands of an instruction, each of which is a direct register or effective memory address. Note that each of these fields are optional in that not all instructions include one or more of these fields. The MOD R / M byte 702 includes a MOD field 742, a register field 744, and R / M field 746.The content of the MOD field 742 distinguishes between memory access and non-memory access modes. In some embodiments, when the MOD field 742 has a value of b11, a register-direct addressing mode is utilized, and otherwise register-indirect addressing is used.The register field 744 may encode either the destination register operand or a source register operand, or may encode an opcode extension and not be used to encode any instruction operand. The content of register index field 744, directly or through address generation, specifies the locations of a source or destination operand (either in a register or in memory) . In some embodiments, the register field 744 is supplemented with an additional bit from a prefix (e.g., prefix 601) to allow for greater addressing.The R / M field 746 may be used to encode an instruction operand that references a memory address, or may be used to encode either the destination register operand or a source register operand. Note the R / M field 746 may be combined with the MOD field 742 to dictate an addressing mode in some embodiments.The SIB byte 704 includes a scale field 752, an index field 754, and a base field 756 to be used in the generation of an address. The scale field 752 indicates scaling factor. The index field 754 specifies an index register to use. In some embodiments, the index field 754 is supplemented with an additional bit from a prefix (e.g., prefix 601) to allow for greater addressing. The base field 756 specifies a base register to use. In some embodiments, the base field 756 is supplemented with an additional bit from a prefix (e.g., prefix 601) to allow for greater addressing. In practice, the content of the scale field 752 allows for the scaling of the content of the index field 754 for memory address generation (e.g., for address generation that uses 2scale *index + base) .Some addressing forms utilize a displacement value to generate a memory address. For example, a memory address may be generated according to 2scale *index + base + displacement, index*scale+displacement, r / m + displacement, instruction pointer (RIP / EIP) + displacement, register + displacement, etc. The displacement may be a 1-byte, 2-byte, 4-byte, etc. value. In some embodiments, a displacement field 607 provides this value. Additionally, in some embodiments, a displacement factor usage is encoded in the MOD field of the addressing field 605 that indicates a compressed displacement scheme for which a displacement value is calculated by multiplying disp8 in conjunction with a scaling factor N that is determined based on the vector length, the value of a b bit, and the input element size of the instruction. The displacement value is stored in the displacement field 607.In some embodiments, an immediate field 609 specifies an immediate for the instruction. An immediate may be encoded as a 1-byte value, a 2-byte value, a 4-byte value, etc.FIG. 8 illustrates embodiments of a first prefix 601 (A) . In some embodiments, the first prefix 601 (A) is an embodiment of a REX prefix. Instructions that use this prefix may specify general purpose registers, 64-bit packed data registers (e.g., single instruction, multiple data (SIMD) registers or vector registers) , and / or control registers and debug registers (e.g., CR8-CR15 and DR8-DR15) .Instructions using the first prefix 601 (A) may specify up to three registers using 3-bit fields depending on the format: 1) using the reg field 744 and the R / M field 746 of the Mod R / M byte 702; 2) using the Mod R / M byte 702 with the SIB byte 704 including using the reg field 744 and the base field 756 and index field 754; or 3) using the register field of an opcode.In the first prefix 601 (A) , bit positions 7: 4 are set as 0100. Bit position 3 (W) can be used to determine the operand size, but may not solely determine operand width. As such, when W = 0, the operand size is determined by a code segment descriptor (CS. D) and when W = 1, the operand size is 64-bit.Note that the addition of another bit allows for 16 (24) registers to be addressed, whereas the MOD R / M reg field 744 and MOD R / M R / M field 746 alone can each only address 8 registers.In the first prefix 601 (A) , bit position 2 (R) may an extension of the MOD R / M reg field 744 and may be used to modify the ModR / M reg field 744 when that field encodes a general purpose register, a 64-bit packed data register (e.g., a SSE register) , or a control or debug register. R is ignored when Mod R / M byte 702 specifies other registers or defines an extended opcode.Bit position 1 (X) X bit may modify the SIB byte index field 754.Bit position B (B) B may modify the base in the Mod R / M R / M field 746 or the SIB byte base field 756; or it may modify the opcode register field used for accessing general purpose registers (e.g., general purpose registers 525) .FIGS. 9 (A) - (D) illustrate embodiments of how the R, X, and B fields of the first prefix 601 (A) are used. FIG. 9 (A) illustrates R and B from the first prefix 601 (A) being used to extend the reg field 744 and R / M field 746 of the MOD R / M byte 702 when the SIB byte 7 04 is not used for memory addressing. FIG. 9 (B) illustrates R and B from the first prefix 601 (A) being used to extend the reg field 744 and R / M field 746 of the MOD R / M byte 702 when the SIB byte 7 04 is not used (register-register addressing) . FIG. 9 (C) illustrates R, X, and B from the first prefix 601 (A) being used to extend the reg field 744 of the MOD R / M byte 702 and the index field 754 and base field 756 when the SIB byte 7 04 being used for memory addressing. FIG. 9 (D) illustrates B from the first prefix 601 (A) being used to extend the reg field744 of the MOD R / M byte 702 when a register is encoded in the opcode 603.FIGS. 10 (A) - (B) illustrate embodiments of a second prefix 601 (B) . In some embodiments, the second prefix 601 (B) is an embodiment of a VEX prefix. The second prefix 601 (B) encoding allows instructions to have more than two operands, and allows SIMD vector registers (e.g., vector / SIMD registers 510) to be longer than 64-bits (e.g., 128-bit and 256-bit) . The use of the second prefix 601 (B) provides for three-operand (or more) syntax. For example, previous two-operand instructions performed operations such as A = A + B, which overwrites a source operand. The use of the second prefix 601 (B) enables operands to perform nondestructive operations such as A = B + C.In some embodiments, the second prefix 601 (B) comes in two forms –a two-byte form and a three-byte form. The two-byte second prefix 601(B) is used mainly for 128-bit, scalar, and some 256-bit instructions; while the three-byte second prefix 601 (B) provides a compact replacement of the first prefix 601 (A) and 3-byte opcode instructions.FIG. 0 (A) illustrates embodiments of a two-byte form of the second prefix 601 (B) . In one example, a format field 1001 (byte 0 1003) contains the value C5H. In one example, byte 1 1005 includes a “R” value in bit [7] . This value is the complement of the same value of the first prefix 601 (A) . Bit [2] is used to dictate the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector) . Bits [1: 0] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H) . Bits [6: 3] shown as vvvv may be used to: 1) encode the first source register operand, specified in inverted (1s complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in 1s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as 1111b.Instructions that use this prefix may use the Mod R / M R / M field 746 to encode the instruction operand that references a memory address or encode either the destination register operand or a source register operand.Instructions that use this prefix may use the Mod R / M reg field 744 to encode either the destination register operand or a source register operand, be treated as an opcode extension and not used to encode any instruction operand.For instruction syntax that support four operands, vvvv, the Mod R / M R / M field 746 and the Mod R / M reg field 744 encode three of the four operands. Bits [7: 4] of the immediate 609 are then used to encode the third source register operand.FIG. 10 (B) illustrates embodiments of a three-byte form of the second prefix 601 (B) . in one example, a format field 1011 (byte 0 1013) contains the value C4H. Byte 1 1015 includes in bits [7: 5] “R, ” “X, ” and “B” which are the complements of the same values of the first prefix 601 (A) . Bits [4: 0] of byte 1 1015 (shown as mmmmm) include content to encode, as need, one or more implied leading opcode bytes. For example, 00001 implies a 0FH leading opcode, 00010 implies a 0F38H leading opcode, 00011 implies a leading 0F3AH opcode, etc.Bit [7] of byte 2 1017 is used similar to W of the first prefix 601 (A) including helping to determine promotable operand sizes. Bit [2] is used to dictate the length (L) of the vector (where a value of 0 is a scalar or 128-bit vector and a value of 1 is a 256-bit vector) . Bits [1: 0] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H) . Bits [6: 3] , shown as vvvv, may be used to: 1) encode the first source register operand, specified in inverted (1s complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in 1s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as 1111b.Instructions that use this prefix may use the Mod R / M R / M field 746 to encode the instruction operand that references a memory address or encode either the destination register operand or a source register operand.Instructions that use this prefix may use the Mod R / M reg field 744 to encode either the destination register operand or a source register operand, be treated as an opcode extension and not used to encode any instruction operand.For instruction syntax that support four operands, vvvv, the Mod R / M R / M field 746, and the Mod R / M reg field 744 encode three of the four operands. Bits [7: 4] of the immediate 609 are then used to encode the third source register operand.FIG. 11 illustrates embodiments of a third prefix 601 (C) . In some embodiments, the first prefix 601 (A) is an embodiment of an EVEX prefix. The third prefix 601 (C) is a four-byte prefix.The third prefix 601 (C) can encode 32 vector registers (e.g., 128-bit, 256-bit, and 512-bit registers) in 64-bit mode. In some embodiments, instructions that utilize a writemask / opmask (see discussion of registers in a previous figure, such as FIG. 5) or predication utilize this prefix. Opmask register allow for conditional processing or selection control. Opmask instructions, whose source / destination operands are opmask registers and treat the content of an opmask register as a single value, are encoded using the second prefix 601 (B) .The third prefix 601 (C) may encode functionality that is specific to instruction classes (e.g., a packed instruction with “load+op” semantic can support embedded broadcast functionality, a floating-point instruction with rounding semantic can support static rounding functionality, a floating-point instruction with non-rounding arithmetic semantic can support “suppress all exceptions” functionality, etc. ) .The first byte of the third prefix 601 (C) is a format field 1111 that has a value, in one example, of 62H. Subsequent bytes are referred to as payload bytes 1115-1119 and collectively form a 24-bit value of P [23: 0] providing specific capability in the form of one or more fields (detailed herein) .In some embodiments, P [1: 0] of payload byte 1119 are identical to the low two mmmmm bits. P [3: 2] are reserved in some embodiments. Bit P[4] (R’ ) allows access to the high 16 vector register set when combined with P [7] and the ModR / M reg field 744. P [6] can also provide access to a high 16 vector register when SIB-type addressing is not needed. P [7: 5] consist of an R, X, and B which are operand specifier modifier bits for vector register, general purpose register, memory addressing and allow access to the next set of 8 registers beyond the low 8 registers when combined with the ModR / M register field 744 and ModR / M R / M field 746. P [9: 8] provide opcode extensionality equivalent to some legacy prefixes (e.g., 00 = no prefix, 01 = 66H, 10 = F3H, and 11 = F2H) . P

[0010] in some embodiments is a fixed value of 1. P [14: 11] , shown as vvvv, may be used to: 1) encode the first source register operand, specified in inverted (1s complement) form and valid for instructions with 2 or more source operands; 2) encode the destination register operand, specified in 1s complement form for certain vector shifts; or 3) not encode any operand, the field is reserved and should contain a certain value, such as 1111b.P

[0015] is similar to W of the first prefix 601 (A) and second prefix 611 (B) and may serve as an opcode extension bit or operand size promotion.P[18: 16] specify the index of a register in the opmask (writemask) registers (e.g., writemask / predicate registers 515) . In one embodiment of the invention, the specific value aaa = 000 has a special behavior implying no opmask is used for the particular instruction (this may be implemented in a variety of ways including the use of a opmask hardwired to all ones or hardware that bypasses the masking hardware) . When merging, vector masks allow any set of elements in the destination to be protected from updates during the execution of any operation (specified by the base operation and the augmentation operation) ; in other one embodiment, preserving the old value of each element of the destination where the corresponding mask bit has a 0. In contrast, when zeroing vector masks allow any set of elements in the destination to be zeroed during the execution of any operation (specified by the base operation and the augmentation operation) ; in one embodiment, an element of the destination is set to 0 when the corresponding mask bit has a 0 value. A subset of this functionality is the ability to control the vector length of the operation being performed (that is, the span of elements being modified, from the first to the last one) ; however, it is not necessary that the elements that are modified be consecutive. Thus, the opmask field allows for partial vector operations, including loads, stores, arithmetic, logical, etc. While embodiments of the invention are described in which the opmask field’s content selects one of a number of opmask registers that contains the opmask to be used (and thus the opmask field’s content indirectly identifies that masking to be performed) , alternative embodiments instead or additional allow the mask write field’s content to directly specify the masking to be performed.P

[0019] can be combined with P [14: 11] to encode a second source vector register in a non-destructive source syntax which can access an upper 16 vector registers using P

[0019] . P

[0020] encodes multiple functionalities, which differs across different classes of instructions and can affect the meaning of the vector length / rounding control specifier field (P [22: 21] ) . P

[0023] indicates support for merging-writemasking (e.g., when set to 0) or support for zeroing and merging-writemasking (e.g., when set to 1) .Exemplary embodiments of encoding of registers in instructions using the third prefix 601 (C) are detailed in the following tables.Table 1: 32-Register Support in 64-bit ModeTable 2: Encoding Register Specifiers in 32-bit ModeTable 3: Opmask Register Specifier EncodingProgram code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices, in known fashion. For purposes of this application, a processing system includes any system that has a processor, such as, for example, a digital signal processor (DSP) , a microcontroller, an application specific integrated circuit (ASIC) , or a microprocessor.The program code may be implemented in a high-level procedural or object-oriented programming language to communicate with a processing system. The program code may also be implemented in assembly or machine language, if desired. In fact, the mechanisms described herein are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments of the invention may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements) , at least one input device, and at least one output device.One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.Such machine-readable storage media may include, without limitation, non-transitory, tangible arrangements of articles manufactured or formed by a machine or device, including storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs) , compact disk rewritable’s (CD-RWs) , and magneto-optical disks, semiconductor devices such as read-only memories (ROMs) , random access memories (RAMs) such as dynamic random access memories (DRAMs) , static random access memories (SRAMs) , erasable programmable read-only memories (EPROMs) , flash memories, electrically erasable programmable read-only memories (EEPROMs) , phase change memory (PCM) , magnetic or optical cards, or any other type of media suitable for storing electronic instructions.Accordingly, embodiments of the invention also include non-transitory, tangible machine-readable media containing instructions or containing design data, such as Hardware Description Language (HDL) , which defines structures, circuits, apparatuses, processors and / or system features described herein. Such embodiments may also be referred to as program products.Emulation (including binary translation, code morphing, etc. )In some cases, an instruction converter may be used to convert an instruction from a source instruction set to a target instruction set. For example, the instruction converter may translate (e.g., using static binary translation, dynamic binary translation including dynamic compilation) , morph, emulate, or otherwise convert an instruction to one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on processor, off processor, or part on and part off processor.FIG. 12 illustrates a block diagram contrasting the use of a software instruction converter to convert binary instructions in a source instruction set to binary instructions in a target instruction set according to certain implementations. In the illustrated embodiment, the instruction converter is a software instruction converter, although alternatively the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. FIG. 12 shows a program in a high level language 1202 may be compiled using a first ISA compiler 1204 to generate first ISA binary code 1206 that may be natively executed by a processor with at least one first instruction set core 1216. The processor with at least one first ISA instruction set core 1216 represents any processor that can perform substantially the same functions as anprocessor with at least one first ISA instruction set core by compatibly executing or otherwise processing (1) a substantial portion of the instruction set of the first ISA instruction set core or (2) object code versions of applications or other software targeted to run on an Intel processor with at least one first ISA instruction set core, in order to achieve substantially the same result as a processor with at least one first ISA instruction set core. The first ISA compiler 1204 represents a compiler that is operable to generate first ISA a binary code 1206 (e.g., object code) that can, with or without additional linkage processing, be executed on the processor with at least one first ISA instruction set core 1216.Similarly, FIG. 12 shows the program in the high level language 1202 may be compiled using an alternative instruction set compiler 1208 to generate alternative instruction set binary code 1210 that may be natively executed by a processor without a first ISA instruction set core 1214. The instruction converter 1212 is used to convert the first ISA binary code 1206 into code that may be natively executed by the processor without a first ISA instruction set core 1214. This converted code is not likely to be the same as the alternative instruction set binary code 1210 because an instruction converter capable of this is difficult to make; however, the converted code will accomplish the general operation and be made up of instructions from the alternative instruction set. Thus, the instruction converter 1212 represents software, firmware, hardware, or a combination thereof that, through emulation, simulation or any other process, allows a processor or other electronic device that does not have a first ISA instruction set processor or core to execute the first ISA binary code 1206.APPARATUS AND METHOD FOR A REUSED-DATA-CACHEEmbodiments of the invention include a microarchitectural feature, referred to herein as a reused-data-cache (RDC) , to identify and hold likely-to-be-reused data. Some implementations include a separate physical data caching structure with dedicated capacity while other implementations carve out capacity from the existing cache, reserving that capacity for certain types of data (e.g., “high priority” data, data associated with certain logical processors, data associated with certain type of workloads, etc) . One embodiment uses cache allocation technology (CAT) or similar techniques to partition the cache and allocate a specific portion of the cache as the reused-data-cache (e.g., using way or set partitioning) .Some embodiments of the reused-data-cache are used in combination with data-aware cache replacement policies. As such, examples of data-aware cache replacement policies will first be provided, followed by a description of implementations of a reused-data-cache.A. Data-aware Cache Replacement PoliciesWorkloads associated with online transaction processing (OLTP) and online analytical processing (OLAP) applications may demonstrate markedly different cache use behaviors. For example, OLTP applications (e.g., HammerDB, TPC-C, etc. ) are typically frontend-bound and initially load large amounts of data to a processor cache for OLTP workloads. However, OLAP applications (e.g., TPC-DS, TPC-H, etc. ) are typically backend-bound and initially load smaller amounts of data to a processor cache (e.g., the L2 / L3 cache) followed by larger amounts of data for executing an OLAP workload. As a result of these markedly different cache use behaviors, an OLAP workload’s processor cache miss pattern can be very different compared to an OLTP workload’s processor cache miss pattern.Note that the term “frontend bound” means that overall processing performance is being limited by components in the processor frontend, such as the instruction fetch unit, the instruction decoder, L1 instruction cache, and various other components towards the “front end” of the instruction processing pipeline. Similarly, “backend bound” means that processing performance is limited by components in the processor backend, such as the execution circuitry, memory access circuitry, retirement or writeback units, and other components towards the “back end” of the instruction processing pipeline.Increases in processor cache capacities that are typical for successive CPU generations has been shown to improve performance for OLTP workloads. In contrast, OLAP workloads realize little or no performance gain as a result of processor cache miss patterns for OLAP workloads that are backend-bound. Techniques are described below which allow certain types of applications and workloads, including but not limited to OLAP applications and workloads, to benefit when a processor cache capacity is increased. In particular, a novel data-aware cache replacement policy is described in which hints are used to identify likely-to-be-reused cached data. Once identified, the likely-to-be reused cache lines are associated with a higher priority, or other designation, causing the cache lines to be maintained in a processor cache for a longer duration. For example, the cache controller may factor in the higher priority designation when implementing its cache line replacement policy and choosing cache lines for eviction from the cache. Maintaining the likely-to-be-reused data in the cache for longer periods of time improve the performance gains of backend-bound workloads such as OLAP workloads when processor cache capacities are increased.FIigure. 13 illustrates an example backend-bound workload known as a hash join scheme 1300. In some examples, hash join scheme 1300 is a type of join operation commonly referred to as BroadcastHashjoin (BHJ) . Hash join scheme 1300 includes an application driver 1332 and a plurality of execution or work nodes 1340-1 to 1340-n which can be, for example, separate processing cores. According to some examples, the BHJ operation depicted by hash join scheme 1300 works by application driver 1332 broadcasting a small dataset included in table 1315 (small table) to all work nodes 1340-1 to 1340-n during broadcast phase 1301. For these examples, following broadcast phase 1301, a standard hash join is performed by each work node of work nodes 1340-1 to 1340n at hash join phase 1302. In hash join phase 1302, the small dataset included in table 1315 is hashed in all work nodes 1340-1 to 1340-n and separately joined with a respective partition of a big dataset included in table 1305 (large table) to generate a combined dataset to be included in table 1325. For example, table 1315 is hashed by work nodes 1340-1, 1340-2, 1340-3 and 1350-n and then separately joined with respective partitions 1305-1, 1305-2, 1305-3 and 1305-n of table 1305 to generate a combined dataset included in table 1325.Figure 14 illustrates another example hash join scheme 1400. In some examples, hash join scheme 1400 is a type of join operation commonly referred to as ShuffledHashJoin (SHJ) . Hash join scheme 1400 includes moving data included in tables 1405 and 1415 with a same value of join key in a same executor or work node from among work nodes 1440-1 to 1440-n, which can be, for example, separate processing cores. For an SHJ join operation such as hash join scheme 1400, at shuffle phase 1401, a join condition is used as an output key, partition data 1405-1 to 1405-n included in table 1405 and partitioned data 1415-1 to 1415-n included in table 1415 are shuffled amongst work nodes 1440-1 to 1440-n. Then, at hash join phase 1402, data is combined by each work node from among work nodes 1440-1 to 1440-n to generate a combined data set included in table 1425.The three most common join operation implementations include BHJ, SHJ and SortMergeJoin (SMJ) . As mentioned above for BHJ and SHJ operations depicted by respective hash join schemes 1300 and 1400, join operations combine data from two or more tables to obtain required information for analysis and reporting such as, but not limited to, OLAP application workloads. Join operations can be considered a fundamental operation in big data analytics software, which is designed to extract insight from a wide range of large data sources. Among the three most common join operation implementations of BHJ, SHJ and SMJ, SMJ requires that the join keys are sortable and SMJ’s performance is poor compared to BHJ’s or SHJ’s performance. As a result, SMJ is less popular or even unsupported in some popular distributed SQL query engines for big data. BHJ and SHJ are generally recognized as the most widely used and preferred join operation implementations for open-source software such as, but not limited to, Apache SparkTM, especially when associated with queries requiring low latency. Also, besides open-source software, a similar preference for BHJ or SHJ has been observed for cloud service providers (CSPs) such as ByteDance or Baidu for big data analytics.According to some examples, implementation of hash join schemes 1300 and 1400 for BHJ and SHJ are similar. This implementation can be performed by an application driver first creating a hash table based on a join_key or smaller relation (i.e., small table) and then looping the larger relation (i.e., large table) to match the hashed join-key values. For example, the smaller relation refers to table 1315 shown in Figure 13 for hash join scheme 1300 (BHJ) and refers to partitions 1415-1 to 1415-n from table 1415 shown in Figure 14 for the hash join scheme 1400 (SHJ) . Meanwhile, for this example, the larger relation refers to table 1305 shown in Figure 13 for hash join scheme 1300 (BHJ) and refers to table 1405 shown in Figure 14 for hash join scheme 1400 (SHJ) .Figure 15 illustrates an example code 1500 which is an example pseudo-code of a hash join implementation. For these examples, “emit_join_result” combines entries on multiple tables into one table as depicted in Figures 13-14 for hash join schemes 1300 and 1400. In general, “emit_join_result” is not limited to combine table entries together. In some examples, a join operation can carry some payload in a result which will be used in following operators. Thus, a table payload size can be one factor causing caching pollution in cache lines saved to a processor cache. For more complex scenarios, besides to compare join-keys values, some other condition checks can be required before an “emit_join_result” is generated using code 1500. Under such circumstances, not only the keys but also some other table payloads need to be fetched into the processor cache. These complex scenarios are not uncommon. For example, some ad-hoc queries handled by content provider platforms can often show a complicated syntax and behavior.According to some examples, if there is little to no interference or cache pollution when implementing a hash join operation such as implementing a BHJ operation for OLAP workloads, a benefit / improved performance can occur from use of large processor caches when executing the OLAP workload. For example, a hash table containing “Table_Small” (e.g., smaller relation) can see re-use in each iteration of code 1500, and a larger processor cache should hold more entries of the hash table. Theoretically, the enlarged processor cache should lead to better performance and a lower miss per instruction (MPI) . However, an OLAP workload’s often complex characteristics (e.g., streaming effect from large table scanning, pollution from table payload, noise from other concurrent operations, etc. ) oftentimes pollutes the processor cache. The polluted processor cache can result in cache lines included hash table entries being evicted too eagerly and requiring data for the hash table entries to be obtained from system memory rather than keeping this data in the processor cache. As a result, cache capacity benefits associated with increasing processor cache capacities are not realized for OLAP workloads.Figure 16 illustrates an example code sequence 1600 associated with software assistance and a hash join operation to indicate via a “HINT” or lack of a “HINT” as to whether data loaded to a cache line for a hash join operation includes likely-to-be-reused data. The HINT indicates a special LOAD which includes an indication of a priority or other designation to the likely-to-be-reused data so that the data will be maintained for a longer time in the cache before being replaced or evicted from the cache. If the HINT is not provided, the cache controller does not attach or indicate a priority to data in a cache line for that hash join operation. In some examples, the HINT is provided as a prefix to the special LOAD instruction such as prefix 601 illustrated in Figure 6. In some examples, the special LOAD may be a new instruction of an instruction set architecture (ISA) identified as MOVREUSE (move data w / reuse) . For these examples, the special LOAD MOVREUSE acts as the “HINT” to indicate that data loaded to a cache line is likely-to-be-reused data.Figure 17 illustrates an example comparison of cache replacement policy 1710 to cache replacement policy 1720. According to some examples, policy 1710 and policy 1720 are both based on a least recently used (LRU) cache replacement policy that includes use of an age bit “A” to indicate how long a cache line entry has been stored in a cache compared to other cache line entries and to keep track of the order of access. For simplicity, a 4-way associative cache is used for both policy 1710 and policy 1720 and similar block-request sequences of <0, 1, 2, 3, 4 (from special LOAD for BHJ) , 2, 3, 1, 5, 6>. For these examples, policy 1710 indicates implementation of a typical LRU policy for which a cache controller evicts or replaces a data entry for a cache line for which the age bit = 0. For example, for policy 1710, cache line 0’s entry of “0” is eventually aged to have an age bit = 0 by time of block-request in sequence of “4” (BHJ) and according to policy 1701 the cache line 0 entry of “0” is replaced with an entry of “4” .In some examples, policy 1720 shows an enhanced data-aware cache replacement policy that includes use of at least one additional bit to indicate priority information (although embodiments of the invention are not limited to a 1-bit priority indication) . For normal or regular loads of data / entries to a cache line (e.g., no special LOAD instruction or other hint of likely data reuse) , on a cache miss, the priority bit of P / A for that cache line is cleared (e.g., set to 0) . Then on a cache hit with a normal or regular load, the priority bit of P / A is left unchanged (e.g., stays 0 if already 0, and stays 1 if already 1) . Responsive to a special LOAD instruction (e.g., MOVREUSE) , a cache controller sets the priority bit of P / A (e.g., set to value of 1) for the cache line that is identified by the special LOAD instruction as including likely-to-be-reused data to be included in the entry to the cache line. The priority bit of P / A is set to 1 regardless of whether the entry to that cache line is a cache miss or cache hit.According to some examples, for policy 1720, 2 bits for P / A can be used by a cache controller to indicate a priority and to indicate an age of an entry maintained in a cache line. The data-ware cache replacement policy of policy 1720 includes the priority bit being set to 1 when a cache line entry is loaded with a special LOAD instruction (e.g., MOVREUSE) . A cache controller can be configured to only replace cache lines with both priority bit = 0 and age bit = 0. If a cache line entry with age bit = 1 and a priority bit = 1 is detected by the cache controller (even on a cache hit) , the cache controller can be configured to reduce the priority bit by 1. As a result, priority bit = 0 and the age bit is not changed and thus the entry in that cache line loses its priority, but is saved from being the next entry of a cache line to be evicted or replaced. Only changing the priority bit and not changing the age bit keeps data in an entry of a cache line with a higher priority in the cache longer. Keeping the entry of the cache line longer in the cache allows for more opportunities to reuse the entry, without pinning the prioritized data in the cache.The data-aware cache replacement policy 1720 is not limited to using LRU implementations. A pseudo-LRU implementation is also contemplated and frequency-based cache replacement implementations / algorithms are also contemplated. Also, as mentioned previously, the number of priority bits are not limited to 1. In other words, the number of priority bits can strike a balance based on software characteristics and hardware costs associated with supporting multiple priority bits. For example, multiple bits will consume more cache line capacity and add complexity. Also, examples are not limited to the 4-way associative cache described above for Figure 17.Additional examples are contemplated, for example, including having an entry for a cache line losing its priority but having its age bit reset to a value corresponding to the most-recently-used cache line (e.g., increase age bit value from 0 to 3) , to give the entry even longer life in the cache before being replaced or evicted.In some examples, a processor may include decoder circuitry to decode a special LOAD instruction (e.g. MOVREUSE) . The decoded special LOAD instruction to provide a temporal locality hint (e.g., to a cache controller) for a cache line to prevent eviction of data maintained in the cache line for at least one cache line eviction event due to a cache line miss. The cache line to be prevented from eviction for the at least one cache line eviction event without needing to pin the data to the cache line.According to some examples, the data-aware cache replacement policy 1720, by having a priority bit cleared as a cache line entry is about to become the next entry to be evicted, a cache is ensured to not be filled with cache line entries all having their priority bits set. However, if all but one of the cache line entries have a priority bit set when a cache miss occurs, the LRU cache line will be evicted, and then a conundrum results: a need exists to age the existing cache line entries, making one these cache line entries as the new LRU cache line (e.g., next evicted cache line entry) , but all cache lines have priority bit sets for their respective entries. In this example, the cache line entry with the “oldest” age bit will have its priority bit cleared and also will have its age bit set to 0 to address this conundrum.As shown in Figure 17, the grey-shaded columns for policy 1710 and for policy 1720 highlight how the two cache replacement policies are different following a special LOAD instruction (e.g., MOVREUSE) . In one example, a cache controller and / or the cache is not arranged or configured to use a priority bit to indicate data is likely to be reused following a special LOAD instruction, for example, a special LOAD instruction associated with a BHJ operation as shown at block-request in sequence 4 (BHJ) for policy 1710. For this one example, policy 1710 is implemented and as shown in Figure 17 only an age bit is set for entry 4 of cache line 0 when entry 4 is placed in cache line 0. Consequently, entry 4’s age bit is decremented following successive hits for other entries for block-request sequences 2, 3, 1 and then cache line 0’s entry 4 is evicted based on its age bit reaching zero and replaced with entry 5. In another example, a cache controller and / or the cache is arranged to use both a priority bit and an age bit to indicate data is likely to be reused following a special LOAD instruction (e.g., a MOVREUSE instruction associated with a BHJ operation) . For this example, policy 1720 is implemented where both a priority bit and an age bit is set for entry 4 of cache line 0 when entry 4 is placed in cache line 0. Consequently, entry 4’s age bit is decremented following successive hits for block-request sequences 2, 3, but rather than having the age bit incremented to 0 following block-request 4, only the priority bit is decremented for entry 4 and entry 4’s age bit is not decremented. Thus, at block-request 5, entry 4 is not yet evicted from cache line 0, but its age bit is decremented to 0. So as shown in Figure 17 for policy 1710, entry 4 was evicted following block-request 5, but for policy 1720, entry 4 was allowed to remain in cache line 0 for at least an additional block-request.Included herein is a logic flow representative of example methodologies for performing novel aspects of the disclosed techniques for a data-aware cache replacement. While, for purposes of simplicity of explanation, the one or more methodologies shown herein are shown and described as a series of acts, those skilled in the art will understand and appreciate that the methodologies are not limited by the order of acts. Some acts may, in accordance therewith, occur in a different order and / or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.A logic flow may be implemented in software, firmware, and / or hardware. In software and firmware examples, a logic flow can be implemented by computer executable instructions stored on at least one non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage. The examples are not limited in this context.Figure 18 illustrates an example flow 1800 which can be performed by software executed based on an OLAP codebase in coordination with an application driver and a cache controller of a processor cache to enable the cache controller to implement a data-aware cache replacement policy / algorithm. For example, an OLAP application in coordination with an application driver and cache controller to enable cache controller to implement policy 1720 as described above.In some examples, at 1810, a workload begins. For these examples, the workload may be associated with execution of an OLAP application.According to some examples, at 1820, CodeGen associated with the OLAP application executes a Hash Table for a join operation with or without a special LOAD instruction (e.g., MOVREUSE) . For these examples, code 1500 and code 1600 shown in Figures 15 and 16 may be at least portions of the CodeGen associated with the OLAP application to execute the Hash Table for a join operation (e.g., a BHJ operation) . For these examples, without a special LOAD instruction indicates a regular LOAD that does not include a “HINT” that indicates to a cache controller such as cache controller that the data is not likely to be reused. Also for these examples, with a special LOAD instruction indicates a special LOAD that includes a “HINT” that indicates to the cache controller that the data is likely to be reused.In some examples, at 1820, the application continues running on hardware as data associated with the join operation is loaded into cache. For these examples, data associated with the join operation can be pulled or obtained from memory responsive to requests from an application driver for the OLAP application. The obtained data may then be loaded to cache.In some examples, at 1825, a determination is made as to whether the data is associated with a regular LOAD. For these examples, if the Hash Table for the join operation was executed with a special LOAD instruction, then the LOAD is not a regular LOAD and flow 1800 moves to 1830. If the Hash Table for the join operation was executed without a special LOAD instruction, the LOAD is a regular LOAD and flow 1800 moves to 1835.According to some examples, at 1830, the cache controller updates or sets a priority bit of an entry to the cache line that will store data for the entry to the cache. For these examples, the cache controller sets a priority bit for the entry to the cache line to stored data for the entry to the cache to indicate that this data is likely to be reused. The priority bit, for example, is set according to policy 1720 as described above. Flow 1800 then continues from 1830 back to 1820.In some examples, at 1835, the cache controller does not update or set a priority bit for the entry to the cache line that will store data for the entry to the cache. For these examples, the cache controller does not set the priority bit because no indication was provided that the data was likely to be reused.According to some examples, at 1840, the cache controller determines that an entry maintained in a cache line needs to be evicted or replaced (e.g., due to a cache miss) . For these examples, cache controller 145 determines that all cache lines have entries / data and due to the cache miss data in at least one of the cache lines needs to be evicted or replaced.In some examples, the cache controller determines if the entry of the cache line has a priority bit set. For example, if cache controller determines that the cache line has an entry to store data in cache that does not have the priority bit set, then flow 1800 moves to 1850. If the cache controller determines that the cache line has an entry to store data in the cache that does have a priority bit set, then flow 1800 moves to 1855.According to some examples, at 1850, the cache controller applies an original replacement policy that relies just on an age bit to determine that the entry included in the cache line is to be evicted or replaced. For example, if the priority bit and the age bit are both set to 0 for this entry of the cache line, then cache controller evicts or replaces the data for the entry in the cache line with newly loaded data. Flow 1800 then continues back to 1820.In some examples, at 1855, the cache controller reduces the priority bit for the entry of the cache line by 1 (e.g., set to 0) , and an entry for another cache line is picked for eviction. For these examples, the cache controller sets the priority bit of the entry of the cache line to 0 and another entry of another cache line with the next LRU status is picked to have its data evicted or replaced. Flow 1800 then continues back to 1820. Flow 1800 can then continue as long as data continues to be loaded to the cache in association with execution of a workload for the OLAP application.B. Embodiments of a Reused-Data-CacheSome embodiments of the invention also include a microarchitectural feature, referred to herein as a reused-data-cache (RDC) which holds cachelines containing likely-to-be-reused data. Some implementations include a separate physical data caching structure with dedicated capacity while other implementations carve out capacity from an existing cache, reserving that capacity for data which is likely to be reused (e.g., “high priority” data, data associated with certain logical processors, data associated with certain workloads, etc) .One embodiment uses cache allocation technology (CAT) or similar techniques to partition the cache and reserve a specific portion of the cache as the reused-data-cache (e.g., using way or set partitioning) . For example, a specific number of cache ways (or sets) may be reserved and used for storing cache lines identified as containing likely to be reused data. The cache ways may be indicated using a bitmask associated with likely to be reused data in which each bit position is associated with a particular cache way and each bit value indicates whether the corresponding way is reserved for likely to be reused data (e.g., if set to 1) .In the various embodiments described below, any of the techniques described above may be used to identify likely-to-be-reused data. For example, these types of data may be loaded from memory into the RDC using a load instruction which identifies the corresponding cache lines as likely to be reused (e.g., MOVREUSE) , causing the cache lines to be stored in the RDC.In addition, when data is loaded into RDC, the initial state can be set directly to Share (S) rather than Exclusive (E) , thereby avoiding the state transition from “E” to “S” . These implementations of RDC not only maximize the cacheline re-use but also minimize the cache coherence enforcement cost.These embodiments maximize the performance benefit of existing large cache designs for artificial intelligence (AI)  / deep learning (DL) and analytics. With respect to AI / DL, embodiments of the invention address the need of minimizing cache misses for critical static data. In one ResNet50 example, the input / output tensor size for the first 10 Conv layers were 276 and 514 MB respectively, while the weight tensor size was less than 0.3MB. The embodiments described herein allow the cache controller to recognize the weight tensors and minimize the corresponding cache miss rate. Conversely, large-scale AI models (e.g., GPT-3) have large number of model parameters besides input / output tensors. Holding those constant parameters in an RDC implementation minimizes the parameter miss rate and reduces inference latency.As previously described, with respect to analytics, the design strategy of increasing cache capacity in each new generation is based on OLTP performance characteristics but is not necessarily beneficial for online analytical processing OLAP. The embodiments of the invention use the additional cache capacity for a special purpose cache or portion of an existing cache which hold likely-to-be-reused data. Using these techniques, analytics application performance can benefit from the “larger cache” design as well.In comparison to using data-aware cache replacement policies alone as described above with respect to Figure 18, the embodiments of the invention operate with new configurations of existing cache designs and enable modular designs, which is critical in terms of faster design cycle, lower validation cost, and scalability. Moreover, fixed (but possibly re-configurable) capacity of the RDC simplifies software optimization. For example, the smaller table size for JOIN operations (see, e.g., Figures 15-16 and associated text) can be fine-tuned based on RDC capacity. In AI / DL, the data and model parallelization determine the size of data partitions or sub-models, which can also be optimized based on RDC capacity.While the description below focuses on an RDC within the L2 cache level for the purpose of explanation, the underlying principles of the invention may be implemented at any cache level including L3 caches and L1 caches.Many processors have separate dedicated L1 caches for data and instructions, but a unified L2 cache per core. For example, the core architecture described with respect to Figure 3B includes a unified L2 cache 376 for caching instructions and data, an L1 instruction cache 334, and an L1 data cache 374. Figure 19 illustrates how one embodiment of a reused data cache 1977 is integrated within an L2 cache complex 1980 which includes a combination of an L2 cache 1976 and an L2 reused-data cache 1977, which may be a dedicated hardware structure for cache lines containing likely-to-be-reused data or which may be a reserved region of the L2 cache 376. In the latter case, the L2 cache 1976 comprises the unreserved region of the complete L2 cache 376.A selector 1985 chooses between the L2 cache 1976 and the L2 reused data cache 1980 based on whether the corresponding operation (e.g., a load or store) includes data which is likely to be reused. This characterization of the data may be made using the techniques described herein, including a special load instruction or a standard load instruction with a field to indicate that likely-to-be-reused data is being loaded.Figure 20 illustrates one implementation of the L2 cache 1976 and L2 reused data cache 1977 and a cache controller 2010 which performs lookups in parallel based on the address 2001 associated with the request. In this example, the address 2001 includes a k bit index value 2002 and an m-k bit tag value 2003 (e.g., with m=32 and k=10) . The index value 2002 is used to identify a particular cache line from one or both of the L2 cache 1976 and L2 reused data cache 1977. The tag value 2003 of the cache line (s) is compared with the m-k bit tag 2003. If there is a match for both the index value 2002 and the tag value 2003, and if the identified cache line is valid, as indicated by a valid bit, then the corresponding signal line, 2015 or 2016 will be set to a value of 1 (i.e., based on an AND of the valid bit and the result of the tag comparison) . The selector 1985 (which may also be a component of the cache controller then selects the corresponding cache line from either the L2 cache 1976 or the L2 reused data cache 1977 to send to the requestor over signal line 2011.Thus, when a core of the processor attempts to read from memory, the address will be sent to a cache controller 2010. On a cache look-up, the cache controller 2010 checks whether the data is missed or hit. One implementation performs the lookup in parallel, and the selector 1985 is set accordingly, depending on which L2 cache 1976-1977 is storing the cache line.Upon a cache miss, the cache controller 2010 may fill the cache line into either the regular L2 cache 1976 or the L2 reused-data-cache (RDC) 1977, depending on the load type. For the reused data load instructions described above, the cache controller 2010 fetches the data directly to the RDC 1977. Similarly, the lowest k bits of the address specify a cache block, the upper (m -k) address bits are stored in the block’s tag field, the data from main memory is stored in the cache block’s data field, and the valid bit is set to 1. It should be noted that, after the data has been loaded, the cache controller 2010 may implement the default cache coherence protocol.Since the data loaded into the RDC 1977 may be read and reused frequently, embodiments of the invention perform specific cache coherency optimizations. For example, when the data is initially loaded into the RDC 1977, the cache controller 2010 sets the initial state directly to “S” (share) rather than “E” (exclusive) . It therefore avoids the state transition from “E” (exclusive) to “S” . One particular implementation software to configure the cache coherency optimizations, although this is not required for complying with the underlying principles of the invention.Figure 21 illustrates one embodiment of a processor which includes a heterogeneous tile-based architecture (e.g., with multiple heterogeneous die integrated on a single processor package) . The processor includes a CPU tile 2115 with a heterogeneous set of cores including efficiency cores (E-cores) arranged into two E-core clusters 2110-2111 and a plurality of performance cores (P-cores) 2120-2121. Some embodiments of the SoC tile 2110 include a set of E-cores 2112-2113 and a memory controller 2115 to couple the processor to system memory 2150 (e.g., DDR DRAM memory, HBM memory, etc) . Similarly, a GPU tile 2105 includes a plurality of graphics cores 2107-2108 which may be managed in the same manner as the P-cores and E-cores as described herein.The CPU tile 2115 includes multiple L2 cache regions 2180-2183, each of which may be implemented with an L2 reused-data cache as described herein. L2 cache region 2183 is highlighted and includes a selector 2185 coupled to an L2 cache region 2176 and an L2 reused-data cache region 2177. As mentioned, the L2 reused-data cache region 2177 may be a reserved portion of the overall L2 cache 2183 or may be a separate dedicated region. The same or a similar reused-data cache architecture may be implemented in the L3 caches 2191-2192 or the L1 caches (not shown) .The E-cores in the E-core clusters 2110-2111 and the SoC tile 2110 are physically smaller (with multiple E-cores fitting into the physical die space of a P-core) , are designed to maximize CPU efficiency, measured as performance-per-watt, and are typically used for scalable, multi-threaded performance. The E-cores work in concert with P-cores 2120-2121 to accelerate tasks which tend to consume a large number of cores. The E-cores are optimized to run background tasks efficiently and, as such, smaller tasks are typically offloaded to E-cores (e.g., handling Discord or antivirus software) –leaving the P-cores 2120-2121 free to drive high performance tasks such as gaming or 3D rendering.The P-cores 2120-2121 are physically larger, high-performance cores which are tuned for high turbo frequencies and high IPC (instructions per cycle) and are particularly suited to processing heavy single-threaded work. In some embodiments, the P-cores are also capable of hyper-threading (i.e., concurrently running multiple software threads) .C. Additional Analysis and Embodiments of a Reused-Data-CacheTo facilitate the discussion, the reused-data cache is described below as a separate physical structure with some dedicated capacity. The analysis below highlights how the embodiments of the invention improve performance not only for large natural language processing (NLP) models but also image classification models, as well as big data analytics. Details are then provided in the context of hash-join from big data analytics.Minimizing the cache miss rate on important static data (such as weight) is critical to DL Recommendation, NLP and CV related models. In addition, large natural language models (GPT) and image recognition models (ResNet) are evaluated in detail.ResNet5O Model for Image Classification InferenceResNet stands for Residual Network, and ResNet-50 is a typical and popular convolution Residual Network which is widely used for Image Classification and is used as the backbone for other workloads (e.g. Mask-RCNN) .Figure 22A shows the Residual Block topology of ResNet-50.Popular frameworks (e.g. PyTorch, TensorFlow, etc. ) fuse the convolution and its consecutive elementwise operations to accelerate the model performance by default. Hence, the residual block of ResNet-50 could be transformed as Figure 22B. In comparison with input / output tensor footprint, the weight tensor footprint is insignificant. Figure 22C shows that the weight tensor footprint is less than 0.1%of total input / output tensor footprint.Using a concrete example of ResNet-50 with the shape of input tensor to the first layer as [64, 3, 224, 224] . The ResNet-50 contains 48 convolution layers, and the data size of the input tensor, weight, and output tensor per layer is calculated. Because BF16 is employed in this example, the model size (i.e. total weight tensor size) is about 1 / 2 of external publications which are based on FP32.Similar to the Large-scale Transformer, the streaming characteristic of input data streams makes it hard to re-use weights (model parameters) before they are kicked out of the cache. Unfortunately, the real-time requirement demands minimal cache miss.The performance benefit of loading ResNet-50 Weights into the RDC is projected at a potential 25%speed-up on latency, based on a study of BenchCNN vs. Framework on SPR6459C with 512GB DDR5 memory. The configuration for ResNet-50 included: Instance=1, Batch Size=32, OMP Threads#=32, Data set=dummy data, iomp5, jemalloc 5.2.1.The framework needs to run all 48 convolutions sequentially, and the total footprint is estimated as the following:Read tensor = sum (input tensor) + sum (weight) = 1.17GigabytesWrite tensor = sum (output tensor) = 1.2GigabytesTwo sets of experiments are described, i.e. BenchCNN vs. Framework. The Exp-1 BenchCNN (Figure 23A) runs one layer with 1000 iterations and the next layer with 1000 iterations. All weights are most likely in cache during convolution computation. The Exp-2 Framework (Figure 23B) runs all layers sequentially per iteration and then repeat for 1000 iterations, which is the real world scenario. From the topology perspective, the input of the Nth layer is the output of the (N-1) th layer. Therefore, similar to Exp-1, the input tensor of each layer is very likely in the cache immediately before the convolution calculation starts. In this way, the performance benefit can be estimated if all the weights have been loaded into the RDC.The above projection is primarily based on the tensor footprint size and cache capacity miss. Additional tests were designed and conducted on both SPR6459C and another SPR32c-emulator to validate if the cacheline conflict behavior between Exp-1 and Exp-2 has an insignificant contribution to our projection or not. Figure 24 shows that the cache way has a limited impact and it confirms that the capacity miss is the dominant for both BenchCNN and Framework. In particular, Figure 24 shows LLC cache miss behavior between BenchCNN and Framework. Total cache capacity is similar, but SPR6459C with default 15-way and SPR-32c-LLC9way is achieved by enabling 32 cores only on a 56-core SPR and configuring LLC with 9-way only.Large-Scale Transformer for InferenceMany real-world applications require blazingly fast inference time, varying from a few milliseconds to one second. Minimizing the model parameter cache miss becomes critical. Unfortunately, real-time inference handles continuous streams of data. The streaming characteristic of input data streams, together with complex data, model and pipeline parallelization, make it hard to re-use those model parameters before they are kicked out of the cache.In the meantime, an enormous number of model parameters in large NLP models has made it more challenging. For example, the engine underneath the highly popular chatGPT, i.e. GPT-3 language model, consists of 175 billion parameters. Moreover, the powerful Megatron-LM from Nvidia and Microsoft employs 1,000 billion parameters. The table in Figure 25 shows that the GPT models on GPU V100 has approximately 2B model parameters per GPU (or 0.4M per core) .To perform real-time inference, one would have to use a group of CPUs, such as, 47or example, a 44-core Intel Xeon CPU which is configured 3.5 times faster than the NVIDIA Tesla V100 GPUs in AI deep learning. The GPT model of 1008 billion parameters on 3072 GPU roughly needs [3072 / 3.5*44] = 38, 620 Xeon Skylake cores. In other words, there would be [0.2B *3.5 / 44] =16M model parameters for each Xeon core, which corresponds to roughly a 64 / 32 / 16MB parameter footprint per core if FP32, BF16, or INT8 is used for model parameters, respectively.Naturally, loading those read-only model parameters into the RDC can not only maximize their re-use but also minimize the cache coherence enforcement cost. Despite the larger memory footprint, having a dedicated cache for model parameters provides a better trade-off and adapts better to data / model / pipeline parallelization. For example, prefetching data is straightforward and likely more effective, as RDC holds only the same type of model parameters.Despite the challenge of having 16MB or larger cache per core with today’s technology, the rapid progress of process technology makes it possible in a foreseeable future. With today’s process technology, the RDC is applicable to GPT3 models with 200 billion parameters.Big Data AnalyticsOLAP workloads (e.g., TPC-DS) include significant amounts of streaming accesses, where they scan over a large amount of data. In addition, when emitting JOIN results, the output entries of the joined table occupy cache space. Moreover, high concurrency of different operators and streams makes cache sharing more complicated. As a result, the chance to reuse the data before it gets kicked out is relatively low in TPC-DS.TPC-DS consists of 99 queries. Almost all major queries (except q72) are insensitive to L2 capacity change. Figure 26 shows how the L2 misses per instruction (MPI) of the most time-consuming queries varies as L2 cache capacity varies. The focus is on q4 and q72 to explain why queries are insensitive or sensitive to L2 cache capacity.To understand why large cache capacity helps q72 performance, we need to look at what and how q72 executes. The execution of Q72 can be divided into three parts of jobs, an example of which is illustrated in Figure 27: (Part 1 2701) Prepare data sheets; (Part 2 2702) Join data sheets; (Part 3 2703) Perform select and aggregate operations.In particular, Figure 27 illustrates the DAG (Directed Acyclic Graph) of q72, which shows these three parts are executed almost sequentially. (Part 2 2702) is the most time-consuming part, including 8 sequential BHJ (BroadcastHashJoin) . The corresponding Physical Plan also confirms that BHJ operations execute sequentially and it has NO other operations (e.g. aggregate) in the middle of BHJ execution. In addition, the table payload is reasonably small. All combinations minimize the cache interference and pollution. As a result, 2.6x cache capacity (6→16way) increase leads to 13x reduction on MPI (14.6→1.1MPKI) and 30%reduction on execution time (64→48sec) .However, to have sequential BHJ operations (e.g., q72) is less common. More frequently, BHJ operations are in parallel and intermingle with other operations. Figure 28 shows a portion 2802 of a DAG of Q4, which has 6 pairs of BHJ which run in parallel during that duration. Despite the intensive BHJ operations highlighted in rectangles (e.g., 2801) , the high concurrency and complex task parallelism cause interference and cache pollution. As a result, the greatly-enlarged L2 cache capacity introduces little or limited benefit to Q4.The above analysis is further validated by a payload size sensitivity study, result of which are shown in Figure 29. The payload size is adjusted by adding additional column with variable size and by varying the batch size and shuffle partition setting for Apache Spark (row based) (graph 2901) and an in-house Native SQL engine (column based) (graph 2902) , respectively. Figure 29 shows that the performance benefit of L2 cache size reduces as the payload size increases. In other words, the embodiments of the invention can lead to similar performance benefits of cache size, regardless the payload size.As described with respect to Figure 13-14, JOIN is a fundamental operation in big data analytics software, which combines data from two or more tables to extract insight from a wide range of large data sources. The JOIN operations in Q72 are used as an example for the purpose of explanation.As shown in Figure 13, BroadcastHashJoin (BHJ) works by broadcasting the small dataset to all the executors (e.g., work nodes 1340, which may be cores) and once the data is broadcasted a standard hash join is performed in all the executors. In the Hash Join phase, small dataset is hashed in all the executors and joined with the partitioned big dataset.Referring to Figure 14, ShuffledHashJoin (SHJ) involves moving data with the same value of join key in the same executor node followed by Hash Join. Using the join condition as output key, data is shuffled amongst executor nodes 1440 (e.g., cores) and in the last step, data is combined using Hash Join.The implementation of Hash Join between BHJ and SHJ is similar, which is performed by first creating a Hash Table based on join_key of smaller relation (i.e., table) and then looping over the larger relation to match the hashed join_key values. The smaller relation refers to Table 1315 in Figure 13 and Partitions 1415-i from Table 1415 in Figure 14. The larger relation refers to Table 1305 and 1405 in Figures 13 and 14, respectively. Figure 15 shows a pseudo-code implementation.In general, “emit_join_result” is not limited to combining table entries together only. Oftentimes, the JOIN carries some payload in the result which will be used in the subsequent operators. Thus, the table payload size is one factor causing caching pollution. For more complex scenarios, besides the comparison of JOIN keys, some other condition checks may be required before emitting the JOIN result. Under such circumstances, not only the keys but also some other table payloads need to be fetched into the cache. Such complex scenarios are not uncommon in production.If there is no interference, this <broadcasthashjoin>implementation would benefit from larger caches. The hash table containing Table_Small (smaller relation) sees re-use in each iteration, and a larger cache should hold more entries of the hash table. Theoretically, the enlarged cache should lead to better performance and lower MPI (Miss per Instruction) . Unfortunately, OLAP workloads’ complex characteristics (e.g., streaming effect from large table scanning, pollution from the table payload, noise from other concurrent operations, etc) oftentimes pollutes the cache, evicting hash table entries too eagerly. As a result, the cache capacity benefit diminishes.Software AssistanceApache Spark is used as an example to elaborate on embodiments of the invention which include software assistance. The big data analytics engine Spark has evolved for more than a decade and become a popular OLAP solution. Figure 30 shows a typical example of how BHJ (BroadcastHashJoin) is executed step-by-step in Spark.In step 3001, the SCAN operator reads the small table into memory.In step 3002, the Spark driver collects the small table (smaller relation) from work nodes, and builds the hash table. It then then broadcasts the hash table to each worker.In step 3003, the new WholeStageCodegen operator on the worker reads in and filters the necessary records in the large table (larger relation) , then starts to probe in the hashtable to output the matching ones.A software change such as that described above with respect to Figure 16 may be used by embodiments of the invention. For example, at the assembly code level, a prefix hint is added to the LOAD instruction (e.g. “HINT mov rax, QWORD PTR [rbp-16] ” ) . The prefix is a nop on implementations not utilizing embodiments of the invention. It is worth pointing out that Deep-Learning compiler has a similar feature as code-gen.In addition to a new instruction prefix, other embodiments include a new instruction such as MOVREUSE, move data w / reuse. In addition, utilities and other software tools may include a set of load instructions that take an 8-bit immediate (e.g., movadvise rax, m64, imm8) comprising hints for how data will be used in the future, which can then be acted upon by the architecture. For example, a “high reuse” hint may be selected in some embodiments.Embodiments of the invention described above enable and maximize the performance benefit of the existing greatly-enlarged-cache design strategy to not only AI / DL but also analytics.With respect to AI and DL, embodiments of the invention address the need of minimizing the cache miss for critical static data. In one ResNet50 example (Figure 22C) , the input / output tensor size for the first 10 Conv layers are 276 and 514 MB respectively, while the weight tensor size is less than 0.3MB. Embodiments of the invention enable a cache controller to recognize the weight tensors and minimize the corresponding cache miss. Large-scale AI models (e.g. GPT-3) have a huge amount of model parameters, besides input / output tensors. Holding those constant parameters in RDC helps to minimize the parameter miss rate and reduce inference latency.With respect to analytics, the design strategy of increasing cache capacity (i.e. to allocate more transistors for the cache) is based on OLTP performance characteristics but is not OLAP-friendly. The embodiments of the invention use those additional transistors for a special purpose cache, which holds likely-to-be-reused data. Therefore, analytics application performance can benefit from the “larger cache” design as well.Overall, by enabling the same general purpose processor design to deliver better performance for a broader set of workloads (e.g., AI / DL, analytics, etc. ) , the embodiments of the invention provide improved TCO.EXAMPLESThe following are example implementations of different embodiments of the invention.Example 1. A processor, comprising: a plurality of processing cores; a first cache of a cache level shared by the plurality of processing cores, the first cache to store cache lines associated with data that is not identified as data likely to be reused; a second cache of the cache level coupled to the plurality of processing cores, the second cache to store cache lines associated with data that is identified as data likely to be reused; a cache controller configured to: receive a first address associated with a first load operation for first data; read the first data from a memory if the lookup results in a miss in the first cache and the second cache; store the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; and store the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.Example 2. The processor of example 1 wherein the cache controller is further configured to: perform a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; and read the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.Example 3. The processor of example 1 wherein the cache level comprises one of Level 2 (L2) or Level 3 (L3) wherein if the cache level comprises L2, then the first cache and the second cache are both L2 caches and if the cache level comprises L3, then the first cache and the second cache are both L3 caches.Example 4. The processor of examples 1 or 3 wherein the first cache comprises a first partition of a larger cache at the cache level and the second cache comprises a second partition of the larger cache at the cache level.Example 5. The processor of any of examples 1 to 4 wherein the cache controller is to implement a first cache coherency protocol to maintain coherency of cache lines of the first cache and is to implement a second cache coherency protocol to maintain coherency of cache lines of the second cache.Example 6. The processor of example 5 wherein the second cache coherency protocol comprises setting an initial state of each cache line to share (S) when it is first loaded into the second cache.Example 7. The processor of any of examples 1 to 6 wherein if the load operation comprises a first type of load operation, then the cache controller is to only perform a lookup in the first cache and wherein if the load operation comprises a second type of load operation, then the cache controller is to only perform a lookup in the second cache, wherein the second type of load operation comprises a load operation including an indication that the first data is likely to be reused.Example 8. The processor of any of examples 1 to 7 wherein the load operation for the first data comprises a load operation of one or more online analytical processing (OLAP) workloads and wherein the first data is specifically identified as data likely to be reused based on the one or more OLAP workloads executed by one or more processing cores of the plurality of processing cores.Example 9. The processor of any of examples 1 to 7 wherein the first data is identified as likely to be reused based on use of the first data in a hash join operation.Example 10. The apparatus of example 9, wherein the hash join operation is a BroadcastHashjoin (BHJ) operation or a ShuffledHashjoin(SHJ) operation.Example 11. A method comprising: receiving, at a cache controller, an address associated with a first load operation for first data; performing a lookup at a cache level shared by a plurality of processor cores, the cache level comprising a first cache storing cache lines associated with data that is not identified as data likely to be reused and a second cache storing cache lines associated with data that is identified as data likely to be reused; reading the first data from a memory if the lookup results in a miss in the first cache and the second cache; storing the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; and storing the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.Example 12. The method of example 11 further comprising: performing a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; and reading the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.Example 13. The method of example 12 wherein the cache level comprises one of Level 2 (L2) or Level 3 (L3) wherein if the cache level comprises L2, then the first cache and the second cache are both L2 caches and if the cache level comprises L3, then the first cache and the second cache are both L3 caches.Example 14. The method of examples 12 or 13 wherein the first cache comprises a first partition of a larger cache at the cache level and the second cache comprises a second partition of the larger cache at the cache level.Example 15. The method of any of examples 12 to 14 wherein the cache controller is to implement a first cache coherency protocol to maintain coherency of cache lines of the first cache and is to implement a second cache coherency protocol to maintain coherency of cache lines of the second cache.Example 16. The method of example 15 wherein the second cache coherency protocol comprises setting an initial state of each cache line to share (S) when it is first loaded into the second cache.Example 17. The method of any of examples 12 to 16 wherein if the load operation comprises a first type of load operation, then the cache controller is to only perform a lookup in the first cache and wherein if the load operation comprises a second type of load operation, then the cache controller is to only perform a lookup in the second cache, wherein the second type of load operation comprises a load operation including an indication that the first data is likely to be reused.Example 18. The method of any of examples 12 to 17 wherein the load operation for the first data comprises a load operation of one or more online analytical processing (OLAP) workloads and wherein the first data is specifically identified as data likely to be reused based on the one or more OLAP workloads executed by one or more processing cores of the plurality of processing cores.Example 19. The method of any of examples 12 to 18 wherein the first data is identified as likely to be reused based on use of the first data in a hash join operation.Example 20. The method of example 19, wherein the hash join operation is a BroadcastHashjoin (BHJ) operation or a ShuffledHashjoin (SHJ) operation.Example 21. At least one machine readable medium comprising a plurality of instructions that in response to being executed by a processor, causes the processor to: receiving, at a cache controller, an address associated with a first load operation for first data; performing a lookup at a cache level shared by a plurality of processor cores, the cache level comprising a first cache storing cache lines associated with data that is not identified as data likely to be reused and a second cache storing cache lines associated with data that is identified as data likely to be reused; reading the first data from a memory if the lookup results in a miss in the first cache and the second cache; storing the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; and storing the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.Example 22. The machine-readable medium of example 21 further comprising instructions to cause the processor to perform additional operations comprising: performing a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; and reading the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.Example 23. The machine-readable medium of example 21 wherein the cache level comprises one of Level 2 (L2) or Level 3 (L3) wherein if the cache level comprises L2, then the first cache and the second cache are both L2 caches and if the cache level comprises L3, then the first cache and the second cache are both L3 caches.Example 24. The machine-readable medium of examples 21 or 23 wherein the first cache comprises a first partition of a larger cache at the cache level and the second cache comprises a second partition of the larger cache at the cache level.Example 25. The machine-readable medium of any of examples 22 to 24 wherein the cache controller is to implement a first cache coherency protocol to maintain coherency of cache lines of the first cache and is to implement a second cache coherency protocol to maintain coherency of cache lines of the second cache.Example 26. The machine-readable medium of example 25 wherein the second cache coherency protocol comprises setting an initial state of each cache line to share (S) when it is first loaded into the second cache.Example 27. The machine-readable medium of any of examples 21 to 26 wherein if the load operation comprises a first type of load operation, then the cache controller is to only perform a lookup in the first cache and wherein if the load operation comprises a second type of load operation, then the cache controller is to only perform a lookup in the second cache, wherein the second type of load operation comprises a load operation including an indication that the first data is likely to be reused.Example 28. The machine-readable medium of any of examples 21 to 27 wherein the load operation for the first data comprises a load operation of one or more online analytical processing (OLAP) workloads and wherein the first data is specifically identified as data likely to be reused based on the one or more OLAP workloads executed by one or more processing cores of the plurality of processing cores.Example 29. The machine-readable medium of any of examples 21 to 28 wherein the first data is identified as likely to be reused based on use of the first data in a hash join operation.Example 30. The machine-readable medium of example 29, wherein the hash join operation is a BroadcastHashjoin (BHJ) operation or a ShuffledHashjoin (SHJ) operation.Embodiments of the invention may include various steps, which have been described above. The steps may be embodied in machine-executable instructions which may be used to cause a general-purpose or special-purpose processor to perform the steps. Alternatively, these steps may be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components.As described herein, instructions may refer to specific configurations of hardware such as application specific integrated circuits (ASICs) configured to perform certain operations or having a predetermined functionality or software instructions stored in memory embodied in a non-transitory computer readable medium. Thus, the techniques shown in the Figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., an end station, a network element, etc. ) . Such electronic devices store and communicate (internally and / or with other electronic devices over a network) code and data using computer machine-readable media, such as non-transitory computer machine-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and transitory computer machine-readable communication media (e.g., electrical, optical, acoustical or other form of propagated signals –such as carrier waves, infrared signals, digital signals, etc. ) . In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media) , user input / output devices (e.g., a keyboard, a touchscreen, and / or a display) , and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers) . The storage device and signals carrying the network traffic respectively represent one or more machine-readable storage media and machine-readable communication media. Thus, the storage device of a given electronic device typically stores code and / or data for execution on the set of one or more processors of that electronic device. Of course, one or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and / or hardware. Throughout this detailed description, for the purposes of explanation, numerous specific details were set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without some of these specific details. In certain instances, well known structures and functions were not described in elaborate detail in order to avoid obscuring the subject matter of the present invention. Accordingly, the scope and spirit of the invention should be judged in terms of the claims which follow.

Claims

1.A processor, comprising:a plurality of processing cores;a first cache of a cache level shared by the plurality of processing cores, the first cache to store cache lines associated with data that is not identified as data likely to be reused;a second cache of the cache level coupled to the plurality of processing cores, the second cache to store cache lines associated with data that is identified as data likely to be reused;a cache controller configured to:receive a first address associated with a first load operation for first data;read the first data from a memory if a lookup based on the first address results in a miss in the first cache and the second cache;store the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; andstore the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.2.The processor of claim 1 wherein the cache controller is further configured to:perform a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; andread the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.3.The processor of claim 1 wherein the cache level comprises one of Level 2 (L2) or Level 3 (L3) wherein if the cache level comprises L2, then the  first cache and the second cache are both L2 caches and if the cache level comprises L3, then the first cache and the second cache are both L3 caches.4.The processor of claim 1 wherein the first cache comprises a first partition of a larger cache at the cache level and the second cache comprises a second partition of the larger cache at the cache level.5.The processor of claim 4 wherein the cache controller is to implement a first cache coherency protocol to maintain coherency of cache lines of the first cache and is to implement a second cache coherency protocol to maintain coherency of cache lines of the second cache.6.The processor of claim 5 wherein the second cache coherency protocol comprises setting an initial state of each cache line to share (S) when it is first loaded into the second cache.7.The processor of claim 1 wherein if the load operation comprises a first type of load operation, then the cache controller is to only perform a lookup in the first cache and wherein if the load operation comprises a second type of load operation, then the cache controller is to only perform a lookup in the second cache, wherein the second type of load operation comprises a load operation including an indication that the first data is likely to be reused.8.The processor of claim 1 wherein the load operation for the first data comprises a load operation of one or more online analytical processing (OLAP) workloads and wherein the first data is specifically identified as data likely to be reused based on the one or more OLAP workloads executed by one or more processing cores of the plurality of processing cores.9.The processor of claim 1 wherein the first data is identified as likely to be reused based on use of the first data in a hash join operation.10.The processor of claim 9, wherein the hash join operation is a BroadcastHashjoin (BHJ) operation or a ShuffledHashjoin (SHJ) operation.11.A method comprising:receiving, at a cache controller, an address associated with a first load operation for first data;performing a lookup at a cache level shared by a plurality of processor cores, the cache level comprising a first cache storing cache lines associated with data that is not identified as data likely to be reused and a second cache storing cache lines associated with data that is identified as data likely to be reused;reading the first data from a memory if a lookup based on the first address results in a miss in the first cache and the second cache;storing the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; andstoring the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.12.The method of claim 11 further comprising:performing a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; andreading the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.13.The method of claim 12 wherein the cache level comprises one of Level 2 (L2) or Level 3 (L3) wherein if the cache level comprises L2, then the first cache and the second cache are both L2 caches and if the cache level comprises L3, then the first cache and the second cache are both L3 caches.14.The method of claim 12 wherein the first cache comprises a first partition of a larger cache at the cache level and the second cache comprises a second partition of the larger cache at the cache level.15.The method of claim 14 wherein the cache controller is to implement a first cache coherency protocol to maintain coherency of cache lines of the first cache and is to implement a second cache coherency protocol to maintain coherency of cache lines of the second cache.16.The method of claim 15 wherein the second cache coherency protocol comprises setting an initial state of each cache line to share (S) when it is first loaded into the second cache.17.The method of claim 16 wherein if the load operation comprises a first type of load operation, then the cache controller is to only perform a lookup in the first cache and wherein if the load operation comprises a second type of load operation, then the cache controller is to only perform a lookup in the second cache, wherein the second type of load operation comprises a load operation including an indication that the first data is likely to be reused.18.The method of claim 12 wherein the load operation for the first data comprises a load operation of one or more online analytical processing (OLAP) workloads and wherein the first data is specifically identified as data likely to be reused based on the one or more OLAP workloads executed by one or more processing cores of the plurality of processing cores.19.At least one machine readable medium comprising a plurality of instructions that in response to being executed by a processor, causes the processor to:receiving, at a cache controller, an address associated with a first load operation for first data;performing a lookup at a cache level shared by a plurality of processor cores, the cache level comprising a first cache storing cache lines associated with data that is not identified as data likely to be reused and a second cache storing cache lines associated with data that is identified as data likely to be reused;reading the first data from a memory if a lookup based on the first address results in a miss in the first cache and the second cache;storing the first data in one or more cache lines of the first cache if the first data is not identified as data likely to be reused; andstoring the first data in one or more cache lines of the second cache if the first data is identified as data likely to be reused.20.The machine-readable medium of claim 19 further comprising instructions to cause the processor to perform additional operations comprising:performing a concurrent lookup in both the first cache and the second cache using a second address associated with a second load operation for second data; andreading the second data from at least one cache line of the first cache or the second cache if the lookup results in a hit in the first cache or the second cache, respectively.

Images