RU2813618C1 - Hardware acceleration for processing functions - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: invention relates to methods of configuring a hardware circuit to perform a function. Method comprises receiving, in a function processing service, a request to execute a source code, wherein the request is received from a requesting entity, and wherein the source code contains instructions for executing the function; determining that the hardware acceleration condition has been satisfied for the function, wherein determining that the hardware acceleration condition has been met comprises counting the number of requests corresponding to one or more functions and received by the function processing service during the time interval, and determining whether that number of requests exceeds a threshold value; source code instructions are translated into a hardware-dependent code corresponding to the hardware circuit; configuring the hardware circuit based on the hardware-dependent code; instructing the hardware circuit to perform the function and providing the result obtained from the hardware circuit to a requesting entity.

EFFECT: providing more efficient execution of a function processing service.

20 cl, 18 dwg

Description

State of the art

[0001] Cloud computing is the delivery of computing services (eg, servers, storage devices, databases, networking, software, analytics) over the Internet. Generally speaking, a cloud computing system includes two sections, a front-end and a back-end, which support electronic communication with each other via the Internet. The frontend includes the interface that users interact with through the client device. The backend includes the resources that deliver cloud computing services, including processors, memory, storage, and network hardware. The back-end of a cloud computing system typically includes one or more data processing and storage centers, which may be located in different geographic areas. Each data center typically includes a large number (eg, hundreds or thousands) of computing devices, which may be referred to as "host machines."

[0002] Many different types of services can be provided through a cloud computing system. A function processing service is a cloud computing service that enables users to execute source code without the complexity of creating and maintaining the infrastructure that is typically associated with developing and running an application. The function processing service automatically manages the computing resources required to run the source code. Hence, the function processing service allows software developers to execute source code without having to worry about provisioning or managing servers.

[0003] As the name "function processing" implies, a function processing service may be used to execute source code that includes instructions to perform one or more functions. Function processing is sometimes called "serverless computing" or "function-as-a-service (FaaS)".

[0004] As function processing services become more popular, the source code that is executed becomes more complex and information intensive. For example, applications based on machine learning or artificial intelligence can use information-intensive scripts that process huge volumes of data. These information-intensive scenarios can significantly increase processing time and consume significant amounts of computing resources. However, users expect function processing services to run efficiently and quickly. Accordingly, benefits can be realized through technologies to improve the efficiency of a function processing service in a cloud computing system.

The essence of the invention

[0005] In accordance with one aspect of the present disclosure, a computer-implemented method is disclosed that includes receiving, at a function processing service, a request to execute source code. The request is received from the requesting entity. The source code includes instructions for executing the function. The method further includes determining that a hardware acceleration condition has been satisfied for the function, translating instructions in the source code into hardware-dependent code corresponding to the hardware circuit, configuring the hardware circuit based on the hardware-dependent code, causing the hardware circuit to execute the function, and providing the result. , obtained from the hardware circuit, into the requesting object.

[0006] As an example, the hardware circuit may include a field programmable gate array (FPGA), and the hardware-specific code may include hardware description language (HDL) code corresponding to the FPGA. As another example, the hardware circuit may include a graphics processing unit (GPU), and the hardware-dependent code may include GPU code. As another example, the hardware circuit may include a digital signal processor (DSP), and the hardware-dependent code may include the DSP code. As another example, the hardware circuit may include an application specific integrated circuit (ASIC), and the hardware-specific code may include hardware description language (HDL) code.

[0007] Determining that the hardware acceleration condition has been satisfied may include counting the number of requests to perform a function that the function processing service receives during the time interval and determining that the number of requests exceeds a threshold.

[0008] In some embodiments, a function may belong to a family of functions. In such embodiments, determining that a hardware acceleration condition has been satisfied may include counting the number of requests to perform any function in a family of functions that the function processing service accepts during the time interval, and determining that the number of requests exceeds the threshold value.

[0009] In some embodiments, determining that the hardware acceleration condition has been satisfied may include determining an estimated cost reduction associated with executing the function through the hardware circuit compared to executing the function through a general purpose processor, and determining that the estimated cost reduction exceeds the threshold.

[0010] In some embodiments, determining that the hardware acceleration condition has been satisfied may include determining that the function is included in the function library, and may further include adding new functions to the function library.

[0011] In accordance with another aspect of the present disclosure, a computer-implemented method is disclosed that includes determining that a hardware acceleration condition has been satisfied for a first function, configuring a hardware circuit capable of executing the first function, and adding the first function to a library of functions. which is implemented in hardware circuits. The method further includes receiving, at the function processing service, a request to execute the source code. The source code includes instructions for performing the first function. The method further includes causing the first function to be performed via the hardware circuitry.

[0012] In some embodiments, the method may further include configuring the hardware circuit to perform the second function in parallel with the first function. The second function may be different from the first function. In other embodiments, the method may further include configuring the hardware circuit to be capable of executing multiple instances of the hardware circuit in parallel.

[0013] According to another aspect of the present disclosure, a computer-implemented method includes analyzing first statistical information associated with a first set of requests received by a function processing service during a first time interval, configuring a set of hardware circuits to perform the first set of functions during a first time interval based on the first statistical information; and analyzing second statistical information associated with a second plurality of requests received by the function processing service during the second time interval. The second time interval is different from the first time interval. The method further includes configuring a set of hardware circuits to perform a second set of functions during a second time interval based on the second statistical information. The second set of functions is different from the first set of functions.

[0014] The method may further include receiving a first request to execute the first source code. The first request may be received during the first time slot. The first source code may further include first instructions for performing the first function. The first set of functions may include the first function. The method may further include causing a first function to be executed through a first hardware circuit in the set of hardware circuits and receiving a second request to execute the second source code. The second request may be received during the second time slot. The second source code may include second instructions to perform the second function. The second set of functions may include a second function performing the second function during a second time interval through a second hardware circuit in the set of hardware circuits.

[0015] This summary is provided to present in a simplified form a selection of concepts that are further described below in the detailed description. This essence is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in defining the scope of the claimed subject matter.

[0016] Additional features and advantages will be set forth in the description below. The features and advantages of the disclosure may be realized and obtained through systems and methods that are specifically set forth in the appended claims. Features of the present disclosure will become more apparent from the following description and the appended claims or may be learned by practice of the disclosed subject matter as set forth below.

Brief description of drawings

[0017] In order to describe the manner in which the foregoing and other features of the disclosure can be obtained, more detailed description is provided with respect to specific embodiments thereof, which are illustrated in the accompanying drawings. For better understanding, like elements are designated by like numbered references throughout the various accompanying drawings. With the understanding that the drawings illustrate certain exemplary embodiments, the embodiments are described and explained in further particularity and detail with reference to the accompanying drawings, in which:

[0018] FIG. 1 illustrates an example of a function processing service that is configured to selectively use hardware acceleration in accordance with the present disclosure.

[0019] FIG. 2 illustrates aspects of a function processing service that implements a hardware acceleration condition based on the number of requests to execute a function that are accepted.

[0020] FIG. 3 illustrates aspects of a feature processing service that implements a hardware acceleration condition based on the number of requests that are received during a given time interval, with counters being used to keep track of the number of requests that are received in connection with various functions.

[0021] FIG. 4 illustrates aspects of a function processing service that implements a hardware acceleration condition based on the number of requests that are received during a given time interval, with statistical information maintained regarding previous requests that are received.

[0022] FIG. 5 illustrates aspects of a function processing service that implements a hardware acceleration condition based on the number of requests to execute a function that are received in connection with any function in a family of related functions.

[0023] FIG. 6 illustrates aspects of a function processing service that implements a hardware acceleration condition based on the estimated cost savings associated with using hardware acceleration to perform a function.

[0024] FIG. 7 illustrates aspects of a function processing service that maintains a function library, and which implements a hardware acceleration condition based on whether or not a particular function is already included in the function library.

[0025] FIG. 8 illustrates an example of a function processing service for which a plurality of hardware acceleration conditions are specified.

[0026] FIG. 9 illustrates an example of a method that may be implemented by a condition evaluation module in a function processing system.

[0027] FIG. 9A illustrates an example of an alternative method that may be implemented by a condition evaluation module in an embodiment in which the user is provided with the ability to select whether or not hardware acceleration can be performed.

[0028] FIG. 10 illustrates an example of a function processing service that maintains a function library.

[0029] FIG. 11 illustrates an example of a method that can be implemented by the function processing service shown in FIG. 10.

[0030] FIG. 12 illustrates an example of a hardware circuit that is configured to perform two different functions.

[0031] FIG. 13 illustrates an example of a hardware circuit that is configured to perform two different instances of an identical function.

[0032] FIG. 14A-B illustrate an example of a function processing service that periodically reconfigures a set of hardware circuits based on expected demand.

[0033] FIG. 15 illustrates an example of a method that may be implemented by the function processing service of FIG. 14A-B.

[0034] FIG. 16 illustrates certain components that may be included in a computing system.

Detailed Description of the Invention

[0035] The present disclosure generally relates to improving the efficiency of a function processing service in a cloud computing system. In accordance with one aspect of the present disclosure, a function processing service may be configured to selectively use hardware acceleration. More specifically, the function processing service may be configured to use hardware acceleration in order to execute a function when a determination is made as to what should be advantageous to achieve it. This determination may be made based on various factors, such as how frequently requests to perform a function are received, whether or not processing speed may or may not increase by a significant amount, and/or whether or not processing costs may be reduced by a significant amount. size.

[0036] In this context, the term "hardware acceleration" may mean the use of hardware circuitry to perform a function, wherein the hardware circuitry is specifically designed or programmed to perform the function in such a way that the function can be executed faster than if specified in software. software and runs on a general purpose processor. The term "hardware circuit" can generally mean any configuration of electrically or electromagnetically coupled components or devices other than a general purpose processor. The hardware circuit may be an integrated circuit. Some examples of hardware circuits that may be used in accordance with the present disclosure include field programmable gate arrays (FPGAs), graphics processing units (GPUs), digital signal processors (DSPs), and application specific integrated circuits (ASICs).

[0037] There are many different types of functions that can benefit from hardware acceleration. Some examples include data processing, compression or encryption, location tracking, video processing, financial transactions, log analysis, word processing, fast filtering of streaming data, web hosting, machine learning training (e.g. linear regression), inference based on machine learning (for example, image recognition), signal processing (for example, using DSP), etc.

[0038] In some embodiments, one or more conditions may be specified that indicate when hardware acceleration should be used in order to perform a function. Such conditions may be referred to herein as “hardware acceleration conditions.” When a function processing service receives a request to execute source code that includes instructions for executing a function, the function processing service may determine whether or not any of the specified hardware acceleration conditions are satisfied. If at least one hardware acceleration condition is satisfied, then hardware acceleration can be used to perform the function.

[0039] In some embodiments, hardware acceleration may be performed automatically, without the user having to specifically request hardware acceleration or provide hardware-dependent code, such as inter-register transfer logic (RTL) code for the FPGA. For example, a user's request to execute a particular function may take the form of a request to execute source code. The source code is typically written in a high-level programming language such as Java, C++, Python, etc. A function processing system that receives such a request may automatically determine whether or not it should preferentially use hardware acceleration in order to execute the function. If it is determined that hardware acceleration would be beneficial, then the source code can be automatically translated into hardware-dependent code without requiring additional input from the user.

[0040] In some embodiments, before the function processing service uses hardware acceleration to perform a function, the user may be notified of the possibility of using hardware acceleration and be able to select whether or not hardware acceleration can be performed.

[0041] FIG. 1 illustrates an example of a function processing service 102 that is configured to selectively use hardware acceleration in accordance with the present disclosure. The function processing service 102 is shown receiving a request 104 to perform a particular function. However, request 104 is not a request to perform a function through hardware circuitry. Instead, request 104 is to execute source code 106. Request 104 may be received from client device 108. Source code 106 includes instructions 110 that, if executed by general purpose processor 112, instruct a particular function to be executed.

[0042] In the illustrated example, a plurality of hardware acceleration conditions 114 are specified for the function processing service 102 . In addition, the function processing service 102 includes a component that is configured to determine whether or not any of the hardware acceleration conditions 114 are satisfied. This component may be referred to herein as “condition evaluation module 116.”

[0043] In response to receiving request 104, condition evaluator 116 determines whether or not any of the hardware acceleration conditions 114 are satisfied with respect to a function that is specified by instructions 110 in the source code 106. If none of the hardware acceleration conditions 114 are satisfied is satisfied, then the function processing service 102 makes the request 104 by causing instructions 110 on the source code 106 to be executed by the general purpose processor 112.

[0044] However, if at least one of the hardware acceleration conditions 114 is satisfied, then hardware acceleration can be used to perform the function. The function processing service 102 includes a component that is configured to facilitate the use of hardware acceleration. This component may be referred to herein as “hardware acceleration component 124.” Hardware acceleration component 124 may be configured to translate instructions 110 on source code 106 into hardware-dependent code 120 corresponding to hardware circuit 122. After hardware-dependent code 120 has been generated, hardware acceleration component 124 can then configure hardware circuit 122 based on hardware-dependent code 120 and instruct hardware circuit 122 to perform the function. The hardware circuit 122 can then execute the function and generate a particular result 126. The function processing service 102 can then provide this result 126 to the requesting entity, which is the client device 108 in the illustrated example.

[0045] There are many different types of hardware acceleration conditions that can be set in accordance with the present disclosure. For example, the hardware acceleration condition associated with a particular function may be based on how many requests to execute the function are accepted. In some embodiments, the hardware acceleration condition may be specified in terms of a threshold value that specifies the minimum number of requests to perform a particular function that must be accepted to justify the use of hardware acceleration for that function. The number of such requests that are received by the function processing service can then be counted and compared to a threshold. If the number of such requests that are received exceeds the threshold, then the hardware acceleration condition is satisfied and hardware acceleration can be used to execute the function.

[0046] FIG. 2 illustrates aspects of a function processing service 202 that implements a hardware acceleration condition 214 based on the number of requests to execute a function that are accepted.

[0047] Function processing service 202 may define a threshold 228 that specifies the minimum number of requests to execute a particular function that must be accepted to justify using hardware acceleration for the function. The function processing service 202 may also keep track of the number of requests that are received in connection with various functions. In the illustrated embodiment, function processing service 202 uses counters 232 corresponding to a plurality of functions that can be performed by function processing service 202. Fig. 2 shows a function processing service 202 with a counter 232a indicating the number of requests that are received to perform function A, a counter 232b indicating the number of requests that are received to perform function B, and a counter 232c indicating the number of requests that adopted in order to perform the function C.

[0048] The function processing service 202 may also include a component that is configured to update the counters 232 when requests to perform specific functions are received. This component may be referred to herein as the “counter update component 234.” When function processing service 202 receives a request to perform a particular function (eg, function A), counter update component 234 may increment the corresponding counter (eg, function A execution counter 232a).

[0049] The function processing service 202 includes a condition evaluation module 216, which is configured to determine whether the hardware acceleration condition 214 is satisfied or not. The hardware acceleration condition 214 may be set such that hardware acceleration is performed for a particular function if the value of the corresponding counter 232 exceeds a predetermined threshold 228. Thus, when the function processing service 202 receives a request to perform a specific function (for example, function A ), condition evaluator 216 may compare the value of a counter 232 corresponding to the function (eg, function A execution counter 232a) with a threshold value 228. If the value of the corresponding counter 232 exceeds threshold 228, condition evaluator 216 may conclude that hardware acceleration condition 214 is satisfied and hardware acceleration can be used to execute the function. However, if the value of the corresponding counter 232 is less than the threshold value 228, the condition evaluator 216 may conclude that the hardware acceleration condition 214 is not satisfied. If there is no other hardware acceleration condition that has been satisfied for the function, then the function can be executed using a general purpose processor.

[0050] In some embodiments, a hardware acceleration condition may be set such that hardware acceleration is performed for a particular function only if a certain number of requests to execute the function are received within a given time interval. In such embodiments, the function processing service may specify both the threshold value and the relevant time interval. The threshold may specify the minimum number of requests to execute a particular function that must be accepted during a time interval in order to justify the use of hardware acceleration for the function.

[0051] For example, assume that the threshold value is N (where N represents a positive integer) and the time interval is one week. In the event that more than N requests to perform a particular function are received during the same week, then the hardware acceleration condition can be considered to have been satisfied and hardware acceleration can be performed. However, if more than N requests to perform a particular function are accepted, but not within the same week, then we can conclude that the hardware acceleration condition is not satisfied.

[0052] There are various ways in which such a time limit can be implemented. In some embodiments, the function processing service may use counters corresponding to functions that can be executed by the function processing service, and the counters may be reset periodically based on a time interval that is set for the hardware acceleration condition. For example, if the specified time interval is one week, then the counters can be reset once a week.

[0053] In some embodiments, the function processing service may store statistical information that includes information regarding previous requests that were accepted. Information that is stored regarding a particular request may include information identifying the requested function as well as a timestamp indicating when the request was received. In such embodiments, stored statistical information may be queried to determine how many requests to perform a particular function are received during a certain period of time. For example, if a request to perform a particular function is received at time t, statistical information may be requested to determine how many requests to perform that function are received during a time period corresponding to a given time interval (e.g., a given time interval immediately preceding time t). The result of this query can then be compared to a threshold to determine whether the hardware acceleration condition is satisfied or not.

[0054] FIG. 3 illustrates aspects of a function processing service 302 that implements a hardware acceleration condition 314 based on the number of requests that are received during a given time interval 330, with counters 332 being used to keep track of the number of requests that are received in connection with various functions. Fig. 3 shows a function processing service 302 with a counter 332a indicating the number of requests that are received to perform function A, a counter 332b indicating the number of requests that are received to perform function B, and a counter 332c indicating the number of requests that are received in order to perform function C. The function processing service 302 includes a counter update component 334 that is configured to update the counters 332 when requests to perform specific functions are received.

[0055] In the illustrated embodiment, threshold 328 indicates the minimum number of requests to execute a particular function that must be received within a given time interval 330 to justify using hardware acceleration for the function. The counters 332 may be reset periodically based on a time interval 330 that is set for the hardware acceleration condition 314 .

[0056] Function processing service 302 may use timer 336 to keep track of when counters 332 should be reset. In some embodiments, timer 336 may be a countdown timer, and the value of the countdown timer may be set to a predetermined time interval 330 The counters 332 can be reset each time the countdown timer expires. Alternatively, timer 336 may be an up timer, and counters 332 may be reset each time the up timer reaches a value that is equivalent to a predetermined time interval 330.

[0057] When function processing service 302 receives a request to perform a particular function (e.g., function A), condition evaluator 316 may compare the value of a counter 332 corresponding to that function (e.g., function A execution counter 332a) with a threshold value 328 If the value of the corresponding counter 332 exceeds the threshold 328, hardware acceleration can be used to perform the function. However, if the value of the corresponding counter 332 is less than the threshold 328, the function can be executed using a general purpose processor.

[0058] FIG. 4 illustrates aspects of a function processing service 402 that implements a hardware acceleration condition 414 based on the number of requests that are received during a given time interval 430, with statistical information stored regarding previous requests that are received.

[0059] As discussed above, function processing service 402 may define a threshold 428 that specifies the minimum number of requests to execute a particular function that must be received within a given time interval 430 to justify using hardware acceleration for the function.

[0060] Statistical information may be stored in the database 448 . The statistical information may include a plurality of entries 440, and each entry 440 may correspond to a particular request that the function processing service 402 receives. More specifically, each entry 440 may include information identifying the requested function as well as a timestamp indicating when the request was received. Fig. 4 shows statistical information with an entry 440a corresponding to a request to process function A, an entry 440b corresponding to a request to process function B, an entry 440c corresponding to another request to process function A, and an entry 440d corresponding to request to process function C. Records-440a-d include timestamps. The timestamp in a particular entry 440 indicates the time at which the corresponding request was received.

[0061] The function processing service 402 includes a condition evaluation module 416, which is configured to determine whether the hardware acceleration condition 414 is satisfied or not. The condition evaluation module 416 may include a query execution component 446 that allows a query to be made to the database 448 to determine how many requests to perform a particular function are accepted during a certain period of time. For example, if a request to perform a particular function is received at time t, request fulfillment component 446 may query database 448 to determine how many requests to perform that function are received during the time period corresponding a given time interval 430 (eg, a given time interval 430 immediately preceding time t). The result of this query may then be compared to a threshold 428 to determine whether or not the hardware acceleration condition 414 is satisfied.

[0062] Instead of specifying the hardware acceleration condition in terms of a threshold value for a particular function, the hardware acceleration condition may instead be defined in terms of a threshold value for a family of related functions. In other words, the hardware acceleration condition can be set such that each time a request is received to perform any function in a family of related functions, it counts toward satisfying the threshold. If the number of such requests that are received during a time interval exceeds a threshold, then the hardware acceleration condition can be considered to have been satisfied, and hardware acceleration can be used to perform any function in a family of related functions.

[0063] In embodiments in which the hardware acceleration condition is specified in terms of a threshold value for a family of related functions, the hardware acceleration condition may be implemented with or without a time limit. In other words, in some embodiments, the threshold may be set in terms of the total number of requests that are received in connection with any function in a family of related functions, regardless of when those requests are received. Alternatively, in other embodiments, the threshold may be set in terms of the total number of requests that are received in connection with any function in a family of related functions during a given time interval. In embodiments in which a hardware acceleration condition is specified in terms of a threshold value for a family of related functions and a timing constraint is used, the timing constraint may be implemented in a variety of ways, including the methods explained above (eg, as counters and statistics).

[0064] FIG. 5 illustrates aspects of a function processing service 502 that implements a hardware acceleration condition 514 based on the number of requests to execute a function that are received in connection with any function in a family of related functions. For simplicity, timing restrictions are not used in the illustrated embodiment.

[0065] Function processing service 502 may define a threshold 528 that specifies the minimum number of requests to execute any function in a family of related functions that must be accepted to justify the use of hardware acceleration for functions in that family. The feature processing service 502 may also track the number of requests that are received in connection with various feature families. In the illustrated embodiment, function processing service 502 uses counters 532 corresponding to different families of functions that can be performed by function processing service 502. It is assumed that at least two families of functions are specified: (i) a first family of functions which includes function A, function B and function C, and (ii) a second family of functions which includes function D, function E and function F. FIG. 5 shows a function processing service 502 with a first counter 532a and a second counter 532b. The first counter 532a indicates the number of requests that are received to perform any of the functions in the first family of functions (function A, function B, or function C). A second counter 532b indicates the number of requests that are received to perform any of the functions in the second family of functions (function D, function E, or function F).

[0066] The function processing service 502 may also include a counter update component 534 that is configured to update the counters 532 when requests to perform specific functions are received. When function processing service 502 receives a request to perform a particular function, counter update component 534 may incrementally increment the corresponding counter 532. Because counters 532 correspond to specific families of functions, requests to perform different functions may cause an identical counter 532 to be updated. For example, if function processing service 502 receives a request to perform function A, the first counter 532a may be updated because the first counter 532a corresponds to an identical family of functions to which function A belongs. If function processing service 502 then receives the request to perform function B, the first counter 532a may be updated once again because function B belongs to the same family as function A. However, if function processing service 502 then receives a request to perform function D, another counter (specifically, second counter 532b ) can be updated because feature D belongs to a different family than feature A and feature B.

[0067] The function processing service 502 includes a condition evaluation module 516, which is configured to determine whether the hardware acceleration condition 514 is satisfied or not. The hardware acceleration condition 514 may be specified such that hardware acceleration occurs for a particular function if the value of the relevant counter 532 (i.e., the counter 532 corresponding to the family of functions to which the specified function belongs) exceeds a predetermined threshold value 528. Thus, when Function processing service 502 receives a request to perform a specific function (eg, function A), condition evaluator 516 may compare the value of a counter 532 corresponding to the family of functions to which the specified function belongs (eg, first counter 532a) with a threshold value 528 If the value of the corresponding counter 532 exceeds the threshold 528, the condition evaluation module 516 may conclude that the hardware acceleration condition 514 is satisfied, and the hardware acceleration can be used to perform the function. However, if the value of the corresponding counter 532 is less than the threshold 528, the condition evaluator 516 may conclude that the hardware acceleration condition 514 is not satisfied. If another hardware acceleration condition has not been met for a function, the function can be executed using a general purpose processor.

[0068] In some embodiments, the hardware acceleration condition may be based on an estimated cost reduction associated with using hardware acceleration to perform a function compared to executing the function through a general purpose processor. Generally speaking, less power is required to execute a function through hardware acceleration than to execute a function through a general purpose processor. These energy savings can also lead to lower costs. If the cost savings are high enough, then it may justify using hardware acceleration to perform the function.

[0069] In some embodiments, the hardware acceleration condition may be specified in terms of a threshold value that indicates the minimum estimated cost reduction that must justify the use of hardware acceleration. When hardware acceleration is considered for a specific function, the cost savings for using hardware acceleration can be assessed. This estimated cost reduction can then be compared to a threshold value. If the estimated cost reduction exceeds the threshold, then it can be concluded that the hardware acceleration condition has been satisfied and hardware acceleration can be used to perform the function.

[0070] Some examples of factors that may be considered in connection with determining the cost savings for using hardware acceleration include (i) the cost of a general purpose processor per second of execution, (ii) the cost of the energy that is consumed, and (iii) the product of energy and delays. Each of these factors can be weighted independently in a cost model.

[0071] As an example, assume that a basic function requires I instructions and T seconds to complete on a general purpose processor, the processor overhead is C, and the energy required to complete the operation is E joules. Using hardware acceleration, operations can be completed in Ta=T/k1 seconds and use E/k2 joules of energy. In addition, the accelerator time consumption can be C/(k3*Ta). The k1 parameter indicates how much faster the function can be executed using hardware acceleration compared to using a general purpose processor. The k2 parameter indicates how much power can be saved using hardware acceleration compared to using a general purpose processor. The k3 parameter indicates how much less expensive it is to use hardware acceleration compared to using a general purpose processor. The parameters k1, k2 and k3 can be measured for certain operations, and these measurements can be used to estimate these parameters for other operations.

[0072] FIG. 6 illustrates aspects of a function processing service 602 that implements a hardware acceleration condition 614 based on the estimated cost savings associated with using hardware acceleration to perform a function. As discussed above, function processing service 602 may set a threshold 628 that indicates the minimum estimated cost reduction that must justify the use of hardware acceleration.

[0073] The function processing service 602 may include a component that is configured to obtain cost reduction estimates 654 for the use of hardware acceleration in connection with specific functions. This component may be referred to herein as “cost reduction evaluation module 652.” Fig. 6 shows several examples of cost reduction estimates 654, including cost reduction estimate 654a for function A, cost reduction estimate 654b for function B, and cost reduction estimate 654c for function C.

[0074] The function processing service 602 includes a condition evaluation module 616, which is configured to determine whether the hardware acceleration condition 614 is satisfied or not. The hardware acceleration condition 614 may be set such that hardware acceleration is performed for a particular function if the value of the corresponding cost reduction estimate 654 exceeds a predetermined threshold 628. Thus, when the function processing service 602 receives a request to perform a specific function (e.g. function A), the condition evaluation module 616 may compare the value of the cost reduction estimate 654 corresponding to that function (eg, the cost reduction estimate 654a corresponding to function A) with a threshold value 628. If the value of the corresponding cost reduction estimate 654 exceeds the threshold 628, the module Condition evaluation 616 may conclude that hardware acceleration condition 614 is satisfied, and hardware acceleration can be used to perform the function. However, if the value of the corresponding cost reduction estimate 654 is less than the threshold 628, the condition evaluation module 616 may conclude that the hardware acceleration condition 614 is not satisfied. If another hardware acceleration condition has not been met for a function, the function can be executed using a general purpose processor.

[0075] In some embodiments, a library of functions may be maintained. Functions can be added to the function library on an ongoing basis. In this context, the term "function library" may mean a library of functions that are implemented in hardware circuits. In such embodiments, the hardware acceleration condition may be based on whether or not a particular function is already included in the function library. For example, when hardware acceleration is being considered for a particular feature, a determination may be made regarding whether or not that feature is already included in the feature library. If enabled, we can conclude that the hardware acceleration condition has been satisfied and hardware acceleration can be used to perform the function.

[0076] FIG. 7 illustrates aspects of a function processing service 702 that maintains a function library, and which implements a hardware acceleration condition 714 based on whether or not a particular function is already included in the function library.

[0077] In the illustrated embodiment, function processing service 702 maintains a function library index 756 that includes information regarding functions that are currently included in the function library. The function library index 756 may include a plurality of entries 758, and each entry 758 may identify a particular function in the function library as well as hardware circuitry that is configured to perform that function. Fig. 7 shows a function library index 756 with a first entry 758a, a second entry 758b, and a third entry 758c. The first record 758a includes identifying information 764a regarding function A, as well as an identifier 762a corresponding to the first hardware circuit 722a that is configured to perform function A. Likewise, the second record 758b includes identifying information 764b regarding function B, as well as an identifier 762b corresponding to a second hardware circuit 722b that is configured to perform function B. A third entry 758c includes identifying information 764c regarding function C, as well as an identifier 762c corresponding to a third hardware circuit 722c that is configured to perform function C.

[0078] The function processing service 702 includes a condition evaluation module 716, which is configured to determine whether the hardware acceleration condition 714 is satisfied or not. The hardware acceleration condition 714 may be specified such that hardware acceleration is performed on a particular function if that function is already included in the function library. To determine whether or not a particular function is already included in the function library, the condition evaluation module 716 may be configured to determine whether or not identifying information regarding that function is included in the function library index 756 . Thus, when function processing service 702 receives a request to perform a particular function (eg, function A), condition evaluator 716 may search the function library index 756 for identifying information regarding the function (eg, function A identifying information 764a). If condition evaluator 716 finds identifying information regarding the requested function in function library index 756, condition evaluator 716 may conclude that hardware acceleration condition 714 is satisfied and hardware acceleration can be used to execute the function. However, if the condition evaluator 716 does not find identifying information regarding a function in the function library index 756, the condition evaluator 716 may conclude that the hardware acceleration condition 714 is not satisfied. If another hardware acceleration condition has not been met for a function, the function can be executed using a general purpose processor.

[0079] As stated above, functions may be added to the function library on an ongoing basis. In some embodiments, each time hardware acceleration is used to perform a function, the function may be added to the function library provided that there is space to implement the function on available hardware circuits. When available space becomes limited, a function with higher priority (eg, based on usage) can be stored in the function library.

[0080] As stated above, a function processing service may be used to execute source code that includes instructions to perform one or more functions. When a function processing service receives a request to execute source code that includes instructions to perform a particular function, a determination may be made regarding whether or not a hardware acceleration condition is satisfied. In some embodiments, a plurality of hardware acceleration conditions may be specified. In embodiments in which multiple hardware acceleration conditions are specified, hardware acceleration may be used in connection with a particular function if any of the hardware acceleration conditions are satisfied. However, if none of the hardware acceleration conditions are met, the function can be executed using a general purpose processor.

[0081] FIG. 8 illustrates an example of a function processing service 802 for which a plurality of hardware acceleration conditions 814 are specified. For example, hardware acceleration condition 814a is set based on whether or not a particular function is already included in the function library. In the following explanation, this type of hardware acceleration condition 814a may be referred to as a “function library-based hardware acceleration condition 814a.” An example of a function library-based hardware acceleration condition 814a is explained above in connection with FIG. 7.

[0082] In addition, the hardware acceleration condition 814b is set based on the number of requests to execute the function that are accepted. In the following explanation, this type of hardware acceleration condition 814b may be referred to as a “demand-based hardware acceleration condition 814b.” Several examples of demand-based hardware acceleration conditions 814b are explained above in connection with FIG. 2-5. Although only one demand-based hardware acceleration condition 814b is shown in FIG. 8, in some embodiments, more than one demand-based hardware acceleration conditions 814b may be specified.

[0083] In addition, hardware acceleration condition 814c is set based on the estimated cost savings associated with using hardware acceleration to perform the function. In the following explanation, this type of hardware acceleration condition 814c may be referred to as a “cost-based hardware acceleration condition 814c.” An example of cost-based hardware acceleration condition 814c is explained above in connection with FIG. 6.

[0084] The function processing service 802 includes a condition evaluation module 816, which is configured to determine whether or not any of the hardware acceleration conditions 814a-c are satisfied. The function processing service 802 also includes a hardware acceleration component 824 that is configured to facilitate the use of hardware acceleration. Fig. 9 illustrates an example of a method 900 that may be implemented by a condition evaluation module 816 and a hardware acceleration component 824.

[0085] Method 900 includes receiving 902 a request 804 to perform a function. More specifically, condition evaluator 816 may receive a request 804 to execute source code 806, and source code 806 may include instructions 810 that, if executed by general purpose processor 812, instruct a particular function to be executed.

[0086] In response to receiving the request 902, the condition evaluation module 816 may determine whether any of the specified hardware acceleration conditions 814 are satisfied or not. In the illustrated example, condition evaluator 816 initially determines 904 whether hardware acceleration condition 814a is satisfied or not based on the function library. If the condition evaluator 816 determines 904 that the function library-based hardware acceleration condition 814a is satisfied, this means that the hardware circuit 822 is already configured to execute the function. Therefore, method 900 may then include instructing 906 hardware circuit 822 to perform a function.

[0087] However, if the condition evaluator 816 determines 904 that the function library-based hardware acceleration condition 814a is not satisfied, the condition evaluator 816 can then determine whether another of the predetermined hardware acceleration conditions 814 is satisfied or not. In the illustrated example, the condition evaluation module 816 then determines 908 whether or not the hardware acceleration condition 814b is satisfied based on the demand. If demand-based hardware acceleration condition 814b is satisfied, then method 900 may include configuring 910 hardware circuit 822 to perform a function (since it is predetermined, as part of function library-based hardware acceleration condition 814a, that hardware circuit 822 already not configured to perform the function). Method 900 may then include instructing 912 hardware circuit 822 to perform a function.

[0088] However, if the condition evaluator 816 determines 908 that the demand-based hardware acceleration condition 814b is not satisfied, the condition evaluator 816 can then determine whether another of the predetermined hardware acceleration conditions 814 is satisfied or not. In the illustrated example, condition evaluator 816 then determines 914 whether or not hardware acceleration condition 814c is satisfied based on cost. If demand-based hardware acceleration condition 814b is satisfied, then method 900 may include configuring 910 hardware circuit 822 to perform a function and causing 912 hardware circuit 822 to perform the function.

[0089] However, if the condition evaluator 816 determines 914 that the cost-based hardware acceleration condition 814c is not satisfied, this means that none of the predetermined hardware acceleration conditions 814a-c are satisfied. In this case, the method 900 may then include causing the function 916 to be executed using the general purpose processor 812.

[0090] In some embodiments, the function processing service may be configured such that the user (i.e., the person or entity that makes the request(s) to execute the source code) has the ability to choose whether or not to implement hardware acceleration option. When a user submits a request to execute a function to a function processing service, the user typically assumes that the function should be executed using a general purpose processor. In some embodiments, before the function processing service uses hardware acceleration to perform a function, the user may be notified of the possibility of using hardware acceleration and be able to select whether or not hardware acceleration can be performed.

[0091] FIG. 9A illustrates an example of an alternative method 900A that may be implemented by condition evaluation module 816 in an embodiment in which the user is provided with the ability to select whether or not hardware acceleration can be performed. Method 900A is similar to method 900 shown in FIG. 9, except as provided below.

[0092] As stated above, method 900A includes receiving 902 a request 804 to perform a function. However, method 900A also includes determining 903 whether or not the user indicates a preference for using hardware acceleration when it should be preferable to achieve it (eg, when one or more hardware acceleration conditions 814a-c are satisfied). In some embodiments, determining 903 whether or not a user indicates a preference for using hardware acceleration may involve accessing stored information regarding the user's preferences. As another example, determining 903 whether or not the user indicates a preference for using hardware acceleration may involve issuing instructions to the user for authorization to perform hardware acceleration.

[0093] If it is determined 903 that the user does not indicate a preference for using hardware acceleration, then the method 900A may proceed to the act of causing the function 916 to be executed using the general purpose processor 812. However, if it is determined 903 that the user indicates a preference for using hardware acceleration, then the method 900A involves determining whether or not the hardware acceleration conditions 814a-c are satisfied in the manner described above.

[0094] The specific order in which hardware acceleration conditions 814a-c are evaluated in methods 900A shown in FIG. 9 and 9A are provided by way of example only and should not be interpreted as limiting the scope of this disclosure. In alternative embodiments, hardware acceleration conditions 814a-c may be evaluated in a different order. In some embodiments, after a determination is made that a hardware acceleration condition has been satisfied and hardware acceleration is to be used in connection with a function, a determination may be made as to whether or not hardware circuitry has already been configured for the function.

[0095] To configure a hardware circuit to perform a particular function, source code that includes instructions to perform the function may be translated into hardware-specific code corresponding to the type of hardware circuit to be used. For example, if an FPGA is to be used to perform hardware acceleration, then the source code can be translated into hardware description language (HDL) code corresponding to the FPGA. If the GPU is to be used to perform hardware acceleration, then the source code can be translated into GPU code. If a programmable ASIC is to be used to perform hardware acceleration, then a custom compiler can take the source code and generate machine code that is specific to the programmable ASIC. If the DSP is to be used to perform hardware acceleration, then the source code can be translated into DSP code.

[0096] After the source code is translated into hardware-specific code corresponding to the type of hardware circuit to be used, the hardware-specific code can then be provided to the hardware circuit. The function can then be performed through hardware circuitry. The result that is obtained from executing the function can then be provided to an object that requests the function to be executed.

[0097] As stated above, the function processing service may maintain a library of functions. In some embodiments, the function processing service may add a function to the library whenever a determination is made that a hardware acceleration condition corresponding to the function is satisfied. In other words, once a determination is made that a hardware acceleration condition has been satisfied for a particular function, the hardware circuit may be configured to perform that function, and the function may be added to the library. Thereafter, when subsequently receiving a request to execute the source code that includes instructions for executing the function, the function may be executed through the hardware circuit.

[0098] FIG. 10 illustrates an example of a function processing service 1002 that maintains a function library. Fig. 11 illustrates an example of a method 1100 that may be performed by a function processing service 1002 in accordance with the present disclosure. The following describes various components of the function processing service 1002 in connection with the method 1100.

[0099] Method 1100 includes determining 1102 that a hardware acceleration condition 1014 is satisfied for a particular function. This determination may be made by the condition evaluation module 1016 in the function processing service 1002 . In some embodiments, this determination may be made in response to receiving a request to execute the source code. Alternatively, in other embodiments, this determination may be made regardless of receipt of a specific request to execute the source code. For example, function processing service 1002 may determine that a cost-based hardware acceleration condition is satisfied for a particular function before receiving a request to perform that function.

[00100] In response to determination 1102 that a hardware acceleration condition 1014 is satisfied for a particular function, hardware circuitry 1022 may be configured 1104 to perform that function. This operation may be performed by a hardware acceleration component 1024 in the function processing service 1002 . In addition, the function may be added to a function library that is maintained by the function processing service 1002. This may involve adding entry 1058 to function library index 1056. Record 1058 may include identifying information 1064 regarding the function, as well as an identifier 1062 corresponding to hardware circuit 1022 that is configured to perform the function.

[00101] At some point after a function is added to the function library, a request 1004 may be received 1108 to execute the function. More specifically, a request 1004 to execute source code 1006 may be accepted. Source code 1006 may include instructions 1010 that, when executed by general purpose processor 1012, instruct functions to be executed.

[00102] In response to receiving request 1004, function processing service 1002 may instruct functions 1110 to be executed through hardware circuit 1022. This may include providing input data to hardware circuit 1022 as well as instructions to begin processing the input data. In some embodiments, function processing service 1002 may instruct functions 1110 to be executed through hardware circuitry 1022 in response to receiving a request 1004 and determining that the function is included in a function library that is maintained by function processing service 1002. Alternatively, in other embodiments, function processing service 1002 may instruct functions 1110 to be executed through hardware circuit 1022 in response to receiving request 1004, determining that the function is included in a library of functions that is maintained by function processing service 1002, and determining that at least one additional condition for hardware acceleration is satisfied (eg, that the user expresses a preference for hardware acceleration).

[00103] In some embodiments, the hardware circuit may be configured to perform multiple functions in parallel. For example, the hardware circuit may be configured to perform many different functions in parallel with each other. Fig. 12 illustrates an example of hardware circuit 1222 that is configured to perform two different functions, Function A and Function B, in parallel with each other. Specifically, the first section 1266a of the hardware circuit 1222 is configured to perform function A, and the second section 1266b of the hardware circuit 1222 is configured to perform function B.

[00104] There are various scenarios in which such hardware circuit 1222 may be used. As an example, assume that function processing service 1202 receives multiple requests 1204a-b to execute source code 1206a-b. Source code 1206a in first request 1204a may include instructions 1210a that, if executed by a general purpose processor, instruct functions A to be executed. Source code 1206b in second request 1204b may include instructions 1210b that, if executed by a general purpose processor, instruct functions B to be executed. Requests 1204a-b may be received substantially simultaneously, and/or function processing service 1202 may attempt to process requests 1204a-b substantially simultaneously. In response to determining, through condition evaluation module 1216, that at least one hardware acceleration condition 1214 is satisfied for both function A and function B, hardware acceleration component 1224 in function processing service 1202 may instruct hardware circuitry 1222 to perform both function A and function B in parallel. In particular, the function processing service 1202 may cause the first section 1266a of the hardware circuit 1222 to perform function A and the second section 1266b of the hardware circuit 1222 to perform function B.

[00105] Although the example shown in FIG. 12 shows the parallel execution of only two different functions, this should not be interpreted as limiting the scope of the present disclosure. More than two functions may be executed in parallel in accordance with the present disclosure. In general, there may be N pipelines running in parallel (wherein the term "pipeline" means a section of hardware circuitry that is configured to perform a particular function, and wherein N can be any positive integer). These N pipelines can be configured to perform up to N different functions in parallel.

[00106] As another example, hardware circuitry may be configured to execute multiple different instances of an identical function in parallel with each other. Fig. 13 illustrates an example of hardware circuit 1322 that is configured to execute two instances of an identical function in parallel with each other. Specifically, a first section 1366a of the hardware circuit 1322 is configured to execute a first instance of a function, and a second section 1366b of a hardware circuit 1322 is configured to execute a second instance of a function.

[00107] The following describes an example that is similar to the example explained above in connection with the hardware circuit 1222 shown in FIG. 12. Assume that function processing service 1302 receives multiple requests 1304a-b to execute source code 1306a-b. Additionally, assume that the source code 1306a-b in both requests 1304a-b includes instructions-1310a-b that, if executed by the general purpose processor 1312, instruct a particular function to be executed. Requests 1304a-b may be received substantially simultaneously, and/or function processing service 1302 may attempt to process requests 1304a-b substantially simultaneously. In response to determining, through condition evaluation module 1316, that at least one hardware acceleration condition 1314 has been satisfied for a function, hardware acceleration component 1324 in function processing service 1302 may cause hardware circuitry 1322 to execute two different instances of the function in parallel. In particular, the function processing service 1302 may cause the first section 1366a of the hardware circuit 1322 to execute the first instance of the function and the second section 1366b of the hardware circuit 1322 to execute the second instance of the function.

[00108] Although the example shown in FIG. 13 shows the parallel execution of only two instances of the function, this should not be interpreted as a limitation on the scope of the present disclosure. More than two instances of a particular function may be executed in parallel in accordance with the present disclosure. In general, there may be N pipelines running in parallel (wherein the term "pipeline" means a section of hardware circuitry that is configured to perform a function, and wherein N can be any positive integer). These N pipelines can be configured to execute up to N instances of a function in parallel.

[00109] According to another aspect of the present disclosure, hardware acceleration may be used in connection with various functions during various time intervals. In other words, a particular set of hardware circuits can be periodically reconfigured to perform different functions. This may be advantageous in a scenario in which the function processing service has a specific set of hardware circuits available for use, and the function processing service accepts different types of requests at different times (eg, at different times of the day). In this case, a set of hardware circuits may be configured to perform one set of functions during one particular time interval (for example, during one part of the day) and perform a different set of functions during a different time interval (for example, during another part of the day) .

[00110] To identify functions that should use hardware acceleration during a particular time interval, statistical information may be analyzed regarding requests that were previously received by the function processing service during that time interval. If this analysis indicates that requests to perform a particular set of functions are frequently received during this time interval, then the available set of hardware circuits may be configured to perform that set of functions.

[00111] FIG. 14A-B illustrate an example of a function processing service 1402 that periodically reconfigures a set of hardware circuits 1422 based on expected demand. Fig. 15 illustrates an example of a method 1500 that may be performed by a function processing service 1402 in accordance with the present disclosure. The following describes various components of the function processing service 1402 in connection with the method 1500.

[00112] For simplicity, only two different time intervals are specified in the function processing service 1402 shown in FIG. 14A-B. In some embodiments, the time slots may be non-overlapping time slots such that the first time slot does not overlap with the second time slot. In other embodiments, the time slots may at least partially overlap each other. Different time intervals may correspond to different parts of an identical day, week, month, etc.

[00113] Method 1500 includes analyzing 1502 statistical information 1468a associated with requests received during a first time slot. The function processing service 1402 is shown with a query analyzer 1474, which is configured to analyze statistical information 1468a. The analysis 1502 of the statistical information 1468a may include identifying the types of requests that are received most frequently during the first time slot. Based on the analysis of this statistical information 1468a, the first set of functions can be identified as functions that are executed most frequently during the first time interval and that can benefit from hardware acceleration. Method 1500 then includes configuring 1504, through hardware acceleration component 1424 in function processing service 1402, available hardware circuits 1422 to perform the first set of functions during the first time interval. Fig. 14A shows hardware circuits 1422 in a first configuration 1472a, in which hardware circuits 1422 are configured to perform a first set of functions.

[00114] Suppose that function processing service 1402 receives a request 1404a during a first time slot to execute source code 1406a that includes instructions 1410a for executing a function in the first function set. As discussed above, hardware circuits 1422 are configured to perform a first set of functions during a first time slot. Therefore, function processing service 1402 may cause functions to be executed by one of the available hardware circuits 1422 that is configured to perform the relevant function.

[00115] Method 1500 also includes analyzing 1506 statistical information 1468b associated with requests received during the second time slot. This may include identifying the types of requests that are received most frequently during the second time slot. Based on analysis of this statistical information 1468b, a second set of functions may be identified as functions that execute most frequently during the second time slot and that may benefit from hardware acceleration. Method 1500 then includes configuring 1508, through hardware acceleration component 1424, available hardware circuits 1422 to perform a second set of functions during a second time interval.

[00116] Assume that function processing service 1402 receives a request 1404b during a second time slot to execute source code 1406b that includes instructions 1410b to execute a function in a second function set. As discussed above, hardware circuits 1422 are configured to perform a second set of functions during a second time slot. Therefore, function processing service 1402 may cause functions to be executed by one of the available hardware circuits 1422 that is configured to perform the relevant function.

[00117] One or more computing systems may be used to implement a function processing service as disclosed herein. Fig. 16 illustrates certain components that may be included in the computing system 1600.

[00118] The computing system 1600 includes a processor 1601. The processor 1601 may be a single-chip or multi-chip general purpose microprocessor (e.g., a RISC (reduced instruction set computer) (ARM) microprocessor), a special purpose microprocessor ( e.g. digital signal processor (DSP), microcontroller, programmable gate array, etc. The processor 1601 may be referred to as a "central processing unit (CPU)." Although only one processor 1601 is shown in the computing system 1600 of FIG. 16, in an alternative configuration, a combination of processors (eg, ARM and DSP) may be used.

[00119] The computing system 1600 also includes a storage device 1603 in electronic communication with the processor 1601. The storage device 1603 may be any electronic component capable of storing electronic information. For example, storage device 1603 may be implemented as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, embedded storage included in processor 1601 , erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), registers, etc., including combinations of the above.

[00120] Instructions 1605 and data 1607 may be stored in memory 1603. Instructions 1605 may be executed by processor 1601 to implement some or all of the methods, steps, operations, acts, or other functionality that are disclosed herein. Execution of instructions 1605 may involve the use of data 1607 that is stored in memory 1603. Unless otherwise noted, any of the various example modules and components described herein may be implemented, in part or in whole, as instructions 1605 stored in memory 1603 and executed by processor 1601. Any of the various examples of data described herein may be among the data 1607 that is stored in memory 1603 and used during execution of instructions 1605 by processor 1601.

[00121] The computing system 1600 may also include one or more communication interfaces 1609 for exchanging data with other electronic devices. Communication interface(s) 1609 may be based on wired communication technology, wireless communication technology, or both technologies. Some examples of communication interfaces 1609 include a universal serial bus (USB) interface, an Ethernet adapter, a wireless adapter that operates in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 1602.11 wireless communication protocol, a Bluetooth® wireless adapter, and a port infrared (IR) communications.

[00122] The computing system 1600 may also include one or more input devices 1611 and one or more output devices 1613. Some examples of input devices 1611 include a keyboard, mouse, microphone, remote control, button, joystick, trackball, touchpad, and light pen. One particular type of output device 1613 that is typically included in the computing system 1600 is a display device 1615. Display devices 1615 used with the embodiments disclosed herein may use any suitable image projection technology, such as liquid crystal display (LCD), light emitting diode (LED), gas plasma, electroluminescence, and the like. A display controller 1617 may also be provided to convert data 1607 stored in the storage device 1603 into text, graphics, and/or moving images (as appropriate) displayed on the display device 1615. The computing system 1600 may also include other types of output devices 1613, such as a speaker, printer, etc.

[00123] The various components of the computing system 1600 may be interconnected via one or more buses, which may include a power supply bus, a control signal bus, a status signal bus, a data bus, etc. For clarity, various tires are illustrated in FIG. 16 as a 1619 bus system.

[00124] The technologies described herein may be implemented in hardware, software, firmware, or any combination thereof, unless specifically described as being implemented in a particular manner. Any features described as modules, components, and the like may also be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. When implemented in software, the technologies may be implemented at least in part through a non-transitory computer-readable medium storing computer-executable instructions that, when executed by at least one processor, perform some or all of the steps, operations, actions, or other functionality disclosed in this document. Instructions can be organized into procedures, programs, objects, components, data structures, etc., which can perform specific tasks and/or implement specific data types, and which can be combined or distributed as desired in various embodiments.

[00125] The steps, operations and/or actions of the methods described herein may be interchanged with each other without departing from the scope of the claims. In other words, if a particular order of steps, operations and/or actions is not required for proper operation of the method that is described, the order and/or use of the specific steps, operations and/or actions may be modified without departing from the scope of the claims.

[00126] In the example, the term "determining" (and its grammatical variations) encompasses a wide range of actions, and as such, "determining" may include computing, calculating, processing, retrieving, examining, searching (e.g., searching in table, database or other data structure), identification, etc. In addition, "sensing" may include receiving (eg, receiving information), accessing (eg, accessing data in a storage device), and the like. In addition, "determining" may include allowing, selecting, selecting, establishing, and the like.

[00127] The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements other than the listed elements may be provided. Additionally, it should be understood that references to “one embodiment” or “an embodiment” of the present disclosure are not intended to be interpreted as precluding the existence of additional embodiments that also include the set forth features. For example, any element or feature described with respect to an embodiment herein may be combined with any element or feature of any other embodiment described herein if compatible.

[00128] The present disclosure may be embodied in other representative forms without departing from the spirit or characteristics. The described embodiments are to be considered illustrative and not limiting. Accordingly, the scope of the disclosure is indicated by the appended claims rather than by the above description. Changes that fall within the meaning and scope of the claims must be covered by its scope.

Claims (61)

1. A computer-implemented method of configuring hardware to perform a function, comprising the steps of: - receiving, at a function processing service, a request to execute the source code, wherein the request is received from a requesting entity, and wherein the source code contains instructions for executing the function; - determining that the hardware acceleration condition has been satisfied for the function, wherein determining that the hardware acceleration condition has been satisfied comprises counting the number of requests corresponding to one or more functions and received by the function processing service during the time interval, and determining that this number of requests exceeds the threshold value; - translate instructions in the source code into hardware-dependent code corresponding to the hardware circuit; - configuring the hardware circuit based on the hardware-dependent code; - instructing the hardware circuit to perform the function; And - provide the result obtained from the hardware circuit to the requesting entity. 2. The computer-implemented method according to claim 1, in which: - the hardware circuit contains a field programmable gate array (FPGA); And - Hardware-specific code contains hardware description language (HDL) code corresponding to the FPGA. 3. The computer-implemented method of claim 1, wherein: - the hardware circuit contains at least one of a graphics processing unit (GPU) or a digital signal processor (DSP); And - the hardware-dependent code contains at least one of GPU code or DSP code. 4. The computer-implemented method of claim 1, wherein: - the hardware circuit contains an application-specific integrated circuit (ASIC); And - hardware-dependent code contains code in hardware description language (HDL). 5. The computer-implemented method of claim 1, wherein: a function belongs to a family of functions; requests corresponding to one or more functions are requests to perform any function from a family of functions. 6. The computer-implemented method of claim 1, wherein determining that the hardware acceleration condition has been satisfied further comprises the steps of: - determine the estimated cost reduction associated with executing the function through hardware circuitry compared to executing the function through a general purpose processor; And - determine that the estimated cost reduction exceeds a threshold value. 7. The computer-implemented method of claim 1, wherein the requests corresponding to the one or more functions are requests to perform the function. 8. A computer-implemented method of configuring hardware to perform a function, comprising the steps of: - receiving, at a function processing service, a request to execute the source code, wherein the request is received from a requesting entity, and wherein the source code contains instructions for executing the function; - determining that the hardware acceleration condition has been satisfied for the function, wherein determining that the hardware acceleration condition has been satisfied comprises determining the estimated cost reduction associated with executing the function through the hardware circuit compared to executing the function through a general purpose processor, and determining that the estimated cost reduction exceeds a threshold; - translate instructions in the source code into hardware-dependent code corresponding to the hardware circuit; - configuring the hardware circuit based on the hardware-dependent code; - instructing the hardware circuit to perform the function; And - provide the result obtained from the hardware circuit to the requesting entity. 9. The computer-implemented method of claim 8, wherein: - the hardware circuit contains a field programmable gate array (FPGA); And - Hardware-specific code contains hardware description language (HDL) code corresponding to the FPGA. 10. The computer-implemented method of claim 8, wherein: - the hardware circuit contains at least one of a graphics processing unit (GPU) or a digital signal processor (DSP); And - the hardware-dependent code contains at least one of GPU code or DSP code. 11. The computer-implemented method of claim 8, wherein: - the hardware circuit contains an application-specific integrated circuit (ASIC); And - hardware-dependent code contains code in hardware description language (HDL). 12. The computer-implemented method of claim 8, further comprising obtaining a plurality of different estimated cost savings for a plurality of different functions. 13. The computer-implemented method of claim 8, wherein the threshold value indicates the minimum estimated cost reduction that justifies the use of hardware acceleration. 14. A computer-implemented method of configuring hardware circuitry to perform a function, comprising the steps of: - receiving, at a function processing service, a request to execute the source code, wherein the request is received from a requesting entity, and wherein the source code contains instructions for executing the function; - determining that the hardware acceleration condition has been satisfied for the function, wherein determining that the hardware acceleration condition has been satisfied comprises determining that the function is included in the function library; - translate instructions in the source code into hardware-dependent code corresponding to the hardware circuit; - configuring the hardware circuit based on the hardware-dependent code; - instructing the hardware circuit to perform the function; - provide the result obtained from the hardware circuit to the requesting entity; And - add an additional function to the function library. 15. The computer-implemented method of claim 14, wherein: - the hardware circuit contains a field programmable gate array (FPGA); And - Hardware-specific code contains hardware description language (HDL) code corresponding to the FPGA. 16. The computer-implemented method of claim 14, wherein: - the hardware circuit contains at least one of a graphics processing unit (GPU) or a digital signal processor (DSP); And - the hardware-dependent code contains at least one of GPU code or DSP code. 17. The computer-implemented method of claim 14, wherein: - the hardware circuit contains an application-specific integrated circuit (ASIC); And - hardware-dependent code contains code in hardware description language (HDL). 18. The computer-implemented method of claim 14, wherein the additional function is a function for which the source code contains instructions for execution. 19. The computer-implemented method of claim 14, wherein the additional function is a new function that is different from the function for which the source code contains instructions to execute. 20. The computer-implemented method of claim 14, further comprising maintaining a function library index that contains a plurality of entries, each entry identifying a particular function in the function library and a particular hardware circuit that has been configured to perform that particular function.

Images