Patent Description:
The present description generally relates to compiling neural network model source code for execution on a target platform, including compiling neural network model source code for execution on a specialized processor, such as a resource-constrained processor.

Software engineers and scientists have been using computer hardware for machine learning to make improvements across different industry applications including image classification, video analytics, speech recognition and natural language processing, etc. Notably, neural networks are being utilized more frequently to create systems that can perform different computing tasks based on training from sizable amounts of data.

<CIT> discloses a method comprising accessing a data processing architecture associated with a neural network to determine dependencies between intermediate data layers of the neural network; obtaining dimensions of the intermediate data layers in the neural network; calculating a minimum number of data storage portions for executing the neural network based on the dependencies; determining a memory allocation size for each respective data storage portion of the data storage portions based on the dimensions and dependencies; allocating memory on a storage device for each data storage portion in accordance with its respective determined memory allocation size.

Machine learning has seen a meteoric rise in popularity in recent years due to the availability of massive amounts of training data, and advances in more powerful and efficient computing hardware. A common approach is utilizing a graphical processing unit (GPU) for training a deep neural network, and also for executing the deep neural network on new input data post-training. Moreover, as discussed further below, specialized, custom, and/or dedicated hardware, such as low-power specialized processors that may be always powered on (e.g., to detect audio triggers, collect and process sensor data from integrated accelerometers, gyroscopes and compasses, and the like), may be provided to perform certain operations in a more computationally and/or power efficient manner. However, when deploying a given deep neural network for execution on a target platform and/or target processor on the target platform, depending on the available hardware, resource constraints (e.g., memory and/or computing) can be encountered that may limit the execution of a given neural network. For example, to enable deployment of a neural network model on a specialized processor that has less computing power than a main processor (e.g., CPU) may require modifications to the neural network model that make it compatible with the architecture of the specialized processor. Without such modifications, the neural network model, when running on the specialized processor, can require usage of another processor, such as the CPU, in order to perform some of operations of the neural network model resulting in further consumption of power/memory/computing resources.

Moreover, as discussed further herein, a given electronic device may include a specialized processor that may be always powered on and/or in an active mode, e.g., even when a host/application processor of the device is in a low power mode or in an instance where such an electronic device does not include a host/application processor (e.g., a CPU and/or GPU). Such a specialized processor may be a low computing power processor that is engineered to also utilize less energy than the CPU or GPU, and also is designed, in an example, to be running continuously on the electronic device in order to collect audio and/or sensor data. In an example, such a specialized processor can be an Always On Processor (AOP), which is a small and low power auxiliary processor that is implemented as an embedded motion coprocessor, as provided in an electronic device such as an iPhone® or AirPods®. In existing solutions, running a machine learning model on such a low computing power specialized processor was not feasible due to incompatibility with the structural and/or operational requirements of running the machine learning model (e.g., which may require the additional computing power of a CPU or GPU and/or memory requirements).

Implementations of the subject technology described herein reduce the memory footprint of a neural network by providing code that reuses memory portions as well as allocates all memory at compile time, e.g., before the neural network is run, based on the resource constraints of the given target device/specialized processor. Further, the performance of the neural network may improve by avoiding using dynamic memory allocation and deallocation techniques, which are often performed during running of the neural network model. Additionally, some processors may not allow for or may not feasibly perform dynamic memory allocations, such as some specialized processors provided on a given electronic device. Thus, the subject technology described herein enables a neural network to be run on such specialized, e.g. resource-constrained, processors. These benefits therefore are understood as improving the computing functionality of a given electronic device, such as an end user device which may generally have less computational resources available than, e.g., one or more cloud-based servers.

<FIG> illustrates an example network environment <NUM> for in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

The network environment <NUM> includes a wireless audio output device <NUM>, an electronic device <NUM>, an electronic device <NUM>, and a server <NUM>. The network <NUM> may communicatively (directly or indirectly) couple the electronic device <NUM> and/or the server <NUM>, the electronic device <NUM> and/or the server <NUM>, and/or electronic device <NUM> and/or the electronic device <NUM>. In one or more implementations, the network <NUM> may be an interconnected network of devices that may include, or may be communicatively coupled to, the Internet. In <FIG>, the wireless audio output device <NUM> is illustrated as not being directly coupled to the network <NUM>; however, in one or more implementations, the wireless audio output device <NUM> may be directly coupled to the network <NUM>. For explanatory purposes, the network environment <NUM> is illustrated in <FIG> as including the wireless audio output device <NUM>, the electronic device <NUM>, the electronic device <NUM>, and the server <NUM>; however, the network environment <NUM> may include any number of electronic devices and any number of servers.

The wireless audio output device <NUM> may be, for example, a wireless headset device, one or more wireless earbuds, a smart speaker, or generally any device that includes audio output circuitry and one or more wireless interfaces, such as near-field communication (NFC) radios, WLAN radios, Bluetooth radios, Zigbee radios, and/or other wireless radios. In <FIG>, by way of example, the wireless audio output device <NUM> is depicted as a set of wireless earbuds. The wireless audio output device <NUM> may be, and/or may include all or part of the electronic system discussed below with respect to <FIG>. The wireless audio output device <NUM> may be paired, such as via Bluetooth, with one or more of the electronic devices <NUM> and/or <NUM>. In an implementation, the wireless audio output device <NUM> may not include a main processor such as a CPU and/or a GPU and instead only may include a specialized processor as discussed further below in <FIG>.

The electronic device <NUM> may be, for example, desktop computer, a portable computing device such as a laptop computer, a smartphone, a peripheral device (e.g., a digital camera, headphones), a tablet device, a wearable device such as a watch, a band, and the like. In <FIG>, by way of example, the electronic device <NUM> is depicted as a desktop computer. The electronic device <NUM> may be, and/or may include all or part of, the electronic system discussed below with respect to <FIG>.

In one or more implementations, the electronic device <NUM> may provide a system for transforming neural network models into code in a particular programming language (e.g., C code) as described herein. In particular, the subject system may include a neural network compiler for compiling the code. In an example, the subject system, using the compiled code, can create an executable software package for deployment on a target platform, such as the electronic device <NUM>, with facilitation from the server <NUM>. When executing the compiled code, the target platform can perform a given operation(s) of the neural network model on a specialized processor provided on the target platform.

The electronic device <NUM> may be, for example, a portable computing device such as a laptop computer, a smartphone, a peripheral device (e.g., a digital camera, headphones), a tablet device, a wearable device such as a watch, a band, and the like, or any electronic device. The electronic device may further include processors having different compute capabilities, including, for example, a CPU, a GPU, a neural processor and/or a specialized processor. In <FIG>, by way of example, the electronic device <NUM> is depicted as a smartphone device. In one or more implementations, the electronic device <NUM> may be, and/or may include all or part of, the electronic device discussed below with respect to the electronic system discussed below with respect to <FIG>.

In one or more implementations, the server <NUM> deploys the compiled code included in an executable software package to a target device for execution. In one or more implementations, the server <NUM> may transmit the executable software package to an intermediate device, such as the electronic device <NUM>, for deployment on a target device, such as the wireless audio output device <NUM>. The wireless audio output device <NUM>, in an example, may be a target device for receiving the software package with the compiled neural network code and for executing the compiled code in a runtime environment of the wireless audio output device <NUM>. As described further herein, the subject technology advantageously enables the wireless audio output device <NUM> to run the compiled neural network code without utilizing a framework. A framework can refer to a software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications.

<FIG> illustrates an example software architecture for generating code for neural networks for execution on a specialized processor in accordance with one or more implementations. For explanatory purposes, the software architecture is described as being provided by the electronic device <NUM> of <FIG>, such as by a processor and/or memory of the electronic device <NUM>; however, the software architecture may be implemented by any other electronic device. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

As illustrated, the software architecture includes a machine learning (ML) framework <NUM> that includes a code generator <NUM>, and a neural network compiler <NUM>. A memory <NUM> includes neural network model document files <NUM>. In an example, each of the neural network model document files <NUM> can at least include information that represents a set of operations that are to be performed by corresponding nodes from different layers of a given neural network model. Further, information including descriptions of input and output feature(s), data structures, and feature types may be included in a given neural network model document file.

The code generator <NUM> can take a NN model document file from the neural network model document files <NUM> and transform the NN model document file into code in a particular programming language to execute, once compiled, on a specialized processor of a target device. The neural network compiler <NUM> takes the generated code from the code generator <NUM> and compiles the code into a neural network binary executable, which can be stored in neural network executables <NUM> and then be deployed to one or more different target devices for execution (e.g., the wireless audio output device <NUM>). Although the code generator <NUM> is shown as being separate from the neural network compiler <NUM> for purposes of explanation, in at least one implementation, the code generator <NUM> may be part of the neural network compiler <NUM> such that the neural network compiler <NUM> can transform a given network model file and generate code in a particular programming language that is subsequently compiled by the neural network compiler <NUM>.

Although the neural network compiler <NUM> is provided on the electronic device <NUM> in the example of <FIG>, in some implementations, such a compiler may be provided on a particular electronic device that compiles code for a neural network model and executes the compiled neural network model on the same device.

As discussed above, a neural network model can be compiled for a specific target platform and then deployed to a different device such as the wireless audio output device <NUM> for execution.

As illustrated, wireless audio output device <NUM> includes a system-on-chip (SOC) <NUM>. The SOC <NUM> includes a host processor <NUM>, and a specialized processor <NUM>. The host processor <NUM> may include suitable logic, circuitry, and/or code that enable processing data and/or controlling operations of the wireless audio output device <NUM>. In this regard, the host processor <NUM> may be enabled to provide control signals to various other components of the wireless audio output device <NUM>, respectively. Additionally, the host processor <NUM> may enable implementation of an operating system or otherwise execute code to manage operations of the wireless audio output device <NUM>. In an implementation, the specialized processor <NUM> is a processor that is considered "always on" and continuously runs on the wireless audio output device <NUM>. In this implementation, certain machine learning applications can advantageously execute on the specialized processor <NUM> such as for predicting the movement of a person based on sensor data, detecting voice spoken voice triggers, among other types of machine learning applications. In an example, the specialized processor <NUM> may be utilized to execute operations from a compiled neural network model. In one or more implementations, wireless audio output device <NUM> may communicate directly with the server <NUM>. In one or more implementations, the wireless audio output device <NUM> may only include the specialized processor <NUM> (e.g., exclusive of the host processor <NUM>).

As further illustrated, the electronic device <NUM>, in an implementation, includes a system-on-chip (SOC) <NUM>. The SOC <NUM> includes a specialized processor <NUM>, a CPU <NUM>, and a GPU <NUM>, and a neural processor <NUM>, which may be utilized to execute operations from a compiled neural network model. In an implementation where the specialized processor <NUM> is a processor that is considered "always on" and continuously runs on the electronic device <NUM>, certain machine learning applications can advantageously execute on such a specialized processor such as for predicting the movement of a person based on sensor data, detecting voice spoken voice triggers, among other types of machine learning applications.

As discussed further herein, the code generator <NUM> can generate corresponding code based on a given neural network model file from the neural network model document files <NUM>, which can be compiled by the neural network compiler <NUM> for execution solely on the specialized processor <NUM> provided by the wireless audio output device <NUM>.

A CPU, as discussed herein, can refer to a main processor in a given electronic device that performs operations for basic arithmetic, logical, control and input/output operations specified by the instructions of a computer program or application, including some operations for neural network models. A GPU, as discussed herein, can refer to a specialized electronic circuit designed to perform operations for rendering graphics, which is also being utilized in many instances to process computational workloads for machine learning operations (e.g., as specified by instructions of a computer program or application). The CPU, GPU, neural processor, and specialized processor may each have different computational specifications and capabilities depending on their respective implementations where each of the aforementioned components can provide varying degrees of performance for certain operations in comparison with the other components.

Recently, specialized (e.g., dedicated) hardware has been developed that is optimized for performing particular operations from a given NN. A given electronic device may include a neural processor, which can be implemented as circuitry that performs various machine learning operations based on computations including multiplication, adding and accumulation. Such computations may be arranged to perform, for example, convolution of input data. A neural processor, in an example, is specifically configured to perform machine learning algorithms, typically by operating on predictive models such as NNs. In one or more implementations, an electronic device may include a specialized processor and/or a neural processor in addition to a CPU and/or a GPU.

<FIG> illustrates an example model format of data for an existing NN model document file and corresponding NN model code in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided.

As discussed herein, a neural network (NN) is a computing model that uses a collection of connected nodes to process input data based on machine learning techniques. Neural networks are referred to as networks because they may be represented by connecting together different operations. A model of a NN (e.g., feedforward neural network) may be represented as a graph representing how the operations are connected together from an input layer, through one or more hidden layers, and finally to an output layer, with each layer including one or more nodes, and where different layers perform different types of operations on respective input. It is appreciated, however, that other types of neural networks are contemplated by the implementations described herein. For example, a convolutional neural network (CNN) may be provided for execution on a given specialized processor. Further, a NN as mentioned herein can also refer to a deep neural network corresponding to a neural network with multiple hidden layers. The number of layers and the number of nodes per layer may be set as part of the neural network architecture. The settings (e.g., number of layers, connections between nodes of layers, etc.) for the architecture of a neural network are also referred to as hyperparameters.

As mentioned above, an existing NN model (e.g., a given NN model document file) may be converted to code in a programming language and compiled as a binary for deployment on a target platform, such as the wireless audio output device <NUM>. As illustrated, a NN model document file <NUM> represents an existing NN model with information in a different format from the programming language. In an example, the NN model document file may conform to a particular model specification. The NN model document file <NUM> may include NN data types <NUM> of NN data (e.g., input features, output values, etc.), and information for one or more NN layers <NUM>. The NN data types <NUM> may include information for data types or data structures (e.g., vector, matrix, array, etc.). The NN layers <NUM> include information regarding the structure of the NN model such as a number of layers and a number of nodes per layer, connections between nodes of layers, and functions or operations that are performed at each of the nodes in the layers of the NN model. In an example, each layer in the NN layers <NUM> includes a name, a layer type (e.g., input layer, convolutional layer, pooling layer, rectified linear unit layer, and fully connected layer), a list of input names, a list of output names, and a collection of parameters specific to the layer type.

The converted NN model code <NUM> includes code, in a particular programming language (e.g., C) representing the aforementioned information from the NN model document file <NUM>. For example, the converted NN model code <NUM> includes operations <NUM>, memory allocations <NUM>, data formats <NUM> and data layers <NUM>. The operations <NUM> correspond to respective operations performed at each layer of the NN. In an example, the operations <NUM> may include code, for each layer of the NN, of a respective function call for performing an operation and/or a set of parameters for the function call. The data formats <NUM> (e.g., data blobs, arrays, array of arrays, matrices) may correspond to code corresponding to the NN data types <NUM> and/or include code for specifying a compatible binary format for NN data that is to utilized by a given specialized processor of a target platform (e.g., the wireless audio output device <NUM>). The data layers <NUM> may correspond to code for each layer of the NN, and the memory allocations <NUM> correspond to code for allocating memory portions based on a determined size of each layer of the NN and/or based on an amount of memory available at the target device. Determining a respective size of each layer of the NN is discussed in more detail further below in <FIG>.

When analyzing a NN model document file, the code generator <NUM> performs various optimizations in order to generate code that is smaller and that may run more efficiently on a specialized processor such as a resource-constrained processor. The code generator <NUM>, when analyzing the NN model document file, performs an operation fusion optimization in which multiple operations are combined into the same code segment or function call. For example, the code generator <NUM> can perform a vertical fusion optimization in which multiple operations (e.g., <NUM> to <NUM> operations) are combined. For example, a set of given operations may be denoted as the following:.

The code generator <NUM> can determine that if the result of the operations (<NUM>) and/or (<NUM>) are not used by other operations (or layers), then the code generator <NUM> can combine the aforementioned operations into a single combined operation, as denoted by the following:
(<NUM>) A = convolution of ReLU of X.

The code generator <NUM> may further perform a graph coloring optimization on the NN model document file. Graph coloring, as referred to herein, refers to an optimization for memory allocation of layers of the neural network that involves, in an example, determining which memory allocations are reused by the layers. An example of a memory allocation technique is described in further detail in <FIG> below.

In an implementation, the code generator <NUM> can further generate code for debugging purposes including, for example, data for testing the network and/or a set of compilation flags and metadata to indicate that the binary is to be compiled for debugging or testing purposes.

In an implementation, the code generator <NUM> can also perform quantization of data that is included in the neural network based on, for example, an amount of memory (and/or other resources) available at the target device, e.g., a resource-constrained processor. In an example, such data may be in a floating point format which provides a precision of <NUM> bits of data in some computing architectures. In some instances, the functionality of the network is not impacted if the format of the data is in a different format that uses a less amount of bits (e.g., lower precision) than the aforementioned <NUM> bits for a floating point value. The code generator <NUM> therefore can perform a quantization optimization for floating point data and generate code in a data format that uses a smaller amount of bits (e.g., <NUM> bits, <NUM> bits, <NUM> bit, etc.).

The following discussion relates to examples of code generated, by the code generator <NUM> of the ML framework <NUM>, from a given neural network model document.

The following example code defines a struct (e.g., user defined data type) in the C programming language for a neural network including code indicating an operation and/or layer type each layer of the neural network:
struct EspressoGen::model::network {
network();
~network();
void run();
void test();
// Input/output blobs
Espresso::blob_f4 input1 = nullptr;
Espresso::blob_f4 output1 = nullptr;
// network
static const size_t n_layers = <NUM>;
static const size_t n_blobs = <NUM>;
float gflops = <NUM>;
private:
Espresso::batchnorm_kernel_cpu k_0;
Espresso::transpose_kernel_cpu k_1;
Espresso::convolution_kernel_cpu k_2;
Espresso::pool_kernel_cpu k_3;
Espresso::convolution_kernel_cpu k_4;
Espresso::pool_kernel_cpu k_5;
Espresso::convolution_kernel_cpu k_6;
Espresso::pool_kernel_cpu k_7;
Espresso::transpose_kernel_cpu k_8;
Espresso::transpose_kernel_cpu k_9;
Espresso::flatten_kemel_cpu k_10;
Espresso::inner_product_kernel_cpu k_11;
Espresso::inner_product_kernel_cpu k_12;
Espresso::softmax_kernel_cpu k_13;
Espresso::base_kernel* kernels [<NUM>];
Espresso::abstract_blob_container blobs[<NUM>];
Espresso::layer_data dsts[<NUM>];
Espresso::layer_data srcs[<NUM>];
int64_t last_run_time;
};.

The following code defines static allocations of storage for data from the layers of the neural network, which in an example are determined based on an amount of memory of a target device (e.g., the wireless audio output device <NUM>):.

The following code defines various binary formats for data (e.g., blob shapes, blob topology, etc.), which may be the result of graph coloring optimizations performed by the code generator <NUM>:
// Binary format for blob shapes
static int shapes[<NUM>][<NUM>] = { //<NUM>
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // input1
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // batch_normalization_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // batch_normalization_1_permute_conv1d_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // activation_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // max_poolingld_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // activation_2_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // max_pooling1d_2_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // activation_3_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // max_pooling1d_3_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // max_pooling1d_3_permute_flatten_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // flatten_1_output_permute_
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // flatten_1_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // activation_4_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // dense_2_output
{<NUM>,<NUM>,<NUM>,<NUM>,<NUM>}, // output1
};
// Binary format for blob topology
// For each layer: <n dst blobs> ids. <n src blobs> ids. static unsigned short topology bin info[] = {
<NUM>,<NUM>,<NUM>,<NUM>, // batch_normalization_1
<NUM>,<NUM>,<NUM>,<NUM>, // batch _normalization_1_permute_conv1d_1
<NUM>,<NUM>,<NUM>,<NUM>, // conv1d_1
<NUM>,<NUM>,<NUM>,<NUM>, // max_pooling1d_1
<NUM>,<NUM>,<NUM>,<NUM>, // conv1d_2
<NUM>,<NUM>,<NUM>,<NUM>, // max_pooling1d_2
<NUM>,<NUM>,<NUM>,<NUM>, // conv1d_3
<NUM>,<NUM>,<NUM>,<NUM>, // max_pooling1d_3
<NUM>,<NUM>,<NUM>,<NUM>, // max_pooling1d_3_permute_flatten_1
<NUM>,<NUM>,<NUM>,<NUM>, // flatten_1_permute_
<NUM>,<NUM>,<NUM>,<NUM>, // flatten_1
<NUM>,<NUM>,<NUM>,<NUM>, // dense_1
<NUM>,<NUM>,<NUM>,<NUM>, // dense_2
<NUM>,<NUM>,<NUM>,<NUM>, // activation_5
};
// Binary format for coloring allocator
static unsigned short colors_bin_info[] = {
<NUM>, // color = <NUM><NUM>, // input1 shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // batch_normalization_1_permute_conv1d_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>,
<NUM>)) size=<NUM><NUM>, // max_poolingld_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // activation_4_output shape=((<NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // max_poolingld_2_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // max_poolingld_3_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // flatten_1_output_permute_shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // output1 shape=((<NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // color = <NUM><NUM>, // activation_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // batch_normalization_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // activation_2_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // activation_3_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // max_pooling1d_3_permute_flatten_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>, <NUM>))
size=<NUM><NUM>, // flatten_1_output shape=((<NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM><NUM>, // dense_2_output shape=((<NUM>, <NUM>, <NUM>, <NUM>)) size=<NUM>
};.

In an example, dependency information between respective layers of the network can be indicated in the following code:
static unsigned short topology bin info[] = {<NUM>,<NUM>,<NUM>,<NUM>}.

In the above code examples, each line of code in a similar syntax corresponds to an operation of a given neural network model. By way of example, in order <NUM>,<NUM>,<NUM>,<NUM> for a line: <NUM> is the number of output blobs/tensors, <NUM> is the index of the output blob, <NUM> is the number of input blobs, and <NUM> the index of the input blob.

Although examples described herein pertain to generating code in the C programming language, it is appreciated that this is only one possible target of the compiler. In an implementation, the compiler of the subject technology may generate a LLVM IR (intermediate representation) or binary.

By compiling a given neural network model to a binary and pruning off all the non-used configurations of any operations as described herein, the subject technology is enabled to run neural networks without utilizing a deep learning or machine learning framework on embedded processors (e.g., the specialized processor <NUM>) with limited memory (e.g., in ~<NUM> of kB), by selecting portions of the framework (e.g., the ML framework <NUM>) that are utilized for an inference task (or other machine learning task) of such networks.

As discussed herein, a convolutional neural network refers to a particular type of neural network, but uses different types of layers made up of nodes existing in three dimensions where the dimensions may change between layers. In a convolutional neural network, a node in a layer may only be connected to a subset of the nodes in a previous layer. The final output layer may be fully connected and be sized according to the number of classifiers. In an example where a convolutional neural network performs image classification for digital images representing digits, an example final output layer may have dimensions of [<NUM>×<NUM>×<NUM>]. In another example, a dimension of an final output layer for convolutional neural network that identifies <NUM> different objects (e.g., cats, dogs, people, bridges, etc.) in an image may have dimensions of [<NUM>×<NUM>×<NUM>].

As discussed herein, a convolutional neural network model may include various combinations, and in some instances, multiples of each, and orders of the following types of layers: the input layer, convolutional layers, pooling layers, rectified linear unit layers (ReLU), and fully connected layers. Part of the operations performed by a convolutional neural network includes taking a set of filters (or kernels) that are iterated over input data based on one or more parameters. In an example, the depth of a convolutional layer may equal the number of filters used. It is appreciated that the sizes of the different volumes at each layer may be mathematically determined given the hyperparameters of a convolutional neural network.

In an example, convolutional layers read input data (e.g., a 3D input volume, a 2D image, or a 1D signal), using a kernel that reads in small segments at a time and steps across the entire input field. Each read can result in an input that is projected onto a filter map and represents an internal interpretation of the input. Convolutional neural networks can be applied to human activity recognition data (e.g., sensor data corresponding to motion or movement) where a convolutional neural network model learns to map a given window of signal data to an activity where the model reads across each window of data and prepares an internal representation of the window.

Convolutional neural networks are often run on cloud-based computing platforms due to the volume of data being processed. In such instances, memory management is often an after-thought because cloud-based systems do not have practical memory concerns (e.g., more computing power/memory is readily available). In contrast, storing all the weights and resulting node values of convolutional neural network in memory on a resource/memory limited/constrained device (e.g., a mobile electronic device such as a smartphone) may not be possible or practical.

<FIG> illustrates an example of a convolutional neural network <NUM> in accordance with one or more implementations.

As shown in the example of <FIG>, the convolutional neural network <NUM> illustrates intermediate data layers <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. For the purpose of explanation, the intermediate data layers are illustrated as 2D objects, but it is appreciated that the intermediate data layers may correspond to 3D input volumes. The intermediate data layers <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be different types of layers such as convolutional layers, ReLU layers, etc. Accordingly, different intermediate data layers may have different dimensions. Different computing architectures may store the intermediate data layers in different formats. For example, when a convolutional neural network is processed on a specialized processor (e.g., motion processor), the input data can be represented and stored in a particular binary format that is compatible with the architecture of the specialized processor.

Convolutional neural network <NUM> is illustrated along a vertical temporal axis starting at t0 and ending at t3. The axis illustrates the different, relative, times intermediate data layers may be processed by an electronic device. For example, intermediate data layer <NUM> may be processed first, and then both intermediate data layer <NUM> and intermediate data layer <NUM> are processed in parallel at t1.

Convolutional neural network <NUM> also illustrates the dependencies between different intermediate data layers. Thus, intermediate data layer <NUM> and intermediate data layer <NUM> both use the output of intermediate data layer <NUM>; intermediate data layer <NUM> uses the output of intermediate data layer <NUM>; and intermediate data layer <NUM> uses the output of intermediate data layer <NUM> and intermediate data layer <NUM>. In an implementation, the hyperparameters and architecture (e.g., number of layers and how the layers are connected) of convolutional neural network <NUM> may be included with the code of the network as discussed before in <FIG> and <FIG>. In various examples, the convolutional neural network <NUM> may be executed on a specialized processor of a single electronic device (e.g., mobile device, laptop computer, desktop computer).

The dependencies between the layers of convolutional neural network <NUM> may be used to deduce the minimum number of memory allocations needed to execute the convolutional neural network. Once the dependencies are known, the code generator <NUM> can determine at a particular execution point whether or not the output from a data layer will be needed in the future. If the output is needed, then a memory allocation may be required to hold the output until whatever intermediate data layer needs it has used the output. In an example, the minimum number of memory allocations is based on the largest number of memory allocations needed to hold the depended upon outputs during execution of the convolutional neural network. A visualization of the results (e.g., in tabular format) of the deduction process when performed by the code generator <NUM> is illustrated in <FIG>.

<FIG> illustrates an example table <NUM> of memory allocations in accordance with one or more implementations. The rows of the table <NUM> correspond to times t0 through t3. The columns of table <NUM> represent three different memory allocations, memory allocation <NUM>, memory allocation <NUM>, and memory allocation <NUM>. The labels B1, B2, B3, B4, and B5 correspond to intermediate data layer <NUM>, intermediate data layer <NUM>, intermediate data layer <NUM>, intermediate data layer <NUM>, and intermediate data layer <NUM>.

The following discussion references times (e.g., t0) as if the convolutional neural network was actually running. However, the code generator <NUM> performs the deduction process without actually running the convolutional neural network based on information of dependency and relative order of execution time of operations in the network. The dependency information may be generated as part of the code corresponding to the convolutional neural network. For example, the dependency information for convolutional neural network <NUM> may be represented as:.

The following discussion describes how the code generator <NUM> determines memory allocations for the network. In one or more implementations, the total amount of memory available for allocation may be determined based at least in part on an amount of available memory of a given target device, e.g., a specialized processor provided by the wireless audio output device <NUM>. For example, the code generator <NUM> may utilize information regarding a total amount of available memory of the target device (e.g., the wireless audio output device <NUM>), which could be provided in database or another source such as a table (e.g., lookup table) that includes respective entries for various target devices and relevant information regarding hardware capabilities (e.g., minimum and/or maximum memory allocation sizes, etc.) and amounts of total memory for such target devices. The code generator <NUM>, in an implementation, can track the available amount of memory with respect to the total amount of memory of the target device in view of previous (if any) allocations for the network.

For example, beginning at t0, a first memory allocation, memory allocation <NUM>, is used to hold the data for B1. Then, at t1 both intermediate data layer <NUM> (B2) and intermediate data layer <NUM> (B3) need memory allocations. Accordingly, the code generator <NUM> can perform a check to determine what is stored in memory allocation <NUM>. As previously stated, B1 is currently stored in memory allocation <NUM>. Then, the code generator <NUM> can access the dependency information to determine if B1 is used by other intermediate data layers of the network. In this example, B1 is used by both B2 and B3. Accordingly, memory allocation <NUM> may not be assigned to B2 or B3. Consequently, two new memory allocations are needed, memory allocation <NUM> and memory allocation <NUM>. These allocations are assigned B2 and B3, respectively, by the code generator <NUM>.

Moving to t2, intermediate data layer <NUM> (B4) needs a memory allocation. Again, a check may be made to see if an existing memory allocation may be reused. B1 is still in memory allocation <NUM>, but because both B2 and B3 are now complete, the data from B1 is not needed. Accordingly, memory allocation <NUM> may be reassigned to B4. Similarly, at t3, memory allocation <NUM> may be reassigned to B5 because B3 is no longer needed. Therefore, based on the dependency information, the code generator <NUM> can deduce that a minimum number of three memory allocations is needed to execute the convolutional neural network <NUM>, which is the largest number needed at any point after walking through the dependency tree (e.g., performing a mock execution of the convolutional neural network by the code generator <NUM>).

The code generator <NUM> can also determine which intermediate data layers are assigned to a memory allocation during execution and generate code for such a memory allocation. For example, both B1 and B4 were used by memory allocation <NUM>. The assignment information may be determined at the same time it is determined how many memory allocations are needed.

Next, the code generator <NUM> can determine the needed memory storage size of each of the minimum number of memory allocations. Different computing architectures may allocate memory in different ways. For example, some computing architectures permit linear memory allocations such as in some types of specialized processors. Similarly, different computing architectures can have different requirements for the minimum or maximum size of memory allocations. As described above, the code generator <NUM> may determine a total amount of available memory on the target device (e.g., the wireless audio output device <NUM>) in order to determine an amount of available memory for respective memory allocations and in view of previous (if any) allocations (e.g., which would potentially reduce the amount of available memory).

In an implementation, the code generator <NUM> can iterate through each memory allocation to determine the amount of memory storage to reserve. Thus, with reference back to <FIG>, the code generator <NUM> may examine the underlying intermediate data layers of B1 and B4. As discussed previously, each intermediate data layer may be considered a 3D input volume. In an example, the code generator <NUM> can determine the memory storage needed for an intermediate data layer based on a product of the dimensions of the intermediate data layer and a size of the data at entry point in the volume. Additionally, the code generator <NUM> can check a resource constraint for the target device (e.g., the total amount of memory and the current available amount of memory on the wireless audio output device <NUM>) to further determine whether the needed size of memory for such allocations is possible, and if so, generate code for the memory allocations accordingly.

Some computer architectures may permit memory allocation using linear memory. In such instances, the code generator <NUM> can determine the size of the memory allocation based on the maximum total size of an intermediate data layer for any layers that are to reuse the memory allocation. For example, this can be expressed as max(WB1WB4). In other instances, where textures or linear memory may not be used, the code generator <NUM> can determine the size based on both the maximum width and height of the storage texture. For example, this can be expressed as max(WB1HB1, WB4HB4). The code generator <NUM> can determine an amount of allocated memory space needed based on depth information of a volume. For example, the code generator <NUM> can process a [<NUM>×<NUM>×<NUM>] volume as three, consecutive [<NUM>×<NUM>] arrays (e.g., a [<NUM>×<NUM>]) volume when determining the size of memory allocations. Additionally, the code generator <NUM> can check a resource constraint for the target device (e.g., the total amount of memory and the current available amount of memory on the wireless audio output device <NUM>) to further determine whether the needed size of memory for such allocations is viable, and if so, generate code for such allocations.

<FIG> illustrates a flow diagram of an example process <NUM> for generating code for a neural network model in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to components of the software architecture of <FIG>, which may be executed by one or more processors of the electronic device <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM>, and one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of other suitable devices, such as by the electronic device <NUM>. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The ML framework <NUM> receives a neural network model in a model format, the model format including information for a set of layers of the neural network model, each layer of the set of layers including a set of respective operations (<NUM>). In an example, the NN model includes multiple layers that include operations that are executable on a specialized processor of a target platform. The target platform, in an example, may be a different electronic device, such as the wireless audio output device <NUM>.

The code generator <NUM> generates neural network (NN) code from the neural network model, the NN code being in a programming language distinct from the model format, and the NN code comprising a respective memory allocation for each respective layer of the set of layers of the neural network model (<NUM>). In an example, the code includes particular code (e.g., C code) corresponding to allocations of memory for each layer of the set of layers. Moreover, determining the respective memory allocation for each respective layer is based at least in part on a resource constraint (e.g., a total amount of memory and/or an amount of available memory) of a target device (e.g., the wireless audio output device <NUM>).

The neural network compiler <NUM> compiles the NN code into a binary format (<NUM>). In an example, the binary format is compatible with the hardware architecture of the specialized processor of the target platform (e.g., the wireless audio output device <NUM>).

The neural network compiler <NUM> generates a package for deploying the compiled NN code on the target device (<NUM>).

<FIG> illustrates an example process <NUM> for determining memory allocations for generating code for a convolutional neural network in accordance with one or more implementations. For explanatory purposes, the process <NUM> is primarily described herein with reference to components of the electronic device shown in <FIG>, which may be executed by one or more processors of the electronic device <NUM> of <FIG>. However, the process <NUM> is not limited to the electronic device <NUM>, and one or more blocks (or operations) of the process <NUM> may be performed by one or more other components of other suitable devices. Further for explanatory purposes, the blocks of the process <NUM> are described herein as occurring in serial, or linearly. However, multiple blocks of the process <NUM> may occur in parallel. In addition, the blocks of the process <NUM> need not be performed in the order shown and/or one or more blocks of the process <NUM> need not be performed and/or can be replaced by other operations.

The code generator <NUM> determines dependencies between intermediate data layers of a neural network (<NUM>). In an example, the neural network is a convolutional neural network based on a NN document file (e.g., from the neural network model document files <NUM>). NN document file may identify the number of intermediate data layers, dependencies between the layers, the dimensions (e.g., height, width, depth) of each layer, and the order of execution of the layers. In some examples, ML framework <NUM> is configured to analyze the NN document file.

The code generator <NUM> determines dimensions of the neural network (<NUM>). In some examples the sizes of the intermediate data layers are obtained from the metadata. In some examples, the sizes of the intermediate data layers are calculated based on hyperparameters for the neural network.

The code generator <NUM> determines a minimum number of memory allocation portions for executing the neural network based on the dependencies (<NUM>). The minimum number of memory allocation portions may be deduced from the order of the intermediate data layers within the neural network. For example, if three later intermediate data layers use data from an earlier intermediate data layer, the data in the earlier intermediate data layer may be stored at least until the execution of the three later intermediate data layers. In an example, the minimum number of dependencies is stored as part of the metadata for the neural network. Further, the code generator <NUM> determines designations for assigning intermediate data layers to the memory allocation portions. In an example, this is accomplished by traversing the architecture as if the neural network was run to determine which intermediate data layer is stored in which data storage portion as the neural network would be run. Additionally, more than one intermediate data layer may be designated to a memory allocation portion. In some examples, different memory allocation portions are designated for different intermediate data layers. The resulting designations may be stored as a table that identifies the intermediate data layer and the memory allocation portion designated for the intermediate data layer.

The code generator <NUM> determines determine a memory allocation size for each respective memory allocation portion of the memory allocation portions based on the dimensions and dependencies (<NUM>). The code generator <NUM> generates a memory allocation size for each respective data storage portion is determined based on the dimensions and dependencies. For example, the dependencies may dictate which intermediate data layer are assigned to the memory allocation portions as discussed above. Then, the dimensions of the intermediate data layer(s) assigned to the respective memory allocation portions may be examined to determine the largest intermediate data layer by volume. The memory allocation size for the respective memory allocation portion may be set to at least the size of the largest intermediate data layer. The type of executing environment may affect the memory allocation size. For example, the memory allocation size may be more than the size of the largest intermediate data layer if memory may not be allocated using textures or linearly.

The code generator <NUM> generates code for allocating memory on the target platform (e.g., the wireless audio output device <NUM>) for each memory allocation portion based at least in part on the respective determined memory allocation size (<NUM>).

When the compiled and deployed to a target device, such as the wireless audio output device <NUM>, memory on the target device can be allocated for each memory allocation portion of the neural network in accordance with its respective determined memory allocation size. After allocation, the designation table between intermediate data layers and data storage portions may be updated to include the memory addresses for the allocated memory. In an example, the memory for the data storage portions is allocated as a contiguous block, but virtually split into the number of memory portions. During execution of the neural network, a pointer may be moved around the block corresponding to the memory portions in the contiguous block.

<FIG> illustrates an electronic system <NUM> with which one or more implementations of the subject technology may be implemented. The electronic system <NUM> can be, and/or can be a part of, the electronic device <NUM>, the electronic device <NUM>, and/or the server <NUM> shown in <FIG>. The electronic system <NUM> may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system <NUM> includes a bus <NUM>, one or more processing unit(s) <NUM>, a system memory <NUM> (and/or buffer), a ROM <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>, or subsets and variations thereof.

Finally, as shown in <FIG>, the bus <NUM> also couples the electronic system <NUM> to one or more networks and/or to one or more network nodes, such as the electronic device <NUM> shown in <FIG>, through the one or more network interface(s) <NUM>. In this manner, the electronic system <NUM> can be a part of a network of computers (such as a LAN, a wide area network ("WAN"), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system <NUM> can be used in conjunction with the subject disclosure.

One aspect of the present technology may include the gathering and use of data available from specific and legitimate sources to improve the delivery to users of invitational content or any other content that may be of interest to them. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that may be of greater interest to the user in accordance with their preferences. Accordingly, use of such personal information data enables users to have greater control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used, in accordance with the user's preferences to provide insights into their general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services or anytime thereafter. In another example, users can select not to provide mood-associated data for targeted content delivery services. In yet another example, users can select to limit the length of time mood-associated data is maintained or entirely block the development of a baseline mood profile. In addition to providing "opt in" and "opt out" options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app.

For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user's device or other non-personal information available to the content delivery services.

Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way).

It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous.

Claim 1:
A method comprising:
receiving, at an electronic device (<NUM>) comprising a processor and a memory device, a neural network model (<NUM>) in a model format, the model format including information for a set of layers (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) of the neural network model, each layer of the set of layers including a set of respective operations;
generating, at the electronic device, neural network, NN, code from the neural network model, the NN code being in a programming language distinct from the model format, and the NN code comprising a respective memory allocation for each respective layer of the set of layers of the neural network model, wherein the generating comprises determining the respective memory allocation for each respective layer based at least in part on a resource constraint of a target device (<NUM>, <NUM>) that is separate from the electronic device;
compiling, at the electronic device, the NN code into a binary format (<NUM>), the compiling comprising pruning a set of non-used configurations of operations of the neural network model, wherein the pruning reduces the size of the NN code in the binary format by performing an operation fusion optimization in which multiple operations are combined into the same code segment or function call; and
generating, at the electronic device, a package for deploying the compiled NN code on the target device for execution by a specialized processor (<NUM>, <NUM>) of the target device.