Abstract: A thermal manager manages programmable devices that include one or more accelerators. The thermal manager may be part of an accelerator manager that manages multiple accelerators in multiple programmable devices. The thermal manager monitors the temperature of a programmable device and casts out one or more accelerators when the temperature of the programmable device exceeds a threshold. Where there are multiple accelerator images that have different thermal effects for a given function the thermal manager may replace the cast out accelerator with another accelerator image for the same function that uses less power.

Abstract: An accelerator manager monitors hardware accelerators that are called by one or more computer programs. A virtual function table includes multiple entries, where each entry correlates a call from a computer program to a corresponding call to either a software library or a hardware accelerator. A call by the computer program to a function in the virtual function table results in the call being routed to either the software library or to a hardware accelerator depending on the contents of the corresponding entry in the virtual function table. The accelerator manager, in response to a detected failure in an accelerator, replaces one or more calls in the virtual function table to the failed accelerator with calls to the software library. The accelerator manager can then retry the call that caused the accelerator to fail, which will then be executed by the software library.

Abstract: A cloud-based hardware accelerator is selected by deploying an accelerator image to first and second clouds to generate first and second cloud-based hardware accelerators, executing a first request on the first and second cloud-based hardware accelerators, monitoring characteristics of the first and second cloud-based hardware accelerators executing the first request, which may include execution time and monetary cost, and selecting one of the first and second hardware accelerators according to defined selection criteria. Subsequent requests are then routed to the selected cloud-based accelerator.

Abstract: A method for processing distributed breakpoints when debugging a distributed application includes establishing a breakpoint in source code of a distributed computer program and executing the distributed computer program. Thereafter, an encountering of the breakpoint is detected in one of the processes, and execution of the one of the processes halted. However, halting execution of any other of the processes is delayed for a delay period during which a list both is generated of others of the processes in which the breakpoint is encountered and also is sorted in accordance with prioritization criteria. Finally, the sorted list is presented after the lapse of the delay period, individual ones of the processes selected in the list, and execution of the selected individual ones of the processes in the sorted list halted while halting of execution of non-selected ones of the processes in the sorted list is bypassed.

Abstract: Systems, methods, and computer program products to perform an operation comprising receiving, by a database management system (DBMS), a first query specifying to insert data into a database, generating, by a first clustering algorithm applied to a first portion of the data, a first clustering value for the first portion of the data, and storing the data and the first clustering value as a record in a table of the database, wherein the first clustering value is stored in a first hidden column configured to store clustering values in the table.

Abstract: An accelerator manager monitors and logs performance of multiple accelerators, analyzes the logged performance, determines from the logged performance of a selected accelerator a desired programmable device for the selected accelerator, and specifies the desired programmable device to one or more accelerator developers. The accelerator manager can further analyze the logged performance of the accelerators, and generate from the analyzed logged performance an ordered list of test cases, ordered from fastest to slowest. A test case is selected, and when the estimated simulation time for the selected test case is less than the estimated synthesis time for the test case, the test case is simulated and run. When the estimated simulation time for the selected test case is greater than the estimated synthesis time for the text case, the selected test case is synthesized and run.

Abstract: A computer-implemented method may include identifying a sending computer system and a receiving computer system. The method may also include receiving a request from the sending computer system for a receptiveness value of the receiving computer system, where the receptiveness value indicates openness of the receiving computer system to interruption. The method may also include determining a current state of the receiving computer system. The method may also include determining a known state of the receiving computer system. The method may also include calculating a known state receptiveness value. The method may also include analyzing the current state and the known state to determine whether the current state is equivalent to the known state. The method may also include calculating the receptiveness value for the receiving computer system. The method may also include transmitting computer instructions for displaying the receptiveness value to the sending computer system.

Abstract: A computer-implemented method includes exchanging device data, associated with a first participating user device, with the one or more second participating user devices; receiving audio data associated with a voice command; exchanging the audio data with the one or more second participating user devices; identifying, by the first participating user device, a voice command based on exchanging the audio data; determining which one of the first participating user device or the one or more second participating user devices should respond to the voice command based on details of the voice command and the exchanging the device data; responding to the voice command based on determining that the first participating user device should respond to the voice command; and signaling a particular second participating user device to respond to the voice command based on determining that the particular second participating user device should respond to the voice command.

Abstract: Multiple debug boundaries are defined in a hardware accelerator. The location of debug boundaries can be defined by a human user, or can be determined by automated tools based on characteristics of the circuitry in the hardware accelerator. Each debug boundary includes one or more hardware memory elements that are in a first state to indicate the debug boundary has not yet been reached, and that are changed to a second state by the hardware accelerator to indicate the debug boundary has been reached during execution of the hardware accelerator. Providing multiple debug boundaries in a hardware accelerator aids in debugging the accelerator design by identifying a particular section of the hardware accelerator where the failure occurred. This information regarding location of a failure may be provided to a user or to synthesis and simulation tools for the hardware accelerator design.

Abstract: An accelerator manager monitors and logs performance of multiple accelerators, analyzes the logged performance, determines from the logged performance of a selected accelerator a desired programmable device for the selected accelerator, and specifies the desired programmable device to one or more accelerator developers. The accelerator manager can further analyze the logged performance of the accelerators, and generate from the analyzed logged performance an ordered list of test cases, ordered from fastest to slowest. A test case is selected, and when the estimated simulation time for the selected test case is less than the estimated synthesis time for the test case, the test case is simulated and run. When the estimated simulation time for the selected test case is greater than the estimated synthesis time for the text case, the selected test case is synthesized and run.

Abstract: An accelerator manager monitors run-time performance of multiple accelerators in one or more programmable devices, and when first and second accelerators satisfy at least one coalescence criterion, the accelerator manager generates a new accelerator image corresponding to a third accelerator that coalesces the first accelerator and the second accelerator. In a first embodiment, the accelerator manager generates the new accelerator image from the accelerator images for the first and second accelerators. In a second embodiment, the accelerator manager generates the new accelerator image from hardware description language representations of the first and second accelerators. The new accelerator image is deployed to a programmable device to provide a new accelerator, and calls to the first and second accelerators are replaced with calls to the new accelerator.

Abstract: An accelerator manager validates an accelerator image using one or more suitable validation methods, which may include comparing results of running an accelerator with results of simulating the accelerator, comparing results of running an accelerator on two different programmable devices, and deploying the accelerator to a cloud of an accelerator provider and running the accelerator to determine whether the accelerator meets defined specifications. The accelerator manager can also report information about one or more accelerators to an accelerator provider and/or to a provider of a programmable device.

Abstract: Methods, apparatuses, and computer program products for visualizing migration of a resource of a distributed computing environment are provided. Embodiments include displaying, within a graphical user interface (GUI), one or more graphical resource representations. Each graphical resource representation represents a resource of a distributed computing environment. Each graphical resource representation is displayed in a particular location within the GUI according to a location of the resource within the distributed computing environment. Embodiments also include displaying, within the GUI, a first graphical migration representation. The first graphical migration representation represents a first transfer operation of a first resource of the distributed computing environment.

Abstract: Methods, apparatuses, and computer program products for visualizing migration of a resource of a distributed computing environment are provided. Embodiments include displaying, within a graphical user interface (GUI), one or more graphical resource representations. Each graphical resource representation represents a resource of a distributed computing environment. Each graphical resource representation is displayed in a particular location within the GUI according to a location of the resource within the distributed computing environment. Embodiments also include displaying, within the GUI, a first graphical migration representation. The first graphical migration representation represents a first transfer operation of a first resource of the distributed computing environment.

Abstract: An accelerator image generator includes a synthesis block and a simulation block. The accelerator image generator receives a hardware description language representation for a desired function, inputs the hardware description language representation for the desired function to the synthesis block and to the simulation block so the synthesis block and simulation block work in parallel, monitors progress of the synthesis block and the simulation block, and when a defined threshold is reached in the synthesis block, halts the simulation block while the synthesis block continues until the synthesis block outputs an accelerator image for deployment to a programmable device. When an error is detected in the synthesis block following halting of the simulation block, the simulation block may be resumed, and the defined threshold may be adjusted. The accelerator image can be deployed to a programmable device to provide a hardware accelerator corresponding to the accelerator image.

Abstract: An on-chip accelerator manager manages multiple accelerators in a programmable device. In one specific implementation, the multiple accelerators are identical accelerators. The accelerator manager and the multiple accelerators are deployed to the programmable device. One or more calls to a software library in a virtual function table are replaced with one or more calls to the on-chip accelerator manager. The on-chip accelerator manager receives an accelerator call, and in response, allocates the accelerator call to one of the multiple accelerators, performs load balancing to the multiple accelerators, and performs failover when one of the accelerators fails by allocating work that was allocated to the failed accelerator to a different accelerator. The on-chip accelerator can push work to the multiple accelerators in a first mode of operation, and the multiple accelerators can pull work from the on-chip accelerator manager in a second mode of operation.

Abstract: An accelerator manager monitors usage of accelerators by one or more computer programs, and generates a historical log from the monitored usage. The accelerator manager determines from the historical log which of the plurality of accelerators to implement on one or more application-specific integrated circuits. Each application-specific integrated circuit can include implemented accelerators and accelerator images that can be deployed to external programmable devices. Once one or more accelerators are implemented on one or more application-specific integrated circuits, the accelerator manager can direct one of the application-specific integrated circuits to provide a needed accelerator. An application-specific integrated circuit can provide the needed accelerator either using an accelerator implemented in the application-specific integrated circuit, or by deploying an accelerator image in the application-specific integrated circuit to an external programmable device.

Abstract: An accelerator deployment tool determines resource requirements for one or more accelerator images, determines feature sets of a plurality of programmable devices, compares the resource requirements to the feature sets, determines whether the feature sets satisfy the resource requirements, and when the feature sets satisfy the resource requirements, selects one or more of the plurality of programmable devices that has a feature set that satisfies the resource requirements, and deploys the accelerator image(s) to the selected programmable device(s) to provide one or more accelerators corresponding to the accelerator image(s). A call can then be made to the one or more accelerators. The accelerator deployment tool thus automatically selects one or more programmable devices based on their feature sets and can automatically deploy one or more accelerator images to the one or more programmable devices.

Abstract: An accelerator helper monitors pending calls for a first accelerator, and when the accelerator is too busy, the accelerator helper sends a new call to the first accelerator to a software routine instead of to the first accelerator. The software routine processes the new call in parallel with the first accelerator processing a previous call. When the accelerator is not too busy, the accelerator helper sends to the first accelerator the new call to the first accelerator. The determination of when the accelerator is too busy can be whether a number of pending calls for the first accelerator exceeds a predetermined threshold. The accelerator helper speeds up execution of calls to the first accelerator by executing some calls to the accelerator in a software routine when the first accelerator has too many calls pending.

Abstract: An accelerator helper monitors pending calls for a first accelerator, and when the accelerator is too busy, the accelerator helper sends a new call to the first accelerator to a software routine instead of to the first accelerator. The software routine processes the new call in parallel with the first accelerator processing a previous call. When the accelerator is not too busy, the accelerator helper sends to the first accelerator the new call to the first accelerator. The determination of when the accelerator is too busy can be whether a number of pending calls for the first accelerator exceeds a predetermined threshold. The accelerator helper speeds up execution of calls to the first accelerator by executing some calls to the accelerator in a software routine when the first accelerator has too many calls pending.