Abstract: A stream computing application may be configured to manage the flow of tuples through a section of an operator graph. A window may be generated over one or more stream operators. The window may include breakpoint thresholds that set the maximum flow of tuples within the window. The stream operators within the window may be monitored to determine the flow of tuples occurring within the window using tuple flow counts. The tuple flow counts may be compared to the breakpoint thresholds to determine whether a breakpoint condition has occurred. If a breakpoint condition has occurred, a tuple flow change may be implemented to reduce the flow of tuples within the window.

Abstract: An accelerator deployment tool deploys multiple accelerators to multiple programmable devices, and detects when a new programmable device becomes available. When a first accelerator in a first programmable device is a better match to the new programmable device, the accelerator deployment tool automatically generates an image for the first accelerator for the new programmable device, deploys the image on the new programmable device to generate a second accelerator, changes references to the first accelerator to reference instead the second accelerator, and casts the first accelerator out of the first programmable device.

Abstract: Text is received from a first user. The text is associated with an electronic communication tool for communication to a second user. Candidate answers are generated based on the text using a question answering system. At least one of the candidate answers is provided to the first user.

Abstract: A computer program includes calls to a software library. A virtual function table is built that includes the calls to the software library in the computer program. A programmable device includes one or more currently-implemented accelerators. The available accelerators that are currently-implemented are determined. The calls in the software library that correspond to a currently-implemented accelerator are determined. One or more calls to the software library in the virtual function table are replaced with one or more corresponding calls to a corresponding currently-implemented accelerator. When a call in the software library could be implemented in a new accelerator, an accelerator image for the new accelerator is dynamically generated. The accelerator image is then deployed to create the new accelerator. One or more calls to the software library in the virtual function table are replaced with one or more corresponding calls to the new accelerator.

Abstract: Text is received from a first user. The text is associated with an electronic communication tool for communication to a second user. Candidate answers are generated based on the text using a question answering system. At least one of the candidate answers is provided to the first user.

Abstract: Relocation of virtual machines is facilitated by obtaining, by a first controller, first power-related information from a first power system set that provides power to a first set of powered hardware components, where the first set of powered hardware components are running a first plurality of virtual machines. The first controller generates a relocation protocol for migrating the first plurality of virtual machines based, at least in part, upon the first power-related information. The relocation protocol includes: a migration of a first subset of one or more virtual machines so that the first subset of virtual machine(s) is to be migrated to and run on a second set of powered hardware components in a manner such that the first subset of virtual machine(s) continues to operation in a substantially continuous manner through the migration; and a snapshotting of a second subset of one or more virtual machines.

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 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: Computer-implemented project management platform methods, systems, and computer-readable media are described.

Abstract: High speed optoelectronic devices and associated methods are provided. In one aspect, for example, a high speed optoelectronic device can include a silicon material having an incident light surface, a first doped region and a second doped region forming a semiconductive junction in the silicon material, and a textured region coupled to the silicon material and positioned to interact with electromagnetic radiation. The optoelectronic device has a response time of from about 1 picosecond to about 5 nanoseconds and a responsivity of greater than or equal to about 0.4 A/W for electromagnetic radiation having at least one wavelength from about 800 nm to about 1200 nm.

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: Hardware accelerators are scored according to various metrics and attributes that characterize the accelerators. Examples of suitable accelerator scoring criteria include whether the software simulation of the accelerator is complete, whether hardware testing is complete, whether the accelerator is currently deployed, the number of times the accelerator has been deployed to a private cloud, the number of times the accelerator has been deployed to a public cloud, ratings by users, number of failures, number of executions, space utilization and efficiency, code metrics, power consumption, speed, and image characteristics, including space used, resources used, use of dedicated functions on a programmable device, etc. These accelerator scoring criteria are tracked for each accelerator in an accelerator scoring catalog.

Abstract: A cloud-based accelerator manager manages cloud-based hardware accelerators. The accelerator manager monitors computer programs running in the cloud and generates a trace that indicates which accelerators were used and when. The trace may be for a single computer program or may be for multiple computer programs. Thus, the trace can be program-specific, showing all accesses to accelerators by a single program, or may be accelerator-specific, showing all accesses to each accelerator by all computer programs. The cloud-based accelerator manager detects a failure in one of the computer programs executing in the cloud. The cloud-based accelerator manager provides the trace to a user, who can then analyze the trace to determine whether the failure was due to an accelerator. The cloud-based accelerator manager thus helps detect when cloud-based accelerators are the reason for failures for computer programs running in a cloud.

Abstract: A software application on a device manages transportation procurement for a user. The software application collects application data. The application data is from a plurality of software applications on the device. The application detects a triggering event. The triggering event is based on the collected application data and corresponds to a state of the user. The application determines a transportation need of the user. The need is determined in response to the triggering event. The application determines the need based on the application data. The transportation need includes both a time parameter and a location parameter. The need is determined without direct input from the user. The application generates candidate transportation options which satisfy the need. These options are generated based on the time and location parameters. The application provides the candidate options to the user.

Abstract: An accelerator deployment tool deploys multiple accelerators to multiple programmable devices, and detects when a new programmable device becomes available. When a first accelerator in a first programmable device is a better match to the new programmable device, the accelerator deployment tool automatically generates an image for the first accelerator for the new programmable device, deploys the image on the new programmable device to generate a second accelerator, changes references to the first accelerator to reference instead the second accelerator, and casts the first accelerator out of the first programmable device.

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: Methods, computer program products, and systems are presented. A high availability system includes a high availability set of a primary node processing incoming computational tasks and two or more backup nodes in a queue. The incoming computational tasks for the high availability set is managed according to various policies. For example, based on detecting an impending failure of the primary due to a lack of resources allocated for the primary node, one of the backup node that has the resources lacking from the primary node and that is the least likely to be used for processing the incoming computational tasks is selected as a lender node, according to a borrowing policy, and the resources of the lender node is allocated to the primary for further processing of the incoming computational tasks.

Abstract: An accelerator deployment tool deploys multiple accelerators to multiple programmable devices, and detects when a new programmable device becomes available. When a first accelerator in a first programmable device is a better match to the new programmable device, the accelerator deployment tool automatically generates an image for the first accelerator for the new programmable device, deploys the image on the new programmable device to generate a second accelerator, changes references to the first accelerator to reference instead the second accelerator, and casts the first accelerator out of the first programmable device.

Abstract: A transportation company uses transportation vehicles. The transportation company receives a plurality of transportation needs. These transportation needs are received from user accounts. The transportation needs are based on states of users gathered without user intervention. Each transportation needs include time parameters and location parameters. The transportation company determines a probabilistic model for transportation needs. The probabilistic model is based on the plurality of transportation needs. The first probabilistic model relate to respective probabilities of transportation needs occurring at the locations and times of the plurality of transportation needs. The transportation company determines which transportation vehicles are currently available. The company then determines a plan which includes some of the vehicles going to some of the locations at some of the times. This plan is based on the probabilistic model.

Abstract: An accelerator manager monitors one or more requests for accelerators from one or more users, and deploys one or more accelerators to one or more programmable devices based on the one or more requests from the one or more users. In a first embodiment, the accelerator manager deploys an accelerator that satisfies multiple user requests. The multiple user requests can be multiple requests from one user, or could be multiple requests from multiple users. In a second embodiment, the accelerator manager compiles historical data from the monitored requests, identifies one or more accelerators that are requested following the request for a first accelerator, and deploys the one or more accelerators after the first accelerator is requested and before they are requested.