KR20230116028A - Highly parallel processing architecture using double fork execution - Google Patents

Abstract

Techniques for task processing in a highly parallel processing architecture using dual fork execution are disclosed. A two-dimensional array of compute elements is accessed. Each compute element in the array is known to the compiler and is coupled to its neighboring compute elements in the array of compute elements. Control over the array of compute elements is provided on a cycle-by-cycle basis. Control is made possible by a stream of wide, variable-length control words generated by the compiler. Control includes branching. Both sides of a branch in the array are executed waiting for a branch decision to be acted on by the control logic. Branch decisions are based on the results of calculations in the array. The data generated by the fulfilled branch path is promoted. Results from the side of the branch not indicated by the branch decision are ignored or invalidated.

Description

Highly parallel processing architecture using double fork execution

related applications

This application claims priority to U.S. Provisional Patent Application Serial No. 63/125,994, filed on December 16, 2020, entitled "Highly Parallel Processing Architecture Using Dual Branch Execution."

The foregoing applications are incorporated in their entirety in any jurisdiction where permissible.

technology field

FIELD OF THE INVENTION This application relates generally to task processing, and more specifically to highly parallel processing architectures using dual fork execution.

Typically, organizations perform processing tasks that include accounting, payroll, inventory, and data analysis. Organizations can vary in size from "mom and pop" and other small or local organizations to large international corporations. These organizations include charities, financial institutions, governments, hospitals, manufacturers, research institutes, retail institutions, and universities. Regardless of the size and mission of the organization, the processing operations performed deal with data critical to its operation. Data collections or "datasets" are typically voluminous. These datasets may include bank or intermediary account information, trade and manufacturing process secrets, citizenship and tax records, medical records, academic records of grades and degrees, research data, and sales figures, among other data. Address, age, name, email address, phone number and other identifying information are also typically included. The sizes of datasets make them difficult to manage, and processing of datasets can be computationally complex. Data may also include, among other things, data entered into empty data fields or invalid fields; misspelled names; and inaccuracies such as inconsistently applied abbreviations or shorthand notations. Regardless of the dataset content, effective handling of data is important.

Organizations succeed or fail based on their ability to successfully manage data and execute data processing tasks. In addition, the processing of data must be carried out in a way that directly benefits the organization. Depending on the organization, the direct benefits of data processing are competitive and financial advantages, funding for successful grant applications, or a larger pool of student applicants. Organizations thrive when data processing objectives are successfully met. If organizational objectives are left unmet, undesirable and disastrous results can be expected. Hidden trends within the data must be identified and tracked, and data anomalies must be discovered and addressed. Identified trends and monetizable anomalies can provide organizations with a differentiating and competitive advantage.

The technologies used to collect, aggregate and correlate data from a wide and disparate range of individuals are diverse. Voluntary individuals from whom data is collected include citizens, customers, online shoppers, patients, purchasers, students, test subjects, and volunteers, among many others. However, in other cases, data is unknowingly collected from individuals. Commonly used techniques for data collection include “opt-in” mechanisms in which individuals actively consent to creating an account, registering, signing, or otherwise participating in data collection. Other technologies are legislative, such as governments requiring citizens to obtain a registration number and use that number for all interactions with government agencies, emergency services, law enforcement, and the like. Additional data collection techniques are more subtle or completely hidden, such as collecting network traffic, tracking purchases, website visits, button clicks and menu selections. The data collected is valuable to organizations, regardless of the technologies used to collect the data. Rapid processing of these large datasets is important. Rapid processing of these large datasets is a challenge.

Organizations perform a number of data processing tasks. Job processing consists of many complex tasks, whether it is to pay salaries, analyze research data, or train neural networks for machine learning. Tasks may include loading and saving datasets, accessing processing components and systems, and the like. Tasks themselves can be based on sub-tasks, where sub-tasks load or read data from storage, perform computations on data, store or write data back to storage, data and control It can be used to handle communication between subtasks, such as Accessed datasets are usually voluminous and can easily burden processing architectures that are not suited to processing tasks or are inflexible in their architecture. To significantly improve task processing efficiency and throughput, two-dimensional (2D) arrays of elements may be used for task and sub task processing. Arrays include 2D arrays of compute elements, multiplier elements, caches, queues, controllers, decompressors, arithmetic logic units (ALUs), and other components. These arrays are constructed and operated by providing control to the array on a cycle-by-cycle basis. Control of the 2D array is realized by providing control words generated by a compiler. Control includes a stream of control words, where the control words may include wide variable length microcode control words generated by a compiler. Control words are used to process tasks. Also, the arrays can be configured in a topology most suitable for processing a job. Topologies in which the arrays may be constructed include systolic, vector, cyclic, spatial, streaming, or VLIW (Very Long Instruction Word) topologies. Topologies may include topologies that enable machine learning functionality.

Job processing is based on a highly parallel processing architecture using double fork execution. A processor-implemented method for processing a task is disclosed, comprising: accessing a two-dimensional (2D) array of compute elements - each compute element in the array of compute elements is known to a compiler, and coupled to its neighboring compute elements in the array; providing control over the array of compute elements on a cycle-by-cycle basis, the control being enabled by a stream of wide variable length control words generated by a compiler, the control including branching; executing both sides of a branch in the array while waiting for a branch decision to be acted upon by the control logic, the branch decision being based on calculation results in the array; and based on the branch decision, promoting data generated by the fulfilled branch path.

Embodiments include using the promoted data in a downstream operation. Downstream operations may include arithmetic operations, vector operations, matrix operations, or tensor operations, Boolean operations, and the like. Downstream operations may include operations within a directed acyclic graph (DAG). Promoting data produced by a committed branch path may be based on scheduling, by the compiler, committed writes to occur outside of the branch pending window. Other embodiments include ignoring results from a side of a branch not indicated by branch determination. Ignoring data does not require processing cycles compared to flushing or clearing data associated with unfulfilled branches. Further embodiments include removing results from a side of a branch not indicated by branch determination. Eliminating results may be performed to remove race conditions to avoid data ambiguity or the like. The decision to promote branch path data that has been fulfilled and the decision to ignore branch path data that has not been fulfilled are based on the branch decision. Accordingly, data generated from either branch path cannot be considered valid until branch determination is performed.

Various features, aspects and advantages of various embodiments will become more apparent from the further description that follows.

The following detailed description of specific embodiments may be understood with reference to the following figures:
Figure 1 is a flow diagram for a highly parallel processing architecture using dual branch execution.
2 is a flow chart for promoted data usage.
3 shows a system block diagram for compiler interactions.
4A shows a system block diagram for a highly parallel architecture with shallow pipelines.
4B shows the compute element array details.
5 shows a standard code generation pipeline.
Figure 6 shows the transformation of directions into a directed acyclic graph (DAG) of operations.
7 is a flow chart for creating a SAT model.
8 is a table showing exemplary decompressed control word fields.
Figure 9 shows a branch implemented based on compiler guidance.
10 is a system diagram for job processing using a highly parallel architecture.

Techniques for data manipulation based on a highly parallel processing architecture using dual fork execution are disclosed. The operations to be processed may perform various operations including arithmetic operations, shift operations, logic operations including Boolean operations, vector or matrix operations, tensor operations, and the like. Tasks can contain multiple subtasks. Subtasks can be processed based on priority, priority, coding order, amount of parallelism, data flow, data availability, compute element availability, communication channel availability, and the like. Data manipulation is performed on a two-dimensional array of compute elements. Compute elements may include central processing units (CPUs), graphics processing units (GPUs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), cores, and other processing elements. Compute elements may include heterogeneous processors, processor cores within an integrated circuit or chip, and the like. Compute elements may be coupled to local storage, which may include local memory elements, register files, cache storage, and the like. A cache, which may include a hierarchical cache, may be used to store data such as intermediate results, relevant parts of a control word, and the like. The cache may store promoted data generated by a transitioned branch path, where the transitioned branch path is determined by branch determination. The decompressed control word is used to control one or more compute elements in the array of compute elements.

Multiple layers of a two-dimensional (2D) array of compute elements may be “stacked” to include a three-dimensional (3D) array of compute elements. Similar to compute elements in a 2D array of compute elements, each compute element in a 3D array of compute elements is known to the compiler and coupled to its neighboring compute elements in the array of compute elements. Stacking may include physically stacking individual chips together in an interconnected stack, or a “logical” 3D stack within a single physical chip, or a combination of both. Some embodiments include stacking a 2D array of compute elements with another 2D array of compute elements to form a three-dimensional stack of compute elements. Additional dimensions of the array stack are possible. Tasks, subtasks, etc. are created by the compiler. Compilers may include general-purpose compilers, hardware technology-based compilers, compilers written or “tuned” to an array of compute elements, constraint-based compilers, satisfaction-based compilers (SAT solvers), and the like. Control is provided to hardware in the form of control words, where control words are provided on a cycle-by-cycle basis. One or more control words are generated by the compiler. Control words may include wide variable length microcode control words. The length of the microcode control word can be adjusted by compressing the control word by recognizing that the compute element is not needed by the task so that the control bits in the control word are not required by the compute element or the like. Control words may be used to route data, set up operations to be performed by the compute elements, idle individual compute elements or rows and/or columns of compute elements, and the like. Compiled microcode control words associated with the compute elements are distributed to the compute elements. The compute elements are controlled by a control unit operating on the decompressed control words. Control words enable processing by the compute elements. Job processing is enabled by executing one or more control words. To accelerate the execution of tasks, the execution may include enabling concurrent execution of two or more potential compiled task results or sides. In a usage example, an operation may include a control word that includes a branch. Since the outcome of a branch may not be known a priori to the execution of the control word that contains the branch decision computation, all possible control sequences associated with the sides of the branch may be executed concurrently or using parallel resources available in the array to "pre- can be run". Thus, when a control word containing a branch decision computation is executed, the correct sequence of computations involving branch paths fulfilled can be used, and incorrect sequences of computations (e.g., paths not fulfilled by a branch) can be used. may be ignored and/or removed.

A highly parallel architecture using double fork execution enables task processing. A two-dimensional (2D) array of compute elements is accessed. Computing elements may include computing elements, processors, or cores within an integrated circuit; processors or cores in application specific integrated circuits (ASICs); It may include cores programmed into a programmable device such as a field programmable gate array (FPGA), and the like. Compute elements may include homogeneous or heterogeneous processors. Each compute element in the 2D array of compute elements is known to the compiler. A compiler, which may include a general-purpose compiler, a hardware-specific compiler, or a compiler specific to the compute elements, may compile the code for each of the compute elements. Each compute element is coupled to its neighboring compute elements in the array of compute elements. The coupling of the compute elements enables data communication between the compute elements. Control is provided to the hardware through one or more control words generated by the compiler. Control can be provided on a cycle-by-cycle basis. Cycles may include clock cycles, data cycles, processing cycles, physical cycles, architectural cycles, and the like. Control is enabled by a stream of wide variable length microcode control words generated by the compiler. The microcode control word length may vary based on the type of control, compression, simplification such as identifying that a compute element is not needed, and the like. Control words, which may include compressed control words, may be decoded and provided to a control unit that controls the array of compute elements. Control words can be decompressed to a level of fine control granularity, where each compute element (integer compute element, floating point compute element, address generation compute element, write buffer element, read buffer element, etc.). Each compressed control word is decompressed to allow element-by-element control. Decoding determines whether a given compute element is required to process a task or subtask; It may depend on whether the compute element has a particular control word associated with it or whether the compute element receives repeated control words (eg, a control word used for two or more compute elements), and the like. Based on the set of directions, the compiled work is executed on the array of compute elements. Execution may be accomplished by executing a plurality of sub-tasks associated with a compiled task.

Figure 1 is a flow diagram for a highly parallel processing architecture using dual branch execution. Clusters of compute elements (CEs), such as CEs assembled into a 2D array of CEs, may be configured to handle various tasks and subtasks associated with the tasks. The 2D array may further include other elements such as controllers, storage elements, ALUs, and the like. Jobs can achieve various processing purposes, such as application processing, data manipulation, and the like. Operations include integer, real and character data types; vectors and matrices; tensors; It can operate on a variety of data types, including Control over the array of compute elements is provided on a cycle-by-cycle basis, where the control is based on control words generated by a compiler. Control words, which may include microcode control words, enable or idle various compute elements; provide data; routing results between CEs, caches, and storage; and the like. Controls enable compute element operations, memory access privileges, and the like. Compute element operation and memory access dominance allows hardware to properly rank compute element results. The control enables execution of the compiled job on the array of compute elements. Also, both sides of the branch are executed in the array waiting for a branch decision to be acted upon by the control logic. When a branch decision is made, data produced by the branch patch that has been fulfilled is promoted, while data produced by the side of the branch not marked by the branch decision is ignored.

Flow 100 includes accessing a two-dimensional (2D) array 110 of compute elements, where each compute element in the array of compute elements is known to a compiler and its neighbor in the array of compute elements coupled to the compute elements. A compute element may be based on various types of processors. Compute elements, or CEs, can be programmed into central processing units (CPUs), graphics processing units (GPUs), processors or processing cores in application specific integrated circuits (ASICs), and field programmable gate arrays (FPGAs). processing cores and the like. In embodiments, the compute elements in the array of compute elements have the same functionality. Computing elements may include heterogeneous computing resources, where the heterogeneous computing resources may or may not be collocated within a single integrated circuit or chip. A compute element may be configured in a topology, and the topology may be built into an array, programmed into, or configured into an array. In embodiments, the array of compute elements is configured by a control word to implement one or more of a constrictor, vector, circulator, spatial, streaming, multiple instruction multiple data (MIMD), or very long instruction word (VLIW) topology. .

The compute element may further include a topology suitable for machine learning computation. Compute elements may be coupled to other elements in the array of CEs. In embodiments, a combination of compute elements may enable one or more topologies. Other elements to which CEs can be combined include cache storage of one or more levels; multiplier units; address generator units for generating load (LD) and store (ST) addresses; storage elements such as cues and the like. Compilers for which each compute element is known may include C, C++, or Python compilers. A compiler where each compute element is known may include a compiler written specifically for an array of compute elements. Coupling each CE to its neighboring CEs may include sharing of elements such as cache elements, multiplier elements, ALU elements, or control elements; Enables communication between neighboring CEs and the like.

Flow 100 includes providing control 120 to the array of compute elements on a cycle-by-cycle basis. Control over the array includes compute elements within the array that load and store data; routing data to, from, and between compute elements, and the like. In flow 100, control is enabled 122 by a stream of wide variable length control words. Control words may constitute computing elements and other elements within an array; can enable or disable individual computing elements, rows and/or columns of computing elements, load and store data: route data to, from, and between computing elements can, etc. One or more control words are generated by a compiler (124). A compiler that generates the control words may be a general-purpose compiler such as a C, C++, or Python compiler; hardware description language compilers such as VHDL or Verilog compilers; may include a compiler written for an array of compute elements, and the like. Compilers can be used to map functions to arrays of compute elements. In embodiments, a compiler may map a machine learning function to an array of compute elements. Machine learning can be based on machine learning (ML) networks, deep learning (DL) networks and support vector machines (SVMs), and the like. In embodiments, the machine learning function may include a neural network (NN) implementation. Control words generated by the compiler may be used to configure one or more CEs, allow data to flow to and from the CEs, configure the CEs to perform operations, and the like. Depending on the type and size of the task being compiled to control the array of compute elements, one or more of the CEs may be controlled, but other CEs are not required by the particular task. Unnecessary CEs may be marked as unnecessary in the control word. Unnecessary CEs do not require data, nor are control words required by them. In embodiments, unnecessary compute elements may be controlled by a single bit. In another embodiment, a single bit can control an entire row of CEs by instructing hardware to generate an idle signal for each CE in the row. A single bit can be set to “unnecessary” to indicate when a particular CE is not required by a task, reset to “required,” or a similar use of the bit.

Control words generated by the compiler may contain conditionals. In embodiments, the control includes a branch. Code, which may include code associated with applications such as image processing, audio processing, and the like, may contain conditions that may cause execution of one sequence of code to pass to a different sequence of code. Conditions can be based on evaluating expressions such as boolean or arithmetic expressions. In embodiments, a condition may determine code jumps. Code jumps may include conditional jumps as just described or unconditional jumps such as a jump to abort, terminate, or terminate an instruction. Conditionality can be determined within an array of elements. In embodiments, conditionality is established by a branch decision operation performed on the array pointed to by the control word. The control words may be decompressed by a decompressor logic block, which decompresses the words from the compressed control word cache en route to the array. In embodiments, the set of directions may include a spatial allocation of subtasks on one or more compute elements in the array of compute elements. In other embodiments, the set of directions may enable multiple programming loop instances to cycle within the array of compute elements. Multiple programming loop instances may include multiple instances of the same programming loop, multiple programming loops, etc.

Flow 100 further includes storing relevant portions of control words from the stream of control words in a cache 130 associated with the array of compute elements. Control words stored in the cache may include compressed control words, decompressed control words, and the like. As discussed below, an access queue may be associated with a cache, where access queues may be used to queue requests to access caches, storage, and the like. Data caches can be separate from control word caches, and data caches can be used to store data and load data. Data caches may include multilevel caches such as level 1 (L1) caches, level 2 (L2) caches, and the like. The L1 cache may be used to store blocks of data to be processed. The L1 cache may include small, fast memory that is quickly accessible by compute elements and other components. An L2 cache may contain larger and slower storage compared to an L1 cache. The L2 cache may store results such as "next up" data, intermediate results, and the like. In embodiments, the L1 and L2 caches may also be coupled to a level 3 (L3) cache. L3 caches may be larger than the L2 and L1 caches and may include slower storage. Accessing data from L3 caches is still faster than accessing main storage. In embodiments, the L1, L2 and L3 caches may include 4-way set associative caches. In embodiments, the cache may include a double read, single write (2R1W) data cache. As the name implies, the 2R1W data cache can support up to two read operations and one write operation simultaneously without causing read/write conflicts, race conditions, data corruption, etc. In embodiments, the 2R1W cache may support simultaneous fetching of potential branch paths to the compiler. Recall that a branch condition can control more than one branch path, i.e., a branch path that has been fulfilled and other branch paths that have not fulfilled are determined by the branch decision.

Flow 100 includes loading data 140 into a compute element memory in an array. Data may be integer, real (eg, floating point), or character data; vector, matrix, or array data; tensor data; etc. may be included. Data may be associated with a type of processing application, such as image data for image processing, audio data for audio processing, and the like. Loading data may be accomplished by loading data from a register file, cache, storage internal to the array, external storage coupled to the array, or the like. As discussed below, the data may include data generated by the sides of a branch, where a branch path may be executed in an array. In embodiments, loading of data may occur before a branch decision is made. Because data can be loaded before a branch decision is made, some of the data can be promoted for use by downstream operations, while other data can be ignored. Flow 100 includes using row ring buses 150 to provide branch address offsets to an array of compute elements. Branch offsets may include unequal offsets, and unequal offsets are used for different possible branch paths. Branch offsets can simplify the addressing of data in storage by reducing the size of addresses used for access to storage. In an example of use, an offset address indicating a first storage location for the associated data may be provided. The first data may be located at the offset address, the second data may be located at the offset address + 1, and the third data may be located at the offset address + 2.

Flow 100 includes executing both sides 160 of a branch in the array. As previously discussed, control words provided to an array of compute elements may include a conditionality, where a conditionality causes a branch in control. Control words can cause elements in the array to perform calculations that determine conditions, which conditions are then passed to control logic to change the flow of program control. Since the direction, side or branching path taken is not known before the control unit performs branch determination, both sides of the branch can be executed respectively. Decision data for a branch decision may be provided by a compute element in the array, provided the branch is not an unconditional flow control change, i.e., an unconditional branch. Since any element in the array can provide branch decision data, the control word selects which compute element is the source of decision data to be used by the control logic. In embodiments, the branch decision may come from a neighboring compute element block, such as a block of four neighboring compute elements, which may reduce the branch decision signal fanning into the compute element.

For example, execution of one sequence of control words will result from implementing one branching path, while execution of another sequence of control words will result from implementing another branching path. Since the exact path is not known a priori, execution occurs on both paths. Flow 100 includes waiting for branch decision 170 to be passed to control logic. The wait for branch decision may be based on the number of cycles, architecture cycles, and the like. The wait may be based on the number of control words provided prior to the control word associated with the branch. In flow 100, a branch decision is based on the calculation result 172 in the array. Calculation results may be based on arithmetic or Boolean operations, matrix or tensor operations, and the like. Flow 100 further includes executing an additional branch 180 concurrently with both sides of the branch. Further branching may be based on calculations, evaluations, and the like. In embodiments, the additional branch and both sides of the branch may include multidirectional branch evaluation. In an example of use, a variable (A) may be compared to a second variable (B). The first path may be executed if A < B; The second path may be executed if A + B; A third path may be implemented if A>B; etc. Multidirectional branch evaluation can include control words such as switch operations. In other embodiments, the additional branch and the two sides of the branch may include two independent branch decisions. In use cases, additional branches may be used to handle errors, exceptions, defaults, exits, etc.

Flow 100 includes promoting 190 data generated by a branch path that has been fulfilled based on the branch decision. Once a branch decision is made, the correct branch path can be implemented and associated data promoted. Promoting data generated by the fulfilled path may include writing the data to register files, caches, storage within the array, storage outside the array, and the like. It is important to note that promotion data can only occur after a branch decision. Attempting to promote data prior to a branch decision may result in incomplete or erroneous data. The promoted data may be used as input to one or more other compute elements. In embodiments, promoted data may be used for downstream operations. A variety of techniques can be used to communicate branch conditions. In an embodiment, branch decisions may be communicated using execution bits of an array arithmetic logic unit (ALU). Branch decisions may be communicated using flags or some other indicator. In other embodiments, implementation may remove the branch prediction logic. Branch prediction attempts to predict which side of a branch will be fulfilled based on code analysis, historical data associated with executing instructions, and the like. The need for branch prediction is eliminated by executing the various sides of the branch before the branch decision is known to the control unit, and then selecting the correct branch path based on the branch decision. Flow 100 includes ignoring operations from the side of the branch not indicated by branch determination 192 . Ignoring operations may include simply leaving results associated with the side of an unfulfilled branch in a register file, cache, store, or the like. If ignoring unneeded results could lead to race conditions or potential data collisions, other techniques for handling unneeded data may be applied. Other embodiments also include removing results from the side of a branch not indicated by branch determination. Removal may include overwriting data, deleting data, and the like. Further embodiments may include ignoring data that was loaded into an in-array compute element memory based on the branch decision. Compute element memory in the array may be made available for storage of other data. In general, "side effects" of data from branches that are not migrated are that they do not overwrite data in the array later required by a branch path that is migrated, or data from a migrated path where they are committed from the array to the memory system. Can be ignored unless stored.

In some embodiments, certain operations are performed in the array for two or more sides of a branch instruction. The consequences of an unfulfilled branching path or paths may be ignored, and any side effects of the unfulfilled branching path(s) may be removed. However, minimizing the number of operations performed speculatively may minimize side effects to be canceled or ignored and reduce power consumption in the array. To achieve this, a compiler may implement speculative encoding 194, where a control word may be speculatively encoded such that the encoding may span one or more "basic blocks" implemented in an array, which branch may include temporal spanning of operations. A basic block can be a contiguous group of instructions that occur between branches in the code. Because an array of compute elements can provide a large resource facility, a compression control word (CCW) can speculatively encode multiple parallel operations, which can include multiple branching paths.

When a branch decision is made, say through an arithmetic operation comparing two values, the branch control logic can quickly learn the branch decision results. Branch control logic can then suppress actual calculations for operations on the array that do not need to be completed. That is, the hardware can convert any control words for operations that do not need to complete (suppressed operations) into idle commands for the affected compute elements. Indeed, if a particular compute element has not yet started processing an operation, the motion control start may be withheld from that computer element, ie it is never driven into the array.

To support this approach, the compiler will schedule and reserve into an array all the resources needed to support any potential computation path affected by the branch. Thus, rather than speculatively executing a path with potential early termination where instruction execution terminates somewhere in the execution pipeline, the disclosed invention can implement speculative encoding of control words with early suppression, where in a given cycle Motion control for a particular compute element or elements for a system is not driven by the array.

The various steps in flow 100 may be changed in order, repeated, omitted, etc. without departing from the concepts disclosed. Various embodiments of flow 100 may be included in a computer program product embodied in a computer readable medium containing code executable by one or more processors.

2 is a flow diagram for using promoted data. As discussed throughout, tasks, subtasks, etc. may be processed on an array of compute elements. Operations can be general operations such as arithmetic, vector, array, or matrix operations; Boolean operations such as NAND, NOR, XOR, or NOT; may include operations based applications such as neural networks or deep learning operations, and the like. To ensure that tasks are processed accurately, control words are provided cycle by cycle to the array of compute elements. Control words configure the array to execute the task. Control words may be provided to the array of compute elements by a compiler. Providing control words to control placement, scheduling, data transfer, etc. within the array can maximize job throughput. This maximization ensures that tasks that generate data required by the second task are processed before processing the second task, and the like. In embodiments, tasks may include branching operations. The branching operation may be condition-based, and the condition may be established by the control unit. A branch can include multiple "directions", "paths", or "sides" that can be implemented based on conditions. Conditionals can include evaluating expressions such as arithmetic or boolean expressions, passing from a sequence of instructions to a second sequence of instructions, and the like. In embodiments, a condition may determine code jumps. Since the branching path to be executed is not known a priori to evaluate the condition, each path can be executed. When preconditions are determined, data associated with fulfilled routes may be promoted, while data associated with non-fulfilled routes may be ignored. Promoted data use enables a highly parallel processing architecture that uses double fork execution. A two-dimensional (2D) array of compute elements is accessed, where each compute element in the array of compute elements is known to the compiler and coupled to its neighboring compute elements in the array of compute elements. Control over the array of compute elements is provided on a cycle-by-cycle basis, where control is enabled by a stream of wide, variable-length control words generated by a compiler, where control includes branches. Both sides of the branch are executed in the array while waiting for a branch decision to be actuated by the control logic, the branch decision being based on the result of the calculation in the array. Data generated by fulfilled branch paths is promoted based on branch decisions.

Flow 200 includes using promoted data 210 for downstream operations. Promoting the data may include storing the data in a cache, shared storage, memory element in an array, or the like. Promoting can include forwarding the data to other computing elements in the array of computing elements. Additional embodiments may include using the promoted data for downstream operations. Downstream operations may include arithmetic or boolean operations, matrix operations, neural network operations, and the like. Flow 200 further includes ignoring results 212 from the side of the branch not indicated by the branch determination. Any results, such as data generated by control words associated with the side of a branch not shown, are unnecessary for further processing of the task, subtask, or the like. Rather than having to consume clock cycles, there are architectural cycles and the like. Associated with an array of compute elements to flush, overwrite, or delete unneeded data, no cycles are consumed in ignoring data. Also, no control word is required to override data. Registers, caches, or other storage associated with unneeded data may be made available for further processing. Further embodiments may include removing results from the side of the branch not indicated by branch determination. Unnecessary data may be removed from storage, registers, caches, etc., in cases where leaving data associated with the side of the indicated branch could cause a race condition, data ambiguity, or some other possible processing conflict.

Flow 200 includes using promoted data for committed writes 220 . A write committed may involve writing data to storage that, if it occurs before the data is confirmed by a branch decision, may cause the storage to become corrupted or invalid for any further operation. Committed records may include indications of data ready, data valid, data complete, and the like. Since which of the sides of a branch will be implemented is not known a priori, writing data prior to a decision on which side of the branch direction will be implemented may present a race condition, provide invalid data, etc. . In another embodiment, branch decisions cannot be overridden or reversed, thus reinforcing the need to prevent writes committed before the point at which committed records are invalidated or reversed. Discussed throughout, a committed record may store data in one or more registers, register files, caches, stores, etc. that are not local to the computing element that created the data. In an embodiment, a committed record may include a committed record to a data store. The data store may be located within an array of elements coupled to the array accessible by the array through a network, such as a computer network or the like. In embodiments, the data store is external to the 2D array of compute elements. Flow 200 further includes scheduling, by the compiler, write committed 230 to occur outside of the branch undecided window. The branch pending window may include a number of cycles, architectural cycles, etc., required to execute control words prior to branch decision. The branch pending window may be closed when a branch decision is determined, the control unit is notified, data associated with the migrated side of the branch is promoted, and data associated with the migrated side is ignored. In embodiments, scheduling committed writes can avoid disrupting the operation of the array. Scheduling can be based on cycles, architecture cycles, and the like. Scheduling may include the number of cycles associated with the branch pending window, the number of cycles to promote data, and the like.

Figure 3 shows a system block diagram for compiler interaction. As discussed throughout, the compute elements within an array are known to computers capable of compiling tasks and subtasks for execution on the array. Compiled tasks and subtasks are executed to achieve task processing. A variety of interactions may be associated with the compiler, such as placement of tasks, routing of data, and the like. Interactions use double fork execution to enable highly parallel processing architectures. A two-dimensional (2D) array of compute elements is accessed. Each compute element in the array of compute elements is known to the compiler and is coupled to its neighboring compute elements in the array of compute elements. Control over the array of compute elements is provided on a cycle-by-cycle basis. Control is enabled by a stream of wide variable length control words generated by the compiler, and control includes branches. Both sides of the branch are executed in the array while waiting for a branch decision to be acted on by the control logic. Branch decisions are based on the results of calculations in the array. Data generated by fulfilled branch paths is promoted based on branch decisions.

System block diagram 300 includes compiler 310 . Compilers may include high-level compilers such as C, C++, Python or similar compilers. Compilers may include compilers implemented for hardware description languages such as VHDL™ or Verilog™ compilers. Compilers may include compilers for portable, language-independent, intermediate representations such as low-level virtual machine (LLVM) intermediate representations (IR). A compiler can generate a set of directions that can be provided to computing elements and other elements in the array. A compiler may be used to compile task 320 . Tasks may include a plurality of tasks associated with a processing task. Tasks may further include a plurality of sub-tasks. Tasks may be application based, such as video processing or audio processing applications. In embodiments, tasks may be associated with a machine learning function. A compiler may generate directions for handling compute element results 330 . Compute element results include arithmetic, vector, array, and matrix operations; may include results derived from Boolean operations and the like. In embodiments, compute element results are generated in parallel on an array of compute elements. Parallel results can be produced by compute elements if they can share input data, use independent data, and the like. A compiler may generate a set of directions that control data movement 332 relative to the array of compute elements. Control of data movement may include movement of data to, from, and between compute elements within an array of compute elements. Control of data movement may include loading and storing data, such as temporary data storage during data movement. In another embodiment, data movement may include intra-array data movement.

Like a general-purpose compiler used to create tasks and subtasks for execution on one or more processors, a compiler can provide directions for task and subtask handling, input data handling, intermediate and result data handling, and the like. A compiler may also generate directions for constructing the compute elements, storage elements, control units, ALUs, etc. associated with the array. As previously discussed, the compiler generates directions for data handling to support task handling. In the system block diagram, data movement may include load and store 340 with a memory array. Loading and storing may involve handling various data types such as integer, real or float, double precision, character, and other data types. Load and store may load and store data to local storage such as registers, register files, caches, and the like. The cache may include one or more levels of cache, such as a level 1 (L1) cache, a level 2 (L2) cache, and a level 3 (L3) cache. Loads and stores may also be associated with storage such as shared memory, distributed memory, and the like. In addition to loads and stores, the compiler may handle other memory and store management operations including memory access privileges. In the system block diagram, memory access predominance may enable ordering of memory data 342 . Memory data may be ordered based on working data requirements, sub-working data requirements, and the like. Memory data ordering can enable parallel execution of tasks and subtasks.

In system block diagram 300 , ordering of memory data may enable compute element result ordering 344 . For task processing to be successfully achieved, tasks and subtasks must be executed in an order that can accommodate task priorities, task precedence, and scheduling of operations. Memory data may be ordered such that data requested by tasks and subtasks is available for processing when the tasks and subtasks are scheduled to run. Thus, the results of data processing by jobs and subtasks can be ordered to optimize job execution, reduce or eliminate memory contention conflicts, and the like. The system block diagram includes enabling concurrent execution 346 of two or more potentially compiled work results based on a set of directions. Code compiled by a compiler may include branching points, and branching points may include calculations or flow control. Flow control directs instruction execution to a sequence of different instructions. For example, since the outcome of a branch decision is not known a priori, sequences of instructions associated with two or more potential operation outcomes may be fetched, and each sequence of instructions may begin execution. When the correct outcome of a branch is determined, the sequence of instructions associated with the correct branch outcome continues execution, while unfulfilled branches can be aborted, flushed, ignored, etc. In embodiments, two or more potential compiled results may be executed on spatially separated computing elements within an array of computing elements.

The system block diagram includes a compute element idle 348. In embodiments, a set of directions from a compiler may idle an unneeded compute element in a row of compute elements located in the array of compute elements. Depending on the tasks being processed, subtasks, etc., not all compute elements may be required for processing. The computing elements may simply not be needed because there are fewer tasks to execute than the computing elements available in the array. In embodiments, idle may be controlled by a single bit in a control word generated by the compiler. In the system block diagram, the compute elements in the array may be configured for various compute element functions 350. Compute element functions may enable various types of computational architectures, processing configurations, and the like. In embodiments, a set of directions may enable a machine learning function. Machine learning functions can be trained to process various types of data, such as image data, audio data, medical data, and the like. In embodiments, the machine learning function may include a neural network implementation. The neural network may include a convolutional neural network, a recurrent neural network, a deep learning network, and the like. The system block diagram may include compute element placement within an array of compute elements, result routing, and computed wavefront propagation 352 . A compiler can generate directions or instructions that can place tasks and subtasks on the computing elements in the array. Placement may include placing tasks and subtasks based on data dependencies between or between tasks or subtasks, placing tasks to avoid memory conflicts or communication conflicts, and the like. Directions may also enable computed wavefront propagation. Computational wavefront propagation can describe and control how the execution of tasks and subtasks proceeds through an array of compute elements.

In the system block diagram, the compiler may control the architecture cycle 360. An architectural cycle may include an abstract cycle associated with elements within an array of elements. Elements of the array may include compute elements, storage elements, control elements, ALUs, and the like. Architectural cycles may include “abstract” cycles, where abstract cycles may refer to various architecture level operations such as load cycles, execute cycles, write cycles, and the like. Architectural cycles can refer to macro operations of an architecture rather than low-level operations. One or more architectural cycles are controlled by the compiler. Execution of an architecture cycle may depend on more than one condition. In embodiments, an architectural cycle may occur when a control word may be pipelined to an array of compute elements and when all data dependencies are satisfied. That is, the array of compute elements does not have to wait for dependent data to load or an entire memory queue to clear. In the system block diagram, an architectural cycle may include one or more physical cycles 362. A physical cycle may refer to one or more cycles at the element level required to implement a load, run, write, etc. In embodiments, a set of directions may control an array of compute elements on a physical cycle basis. A physical cycle may be based on a clock, such as a local, module, or system clock, or some other timing or synchronization technique. In embodiments, the physical cycle unit basis may include an architectural cycle. A physical cycle may be based on an enable signal for each element of an array of elements, whereas an architectural cycle may be based on a global architectural signal. In embodiments, the compiler may provide valid bits for each column of the array of compute elements through the control word on a cycle-by-cycle basis. A valid bit may indicate that data is valid and ready to be processed, an address such as a jump address is valid, and the like. In embodiments, valid bits may indicate that a valid memory load access is occurring from the array. A valid memory load access from an array can be used to access data in a memory or storage element. In other embodiments, the compiler may provide operand size information for each column of the array of compute elements via a control word. Operand size is used to determine how many load operations may be required to obtain the data. Various operand sizes may be used. In embodiments, operand sizes may include bytes, half words, words, and double words.

4A shows a system block diagram for a highly parallel architecture with shallow pipelines. A highly parallel architecture may include components including compute elements, processing elements, buffers, one or more levels of cache storage, system management, arithmetic logic units, multipliers, and the like. Various components may be used to achieve task processing, where task processing is associated with program execution, task processing, and the like. Job processing is enabled using a parallel processing architecture with distributed register files. A two-dimensional (2D) array of compute elements is accessed, where each compute element in the array of compute elements is known to the compiler and coupled to its neighboring compute elements in the array of compute elements. Directions are provided to the array of compute elements based on control words generated by the compiler. Control words, which may include microcode control words, enable or idle various compute elements; provide data; routing results between CEs, caches, and storage; and the like. Directions enable compute element operation and memory access dominance. Compute element operation and memory access dominance allows hardware to properly rank compute element results. Directions enable execution of compiled work on an array of compute elements.

A system block diagram 400 is shown for a highly parallel architecture with shallow pipelines. The system block diagram may include an array of compute elements 410 . The computing element array 410 may be based on computing elements, where the computing elements may include processors, central processing units (CPUs), graphics processing units (GPUs), coprocessors, and the like. . Computing elements may be based on processing cores built into chips such as application specific integrated circuits (ASICs), processing cores programmed into programmable chips such as field programmable gate arrays (FPGAs), and the like. Compute elements may include a uniform array of compute elements. System block diagram 400 may include translation and index buffers, such as translation and index buffers 412 and 438. Translation and index buffers are part of the memory addressing system. A memory cache can be used to reduce store access time. The system block diagram may include logic for load and access ordering and selection. Logic for load and access ordering and selection may include logic 414 and logic 440 . Logic 414 and 440 may achieve load and access ordering and selection for lower data blocks 416, 418 and 420 and upper data blocks 442, 444 and 446, respectively. Such layout techniques can double access bandwidth, reduce interconnection complexity, and the like. Logic 440 may be coupled to compute element array 410 via the queues and multiplier units 447 component. In the same manner, logic 414 may be coupled to compute element array 410 via the queues and multiplier units 417 component.

A system block diagram may include access queues. Access queues may include access queues 416 and 442 . Access queues can be used to queue requests to access caches, repositories, etc. to store data and load data. The system block diagram may include level 1 (L1) data caches, such as L1 caches 418 and 444. L1 caches may be used to store blocks of data, such as data to be processed together, data to be processed sequentially, and the like. The L1 cache may include small, fast memory that is quickly accessible by compute elements and other components. The system block diagram may include level 2 (L2) data caches. L2 caches may include L2 caches 420 and 446 . An L2 cache may contain larger and slower storage compared to an L1 cache. The L2 cache may store results such as "next up" data, intermediate results, and the like. The L1 and L2 caches may be further coupled to a level 3 (L3) cache. The L3 cache may include L3 caches 422 and 448. The L3 cache may be larger than the L1 and L2 caches and may include slower stores. Accessing data from L3 caches is still faster than accessing main storage. In embodiments, the L1, L2 and L3 caches may include 4-way set associative caches.

Block diagram 400 may include a system management buffer 424 . The system management buffer may be used to store system management code or control words that may be used to control the array 410 of compute elements. System management buffers may be employed to hold opcodes, codes, routines, functions, and the like. It can be used for handling exceptions or errors, managing a parallel architecture for processing tasks, and so on. A system management buffer may be coupled to decompressor 426 . The decompressor may be used to decompress the system management compressed control words (CCW) from the system management compression control word buffer 428 and store the decompressed system management control words in the system management buffer 424 . A compressed system management control word may require less storage than an uncompressed control word. The system management CCW component 428 also includes a spill buffer. The spill buffer can include a large static random access memory (SRAM) that can be used to support multiple nested levels of exceptions.

Compute elements in the array of compute elements may be controlled by a control unit such as control unit 430 . Although the compiler controls the individual elements via control words, the control unit may pause the array to ensure that no new control words are driven into the array. The control unit receives the decompressed control word from a decompressor (432). The decompressor enables or idles rows or columns of compute elements, enables or idles individual compute elements, compresses control words (described below) to transfer control words to individual compute elements, etc. can be unlocked The decompressor may store compression control words such as compression control word cache 1 (CCWC1) 434. CCWC1 may include a cache such as an L1 cache containing one or more compressed control words. CCWC1 may store additional compression control words such as compression control word cache 2 (CCWC2) 436 . CCWC2 can be used as an L2 cache for compressed control words. CCWC2 can be larger and slower than CCWC1. In embodiments, CCWC1 and CCWC2 may include a 4-way set association. In embodiments, the CCWC1 cache may contain decompressed control words, in which case it may be designated as DCWC1. In that case, decompressor 432 may be coupled between CCWC1 434 (currently DCWC1) and CCWC2 436.

4B shows a compute element array detail 402 . An array of compute elements may be coupled to components that enable the compute elements to process one or more tasks, subtasks, and the like. Components may access and provide data, perform certain high-speed operations, and the like. The compute element array and its associated components enable parallel processing architectures with a background load. Compute element array 450 may perform a variety of processing tasks, where processing tasks include arithmetic, vector, matrix, or tensor operations; audio and video processing operations; neural network operation; It may include operations such as Compute elements may be coupled to multiplier units, such as lower multiplier units 452 and upper multiplier unit 454 . Multiplier units may be used to perform fast multiplications associated with general processing tasks, multiplications associated with neural networks such as deep learning networks, multiplications associated with vector operations, and the like. Compute elements may be coupled to load queues such as load queues 464 and load queue 466 . The load queue may be connected to the L1 data cache as described above. Load queues may be used to load storage access requests from compute elements. The load queues can track expected load latencies and notify the control unit if the load latency exceeds a threshold. The control unit's notification can be used to signal that a load may not arrive within an expected timeframe. Load queues can also be used to pause an array of compute elements. Load queues can send a pause request to the control unit that will pause the entire array, while individual elements can idle under the control of a control word. When an element is not explicitly controlled, it can be placed in an idle (or low power) state. No action is taken, but the ring buses can continue to operate in a “pass through” mode to allow the rest of the array to operate properly. When a compute element is used to route unchanged data through its ALU, it is still considered active.

Background loading of the array from memories (data and control words) may be performed while the array of compute elements is paused. The memory systems can run freely and continue to operate while the array is suspended. Because multi-cycle latencies can occur due to control signal transfers incurring additional "dead time", the memory system "rushes" into the array and loads data while the array is paused to the appropriate scratchpad memories. It may be beneficial to have it forwarded to This mechanism can work so that the array state is known as far as the compiler is concerned. When array operation resumes after a pause, new load data will arrive in the scratchpad, as required by the compiler to maintain a statically scheduled model.

5 shows a standard code generation pipeline. The control provided to the hardware on a cycle-by-cycle basis may include code for task processing. The code can be written in a high-level language such as C, C++, Python, etc.; low-level languages such as assembly language; and so forth. A code generation pipeline can be used to transform intermediate code or intermediate representations, such as low-level virtual machine (LLVM) intermediate representations (IRs), into target machine code. Target machine code may include machine code executable by one or more compute elements in the array of compute elements. The code generation pipeline uses double fork execution to enable highly parallel processing architectures. An exemplary code generation pipeline 500 is shown. The code generation pipeline may perform one or more operations 510 to convert code, such as LLVM IR code, to output code 514 . The pipeline may receive input code 512 . The received input may include a list in the LLVM IR representation 520. Intermediate forms may include single static assignment (SSA) forms, where each variable associated with code is allocated only once. The pipeline may include a DAG lowering component 522 . The DAG degradation component may reduce the order of the DAG and may output an uncertified or unconfirmed DAG 524 . A non-public DAG may be authorized or verified using the DAG Authorization Component 526. The DAG Authorization component may output the Authorization DAG 528 . The authorized DAG may be provided to the instruction selection component 530. The command selection component may include generated commands 532 . The generated instructions may be directly specified in the control word microcode for one or more computing elements of the array of computing elements. Native instructions, which may represent processing tasks and subtasks, may be scheduled using scheduling component 534 . A scheduling component may be used to create a list, which includes code in the form of a static single assignment (SSA) 536 of an intermediate representation (IR). The SSA form may include a single assignment of each variable, where the assignment occurs before the variable is referenced or used in code. The optimizer component 538 may optimize the code in SSA form. The optimizer may generate the optimized code in the form of SSA (540).

Optimized code of the form SSA can be processed using the register allocation component 542. The register allocation component may generate a list of physical registers 544, where the physical registers may include registers or other storage within an array of compute elements. The code generation pipeline may include a post allocation component 546 . The post-allocation component can be used to resolve register allocation conflicts, optimize register allocation, and the like. The post-allocation component may include a list of physical registers 548. The pipeline may include prolog and epilog components 550 . Prolog and Epilog components can add code associated with the prologue and code associated with the epilogue. The prolog may contain code that may prepare registers, etc. for use. The epilog may include code for reversing operations performed by the prolog when the code between the prolog and the epilogue is executed. The prolog and epilog components may create a list of stack reservations 552 that have been resolved. The pipeline may include a peephole optimization component 554 . The peephole optimization component can be used to optimize small sequences of code, or “peepholes,” to improve the performance of small sequences of code. The output of the peephole optimizer component may include an optimized list of decomposed stack reservations 556. The pipeline may include assembly printing component 558 . The assembly printing component may generate assembly language text of assembly code 560 . The output of the standard code generation pipeline may include output code 514 for inclusion in the stream of wide variable length control words.

Figure 6 shows the transformation of directions into a directed acyclic graph (DAG) of operations. The processing of tasks and subtasks on an array of compute elements can be modeled using a directed acyclic graph. A DAG represents dependencies between tasks and subtasks. Dependencies may include task and subtask priorities, priorities, and the like. Dependencies can also indicate the flow of data and execution order to, from, and between tasks and subtasks. Converting instructions to a DAG enables highly parallel processing architectures using double fork execution. A two-dimensional (2D) array of compute elements is accessed. Each compute element in the array is known to the compiler and is coupled to its neighboring compute elements. Control over the array of compute elements is provided on a cycle-by-cycle basis. Both sides of the branch are executed in the array while waiting for a branch decision to be acted on by the control logic. Branch decisions are based on the results of calculations in the array. Data generated by fulfilled branch paths is promoted based on branch decisions.

A set of directions, which may include code, instructions, microcode, etc., may be translated into DAG operations 600. The instructions may include low-level virtual machine (LLVM) instructions. A given code, such as the code describing the directions discussed previously and throughout, can create a DAG. A DAG may contain information about the placement of jobs and subtasks, but does not necessarily contain information about the scheduling of jobs and subtasks and the routing of data to, from, and between jobs. The graph contains entries 610 or inputs, and entries can represent input ports, registers, addresses in storage, and the like. The inlet may be coupled to the output or outlet 612 . A DAG's exit point can be reached by completing the DAG's tasks and subtasks. In case of exceptions, such as errors, missing data, storage access conflicts, etc., the DAG may abort or exit with errors. The inlet and outlet of the DAG may be coupled by one or more arcs 620, where each arc may include one or more processing steps. Processing steps may be associated with tasks, subtasks, and the like. An exemplary sequence of processing steps based on directions is shown. The sequence of processing steps may include various instructions 622 and 624. Instructions may involve double precision (eg, 64-bit) values. The sequence may include other instructions, such as instructions 626 and 628. The sequence may include further instructions 630 . The sequence may include additional instructions 632. The sequence may include further additional instructions 634 . When the last instruction in the sequence of instructions is complete, flow within the DAG proceeds to the exit of graph 612 .

7 is a flow chart for creating a SAT model. Task processing, which includes processing tasks, subtasks, etc., includes performing one or more actions associated with tasks. Operations are arithmetic operations; boolean operations; vector, array, or matrix operations; It may also include tensor operations and the like. To ensure that tasks, subtasks, etc. are processed correctly, controls such as control words, directions, etc. provided to hardware such as compute elements in a 2D array determine when operations are performed and to and from operations. You need to indicate how you want to route the data. A satisfaction or SAT model can be created to order tasks, actions, etc., and to provide data to and from compute elements. Creating a satisfactory model enables highly parallel processing architectures using double fork execution. Each operation associated with a task, subtask, etc. may be assigned a clock cycle, where a clock cycle may relate to a clock cycle associated with the start of a block of instructions. One or more move (MV) operations may be inserted between the output of the operation and the input to one or more add operations.

Flow 700 includes calculating a minimum cycle 710 for an operation. The minimum cycle may include the fastest cycle in which an operation can be performed. A cycle may be a local, module, subsystem, or system clock; May include physical cycles such as architecture clocks and the like. The minimum cycle can be determined by traversing the directed acyclic graph (DAG) in topological order. Traversal can be used to compute the distance between the output and input of a DAG. Data may flow from, to, or between computing elements without colliding with other data. In embodiments, a set of directions may control an array of compute elements on a physical cycle basis. Physical cycles can enable operations, transfer data, and so forth. In an embodiment, it may be enabled by a stream of wide, variable-length microcode control words generated by the compiler on a cycle-by-cycle basis. Microcode control words may enable elements such as compute elements, arithmetic logic units (ALUs), memory or other storage, and the like. In other embodiments, the physical cycle unit basis may include an architectural cycle. A physical cycle may differ from an architectural cycle in that a physical cycle may coordinate a given operation or set of operations for one or more compute elements or other elements. An architecture cycle may include a cycle of an architecture, where an architecture may include compute elements, ALUs, memories, and the like. An architectural cycle may include one or more physical cycles. Flow 700 includes calculating maximum cycles 712 . The maximum cycle may include the most recent cycle in which an operation may be performed. If the minimum cycle equals the maximum cycle for a given operation, then the operation continues on the DAG's critical path.

Flow 700 includes adding move action candidates 720 along different paths from output to input. Move operation candidates may include possible arrangements of operations or “candidates” for computing elements and other elements in the array. Candidates may be based on directions generated by the compiler. In embodiments, the set of directions may include a spatial allocation of subtasks on one or more compute elements in the array of compute elements. Spatial allocation can ensure that operations do not interfere with each other with respect to resource allocation, data transmission, and the like. A subset of the action candidates can be selected such that the resulting program, i.e. the code generated by the compiler, is correct. The correct code achieves the processing of tasks successfully. Flow 700 includes assigning a Boolean variable to each candidate 730 . If the boolean variable is true, the candidate is included. If the boolean variable is false, the candidate is not included. By imposing logical constraints between or between Boolean variables, precise programming can be achieved. Logic constraints are such that all inputs can be satisfied, one or more ALUs have unique configuration, candidates cannot move different values to the same register, and candidates cannot set control word bits to conflicting values. may include performing

Flow 700 includes resolving conflicts 740 between candidates. Conflicts may occur between candidates, where conflicts may include violations of one or more of the constraints listed above, resource contention, data conflicts, and the like. A simple collision between candidates can be formulated using conjunctive normal form (CNF) clauses. Constraints based on CNF clauses can be evaluated using a solver such as an operations research (OR) solver. Flow 700 includes selecting a subset 750 of candidates. As discussed above, a subset of candidates may be selected such that the ordering of the resulting "program", i.e., operations, subtasks, tasks, etc., is accurate. In the context of a program, “correctness” refers to the ability of a program to meet specifications. A program is correct if it produces the expected output for each input. A program can be compiled by a compiler to create a set of directions for an array. Not all elements of the array are required to implement a set of directions. In embodiments, the set of directions may idle an unneeded compute element in a row of compute elements located in the array of compute elements.

8 is a table showing exemplary decompressed control word fields. Overall, control may be provided to the array of compute elements on a cycle-by-cycle basis. Control of the array is enabled by a stream of microcode control words, which can be generated by a compiler. Microcode control words comprising multiple fields can be stored in a compressed format to reduce storage requirements. The compressed control word may be decompressed to enable control of one or more compute elements in the array of compute elements. The fields of the decompressed control word enable highly parallel processing architectures using double branch execution. A two-dimensional (2D) array of compute elements is accessed, where each compute element in the array of compute elements is known to the compiler and coupled to its neighboring compute elements in the array of compute elements. Control over the array of compute elements is provided on a cycle-by-cycle basis, and control is enabled by a stream of wide variable-length control words generated by a compiler. Control includes branching. Data generated by fulfilled branch paths is promoted based on branch decisions.

A table 800 showing control word fields for a decompressed control word is shown. The decompressed control word includes fields 810. Although 22 fields are shown, other numbers of fields may be included in the decompressed control word. The number of fields may be based on the number of compute elements in the array, the processing capabilities of the compute elements, compiler capabilities, requirements of processing tasks, and the like. Each field within the decompressed control word may be assigned a purpose or function 812. The function of a field may include providing commands, data, addresses, etc., controlling, and the like. In embodiments, one or more fields within the decompressed control word may include spare bits. Each field within the decompressed control word may include size 814 . The size can be based on the number of bits, nibbles, bytes, and the like. Comments 816 may also be associated with fields within the decompressed control word. Comments further explain the purpose, function, etc. of a given field.

FIG. 9 shows the branch taken based on the compiler guide 900 . Taken as a whole, both sides of the branch may be executed based on the control provided to the array of compute elements. Control is made possible by a stream of wide, variable-length control words generated by the compiler. A plurality of operations associated with control may include branching. To improve processing performance of the array of compute elements, instructions or operations associated with each of the branch paths may be fetched, and execution of instructions or operations associated with both branch paths may be performed. Each branch path can produce data before a branch decision is acted upon by the control logic. Once a branch decision has been made by the control logic, data associated with the diverged branch path may be promoted, while data associated with the diverged branch path may be ignored. Transitioned branches determined from compiler guidance are based on a highly parallel processing architecture that uses dual branch execution. A two-dimensional (2D) array of compute elements is accessed. Control over the array of compute elements is provided on a cycle-by-cycle basis. Both sides of a branch in the array are executed waiting for a branch decision to be acted upon by the control logic. Data generated by fulfilled branch paths is promoted based on branch decisions. Results from the side of the branch not represented by the branch decision are ignored.

An example of executing each side of the branch is shown (910). The execution of each side of the branch is based on the control word 912 (the control word is highlighted in the dotted box). Control words may be provided by a compiler, where the compiler may generate control words by compiling one or more tasks, subtasks, etc., for execution on an array of compute elements. Execution of the control words may be based on cycles 914, where the control words may be provided cycle by cycle. Control Words may include compressed Control Words. Control words may be stored in compressed or uncompressed formats within a cache associated with an array of compute elements. Each control can be fetched from cache or from storage (indicated by "fetch" in the figure). The fetched control word may be decompressed (decomp) when the control word is stored in a compressed format before being distributed (dr) to the array. Control words can be executed when distributed in an array (ex).

Fetching of control words may include fetching the start fulfilled path fetch 920 control word. The path control words that have been initiated can be decompressed, distributed, and executed if necessary. As the start fulfilled path control word is processed, additional control words may be fetched and processed. In embodiments, fetching and processing may be accomplished using pipeline technology. Among the additional control words that are fetched, there may be control words associated with the two branch paths shown. The control words associated with each branch path can be fetched, decompressed, distributed, and executed. Execution can generate data. Branch decision 922 may be operated by control logic. When a branch decision is made, one of the branch paths may be determined to be a non-senior path 930 while the other branch path may be determined to be a senior branch path 932. Unfulfilled paths may be ignored or discarded (940), as the fetched control word and any data generated are unnecessary. Embodiments may include ignoring results from a side of a branch not indicated by branch determination. Ignored data that may be placed in cache, storage, etc. may simply be left there. When other actions are performed and data is generated, the generated data may be stored in locations of previously ignored data. Other embodiments also include removing results from the side of a branch not indicated by branch determination. Translated path 932 includes branch target 942 . Data associated with a branch target may be promoted. Predicting the data may include storing the data in a cache, shared storage, memory, or the like. Promoting can include forwarding the data to other computing elements in the array of computing elements. Additional embodiments may include using the promoted data for downstream operations. Downstream operations may include arithmetic or boolean operations, matrix operations, neural network operations, and the like.

10 is a system diagram for job processing. Job processing is performed in a highly parallel processing architecture, where the highly parallel processing architecture uses double branch execution. System 1000 may include one or more processors 1010 attached to memory 1012 that stores instructions. System 1000 includes a display 1014 coupled to one or more processors 1010 for displaying data; intermediate steps; directions; control words; a control word that implements a Very Long Instruction Word (VLIW) function; topologies including collapsible, vector, circulatory, spatial, streaming, or VLIW topologies; and the like. In embodiments, one or more processors 1010 are coupled to memory 1012, wherein the one or more processors, when executing stored instructions: access a two-dimensional (2D) array of compute elements—within the array of compute elements. Each compute element is known to the compiler and is coupled to its neighboring compute elements in the array of compute elements; to provide control over an array of compute elements on a cycle-by-cycle basis, where the control is enabled by a stream of wide, variable-length control words generated by a compiler, where the control includes branches; execute both sides of a branch in the array while waiting for a branch decision to be acted upon by the control logic, the branch decision being based on the result of a calculation in the array; and based on the branch decision, promote data generated by the branch path fulfilled. Embodiments include using the promoted data in a downstream operation. Downstream operations may include arithmetic or boolean operations, matrix operations, and the like. A branch path that has been fulfilled can continue execution and generate additional data. Unfulfilled branch paths may be handled differently. Embodiments include ignoring results from a side of a branch not indicated by branch determination. Results from unfulfilled branches can be deleted, overwritten, and so on. Further embodiments include removing results from a side of a branch not indicated by branch determination. Computing elements may include computing elements in one or more integrated circuits or chips; computing elements or cores configured within one or more programmable chips, such as application specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); heterogeneous processors configured as a mesh; standalone processors; etc. may be included.

System 1000 may include cache 1020 . Cache 1020 may be used to store data such as data associated with sides of branches, directions, control words, intermediate results, microcode, and the like. A cache may include small, local, easily accessible memory available to one or more compute elements. In embodiments, the stored data may include data associated with the sides of a branch. Taken as a whole, data associated with one side of a branch may be promoted for downstream operation, while data associated with the other side or sides of a branch may be ignored. Embodiments include storing relevant portions of a direction or control word in a cache associated with an array of computing elements. A cache may be accessible to one or more compute elements. The cache, if present, may include a double read single write (2R1W) cache. That is, the 2R1W cache can simultaneously enable two read operations and one write operation without the read and write operations interfering with each other. System 1000 may include an access component 1030 . Accessing component 1030 may include control logic and functions for accessing a two-dimensional (2D) array of computing elements, where each computing element within the array of computing elements is known to a compiler and is an array of computing elements. coupled to its neighboring computing elements in A compute element may include one or more processors, processor cores, processor macros, and the like. Each compute element may include an amount of local storage. Local storage may be accessible to one or more computing elements. Each compute element may communicate with its neighbors, which may include nearest neighbors or more remote "neighbors." Communication between the compute elements may be accomplished using a bus such as an industry standard bus, a ring bus, a network such as a wired or wireless computer network, and the like. In embodiments, the ring bus is implemented as a distributed multiplexer (MUX). As discussed below, more than one side of a branch may execute while waiting for a branch decision. The branch decision may be based on a code condition, where the condition may be set by the control unit. Code conditions may include branching points, decision points, conditions, and the like. In embodiments, a condition may determine code jumps. A code jump can change code execution from sequential execution of control words to execution of a different set of control words. Conditions may be established by the control unit. In a use case, the 2R1W cache may support simultaneous fetching of potential branch paths to the control unit. Since the branch path implemented by the control word or direction containing the branch may be data dependent and therefore not known a priori, the control words associated with more than one branch path are fetched prior to execution (prefetch) of the branch control word. It can be. As discussed elsewhere, the initial portion of two or more branching paths may be instantiated in a series of control words. When the correct branch path is determined, computations associated with unfulfilled branches are flushed and/or ignored.

System 1000 may include a provisioning component 1040 . Provide component 1040 may include controls and functions that provide control over an array of compute elements on a cycle-by-cycle basis, the control enabled by a stream of wide variable length control words generated by a compiler; The control unit includes branches. Control of the array of compute elements on a cycle-by-cycle basis may include configuring the array to perform various computational operations. Computational operations may enable audio or video processing, artificial intelligence processing, machine learning, deep learning, and the like. Providing control may be based on microcode control words, where microcode control words may include op code fields, data fields, compute array configuration fields, and the like. Compilers that generate control may include general purpose compilers, parallelizing compilers, compilers optimized for arrays of compute elements, compilers specialized to perform one or more processing tasks, and the like. Control provisioning may implement one or more topologies, such as processing topologies within an array of compute elements. In embodiments, topologies implemented within the array of compute elements may include a constrictor, vector, circulator, spatial, streaming, multiple instruction multiple data (MIMD), or very long instruction word (VLIW) topology. Other topologies may include neural network topologies. Control words may enable machine learning functions for neural network topologies.

System 1000 may include an execution component 1050 . Execution component 1050 may include functions for executing both sides of a branch in the array while waiting for control logic and a branch decision to be acted upon by the control logic, the branch decision being based on a result of a computation within the array. . Calculations that may be performed may include arithmetic operations, Boolean operations, matrix operations, neural network operations, and the like. Calculations may be performed on control words generated by the compiler. Control words may be provided to a control unit, where the control unit may control operations of the compute elements in the array of compute elements. Operations of the compute elements may include configuring the compute elements, providing data to the compute elements, routing and ordering results from the compute elements, and the like. In embodiments, the same control word may be executed in a given cycle across an array of compute elements. Executing may include decompressing the control words. The control words may be decompressed in units of compute elements, where each control word may be composed of a plurality of compute element control groups or bundles. One or more control words may be stored in a compressed format in a memory such as a cache. Compression of control words can reduce storage requirements, complexity of decoding components, and the like. In an embodiment, the control unit may operate on the decompressed control word. Both sides of a branch can represent decision points such as true or false, met or not met conditions, evaluations, and so on. Execution on both sides of a branch may include obtaining data, operating on data, storing data, and the like. Execution of both sides of the branch may continue until a branch decision is acted upon by the control logic. A branch may include more than two sides. In embodiments, execution may be performed on more than two sides until a decision is made by control logic.

Branch resolution may be part of a compiled task, which may be one of many tasks associated with a processing task. A compiled job may be executed on one or more compute elements in the array of compute elements. In embodiments, execution of a compiled task may be distributed across compute elements to parallelize execution. Executing the compiled job may include executing the job to process multiple datasets (eg, single instruction multiple data or SIMD execution). Embodiments may include providing concurrent execution of two or more potential compiled job results. Recall that a given control word or words can control a code condition for an array of compute elements. In embodiments, the two or more potential compiled job results include a computation result or flow control. Code conditionality, which may be based on computing a condition, such as a value, a Boolean equation, etc., that, based on the condition, will result in the execution of one of two or more sequences of instructions. can In embodiments, two or more potential compiled results may be controlled by the same control word. In another embodiment, a condition may determine a code jump. The two or more potential compiled job results may be based on one or more branch paths, data, etc. Execution may be based on one or more directions or control words. Since the potential compiled job results are not known a priori in the evaluation of the condition, a set of directions may enable concurrent execution of two or more potential compiled job results. When the condition is evaluated, execution of the set of directions associated with the condition may continue, while the set of directions not associated with the condition (eg, unfulfilled paths) may be stopped and flushed. In embodiments, the same direction or control word may be executed in a given cycle across an array of compute elements. Execution tasks may be performed by compute elements located throughout the array of compute elements. In embodiments, two or more potential compiled results may be executed on spatially separated computing elements within an array of computing elements. Using spatially separated compute elements reduces storage, bus, and network contention; reduced power dissipation by the compute elements; and the like. Whatever the basis for the conditionality, the conditionality is established by the control unit.

System 1000 may include a promotion component 1060 . The promote component 1060 may include control logic and functions to promote data generated by the fulfilled branch path based on the branch decision. A branch decision is made by a compute element in the array, and control unit logic can then determine what action to take based on the branch decision, eg, data associated with the branch path made can be promoted. . Committed branch path data can be promoted by performing a write committed operation. In an embodiment, a committed record may include a committed record to a data store. Data storage may include caches, local storage elements associated with an array of elements, storage coupled to an array of elements, and the like. Committed write operations can be scheduled. Additional embodiments may include scheduling committed writes to occur outside of the branch undecided window, by the compiler. The branch pending window may include an amount of time that may elapse from the time of a branch decision in the array to the time at which the branch decision can be actuated by a control unit, the number of cycles, etc. The flow of control can potentially be changed through the application of released control words. In other embodiments, the promoted data is used for downstream operations. Downstream operations may include operations performed on the same compute element, other compute elements, multiple compute elements, and the like. Additional embodiments include ignoring results from a side of a branch not indicated by branch determination. Data arising from the operation performed by the unfulfilled branch is by definition unnecessary and can simply be ignored. Any additional operations associated with branching do not need to be executed. In some embodiments, results from a side of a branch not indicated by branch determination may be eliminated. Removal may be accomplished by flushing data, overwriting data, and the like.

System 1000 may include a computer program product embodied on a computer readable medium for processing tasks, which computer program product causes one or more processors to: access a two-dimensional (2D) array of compute elements - each compute element in the array of compute elements is known to the compiler and is coupled to its neighboring compute elements in the array of compute elements; providing control over the array of compute elements on a cycle-by-cycle basis, the control being enabled by a stream of wide variable length control words generated by a compiler, the control including branches; executing both sides of a branch in the array while waiting for a branch decision to be acted upon by the control logic, the branch decision being based on calculation results in the array; and code that causes, based on the branch decision, to perform an operation that promotes data generated by the fulfilled branch path.

Each of the above methods may be executed on one or more processors on one or more computer systems. Embodiments may include various forms of distributed computing, client/server computing, and cloud-based computing. Further, it will be understood that the depicted steps or boxes included in the flowcharts of this disclosure are illustrative and explanatory only. Steps may be modified, omitted, repeated, or rearranged without departing from the scope of the present disclosure. Also, each step may include one or more sub-steps. While the foregoing figures and description describe functional aspects of the disclosed systems, no particular implementation or arrangement of software and/or hardware should be inferred from these descriptions unless explicitly stated or otherwise apparent from context. All such arrangements of software and/or hardware are intended to be within the scope of this disclosure.

Block diagrams and flow diagrams depict methods, apparatus, systems and computer program products. Elements and combinations of elements in block diagrams and flow diagrams illustrate functions, steps, or groups of steps of methods, apparatus, systems, computer program products, and/or computer-implemented methods. Any and all such functions, generally referred to herein as a "circuit," "module," or "system," may be implemented by computer program instructions, by special-purpose hardware-based computer systems, by special-purpose hardware and computers. It may be implemented by combinations of instructions, combinations of general-purpose hardware and computer instructions, and the like.

A programmable apparatus that implements any of the above-mentioned computer program products or computer implemented methods includes one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, programmable devices, programmable gate arrays, programmable array logic, memory devices, may include application specific integrated circuits and the like. Each may be suitably used or configured for processing computer program instructions, executing computer logic, storing computer data, and the like.

It will be appreciated that a computer may include a computer program product from a computer readable storage medium, which medium may be internal or external, removable and replaceable or fixed. In addition, a computer may include a Basic Input/Output System (BIOS), firmware, an operating system, a database, and the like that may include, interface, or support the software and hardware described herein.

Embodiments of the present invention are not limited to conventional computer applications or programmable devices that run them. For illustrative purposes, embodiments of the present invention may include optical computers, quantum computers, analog computers, and the like. A computer program can be loaded into a computer to create a particular machine capable of performing some or all of the functions shown. This particular machine provides means for performing any and all of the functions shown.

a non-transitory computer readable medium for storage; electronic, magnetic, optical, electromagnetic, infrared, or semiconductor computer readable storage media or any suitable combination thereof; portable computer diskettes; hard disk; random access memory (RAM); read only memory (ROM), erasable programmable read-only memory (EPROM, Flash, MRAM, FeRAM, or phase change memory); optical fiber; portable compact disc; optical storage devices; Any combination of one or more computer readable media including, but not limited to, a magnetic storage device, or any suitable combination of the foregoing may be used. In the context of this document, a computer readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus or device.

It will be appreciated that computer program instructions may include computer executable code. Various languages for expressing computer program instructions are C, C++, Java, JavaScript™, ActionScript™, assembly language, Lisp, Perl, Tcl, Python, Ruby, hardware description languages, database programming languages, functional programming languages, It may include essential programming languages, but is not limited thereto. In embodiments, computer program instructions may be stored, compiled or interpreted to be executed on a computer, programmable data processing device, processors or heterogeneous combination of processor architectures, or the like. Without limitation, embodiments of the present invention may implement any form of web-based computer software including client/server software, software as a service, peer-to-peer software, and the like.

In embodiments, a computer may enable execution of computer program instructions including multiple programs or threads. Multiple programs or threads may be processed substantially concurrently to enhance utilization of the processor and facilitate substantially concurrent functions. By implementation, any and all methods, program codes, program instructions, etc., described herein may be implemented in one or more threads, which in turn may spawn other threads, which in turn You can have priorities associated with you. In some embodiments, a computer may process these threads based on priority or other order.

Unless explicitly stated or otherwise apparent from context, the verbs “run” and “process” may be used interchangeably to denote run, process, interpret, compile, assemble, link, load, or any combination thereof. there is. Thus, embodiments that execute or process computer program instructions, computer executable code, etc. may act on the instructions or code in any and all of the described ways. Further, the depicted method steps are intended to encompass any suitable method of causing one or more parties or entities to perform the steps. Parties performing a step or part of a step need not be located within a particular geographic location or country boundary. For example, a method is considered to be performed in the United States by a causal entity if an entity located in the United States causes method steps or portions thereof to be performed outside the United States.

Although the present invention has been disclosed in connection with preferred embodiments shown and described in detail, various modifications and improvements will become apparent to those skilled in the art. Therefore, the examples should not limit the spirit and scope of the present invention, but rather should be understood in the broadest sense permitted by law.

Claims (40)

As a processor implementation method for task processing,
accessing a two-dimensional (2D) array of compute elements, each compute element in the array of compute elements being known to a compiler and coupled to its neighboring compute elements in the array of compute elements; ;
providing control over the array of compute elements on a cycle-by-cycle basis, the control enabled by a stream of wide variable length control words generated by the compiler, the control including branches;
executing both sides of the branch in the array while waiting for a branch decision to be acted upon by control logic, the branch decision being based on calculation results in the array; and
based on the branch decision, promoting data generated by a branch path that has been complied with. 2. The method of claim 1, further comprising using the data that was promoted in a downstream operation. 3. The method of claim 2, further comprising ignoring results from a side of the branch not indicated by the branch determination. 3. The method of claim 2, further comprising removing results from a side of the branch not indicated by the branch determination. 2. The method of claim 1, wherein the data generated by a diverged branch path is used for a committed record. 6. The method of claim 5, wherein the committed record cannot be reversed or ignored. 6. The method of claim 5, wherein the committed writes include committed writes to a data store. 8. The method of claim 7, wherein the data store resides external to the 2D array of compute elements. 2. The method of claim 1, further comprising scheduling, by the compiler, a committed write to the data generated by a complied branch path to occur outside of a branch undecided window. 10. The method of claim 9, wherein scheduling the committed write avoids disrupting operation of the array. 2. The method of claim 1, wherein the executing step excludes branch prediction logic. 2. The method of claim 1, further comprising loading the data generated by the transitioned branch path into a compute element memory in an array. 13. The method of claim 12, further comprising ignoring data that was loaded into the in-array compute element memory based on the branch decision. 2. The method of claim 1, further comprising executing an additional branch concurrently with the two sides of the branch. 15. The method of claim 14, wherein the further branch and the two sides of the branch include multidirectional branch evaluation. 15. The method of claim 14, wherein the further branch and the two sides of the branch comprise two independent branch decisions. The method of claim 1 , further comprising providing branch address offsets to the array of compute elements using row ring buses. 2. The method of claim 1, wherein the branch decision is communicated using execution bits of array Arithmetic Logic Units (ALUs). The method of claim 1 , further comprising storing portions of control words from the stream of control words in a cache associated with the array of compute elements. 20. The method of claim 19, wherein the cache comprises a dual read, single write (2R1W) data cache. 21. The method of claim 20, wherein the 2R1W cache supports simultaneous fetching of potential branch paths to a control unit. The method of claim 1 , wherein the compiler maps a machine learning function to the array of compute elements. 23. The method of claim 22, wherein the machine learning function comprises a neural network implementation. The method of claim 1 , further comprising stacking the 2D array of compute elements with another 2D array of compute elements to form a three-dimensional stack of compute elements. A computer program product embodied in a computer readable medium for processing a task, the computer program product causing one or more processors to:
accessing a two-dimensional (2D) array of compute elements, each compute element in the array of compute elements being known to a compiler and coupled to its neighboring compute elements in the array of compute elements; ;
providing control over the array of compute elements on a cycle-by-cycle basis, the control enabled by a stream of wide variable length control words generated by the compiler, the control including branching;
executing both sides of the branch in the array while waiting for a branch decision to be acted upon by control logic, the branch decision being based on calculation results in the array; and
and code that causes, based on the branch decision, to perform operations that promote data generated by a complied branch path. 26. The computer program product of claim 25, further comprising code for using data that was promoted in a downstream operation. 27. The computer program product of claim 26, further comprising code for ignoring results from a side of the branch not indicated by the branch determination. 27. The computer program product of claim 26, further comprising code for removing results from a side of the branch not indicated by the branch determination. 26. The computer program product of claim 25, wherein the data generated by a diverged branch path is used for committed writes. 30. The computer program product of claim 29, wherein the committed record cannot be reversed or ignored. 30. The computer program product of claim 29, wherein the committed write includes a committed write to a data store. 32. The computer program product of claim 31, wherein the data store resides external to the 2D array of compute elements. A computer system for processing tasks,
memory for storing instructions;
and one or more processors coupled to the memory, wherein the one or more processors when executing the stored instructions:
to access a two-dimensional (2D) array of compute elements, each compute element in the array of compute elements being known to a compiler and coupled to its neighboring compute elements in the array of compute elements;
to provide control over the array of compute elements on a cycle-by-cycle basis, the control enabled by a stream of wide variable length control words generated by the compiler, the control including branches;
execute both sides of a branch in the array while waiting for a branch decision to be acted upon by the control logic, the branch decision being based on the result of a calculation in the array; and
and based on the branch determination, promote data generated by a branch path that has been fulfilled. 34. The computer system of claim 33, further configured to use data that was promoted in a downstream operation. 35. The computer system of claim 34, further configured to ignore results from a side of the branch not indicated by the branch determination. 35. The computer system of claim 34, further comprising code for removing results from a side of the branch not indicated by the branch determination. 34. The computer system of claim 33, wherein the data generated by a diverged branch path is used for committed writes. 38. The computer system of claim 37, wherein the committed record cannot be reversed or ignored. 38. The computer system of claim 37, wherein the committed writes include committed writes to a data store. 40. The computer system of claim 39, wherein the data store resides external to the 2D array of compute elements.

Images