Abstract: Launch configurations of a hardware acceleration device are determined, which minimize hardware thread management overhead in running a program code. Based on received hardware behaviors, the architectural features, the thread resources and the constraints associated with the hardware acceleration device, possible launch configurations and impossible launch configurations are generated. A ranking of at least some of the possible launch configurations may be generated and output, based on how well each of said at least some of the possible launch configurations satisfies at least some of the constraints. Parametric values of said at least some of the possible launch configurations, an explanation why the impossible launch configurations have been determined as being impossible, and one or more strategies for scheduling, latencies and efficiencies associated with the hardware acceleration device, are output.

Abstract: An illustrative embodiment includes a method for checkpointing and restarting an application executing at least in part on one or more central processing units coupled to one or more hardware accelerators. The method comprises checkpointing the application at least in part by: transferring checkpoint data of the application to the one or more hardware accelerators; performing distributed compression of the application checkpoint data at least in part using the one or more hardware accelerators; and writing the compressed application checkpoint data to a storage device. The method further comprises restarting the application at least in part by: reading the compressed application checkpoint data from the storage device; transferring the compressed checkpoint data to one or more hardware accelerators; and performing distributed decompression of the application checkpoint data at least in part using said one or more hardware accelerators.

Abstract: Methods for dynamically executing computer code across multiple disparate processing unit architectures are disclosed. During execution of a first portion of computer code on a first processing unit, it is determined that a first dynamic hardware behavior of a plurality of dynamic hardware behaviors will occur at a subsequent point in time, based on a second dynamic hardware behavior that is occurring. The methods include determining to execute code corresponding to the first dynamic hardware behavior on a second processing unit, rather than the first processing unit, and scheduling computer program code corresponding to the first dynamic hardware behavior to execute on the second processing unit rather than the first processing unit. Upon completion of execution of the computer code corresponding to the first dynamic hardware behavior, a remaining portion of the computer code is scheduled to execute on the first processing unit.

Abstract: Launch configurations of a hardware acceleration device are determined, which minimize hardware thread management overhead in running a program code. Based on received hardware behaviors, the architectural features, the thread resources and the constraints associated with the hardware acceleration device, possible launch configurations and impossible launch configurations are generated. A ranking of at least some of the possible launch configurations may be generated and output, based on how well each of said at least some of the possible launch configurations satisfies at least some of the constraints. Parametric values of said at least some of the possible launch configurations, an explanation why the impossible launch configurations have been determined as being impossible, and one or more strategies for scheduling, latencies and efficiencies associated with the hardware acceleration device, are output.

Abstract: An illustrative embodiment includes a method for checkpointing and restarting an application executing at least in part on one or more central processing units coupled to one or more hardware accelerators. The method comprises checkpointing the application at least in part by: transferring checkpoint data of the application to the one or more hardware accelerators; performing distributed compression of the application checkpoint data at least in part using the one or more hardware accelerators; and writing the compressed application checkpoint data to a storage device. The method further comprises restarting the application at least in part by: reading the compressed application checkpoint data from the storage device; transferring the compressed checkpoint data to one or more hardware accelerators; and performing distributed decompression of the application checkpoint data at least in part using said one or more hardware accelerators.

Abstract: Methods for estimating accelerator performance for dynamic hardware behaviors are disclosed. Computer program code to be executed on a first processing unit is received, and an execution of the computer code on the first processing unit is monitored to determine a plurality of performance characteristics. A plurality of dynamic hardware behaviors is determined by applying a clustering algorithm to the performance characteristics, and an equivalent accelerator portion of computer code to be executed on a second processing unit is generated by translating a set of instructions in a first portion of computer code corresponding to a first one of the plurality of dynamic hardware behaviors to an equivalent set of instructions to be executed on the second processing unit. An estimated measure of performance for executing the equivalent accelerator portion on the second processing unit is determined for the first one of the plurality of dynamic hardware behaviors.

Abstract: Methods for dynamically executing computer code across multiple disparate processing unit architectures are disclosed. During execution of a first portion of computer code on a first processing unit, it is determined that a first dynamic hardware behavior of a plurality of dynamic hardware behaviors will occur at a subsequent point in time, based on a second dynamic hardware behavior that is occurring. The methods include determining to execute code corresponding to the first dynamic hardware behavior on a second processing unit, rather than the first processing unit, and scheduling computer program code corresponding to the first dynamic hardware behavior to execute on the second processing unit rather than the first processing unit. Upon completion of execution of the computer code corresponding to the first dynamic hardware behavior, a remaining portion of the computer code is scheduled to execute on the first processing unit.

Abstract: Methods for estimating accelerator performance for dynamic hardware behaviors are disclosed. Computer program code to be executed on a first processing unit is received, and an execution of the computer code on the first processing unit is monitored to determine a plurality of performance characteristics. A plurality of dynamic hardware behaviors is determined by applying a clustering algorithm to the performance characteristics, and an equivalent accelerator portion of computer code to be executed on a second processing unit is generated by translating a set of instructions in a first portion of computer code corresponding to a first one of the plurality of dynamic hardware behaviors to an equivalent set of instructions to be executed on the second processing unit. An estimated measure of performance for executing the equivalent accelerator portion on the second processing unit is determined for the first one of the plurality of dynamic hardware behaviors.