Abstract: A machine learning model network is analyzed to identify types of operations and dependencies associated with different portions of the machine learning model network, including by classifying at least a portion of the types of operations as being memory bandwidth intensive or compute intensive. The machine learning model network is partitioned across a plurality of different machine learning accelerator hardware units based at least in part on the analysis. Parallelization and pipelining of an execution of the machine learning model network is allowed based on the partitioning.

Abstract: A computer program compiled for a machine learning accelerator hardware and associated with a default input data size is received. An execution of an operation of the computer program is initiated. It is identified that a data size of an input data of the operation is smaller than the default input data size. The smaller data size of the input data of the operation rather than the default input data size is caused to be transferred to the machine learning accelerator hardware for the input data of the operation.

Abstract: Disclosed are ways to flexibly arrange, rearrange, and execute optimization modules for program code in user-customizable sequences. In various embodiments, computer programmers can select an order of multiple standalone optimizers that each perform an optimization function on program code, forming a pipeline of a series of optimization modules. The pipeline can be modified by, for example, adding, removing, rearranging, repeating, and/or replacing optimization modules.

Abstract: Disclosed are ways to flexibly arrange, rearrange, and execute optimization modules for program code in user-customizable sequences. In various embodiments, computer programmers can select an order of multiple standalone optimizers that each perform an optimization function on program code, forming a pipeline of a series of optimization modules. The pipeline can be modified by, for example, adding, removing, rearranging, repeating, and/or replacing optimization modules.

Abstract: The technology is directed to profiling binary code based on a computed “density” of functions in the code. The density of a function can be computed as the frequency of execution of the function divided by the size of the function. Functions that execute more often and are smaller in size (“dense functions”) are moved towards the “front” (e.g., beginning) of the binary code. The frequency of execution can be measured at runtime using a performance measurement tool without requiring modification of the binary code or corresponding source code. After density is computed (e.g., over a period of time) for functions, it can be used to cause linkers to rearrange the binary code to place denser functions closer to the “front” of the binary code. By loading denser functions first (e.g., into processor caches and translation lookaside buffer (“TLB”)), the technology reduces cache and TLB misses, and thereby improves system performance.

Abstract: The disclosure is related to optimizing generation of intermediate representation (IR) for a script code by eliminating redundant reference count code from the IR. The reference count code includes code that manages a reference count of an object, e.g., code that increments a reference count of the object (“incref code”) and an observer code which consumes or the execution of which depends on the reference count of the object. The IR is analyzed to identify redundant reference count code. Counters associated with the object are evaluated and upon satisfying the optimization criterion, the incref code is moved closer to the observer code. The incref code and the observer code that are adjacent to each other are identified as redundant code pair and the code pair is eliminated from the IR to generate an optimized IR. The optimized IR is further converted to an executable code.

Abstract: The technology is directed to profiling binary code based on a computed “density” of functions in the code. The density of a function can be computed as the frequency of execution of the function divided by the size of the function. Functions that execute more often and are smaller in size (“dense functions”) are moved towards the “front” (e.g., beginning) of the binary code. The frequency of execution can be measured at runtime using a performance measurement tool without requiring modification of the binary code or corresponding source code. After density is computed (e.g., over a period of time) for functions, it can be used to cause linkers to rearrange the binary code to place denser functions closer to the “front” of the binary code. By loading denser functions first (e.g., into processor caches and translation lookaside buffer (“TLB”)), the technology reduces cache and TLB misses, and thereby improves system performance.

Abstract: The disclosure is related to optimizing generation of intermediate representation (IR) for a script code by eliminating redundant reference count code from the IR. The reference count code includes code that manages a reference count of an object, e.g., code that increments a reference count of the object (“incref code”) and an observer code which consumes or the execution of which depends on the reference count of the object. The IR is analyzed to identify redundant reference count code. Counters associated with the object are evaluated and upon satisfying the optimization criterion, the incref code is moved closer to the observer code. The incref code and the observer code that are adjacent to each other are identified as redundant code pair and the code pair is eliminated from the IR to generate an optimized IR. The optimized IR is further converted to an executable code.