Decoding of variable-length prefix code data of a neural network data stream

Abstract

Decoding a neural network data stream which includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme (such as

Description

BACKGROUND Entropy encoding is a widely used lossless data compression method. An entropy codec (encoder / decoder pair) encodes or compresses a data stream and then decodes or decompresses the compressed data to regenerate the original data. Entropy encoding is generally achieved by designing a code with a one-to-one mapping from “code words” to the symbols they represent. The most common codes are binary codes, where the “code word” is a bit-string comprising “ones” and zeros . Huffman Encoding is a well-known process for compressing a sequence of symbols, which can achieve optimal compression, described, for example, in Shannon C.E, (1948) “A Mathematical Theory of Communication”, Bell System Technical Journal, 27 (3), 379-423. Consequently, it has become the de facto go-to solution used in many applications. For example, the commonly used H.264 video standard uses Huffman to encode discrete cosine transform (DCT) coefficients. Huffman encoded bit-streams are also used in file compression such as for ZIP files, MP3 audio compression, HTTP / 2 Protocol for data transmission and in many more applications. The Huffman algorithm, and other similar algorithms, can be considered to operate as a “dictionary”, which is the set of all used input symbols in a data stream and their relative frequencies in the stream. A code word, e.g. a character-string or bit-string, can be used to represent each of the symbols in the dictionary, where the length of the code word (e.g. number of bits in a bit-string) representing a symbol depends upon the frequency of the symbol in the data stream. In order to decode the data stream, the decoder needs to know the details of the dictionary used in the encoding. Either this can be pre-agreed, or the dictionary itself can be transmitted to the decoder ahead of or with the encoded bit-stream. Efficient codes such as Huffman codes are uniquely and instantaneously decodable, and use short bit-strings to represent common symbols. A prefix code ensures that a bit-string representing a symbol is not used as a prefix of any bit-string for any other symbol. This enables the encoded data to be instantaneously decodable once a recognised bit-string has been received. Using shorter bit-strings to represent common symbols increases the compression of a prefix code. This results in bit-strings of different lengths being used to represent different symbols. Huffman encoding is an example of a variable-length prefix encoding scheme. There are many other examples of variable-length prefix encoding schemes including Golomb encoding, Rice encoding, Fibonacci encoding, Elias Gamma / Exp-Golomb encoding, and Unary encoding. Exp-Golomb, for example, is a common compression technique, and is used in many places including H.264 / MPEG-4 AVC and H.265 High Efficiency Video Coding video compression standards. Prefix codes such as those used by Huffman encoding can be visualised using a tree, e.g. a binary tree. An example of a binary tree is shown in Figure 1. A binary tree 2 begins with a root node 4 with a pair of branches representing the possible bits assigned to the first bit of a bit-string representing a symbol. A second pair of branches represents the second possible bit and so on. The code visualised by the binary tree 2 in figure 1 is a prefix code, and so each symbol represented by the code is found at a leaf node (e.g. node 6) of the tree, i.e. a node with no successors. When a leaf node is reached, the path taken from the root node 4 to the leaf node provides the bit-string for the symbol. The code uses variable length bit-strings, with more common letters represented by shorter bit-strings. For example, in figure 1, “e” (which is the most commonly used letter in the English language) is represented by “010” (i.e. by a bit-string having three bits), “f is represented by “110011”, and “j” (which is one of the least commonly used letters in the English language) is represented by "1100001011” (i.e. by a bit-string having ten bits). The variable-length nature of the encoded bit-strings makes it difficult to quickly decode the bit stream. In a decoder, such as a Huffman decoder, the tree can be traversed from the root node 4 by considering bits of the encoded bit stream in turn to decide which branch of the tree to take at each decision point until a leaf node is reached, at which point a decoded symbol can be output. In other words, each bit is processed sequentially to determine whether sufficient bits have been amassed to decode the next symbol. If not, then a further decision is required to determine whether to take the left or the right branch in the tree. Reading one bit at a time is an inefficient operation for a modem computer processing unit (CPU) / device, and requires a lot of operations. Furthermore, making a decision per bit is expensive for a modern CPU. Advancements in the processing speed of computing devices over the last two decades are largely due to the use of smaller processing chips in parallel, such as in multi-core and parallel processing techniques. Using more processing units can improve the processing speed, but typically requires a trade-off in terms of the size and power consumption of the device. Further, these parallelisation methods fall short for many essential tasks that are implicitly sequential, for example decoding of variable-length prefix data, where the start position of any symbol is only known after all the preceding symbols have been decoded. It would be beneficial to improve (i.e. reduce) one or more of the factors of power consumption, latency, and size (or “footprint”) of a processor without requiring a deterioration (i.e. an increase) in other ones of these factors. An example where prefix codes are used is for representing neural network data. Neural network data is data that defines a neural network. For example, neural network data may be data defining weights and / or biases to be applied by nodes (or “neurons”) of a neural network. It is beneficial to be able to quickly and efficiently encode and decode (i.e. compress and decompress) neural network data, e.g. for efficient transmission, distribution and / or storage of the neural network data. The theory of artificial intelligence (Al) and neural networks has existed for decades, but widespread adoption of Al is a more recent event, made possible by the speed of modem computational systems. In turn, this speed has made it possible to run larger models (i.e. neural networks with more nodes), and these larger models have been able to tackle larger, more useful problems. Indeed the number of nodes in an Al model has grown from thousands to millions to billions in current “Large Language Models” (LLMs). As models have become larger, the time and effort required to train them has grown significantly, and has grown much faster than computational systems have grown. Training a neural network now requires a large group of very powerful machines each exchanging vast amounts of data as they slowly learn how to configure different parts of the large model. What is being “learnt” during the training process are the weights and / or biases required to configure each “neuron” in each “convolution” i.e. all the multiple inputs to each nodes for all the many nodes in the model. This problem of training a large neural network is split over a large group of computers (e.g. Central Processing Units (CPUs) and / or Graphics Processing Units (GPUs)) because: (i) no single computer can hold all the information at once, and (ii) multiple computers can work in parallel on different parts of the model. Typically, each computer will use many gigabytes of memory to store parameters for use in the training of a large neural network, and these parameters (i.e. weights and / or biases) need to be routinely exchanged with the other computers in the group as each computer slowly learns the parameters of the neural network. The computers (e.g. CPUs and / or GPUs) will typically communicate with each other over a network, such as the Internet or a high speed Local Area Network (LAN). The parameters (i.e. weights and / or biases) are compressed before being transmitted between different computers to reduce the amount of data that has to be exchanged between the computers, thereby reducing the time needed to distribute all the new parameters. This numerical data is typically compressed using a variable-length prefix encoding scheme, and the industry standard Huffman algorithm is often used, although other compression schemes may be used. SUMMARY This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. A first aspect provides a computer processing system configured to decode a neural network data stream which includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data, the computer processing system comprising processing logic configured to: receive the neural network data stream; query an acceleration table on the computer processing system with a fixed number of characters of the received neural network data stream to identify an entry of the acceleration table, wherein each of a plurality of the entries of the acceleration table indicates a decoded symbol to be returned, and wherein the acceleration table has multiple entries which indicate the same decoded symbol represented by a character-string having fewer than said fixed number of characters; and if the identified entry indicates a decoded symbol, output the decoded symbol indicated by the identified entry for use in training a neural network. The system may be configured to process the decoded symbols to determine parameters (i.e. weights and / or biases) for configuring neurons in the neural network as part of training the neural network. The system may be part of a group of computer processing systems which are configured to operate together to train the neural network. The processing logic may be configured to receive the neural network data stream from another computer processing systems in the group. The system may be configured to encode the determined parameters into a further neural network data stream and send the further neural network data stream to a different computer processing systems in the group for further use in training the neural network The neural network data stream may be a bit stream, the characters may be bits, and the character-strings may be bit-strings. The system may be configured such that each of the plurality of the entries of the acceleration table that indicate a decoded symbol further indicate a character-length for the indicated symbol, wherein the character-length is the number of characters in the character-string that represents the symbol indicated by that entry, and wherein the system may be further configured to, if the identified entry indicates a decoded symbol, output the indicated character-length for the indicated symbol. The character-length may be a bit-length, wherein the bit-length is the number of bits in the bit-string that represents the symbol indicated by that entry. The fixed number of characters may represent an index of the identified entry in the acceleration table and each entry of the acceleration table may comprise data. Each of the plurality of the entries of the acceleration table may indicate a decoded symbol to be returned using both data of the entry and the index of the entry. The data of each of the plurality of entries may comprise a character-length for the indicated symbol. The system may be further configured to: store a portion of the received neural network data stream in a buffer; shift the portion of the received neural network data stream stored in the buffer using a barrel shifter to position the fixed number of characters of the neural network data stream for identifying an entry of the acceleration table at a predetermined location within the buffer; and access the fixed number of characters of the neural network data stream from the predetermined location within the buffer. The system may be further configured to determine the amount by which to shift the portion of the received neural network data stream in the buffer to position the fixed number of characters of the neural network data stream at the predetermined location based on one or more character-lengths of one or more symbols that have previously been output in respect of the portion of the received neural network data stream that is stored in the buffer. The buffer may be a register of the computer processing system. The system may be configured such that said fixed number is greater than or equal to the number of characters of each of at least 90% of the character-strings included in the neural network data stream. The system may be configured such that for each of the character-strings in the neural network data stream that have a number of characters that is less than or equal to said fixed number, the acceleration table has at least one entry which indicates the decoded symbol represented by that character-string. The system may be configured such that the number of entries in the acceleration table is at least the maximum number of entries able to be distinctly identified by the said fixed number of characters. The system may be configured such that the acceleration table is formed by an array of data pairs, each data pair forming an entry in the acceleration table and wherein each data pair can be read in the same operation. The data pair for each of said plurality of the entries of the acceleration table may comprise i) a decoded symbol and ii) the length of the character-string representing the symbol. The system may be configured such that one or more of the symbols are represented by a respective one or more long character-strings, wherein a long character-string has more than the said fixed number of characters. The system may be configured such that one or more of the entries of the acceleration table is a long character-string entry for one or more long character-strings representing a symbol. The acceleration table may be arranged such that a long character-string entry for a long character-string is identified when the fixed number of characters used to query the table are an initial portion of the characters of the long character-string. The system may be configured such that each of said one or more long character-string entry of the acceleration table identifies an acceleration sub-table to be queried for determining the symbol represented by the long character-string. The system may be further configured to, in response to identifying a long character-string entry of the acceleration table: query the identified acceleration sub-table on the computer processing system with a subsequent fixed number of characters of the received neural network data stream to identify an entry of the acceleration subtable, wherein each of a plurality of the entries of the acceleration sub-table indicates a decoded symbol to be returned; and if the identified entry of the acceleration subtable indicates a decoded symbol, output the decoded symbol indicated by the identified entry of the acceleration sub-table. The system may be further configured to, in response to identifying a long character-string entry of the acceleration table: concatenate a subsequent character of the neural network data stream to the fixed number of characters to form a set of characters; determine whether the set of characters matches a long character-string that represents a decoded symbol; and if the set of characters matches a long character-string that represents a decoded symbol, output the decoded symbol. The system may be further configured to, if the set of characters does not match a long character-string that represents a decoded symbol: concatenate another subsequent character from the neural network data stream to form a further set of characters; and determine whether the further set of characters matches a long character-string that represents a decoded symbol. The acceleration table may be stored in a cache of the computer processing system. The acceleration table may be predetermined and fixed in hardware using fixed-function circuitry in the computer processing system. The system may be configured to form the acceleration table in dependence on the received neural network data stream. The system may be configured to dynamically choose said fixed number in dependence on the received neural network data stream. The variable-length prefix encoding scheme may be any one of: Huffman encoding, Golomb encoding, Rice encoding, Fibonacci encoding, Elias Delta encoding, Elias Gamma encoding, Exp-Golomb encoding, Unary encoding, or any other variable-length prefix encoding scheme. A second aspect provides a computer-implemented method of decoding, on a computer processing system, a neural network data stream which includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data, the method comprising: receiving the neural network data stream at the computer processing system; querying an acceleration table on the computer processing system with a fixed number of characters of the received neural network data stream to identify an entry of the acceleration table, wherein each of a plurality of the entries of the acceleration table indicates a decoded symbol to be returned, and wherein the acceleration table has multiple entries which indicate the same decoded symbol represented by a character-string having fewer than said fixed number of characters; and in response to the identified entry indicating a decoded symbol, outputting the decoded symbol indicated by the identified entry for use in training a neural network. A third aspect provides a computer readable storage medium having stored thereon computer readable instructions that, when executed on a computer processing system, cause the computer processing system to perform any of the methods described herein. There may be provided computer program code for performing any of the methods described herein. There may be provided non-transitory computer readable storage medium having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform any of the methods described herein. The above features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the examples described herein. DESCRIPTION OF THE DRAWINGS The present invention will now be described by way of example with reference to the accompanying drawings. In the drawings: Figure 1 shows an example binary tree used in prior art systems; Figures 2a and 2b show hash tables which may be used to decode a Huffman stream; Figure 3 shows an example acceleration table for decoding a bit stream encoded by a variable-length prefix code; Figure 4 shows an example computer processing system; Figure 5 shows an example method for decoding a bit stream encoded by a variable-length prefix code; and Figure 6 shows a further example method for decoding a bit stream encoded by a variable-length prefix code. DETAILED DESCRIPTION The following description is presented by way of example to enable a person skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art. As described above, a decoder, such as a Huffman decoder, will typically read one bit at a time. These bits can be amalgamated (concatenated) into a set of bits. After each bit is read, the decoder tests to see whether this set of bits matches any of the bit-strings that represent any of the encoded symbols in the Dictionary. If the bit-string is recognised as representing an encoded symbol, the decoder will emit the symbol and restart amalgamating bits one bit at a time. If the bit-string is not recognised, the decoder will repeat the process for the next bit, i.e. it will read and amalgamate another bit to form a new set of bits which can be tested to see whether it matches any of the bit-strings that represent encoded symbols. The process can be repeated multiple times until a bit-string is recognised as representing one of the symbols. There are several methods for decoding an encoded bit-stream which includes variable-length bit-strings representing symbols which have been encoded in accordance with a variable-length encoding scheme, such as a Huffman encoding scheme. One option is to build a hash table prior to decoding the stream containing each symbol in the dictionary with the respective bit-string for each symbol, such as that shown in figure 2a. After each bit is read from the input stream, the amassed set of bits is tested against the pre-built hash table to determine if the bit-string is complete, i.e. to determine whether the set of bits matches one of the bit-strings in the table. This method can be further improved by pre-building several hash tables, one for each length of bit-string, such as in figure 2b. After each bit is read and concatenated to form a set of bits, the set of bits is tested against the appropriate hash table of the current length of the set of bits to determine if the bit-string is complete, i.e. to determine whether the set of bits matches one of the bit-strings in the appropriate table. This method is more efficient as each of the hash tables is smaller than the table in the first option, resulting in fewer look-ups. As an alternative to using hash tables, a binary decoder tree can be pre-built, such as that in figure 1. After each bit is read, the tree is traversed taking left (0) or right (1) branches until a leaf node (e.g. leaf node 6) is found. This option is often the fastest option as a single branch is selected rather than searching a table after each bit is processed, but the memory access patterns are less predictable. These decoding methods can be used with the widespread Huffman encoding system and other similar variable-length prefix encoding systems. However, all of these decoding methods cause problems for a modern CPU. Processing one bit at a time requires frequent small memory transactions, which are significantly less efficient than fewer larger memory transactions. Moreover, the variable sized bit-strings that represent the symbols are difficult for a CPU to process as they form a stream of data, and the bit-strings are not (necessarily) byte / word sized, nor byte / word aligned within the stream. Further, the bit-stream must be read in order from the start of the bit-stream, as there is no indication where any bit-string starts or ends within the stream. Additionally, modern CPUs are typically pipelined, where each operation is split into a series of stages that must execute sequentially one after another. To improve performance, the CPU attempts to overlap the stages of one operation with the stages of the following operations, which can introduce data hazards. Some operations contain branches, so that it is not known which operation must be executed next until all stages of the previous operation have been completed. These branches can drastically slow down a CPU. The decoding techniques described above have multiple branches per symbol, which detrimentally affect the performance of a CPU. Furthermore, these branches are unpredictable, so time and power may be wasted in speculative execution of branches not taken. The binary decoding tree is typically considered the fastest decoding option, however, multiple frequent memory input / outputs are required to decode each symbol and these memory reads access pseudo-random addresses, each have a long read latency, and most likely have low cache hit-rates if any on-chip caching is used. These performance issues are not specific to Huffman encoding / decoding, but are a function of variable size, misaligned data-objects, which will inevitably be generated by variable length prefix codes such as Huffman, Golomb, Rice, Fibonacci, Exp-Golomb, Unary, Elias Delta, Elias Gamma etc. This mismatch leads to inefficiencies and suboptimal performance, especially in high-demand applications. The following description describes improved computer processing systems and computer-implemented methods for decoding a data stream which includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, such as a Huffman encoding scheme. The systems and processes described herein may be used with any data format (any characters) for example binary, hexadecimal, decimal or genomic data. Many of the example computer processing systems and methods described below are for decoding a bit stream comprising bit-strings representing symbols that have been encoded using a variable-length prefix code, but it is to be understood that a bit stream is just an example of a data stream, bits are just an example of characters, and bit-strings are just an example of character-strings. By processing the bit stream in a new manner, the presented methods may overcome many of the inefficiencies of existing decoding techniques, and drastically improve the performance of the decoder. For example, the performance of the computer processing system when decoding the encoded data in the manner described below may be of the order of 3 to 10 times better than the performance of computer processing systems when decoding the encoded data using conventional techniques. This is a huge improvement in performance, which can be achieved with little or no increase in the power consumption or size of the computer processing system. Alternatively, by picking a different point in the trade-off between performance, area and power consumption, the decoding techniques described below can be used to significantly reduce the power consumption or size (e.g. silicon area) of the computer processing system without reducing the performance of the system. The method uses an acceleration table. The acceleration table may be referred to using different terminology, e.g. it may be referred to as an index table or a lookup table or an acceleration structure. The acceleration table is built prior to decoding the encoded bit-stream, to accelerate the decoding of the majority (often all) of the symbols represented by the bit-strings in a bit stream. The acceleration structure is computationally cheap to produce and requires very little memory to store. The decoding method does not require any changes to how the bit stream is encoded, and can be used to decode any variable-length prefix code. The method accesses multiple bits of the bit-stream at a time for use in querying the acceleration table, accessing the same number of bits (i.e. a fixed number of bits) each time. For example, the method may always access 8 bits at a time. The acceleration table has (exactly) one entry (e.g. one row) for each possible combination of bits in the fixed number of bits. For example, if the fixed number of bits is 8 bits, then there are 256 possible combinations of bits in the fixed number of bits and the acceleration table will have 256 entries. The accessed bits are used to indicate an entry within the acceleration table, and therefore the acceleration table does not need to be searched. The accessed bits represent an index of an entry within the acceleration table. An example of part of an acceleration table 300 formed if 8 bits are to be accessed is shown in figure 3. The acceleration table may be populated from a symbol dictionary used when encoding the data. For symbols represented by a bit-string with a length that is the fixed number of bits or less (e.g. 8 or less), each entry indicated by a set of bits (e.g. 8 bits) that has a prefix of a bit-string representing a symbol will be populated by that symbol, and by how many bits are in the bit-string representing the symbol. For example, if a dictionary is used such as that used for the binary tree in figure 1, “e” is represented by the bit-string “101”. Therefore, an acceleration table will be populated by “e” as the symbol, and by “3” as the length of the bit string, in every entry (i.e. row) that can be indexed with a bit-string that begins with “101”. Therefore, every entry of the acceleration table with an index between “10100000” and “10111111” will be populated by “e” and “3”. Therefore in this example, there will be 32 entries of the acceleration table that represent the symbol “e” Symbols that are represented with bit-strings that have fewer than the fixed number of bits (e.g. fewer than 8 bits in the example shown in Figure 3) will be indicated by multiple entries in the acceleration table. The use of the acceleration table enables any symbol represented by a bit-string of the fixed number of bits or less, which (if the “fixed number” is chosen well) will normally be the vast majority of symbols, to be output following one read from the memory, rather than reading one bit at a time, and requires only one look-up in a table, rather than looking-up a table after reading every bit. The acceleration table is queried using the fixed number of bits (e.g. 8 bits) of the bit stream without first querying a table with a smaller number of bits of the bit stream. The pre-computation of the acceleration table is cheap, and the table requires a small amount of memory to store it. For example, the acceleration table 300 shown in Figure 3 may be represented with just 512 bytes. In this example, there are 256 entries (rows) in the table, and each entry may have two pieces of information, such as a symbol and a length. Each symbol and each length may, for example, be represented in the table using one byte (i.e. 8 bits) of data, such that each entry (row) of the table comprises two bytes of data. Since the acceleration table is so small (e.g. 512 bytes) it can be stored in an on-chip cache which the processing logic (e.g. arithmetic logic units (ALUs)) of the computer processing system can access with very low latency. For example, fetching data from an on-chip cache may take approximately 3 clock cycles, whereas fetching data from an off-chip memory may take hundreds of clock cycles. So being able to store the whole table in the on-chip cache, rather than storing it in memory can significantly reduce the latency (i.e. improve the performance) of the computer processing system. However, in some examples, the acceleration table may be stored in an off-chip cache. Furthermore, a single access to the acceleration table is sufficient to decode almost all symbols, and no branches are processed, thus allowing efficient instruction rescheduling, decreasing the prevalence of data-hazards, and increasing the number of operations or instructions per cycle (IPC). A computer processing system 100, such as the example shown in figure 4, is presented for decoding a compressed data stream that has been encoded using a variable-length prefix encoding scheme. The computer processing system 100 comprises a processing unit 102 (e.g. a central processing unit (CPU), a graphics processing unit (GPU), a neural network accelerator (NNA), a digital signal processor (DSP), or any other type of processing unit) and a memory 104. The processing unit 102 comprises processing logic 114, one or more registers, e.g. general purpose registers 112, and a cache 110 (e.g. on “on-chip” cache). The system may be used to decompress (i.e. “decode”) many different data types in one dimensional, two-dimensional or three-dimensional arrays, for many different applications, such as but not limited to: video compression, file compression, audio compression, data transmission, text compression, database management, compiler design, error detection and correction, and embedded systems. In particular, in examples described herein the system is used to decode a neural network data stream for use in forming the coefficients for use in the next stage of training / processing. The system may be used on computing devices such as, but not limited to, computers, smart phones, tablets, set-top boxes, digital audio players, plug-in devices (e.g. Amazon fire stick), Headsets and other devices comprising a processing unit. The compressed data stream (denoted “encoded data” 106 in figure 4) comprises, for example, a sequence of bit-strings, wherein each bit-string represents a symbol. The bit-strings have varying lengths. Each variable-length bit-string represents a symbol that has been encoded in accordance with a variable-length prefix encoding scheme. The bit-strings (encoded symbols) are sent one after another as a continuous bit stream. All the following example systems and methods in which a bit-string is referenced may also be used with character-strings from a non-binary data stream. The system 100 comprises a computer processing unit 102 with processing logic 114. The processing logic 114 may be configured to execute software instructions, and / or may comprise fixed-function hardware, for performing processing functions as described herein. The processing logic 114 is configured to receive the encoded data 106 (bit stream) in the system 100. Although it is not shown in Figure 4, the encoded data may be received from the memory 104, and portions of the encoded data may be stored in the cache 110. The processing logic 114 is configured to output decoded symbols 108. The decoded symbols 108 that are output from the processing logic 114 may be output from the processing unit 102 (as shown in Figure 4). In other examples (not shown in Figure 4) the decoded symbols 108 that are output from the processing logic 114 may be processed further in the processing unit 102, e.g. before they are output from the processing unit 102. As described above, in examples described herein, the system is used to decode a neural network data stream for use in training a neural network. In examples described herein, a neural network data stream includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data. As described above, neural network data is data that defines a neural network. For example, neural network data may be data defining parameters (i.e. weights and / or biases) to be applied by nodes (or “neurons”) of a neural network. The processing logic 114 may be implemented as an entropy decoder within the processing unit 102. In this case, the outputted decoded symbols 108 are processed by the processing unit to determine weights and / or biases of the neural network. The processing logic 114 accesses a plurality of sequential characters from the received data stream simultaneously, e.g. sequential bits from the received bit stream simultaneously. The number of bits that are accessed is the same every time a plurality of bits are accessed. For example, eight sequential bits from the bit stream may be accessed. The number of bits to be accessed may be referred to as the “fixed number”, which is eight in the examples described in detail herein, but in other examples could be other values. Just for the sake of giving some examples, the fixed number could be 4, 7, 9 or 10 in other examples. The fixed number of bits describes a sequence of bits in which the sequence of bits is a fixed number in length. The number of bits that are to be accessed each time (i.e. the fixed number) may be determined prior to processing the encoded bit stream. The fixed number of bits may be determined prior to receiving the bit stream. For example, the code used to compress the data stream may be known in advance by the system 100, and so the optimum length of the fixed number of bits to optimise the decoding process may be pre-determined. In an alternative example, after receiving the encoded bit stream, the received bit stream or a portion of the received bit stream may be analysed to determine an optimum number to use for the fixed number of bits. In a further alternative example, the length of the fixed number of bits may be determined during the decoding process, by analysing the received bit stream, or a portion of the received bit stream, so that the processing could be further optimised by adjusting the length of the fixed number of bits. The length of the fixed number of bits may be dynamically chosen. The fixed number (i.e. the length of the fixed number of bits) may be greater than or equal to the number of bits of each of at least 90% of the bit-strings included in the bit stream. Bigger acceleration tables (larger fixed number of bits) will ensure that a higher percentage of the symbols represented by the bit-strings in the bit-stream are indicated by the table. Increasing the size of the table may not affect the complexity of finding entries in the table, as the indexation of the table means the table is not searched. With this in mind, it may be beneficial to increase the length of the fixed number of bits. However, the larger the fixed number, the larger the acceleration table (the acceleration table may have 2n entries, where n is the fixed number), which will increase the amount of storage space required to store the table. To maximise the efficiency of using the acceleration table, it is preferable to keep the size of the acceleration table small enough to be stored in fast access memory, such as data caches described elsewhere herein. As such, with this in mind, it may be beneficial to decrease the length of the fixed number of bits. As such, there is a trade-off when deciding how long the fixed number of bits should be, and the optimum length of the fixed number of bits may be found by finding a satisfactory position in this trade-off. The increase in efficiency resulting from a small change in the number of bits used to access an acceleration table, i.e. a change of 1 or 2, is likely to be less than 5%. After the fixed number of characters e.g. bits has been determined, a data structure or table can be built for accelerating the decoding process. This acceleration table may be formed by an array of data, wherein each entry (row) in the acceleration table comprises data. Each entry of the acceleration table may comprise a data pair. Each data pair, or entry in the acceleration table, may be read in the same operation. The number of entries in the acceleration table may be defined by the maximum number of entries able to be distinctly identified by the selected fixed number of bits. In other words, the acceleration table includes an entry for each possible combination of the selected fixed number of bits. For example, if eight bits has been selected, the acceleration table is built with 256 entries. This enables the acceleration table to be indexable rather than requiring a search. An entry (e.g. a row) of the acceleration table may be identified using the accessed fixed number of bits from the bit stream. For example, the fixed number of bits taken as a sequence of bits from the bit stream may be used to indicate a binary number, and this binary number may be used as an index to identify an entry (e.g. a row) in the acceleration table. In other words, the binary number indicated by the fixed number of bits may be used to determine the row number (entry number) of the acceleration table. Alternatively, other methods may be used to identify the entry of the acceleration table from the accessed characters from the data stream, described elsewhere herein. In the examples described herein, the sequence of characters, e.g. bits, itself is not stored within the acceleration table; instead the sequence of characters is used as an index to identify an entry (e.g. a row) of the acceleration table. The sequence of characters itself does not need to be stored in the acceleration table because there is a one-to-one relationship between the possible combinations of characters within the fixed number of characters and the entries in the acceleration table. That is, every possible combination of the selected fixed number of characters represents an entry of the acceleration table. For example, the first row of the acceleration table may be identified by a fixed number of bits where all the bits are “0”, and the final row of the acceleration table may be represented by a fixed number of bits where all the bits are “1”. On the other hand, the entries of the table may be indexed in the opposite order, where the first row is identified when all bits are “1”. In other words, rows of the acceleration table may be stored or indexed as big-endian or little-endian. Alternatively, the indexes that identify each entry of the table may be in any order, e.g. mixed-up or seemingly random, as long as the acceleration table is built so that the represented symbol is indicated by the correctly indexed entry. The ordering and indexing of rows of the acceleration table may depend on the architecture of the computing device. The acceleration table 300 is populated using a dictionary of the code used to encode the compressed bit-stream. The dictionary may indicate which bit-strings are used to represent which symbol. The dictionary may be sent with the compressed bit stream, or the dictionary may be known in advance of receiving the bit stream. For example, where a universal code is used to compress a bit-stream, i.e., a prefix code that maps integers onto binary codewords such as Exp-Golomb, Elias Delta or Fibonacci code, it may not be necessary to send the dictionary as the mapping between the bit strings and the integers would be known by the system in advance. Entries of the acceleration table 300 with a row number (index) with a prefix of a bit-string used to represent a symbol in the dictionary, are populated by that symbol. A plurality of the entries of the acceleration table 300 may indicate a decoded symbol. There may be multiple entries in the acceleration table using different row numbers, but with the same prefix (e.g. if the prefix is shorter than the fixed number of bits). There may be multiple entries in the acceleration table which indicate the same decoded symbol. For example, for each of the bit-strings in the bit stream that have a number of bits that is less than or equal to said fixed number, the acceleration table may have at least one entry which indicates the decoded symbol represented by that bit-string. The plurality of the entries of the acceleration table that indicate a decoded symbol may further indicate a bit-length for the indicated symbol, wherein the bitlength is the number of bits in the bit-string that represents the symbol indicated by that entry. A plurality of the entries of the acceleration table may comprise a data pair comprising i) a decoded symbol and ii) an indication of the length of the bit-string representing the symbol. The fixed number of bits may be chosen so that a majority of the entries of the acceleration table comprise a decoded symbol and the length of the bit-string representing the symbol. An example of an acceleration table 300 is shown in figure 3. The table in figure 3 is built for use with eight bits at a time (i.e. it is configured to be queried with an 8-bit value, i.e. the fixed number is 8), and so has 256 rows or entries. Only some of the rows of the table 300 have been shown in figure 3 for clarity. The dictionary used to populate the rows is the same dictionary used for the binary tree and hash tables shown in figures 1,2a and 2b. The first row of the table is row 0, or 00000000 in binary using 8 bits. This binary number has a prefix of 00000, which is the bit-string used to represent the decoded symbol “c”. The prefix of the row number that is equivalent to the representative bit-string has been underlined in figure 3 for clarity. Rows 0 (00000000) to 7 (00000111) of the table all have a row number with a prefix of 00000, and so all these rows indicate the decoded symbol “c” in the first column. Rows 0 to 7 all have a data pair comprising the decoded symbol “c” and the bitlength of the bit-string used to represent “c” (00000). As “c” is represented by five zeros, the second column of all of rows 0 to 7 contains a 5. The subsequent row, row 8 or 00001000, has a prefix of 00001, which is the bit-string used to represent the decoded symbol “u”. Similar to the first eight entries of the table, the subsequent eight entries from 00001000 to 00001111 all indicate the decoded symbol “u” and the bit-length “5”. The symbol "e” is represented by the 3 bit bit-string “010”. Following the entry numbering system described above, rows 64 (01000000) to 96 (01011111) are populated with the decoded symbol “e” and the bit-length “3”. In this example, the symbol "a” is represented by the 4 bit bit-string “1010”, and figure 3 shows that rows 160 (10100000) to 175 (10101111) are populated with the decoded symbol “a” and the bit-length “4”. Figure 3 shows how other entries of the acceleration table can be indexed to indicate decoded symbols “k”, “w”, “f and “space” and their associated bit-lengths. From this description it will be apparent how the entries of the acceleration table 300 will indicate the symbols whose bit-strings have lengths that are less than or equal to the fixed number (i.e. less than or equal to 8 in this example). In the above example, the bits in the bit-stream when viewed as bytes are written such that the most-significant bit is received first. The bits may also be reversed, such that the least-significant bit is received first. How the bits are received may depend on the architecture of the computing device. The order of the rows in an acceleration table may depend on whether the computing device is big-endian or little-endian, to provide an efficient indexing of the table. There may be alternative mappings used for indexing of the table e.g. a XOR or a two’s-complement mapping scheme. The system 100 may be configured to query an acceleration table, such as the acceleration table 300 shown in figure 3. The system 100 may query the acceleration table with a fixed number of characters, such as a fixed number of bits of the received bit stream, to identify an entry of the acceleration table. The acceleration table may be built after the fixed number of bits has been chosen, and so the fixed number of bits from the received bit stream may indicate an entry number (or row number) of the acceleration table, which is the identified entry. When an entry of the acceleration table is identified that indicates a decoded symbol, the indicated decoded symbol may be output. The output decoded symbol may be stored in a memory (e.g. in the memory 104). The output decoded symbol may be stored in a buffer. The output decoded symbol may be stored in the cache 110. When an entry of the acceleration table is identified that indicates a decoded symbol, the bit-length indicated by that entry of the acceleration table may also be output. As well as, or instead of, storing the output decoded symbol and / or bit-length, the decoded symbol and / or bit-length may be output for further processing in the processing unit 102 and / or transmitted to another device, e.g. over a network such as the internet. Often the encoded data stream encodes multiple symbols. When one symbol has been decoded then the next symbol can be decoded. The output bit-length may be used to determine which fixed number of bits should be accessed to decode the next symbol of the bit stream. The first sequence of bits that forms the first fixed number of bits used to query the acceleration table may be the first fixed number of bits in the bit stream. The second sequence of bits used to query the acceleration table, and all subsequent sequences of bits, may depend on the output bit-lengths of previously decoded symbols. Consecutive sequences of bits that are used to query the acceleration table for decoding consecutive symbols may overlap with each other, e.g. if the length of the bit-string representing a first of the consecutive symbols is less than the length of the fixed number of bits in the sequences of bits that are used to query the acceleration table. A portion of the received data stream 106 may be stored in a buffer. This portion may comprise the sequence of the fixed number of characters to be used when querying the acceleration table. The portion may comprise more than the fixed number of characters of the data stream. For example, a read from the memory may fetch 32 bits at once, so the portion of the bit stream that is received include 32 bits of the bit stream. The portion of the received bit stream stored in the buffer may be shifted by a barrel shifter to position the fixed number of bits (e.g. 8 bits) for identifying an entry of the acceleration table at a predetermined location within the buffer. Barrel shifters may shift data by a specified number of bits within a single clock cycle. A barrel shifter may move bits around the buffer in which they are stored. The system 100 may be configured to access the fixed number of bits of the bit stream from the predetermined location within the buffer. In an example where eight bits are used to query the acceleration table, the eight bits may be accessed from the bottom 8 bits of a buffer without the need to mask out any bits, therefore reducing the number of operations required to access the bits. Alternatively, a fixed number of characters may be accessed from any predetermined location within the buffer, such as, but not limited to, the top of the buffer, or the left or right of the buffer. The buffer may be one of a plurality of registers 112 on the processing unit 102 of the computer processing system 100, such as one of the general purpose registers (GPRs). Registers on a processor may be quickly accessible by the processing logic 114. Processor registers, such as general purpose registers (GPRs), may provide the fastest way to access stored data. If the processing logic 114 accesses the same data repeatedly and frequently, holding the data in the registers 112 (rather than in the memory 104 or cache 110) may improve the computer’s performance. A typical register on a modern CPU, such as in a 64-bit computer processing system, will be able to store 64 bits. Increasing the number of bits read from the received bit stream at a time reduces the number of memory transactions. For an example 64-bit system, the system 100 may read 32 bits at a time, reducing the number of memory transactions. The 32 bits may be stored in the register. The barrel shifter may be used to position the fixed number of bits, for example 8 bits, in a predetermined location in the register by shifting the 32 bits. In an example, when the bit stream is first received, the first 32 bits of the bit stream may be read into the register. The barrel shifter may then be used so that the first 8 bits of the bit stream are in a predetermined location, such as at the bottom of the register, so that the bits may be accessed without masking. In this example, the bits will be shifted by 24 bits (32 minus 8). The 8 bits may then be used to query the acceleration table. The predetermined location may be any part of the buffer (or register) that has been indicated to be used as the index for querying the acceleration table. The amount by which to shift the bits in the register may be determined based on one or more bit-lengths of one or more symbols that have previously been output in respect of the portion of the received bit stream that is stored in the buffer or register. If the identified entry indicates a decoded symbol, the bit-length of the indicated symbol may be output. In an example, the barrel shifter may shift the 32 bits according to the output bit-length, so that the next 8 bits that will be used to query the acceleration table for decoding the next symbol are in the predetermined location in the register. The next 8 bits used to query the acceleration table may (or may not) include some of the bits used in the first 8 bits, but may not include the bits of the bit-string used to represent the previous decoded symbol. For example, if the previous decoded symbol has a bit-length of 5, the 32 bits in the register may be shifted by 19 (32 minus (5+8)). Whilst the first portion (e.g. 32 bits) of the bit stream is being processed, a subsequent portion (i.e. the next 32 bits) of the bit stream can be read into the registers 112. If there are less than the fixed number of bits, e.g. 8 bits, which have yet to be decoded from the first portion of the bit stream, then the fixed number of bits can include one or more of the bits from the subsequent portion of the bit stream which are stored in the registers 112. In an example using a 64 bit system, two 32 bit objects may be held in the register at any time. When all of the bits of the first portion of the bit stream have been decoded, the first portion of the bit stream may be displaced by the next portion (after the ‘subsequent portion’) of the bit stream that have yet to be loaded into the register. This ensures that the next fixed number of bits, e.g. 8 bits, will always be in the registers 112 for accessing the acceleration table, removing any latency from waiting for memory accesses for these bits. Such use of the registers increases the memory input / output efficiency, and reduces the average number of instructions executed per output decoded symbol. It is noted that the “subsequent portion” of the bit stream is the portion consecutive with the “first portion” of the bit stream. As an example, the bit stream may include bit-strings representing a sequence of symbols “c”, “a”, “k”, “e”. In the example shown in Figure 3, the bit stream encoding these symbols may have the following 20 bits: 00000101011000011010. 32 bits including these 20 bits can all be read into the registers 112 at once. In this example, the fixed number is eight. As such, the barrel shifter moves the bits so that the first eight bits (‘00000101’) of the bit stream are in the predetermined location in the registers 112 and are used to query the acceleration table 300. These eight bits identify row 5 of the table. The entry at row 5 of the acceleration table outputs the symbol “c” and the length “5”. For the next symbol, the barrel shifter shifts the bits by 5 positions so that the next eight bits (‘10101100’) of the bit stream are in the predetermined location in the registers 112 and are used to query the acceleration table 300. These eight bits identify row 172 of the table. The entry at row 172 of the acceleration table outputs the symbol “a” and the length “4”. For the next symbol, the barrel shifter shifts the bits by 4 more positions so that the next eight bits (‘11000011’) of the bit stream are in the predetermined location in the registers 112 and are used to query the acceleration table 300. These eight bits identify row 195 of the table. The entry at row 195 of the acceleration table outputs the symbol “k” and the length “8”. For the next symbol, the barrel shifter shifts the bits by 8 more positions so that the next eight bits (‘010XXXXX’) of the bit stream are in the predetermined location in the registers 112 and are used to query the acceleration table 300. The ‘X’s here represent bits in the registers after the 20 bits of the bit stream, where each of the ‘X’s may be zero or one. These eight bits identify one of rows 64 to 95 of the table depending on the values of the ‘X’s. The entries at all of rows 64 to 95 of the acceleration table outputs the symbol “e” and the length “3”. So the four outputted symbols are ‘c’, ‘a’, ‘k’ and ‘e’. It is noted that in this example, each of the symbols is represented with a bit-string of a different length, and each of the symbols is outputted following one (i.e. only one) query of the acceleration table 300. The above example, using the example acceleration table in figure 3, uses a binary data stream where the most significant bit is received first. In another example, bit-orderings may be reversed, such as when the least significant bit is received first, and the entries of the acceleration table may be ordered to reflect this. The byte-stream may be big-endian or little-endian. The barrel shifter of the above example may work similarly with any data stream containing characters, such as hexadecimal or genomic data. The example systems and methods are not limited to binary data. The processing logic 114 does not need to consider each bit of the bit stream in turn and make a decision in response to each bit. Instead, the fixed number of bits are accessed and used to query the table. The length of the fixed number of bits may be greater than the length of the bit-string representing the next symbol to be decoded, but this does not cause a problem. Where the length of the fixed number of bits is greater than the length of the bit-string representing the next symbol to be decoded, all of the possible combinations of bits in the fixed number of bits that start with the bits of the bit-string representing the next symbol will index an entry in the acceleration table that outputs the decoded symbol represented by that bit-string. One or more of the symbols which are encoded in the received data-stream may be represented by a long character-string, wherein a long character-string has more than the selected fixed number of characters. The system 100 may be configured to decode symbols that are represented by bit-strings that are longer than the determined fixed number of bits used to build the acceleration table. For example, in the dictionary used to populate the example acceleration table in figure 3, seen in full in the example binary tree in figure 1, symbols “x”, “q”, “z” and “j” are represented by a sequence of bits that is 10 bits long, i.e. has a bit-length of 10. The example acceleration table in figure 3 is built using 8 bits as the fixed number of bits, and so symbols “x”, “q”, “z” and “j” are represented by long bit-strings. Symbols with long bit-strings may not be indicated by an entry in the acceleration table. In other words, the first fixed number of bits of a long bit-string may identify an entry of the acceleration table that does not indicate a decoded symbol. Alternatively, the first fixed number of bits of a long bit-string may identify an entry of the acceleration table that does indicate a decoded symbol, for example when used to decode Exp-Golomb code the entry may comprise the character-length for the symbol. One or more of the entries of the acceleration table may be a long bit-string entry. A long bit-string entry may be identified by the fixed number of bits used to query the table when the fixed number of bits are a first fixed number of bits of a long bit-string representing a symbol. In the example of the acceleration table 300 of figure 3, the first 8 bits of the bit-strings representing symbols “x”, “q”, “z” and “j” are “11000010”. Therefore, row 194 of the table in figure 3 does not indicate a decoded symbol. This example long bit-string entry also does not indicate a bit-length for a bit-string, as the bit-length of the long bit-string is not known from accessing the first 8 bits. It is noted that due to the way in which the data was encoded in this example (e.g. using a Huffman encoding scheme), the likelihood of each bit being a one is intended to be approximately 50% and the likelihood of each bit being a zero is intended to be approximately 50%. As such, the likelihood of a bit-string from the bit stream indexing an entry is approximately equal for all of the entries in the acceleration table 300. In the example shown in Figure 3, only one of the entries of the table (row 194) is a long bit-string entry. In contrast 32 of the entries of the table (rows 64 to 95) indicate the symbol ‘e’ (because ‘e’ is a commonly occurring symbol in the bit stream). All long bit-string entries are used for symbols that occur infrequently in the bit stream. As such, any extra delay when processing a long bit-string entry is only infrequently incurred. In an example, one or more long bit-string entries of the acceleration table may identify an acceleration sub-table to be queried for determining the symbol represented by the long bit-string. An acceleration sub-table may be identified in a variety of different ways, using either the “symbol” field or the “length” field, or a combination of both. For example, the value in the “length” field for a long bit-string entry may identify an acceleration sub-table to be queried. The long bit-string entry in row 194 of the acceleration table 300 shown in figure 3 identifies sub-table A. In another example, a sub-table may be identified by having a sub-table number in the “symbol” field and a zero value in the “length” field. Alternatively, a sub-table may be identified by having a value in the “length” field that is greater than the fixed number of bits used to build the acceleration table e.g. greater than 8. A long bit-string entry may also indicate the width of the sub-table, i.e. the number of bits used to build the sub-table. In a further example, sub-tables may be concatenated together into a single table. If the sub-tables are concatenated together, then the entry in the parent (top-level) acceleration table would only need to identify a long bit-string entry, and would not need to identify the location in memory of the sub-table. These are not limiting examples. The system 100 may be configured to, in response to identifying a long bit-string entry of the acceleration table, query the identified acceleration subtable on the computer processing system with a subsequent fixed number of bits of the received bit stream to identify an entry of the acceleration sub-table. A plurality of the entries of the acceleration sub-table may indicate a decoded symbol to be returned. The system 100 may further be configured to, if the identified entry of the acceleration sub-table indicates a decoded symbol, output the decoded symbol indicated by the identified entry of the acceleration sub-table. The subsequent fixed number of bits used to identify an entry of the acceleration sub-table may be consecutive to the fixed number of bits used to identify the long bit-string entry of the parent acceleration table 300. In other words, the subsequent fixed number of bits will comprise bits of the long bit-string, and start from the next bit after the fixed number of bits used to access the parent acceleration table 300. An acceleration sub-table may be built using the same fixed number of bits as the acceleration table. Alternatively, an acceleration sub-table may be built using more or fewer bits than the acceleration table, and therefore have more or fewer rows (entries). Accordingly, the subsequent fixed number of bits used to access the acceleration sub-table may be the same as, or may be different from the fixed number of bits used to access the parent acceleration table. Furthermore, the subsequent fixed number of bits used to access an acceleration sub-table may be different depending on which acceleration sub-table is identified. Different acceleration sub-tables may be built using different numbers of bits. This may increase the efficiency of storing the sub-tables as some sub-tables may require fewer bits than others to determine the decoded symbol. Examples of different sized sub-tables are provided below. The number of bits used to access the sub-table may optionally be indicated by the long bit-string entry of the top-level table. As the dictionary for the encoded bit stream is known before the acceleration table and acceleration sub-tables are built, the size of the acceleration sub-tables may be optimized. The dictionary used in the example for the table in figure 3 has a maximum bit-length of 10 bits, while the acceleration table 300 is built for use with 8 bits. In this example it may not be optimal for the acceleration sub-table A to be formed using 8-bits, as this would lead to each symbol being indicated by 64 entries. In this example, it may be optimal for acceleration sub-table A to only require two subsequent bits to be accessed to determine the symbol represented by the long bit-string. An example of acceleration sub-table A built with two bits is shown in Table 1. The acceleration sub-table A may be designed to indicate a bit-length value of 10 for each of the symbols, as this is the full length of the bit-string that represents the symbols. Alternatively, as shown in table 1, the acceleration sub-table A may be designed to indicate a bit-length value of 2 for each of the symbols. In this example, the indication of a long bit-string entry in the top-level table may instruct the barrel shifter to shift the bits by 8 positions to access the subsequent bits in the bit-stream. The indication of sub-table A may instruct that only the 2 subsequent bits need to be accessed. These two bits may then be used to query sub-table A to identify the decoded symbol. Table 1: Example of acceleration sub-table A identified by the acceleration table of figure 3. Preferably, the barrel shifter may be used by keeping a record of the how many bits in the barrel shifter buffer have yet to be accessed (so far unused bits). When an acceleration sub-table is identified, the barrel shifter may be used to shift the subsequent required number of bits, e.g. 2 or 8, of the so far un-accessed bits to the predetermined location. These bits may then be accessed to query the acceleration sub-table. Therefore, when the acceleration sub-table is queried, the number of yet to be accessed bits is reduced by, for example, 2 or 8 bits. When a decoded symbol has been identified, the barrel shifter may then shift the subsequent fixed number of bits to the predetermined location. Tracking the number of bits in the barrel shifter buffer which have yet to be accessed may be used to determine when to read the next sequence of bits from the memory, for example the next 32 bit object. Alternatively, the barrel shifter may move the bits in the buffer each time bits are accessed to query an acceleration table and a bit-length is output. There may be multiple acceleration sub-tables identified within one top-level acceleration table. These acceleration sub-tables may all be the same size, based on the same number of bits, or they may vary in size. The acceleration sub-tables may, or may not, be built to use the same number of bits as the parent (top-level) acceleration table. Each acceleration sub-table may be optimized by using a different number of bits for each sub-table, once the dictionary is known. It may be optimal to build each acceleration sub-table with the same number of bits. For example, if the same example dictionary of figure 1 was used to populate a top-level acceleration table built based on the use of 4 bits as a fixed number of bits, the table would have long bit-string entries at 0000, 1000, and 1100. Each of these entries may identify a separate acceleration sub-table, e.g. sub-table A, B and C respectively. Sub-table A may only be based on 1 bit, i.e. have two entries to indicate either “c” or “u”. Subtable B may be based on 2 bits, to identify “b”, “p”, “g” and “y”. Sub-table C may be based on 6 bits. Alternatively, sub-tables A, B and C may all be built using the same fixed number of bits. There may be long bit-strings that are longer than twice the fixed number of bits used for the acceleration table. To decode these long bit-strings, the acceleration subtable may be built using more bits than the fixed number of bits used for the parent acceleration table, e.g. in the example above sub-table C is accessed with 6 bits whilst the parent table is accessed with 4 bits. Alternatively, the acceleration subtable may itself identify a further sub-table, such that there may be multiple levels of sub-tables. Using the example where the top-level acceleration table is built based on 4 bits with the dictionary used for figure 1, the acceleration sub-tables may also be built based on 4 bits. In this example, the acceleration sub-table C may indicate the symbols “v”, “k”, “w”, “m” and “f”, and the sub-table C may also have a long bit-string entry at 0010. This long bit-string entry may indicate an acceleration sub-sub table, for example C1. The acceleration sub-sub-table C1 may indicate the symbols “x”, “q”, “z” and “j”. An example method 200 is shown in figure 5. The method 200 may be used with any variations of the system 100. At step 202, a data stream (e.g. a bit stream) is received at the processing logic 114. As described above, the bit stream may be received from the memory 104. The bit stream is encoded using a variable-length prefix code. The bit stream includes variable-length bit strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, such as Huffman encoding. As described above, the received bit stream is an example of a data stream, and the method 200 may be used with any received data stream, containing character-strings to represent symbols, encoded using a variable-length prefix code. As described above the symbols may represent any suitable data, such as image data, video data, signal data, audio data, or any other type of data. As described above, a fixed number of bits may be determined. As described above, the fixed number of bits may be pre-determined before the bit stream is received, or may be determined based on the received bit stream. An acceleration table may be formed as described previously based on the determined fixed number of bits. The acceleration table has an entry for each possible combination of bits in the fixed number of bits, e.g. where the fixed number of bits is 8 bits then the acceleration table has 256 entries which can be indexed using the fixed number of bits. At step 204, the processing logic 114 uses a first fixed number of characters (e.g. bits), being the first sequence of characters (e.g. bits) of the received data stream and being a fixed number in length, to query the acceleration table to identify an entry of the acceleration table. As described above, each of a plurality of the entries (but not necessarily all of the entries) of the acceleration table indicates a decoded symbol to be returned. Each of the plurality of the entries of the acceleration table also indicates a character-length (e.g. a bit-length) for the indicated symbol. At step 206, the processing logic 114 determines whether the entry of the acceleration table indicates a decoded symbol. If a decoded symbol is not indicated, the method moves to step 208. At step 208, the processing logic 114 queries an acceleration sub-table, which was indicated by the identified entry of the acceleration table, using a subsequent number of characters (e.g. bits) to identify an entry of the acceleration sub-table. The method then returns to the decision at step 206, and the processing logic 114 determines whether the identified entry of the sub-table indicates a decoded symbol. If the identified entry of the acceleration table, or acceleration sub-table, does indicate a decoded symbol, the method moves to step 210. In step 210 the processing logic 114 outputs the identified decoded symbol and the respective character-length (e.g. bit-length) of the character-string (e.g. bit-string) used to represent the decoded symbol. If the identified entry of an acceleration table or acceleration sub-table does not indicate a decoded symbol, the loop of step 206 and step 208 will repeat until the character-string (e.g. bit-string) has been decoded and the decoded symbol has been output in step 210. After the decoded symbol has been output, at step 212 the processing logic 114 determines whether the end of the received data stream (e.g. bit stream) has been reached. If the end of the data stream has not been reached, the method returns to step 204, and the processing logic 114 queries the acceleration table with a different sequence of characters as the ‘fixed number of characters’ to identify an entry. The method proceeds from step 204 as described above. If in step 212 the processing logic 114 determines that the end of the data stream has been reached, the method moves to step 214 and all the decoded symbols from the bit stream are output. The potential of using too many recursive sub-tables can be avoided by ensuring that each table is built using a suitable number of bits. Infinite recursion may be avoided as the maximum bit-string length would require a limited number of recursive tables. For example, a 4GByte input stream that has been encoded using Huffman encoding would require a maximum of four recursive tables built for access with 8 bits. The chance of recursing four times is extremely small. Even if four recursive tables are required, the hardware resource requirements are small, and known prior to decoding the input stream. A software implementation of the method may use tail-recursion to eliminate recursive calls, reduce stack usage, and allow all relevant variables to live in high-speed general purpose registers. Other methods may be implemented for decoding (decompressing) a data stream using an acceleration table as described herein. The method used may depend upon which encoding scheme is used to compress the data stream. For example, the method 300, shown in figure 6 and described below, may be preferably used when a universal encoding scheme is used such as exponential-Golomb encoding. A universal code is a prefix code that maps integers (any natural number) onto codewords e.g. binary codewords or bit-strings. As there are infinite numbers which may be in the data stream, there may be an infinite number of codewords to encode the integers. It is therefore not practical to create a dictionary mapping the integers to representative bit-strings. It is not necessary to produce or send a dictionary which maps the bit-strings to the integers for such a universal code as long as the decoding system knows the universal code which has been used to compress the data stream. Exp-Golomb coding is an example of a universal code which makes use of a number of zeros at the beginning of each binary codeword to indicate how many bits follow the number of zeros within the codeword. Therefore, if the number of zeros at the beginning of the bit-string is known, then the full length of the bit-string is known. For example in an Exp-Golomb code, when a bit-string begins with 3 zeros followed by a one, the 3 zeros indicate that the next 4 bits, following the 3 zeros and including the first one, will complete the bit-string. Similarly, a bit-string beginning with 7 zeros (exactly) indicates that the next 8 bits will complete the current bit-string. The following bits after the zeros can be directly read from the data stream to give the represented integer. The decoding of such universal codes may be improved over prior art methods by use of the acceleration tables described herein, for example, via method 300 shown in Figure 6. The acceleration table used for decoding an Exp-Golomb encoded data stream may have the form of any acceleration table described herein. The acceleration table may be structured such that each entry of the acceleration table has three cells for data, i.e. the table may have three columns. The acceleration table may be structured such that one of the three cells (columns) is empty in each entry (row). The number of columns in the acceleration table may be varied, for example there may be 2, 3 of 4 columns in an acceleration table. The acceleration table may be structured such that each entry comprises a data pair. For example, there is data in two of the three columns. An example of acceleration table for decoding an Exp-Golomb encoded data stream is shown in Table 2. Each column may comprise data with a consistent interpretation. Typically, an entry in an acceleration table will only have two data points, and so preferably an acceleration table may be formed using two columns. A column of the acceleration table may comprise data with inconsistent interpretations, indicating different instructions to the system in different entries. Tables with more than two columns where each entry comprises only two cells of data may be implemented using the same memory requirements as a table with two columns, via a variety of methods known to the skilled reader. As described elsewhere herein, the acceleration table may be accessed by a fixed number of characters (bits). The said fixed number of bits may be used to identify the index of the row (entry) of the acceleration table. In an example, the acceleration table may be accessed using 9 bits, such that the fixed number is 9. The example acceleration table in Table 2 is accessed by 9 bits. The acceleration table has an entry for each possible combination of bits in the fixed number of bits, e.g. where the fixed number of bits is 9 bits then the acceleration table has 512 entries which can be indexed using the fixed number of bits. The fixed number of characters represents an index of the identified entry in the acceleration table. Each entry of the acceleration table comprises data. Each of a plurality of the entries of the acceleration table may indicate a decoded symbol to be returned using both data of the entry and the index of the entry. The data of each of the plurality of entries may comprise a character-length for the indicated symbol. For integers represented by a character-string of the fixed number of characters or fewer, the entries indexed by the fixed number of characters may comprise a data pair of i) a decoded symbol (integer) and ii) the length of the character-string (bit-string) representing the symbol. The length of the character-string may indicate how many bits of the bit stream to consume, in other words, the number of bits to shift in the barrel shifter, as described above, before reading the next fixed number of bits of the bit stream or before accessing the acceleration table with the subsequent fixed number of bits. Alternatively, for example when the data is encoded by a universal code, these entries may only comprise the length of the character-string (bits to consume), as the decoded symbol can be determined by the system directly from the bit stream once the length of the bit-string is known. Indicating the decoded symbol within the acceleration table improves the efficiency of the system as it reduces the number of reads of the data stream. In an example where an acceleration table accessed with 9 bits is used to decompress an Exp-Golomb encoded data stream, such as in Table 2, all bit-strings beginning with 4 zeros or fewer will have a total length of 9 bits or fewer, and so the decoded symbol may be indicated by the table for these entries. For Exp-Golomb codes, an acceleration table accessed by 9 bits would therefore include entries indicating integers (symbols) from 1 to 31. For integers represented by a bit-string longer than the fixed number of bits, the long bit-string entry indexed by the fixed number of bits (the first fixed number of bits of the long bit-string) may comprise different data than for shorter bit-strings. When an Exp-Golomb encoding scheme is used, the full length of the bit-string may be known if the number of zeros at the beginning of the bit-string is less than the fixed number and so the number of zeros is known. For example, in an acceleration table accessed by 9 bits, if the bit-string begins with 8 or fewer zeros then the length of the bit-string is known from the fixed number of bits. However, the symbol (integer) represented by the long bit-string is not yet known. These entries of the acceleration table may therefore comprise data indicating how many bits of the fixed number of bits currently accessed are required and how many further bits are required to be accessed to determine the symbol (integer). For example, if the number of zeros at the beginning of the bit-string is less than the fixed number of bits, the entry may comprise a data pair of i) the number of zeros at the beginning of the long bit-string and ii) the number of bits following the zeros to be read to complete the long bit-string. Such entries in example Table 2 indicate the number of zeros at the beginning of the long bit-string as the number of bits to consume, i.e., the number of bits to shift in the barrel shifter, and the number of bits following the zeros in the complete bit-string as the number of bits to read to determine the symbol, i.e., the number of bits to read following the shift in the barrel reader. Alternatively, the long bit-string entry may comprise a data pair of i) the number of bits already accessed (i.e. the fixed number) and ii) the number of further bits needed to complete the bit-string. Using the information indicated by the acceleration table, the data stream may then be read to determine the decoded symbol (integer) represented by the long bit-string without further reference to a look-up table. For Exp-Golomb codes, an acceleration table accessed by 9 bits would therefore comprise entries indexed by the first 9 bits of the long bit-strings that completely decode short bit-strings representing the integers from 1 to 31, represent the integers from 31 to 511 without requiring a further look-up or acceleration table, whilst larger values would use a sub-table. Table 2: Example of an acceleration table suitable for decompressing an 5 Exp-Golomb encoded data stream. Only some of the rows of the table are shown for clarity. Symbol # bits to consume # bits to read Sub Table to use Ixxxxxxxx 1 1 - - OlOxxxxxx 2 3 - - Ollxxxxxx 3 3 - - OOlOOxxxx 4 5 - - . . . OOOllllxx 15 7 - - 000010000 16 9 - - 000010001 17 9 - - . . . 000011111 31 9 - - OOOOOlxxx - 5 6 - 0000001XX - 6 7 - 00000001X - 7 8 - 000000001 - 8 9 - 000000000 - 9 - A Exp-Golomb encoded data streams may also contain larger integers represented by long bit-strings which begin with a number of zeros that is equal to or greater than io the fixed number of bits used to access an acceleration table. For example, for an acceleration table accessed by 9 bits, the long bit-string may begin with 9 or more zeros. The entry of the acceleration table indexed by all zeros may comprise a data pair of i) the number of bits of the bit string already accessed and ii) an indication of an acceleration sub-table. For example, in Table 2, the entry indexed by all zeros 15 indicates a 9 as the number of bits to consume, i.e., the number of bits the barrel shifter should move the data, and an A to identify an acceleration sub-table to be queried with subsequent bits of the bit stream. As described previously herein, an acceleration sub-table may be identified in a variety of different ways. Acceleration sub-tables for Exp-Golomb code may function similarly to acceleration sub-tables described elsewhere herein. Acceleration sub-tables for Exp-Golomb code may function similarly to the acceleration table described above for long bit-strings, i.e., if the number of zeros in the bit-string is known, the length of the bit string is known but the integer represented by the long bit-string is not yet known. Using the length of the bit string indicated by the acceleration sub-table, the data stream may then be read to determine the decoded symbol (integer) represented by the long bit-string without further reference to a look-up table. For Exp-Golomb codes, an acceleration sub-table accessed by only 5 bits, with a top-level acceleration table accessed by 9 bits, would therefore comprise entries that represent the integers from 512 to 16383 without requiring a further look-up or acceleration table. Larger integers may be decoded by using a bigger acceleration sub-table, or by using sub-sub-tables, as described elsewhere herein. An example method 300 is shown in figure 6. The method 300 may be used with any variations of the system 100. The method 300 may be used to decompress a data stream encoded using Exp-Golomb code. At step 302, a data stream (e.g. a bit stream) is received at the processing logic 114. Step 302 is similar to step 202 of method 200 described above. At step 304, the processing logic 114 uses a first fixed number of characters (e.g. bits), being the first sequence of characters (e.g. bits) of the received data stream and being a fixed number in length, to query an acceleration table to identify an entry of the acceleration table. As described above, each of a plurality of the entries (but not necessarily all of the entries) of the acceleration table indicates a decoded symbol to be returned. Each of a second plurality of entries of the acceleration table indicates a character-length (e.g. a bit-length) for an encoded symbol (integer). At step 306, the processing logic 114 determines whether the entry of the acceleration table indicates a decoded symbol. If the identified entry of the acceleration table does indicate a decoded symbol, the method moves to step 310. In step 310 the processing logic 114 outputs the identified decoded symbol and the respective character-length (e.g. bit-length) of the character-string (e.g. bit-string) used to represent the decoded symbol. If a decoded symbol is not indicated in step 306, the method moves to step 307. At step 307, the processing logic 114 determines whether the entry of the acceleration table indicates a character-length for an encoded symbol, and as such, whether the character-length for the symbol is known. If the character-length of the symbol is known, the method moves to step 310. The decoded symbol may be read from the data stream using the known character-length. As above, in step 310 the processing logic 114 outputs the decoded symbol and the respective character-length. If step 307 determines that a character-length is not known, the method moves to step 308. At step 308, the processing logic 114 queries an acceleration sub-table, which was indicated by the identified entry of the acceleration table, using a subsequent number of characters (e.g. bits) to identify an entry of the acceleration sub-table. The method then returns to the decision at step 306, and the processing logic 114 determines whether the identified entry of the sub-table indicates a decoded symbol. If it is determined at step 306 that the identified entry of an acceleration table or acceleration sub-table does not indicate a decoded symbol, the method proceeds from step 307 as described above. If the identified entry of the acceleration table, or acceleration sub-table, does indicate a decoded symbol, the method moves to step 310. After the decoded symbol has been output in step 310, at step 312 the processing logic 114 determines whether the end of the received data stream (e.g. bit stream) has been reached. If the end of the data stream has not been reached, the method returns to step 304, and the processing logic 114 queries the acceleration table with a different sequence of characters as the ‘fixed number of characters’ to identify an entry. The method proceeds from step 304 as described above. If in step 312 the processing logic 114 determines that the end of the data stream has been reached, the method moves to step 314 and all the decoded symbols from the bit stream are output. Other methods may be used to decode symbols represented by long bit-strings. The system 100 may be configured to in response to identifying a long bit-string entry of the acceleration table, concatenate a subsequent bit of the bit stream to the fixed number of bits to form a set of bits. The subsequent bit may be a single subsequent bit, which is the next bit following the fixed number of bits used to query the acceleration table. The system 100 may be configured to determine whether the set of bits matches a long bit-string that represents a decoded symbol and, if the set of bits matches a long bit-string that represents a decoded symbol, output the decoded symbol. Various methods may be used to determine if the set of bits matches a long bit-string representing a decoding symbol. The system 100 may be further configured to, if the set of bits does not match a long bit-string that represents a decoded symbol, concatenate another subsequent bit from the bit-stream to form a further set of bits and determine whether the further set of bits matches a long bit-string that represents a decoded symbol. In one example method to determine if the set of bits matches a long bit-string, a series of hash tables may be pre-built, before decoding the bit stream. For each of the fixed number of bits that identify a long bit-string entry of the acceleration table, a separate hash table may be built containing all the symbols represented by a long bit-string with this prefix. The table may not have a row (entry) for every possible combination of the subsequent bits. The hash table may have a row for each of the bit-strings with a prefix of the fixed number of bits used to access the acceleration table. The hash table may be similar to the example hash table in figure 2a. Determining whether the set of bits, comprising the fixed number of bits and the subsequent bit, matches a long bit-string may comprise accessing the hash table with the set of bits, similar to the method used with the example table in figure 2a, described previously. In other words, after each bit is read and concatenated to the set of bits, the current set of bits is tested against a specified hash table to determine if the bit-string for the symbol is complete. This method still makes use of the efficiency provided by the use of an acceleration table for the majority of symbols. Reading the bits one at a time for the remaining symbols represented by long bit-strings still enables an efficient system as there are not many long bit-strings included in each of the hash tables, and the majority of symbols are not represented by long bit-strings. In particular, it is noted that due to the way in which the data is encoded, long bit-strings occur infrequently in the bit stream, so the costs involved in processing long bit-strings do not have a large effect on the overall performance of the decoding process. In another example method to determine if the set of bits matches a long bit-string, a binary decoder tree may be pre-built prior to decoding the bit stream, such as the example binary tree in figure 1. The binary tree may be used similarly to the previously described method for the binary tree in figure 1. Where a fixed number of bits identifies a long bit-string entry of the acceleration table, the long bit-string entry may indicate a node in the binary tree that equates to the fixed number of bits used to identify the long bit-string entry. The method may jump to the indicated node of the binary tree, skipping the first fixed number of decisions and branches of the tree. The method may then read the subsequent bit of the bit stream, following the fixed number of bits, and continue to traverse the tree, reading one bit at a time, until a leaf node is reached, thereby determining the symbol represented by the long bit-string. The performance of the methods disclosed herein may be improved by storing data and code in the appropriate memory on the CPU. A processing unit 102, e.g. a CPU, contains internal memory referred to as ‘general purpose registers’ 112 (GPRs). CPUs may execute operations using registers 112 around 100 times quicker than operations which require accessing memory 104. Modern CPUs 102 also include further memory 110 as buffers, referred to as caches. There may be multiple caches on a CPU, subdivided into L1, L2 and sometimes an L3 cache. The L1 cache (e.g. cache 110) is the fastest, enabling operations to be performed around 3-4 times slower than those that use GPRs, but is also the most expensive in terms of hardware size, and so it is typically the smallest. The L1 cache may be outside of the core CPU logic, but within the CPU chip. Each CPU core in a multi-core CPU typically has a separate L1 cache. The on-chip L1 cache may be divided into two parts, half used for data and half used for code. The L2 cache is slower but cheaper. The L2 cache may be off the CPU chip, and is 3-4 times slower than the L1 cache, but still 25 or 50 times faster than an external memory 104. The L2 cache is usually shared by all CPU cores within a chip. Some systems may have an L3 cache. Physically, the L3 cache usually is off-chip, and is shared by all CPU chips in the system. It is slower than the L2 cache, but larger, and it is still much faster than external memory 104. The decoding process described herein may be implemented in hardware (e.g. in fixed-function circuitry) or software (e.g. by running a program on a processing unit) or any combination thereof. In a software-implemented example, an optimal high performance decoding process may fit within the design constraints of the CPU it is running on. Specifically, for optimal performance: the code to be executed may be small enough to fit inside the CPU L1-Code cache, to avoid latency penalties due to accessing an external memory; the data accessed by the algorithm may be stored in the CPU L1-Data cache; and the instructions used to implement the code may store variables in registers 112 rather than memory 104. Modem CPUs typically have 64kB of L1 cache divided into 32kB for Code and 32kB for data. Since each core usually has its own L1 Cache, a typical 4-core CPU will typically further subdivide these L1 caches into 4 quarters. Consequently, a single core (thread) may be serviced with an 8kB L1-code cache, and an 8kB L1-Data cache. Code used to carry out the methods disclosed herein may be less than 8kB, and so may be stored on the L1 cache. Carefully written code may be executed entirely from the smaller but faster GPRs, without stack accesses. Therefore the methods herein can be run with high performance on existing CPU designs. The memory used to store the acceleration table may be small, for example less than 2kB, preferably less than 1kB. There may be a range of formats possible for the acceleration table. An example of an efficient format may be to store an array of data pairs, for example comprising i) a decoded symbol and ii) the length of bit-string representing the symbol. The CPU may read both parts of the data pair in the same read operation. In an example where the table has 256 data pairs (e.g. when accessed using 8 bits), the acceleration table only requires 512 bytes to store the table. As the data in the table will be in regular use and has small memory requirements, the table may be stored in the CPU’s L1 Data cache. In other words, the acceleration table may be stored in the on-chip cache of the computer processing system. Typically, only a small number of acceleration sub-tables may be required, for example, less than eight. The L1 cache is typically large enough, e.g. 8kB, that multiple acceleration tables of 512 byte size may be stored in the L1 Data cache. Acceleration sub-tables may be stored in the CPU’s L1 Data cache. The entire set of the acceleration table and necessary acceleration sub-tables may be stored in the CPU’s L1 Data cache. The set of the acceleration table and necessary acceleration sub-tables may only require a portion of the available L1 Data cache. Storing the acceleration table in the CPU’s L1 Data cache, rather than external memory 104, will have a significantly beneficial effect on the performance of the system and methods disclosed herein. An example method may require more than 15 acceleration sub-tables. If each table requires 512 bytes, more than 16 tables may not fit into the CPU’s L1 Data cache. The probability of requiring this many sub-tables is very low. The acceleration subtables may be accessed far less frequently than the parent (main) acceleration table. The majority of the acceleration tables may be in the CPU’s L1 Data cache. The acceleration sub-tables which are accessed least often, may be in the L2 cache. Accessing the L2 cache is slower, but the sub-tables stored in the L2 cache will be accessed infrequently, and so have little effect on the overall performance of the method. The methods disclosed herein may run efficiently on any suitable processing units including modern CPUs or CPUs manufactured in the last 20 years. The method may be run on a graphics processing unit (GPU), a neural network accelerator (NNA), a digital signal processor (DSP) or any other suitable processing unit. The acceleration table may be built before receiving the encoded bit stream. If the dictionary used to compress the yet-to-be-received bit streams is known, then the acceleration table may be built prior to receiving the bit stream. The acceleration table may be pre-determined. In an example system, a pre-determined acceleration table may be implemented in hardware. For example, to process a bit stream from a Huffman encoder working on byte data, the theoretical maximum size for all acceleration tables and sub-tables is 64kB, which could be implemented in hardware using 64kB of buffer memory. An example hardware implementation may comprise implementing 128 concatenated acceleration tables, each accessed using 8 bits, and so each requiring 512 bytes. In this example system, each bit-string representing a symbol with a length of eight bits or less may identify an entry of a table indicating the decoded symbol and bit-length of the bit-string representing the symbol. Long bit-string entries may comprise a data pair identifying an acceleration sub-table, or identify the bit-length of the bit-string representing the symbol. The example method using this hardware implementation may not require dynamic allocation of subtables. Further, the address of the sub-tables may not need to be stored separately, as they may be captured in the data pair identifying the acceleration sub-table. A hardware implementation may implement an 8byte / 64bit (or larger) output buffer stage to further reduce memory IO. Alternatively, the acceleration table may be built after receiving the encoded bit stream. The acceleration table may be formed in dependence on the received bit stream. The cache requirements for each size of acceleration table may be easily computed and evaluated to determine the optimal size. In an example, the system 100 may be configured to dynamically choose the fixed number to optimise the percentage of bit-strings in the bit stream that are represented by symbols indicated by entries of the acceleration table. Dynamically choosing the size of the acceleration table may improve the performance of the system. For clarity, many examples used throughout this document have been based on an 8 bit acceleration table (an acceleration table accessed using 8 bits). The value of 8 is a pragmatic choice as it provides: high probability that symbols occur in the first (parent) acceleration table, efficient implementation in code, and efficient use of L1-Data cache. For some encoded bit streams, a larger, or a smaller number of bits may result in better performance. Even if 8 bits were chosen for the first (parent or top) level table, values other than 8 may be more suitable for acceleration sub-tables. Acceleration tables may be based on a number of bits between 2 and 16, more preferably between 4 and 12 bits. To give some more specific examples, acceleration tables may be based on using 7, 8 or 9 bits. The methods and systems disclosed herein function regardless of the number of bits used to determine the size of an acceleration table. The high performance achieved by the methods and systems disclosed herein is gained by a multitude of enhancements over prior art techniques. There may be efficient reading of the bit stream, e.g. by reading multiple bits at a time e.g. 32 rather than 1 . There may be cheap pre-computation of an acceleration table enabling non-branching code which allows the CPU to execute without stalls and data which fits inside the CPU L1-Data cache. Decisions in the code are relatively predictable, such as step 206 in example method 200, as the acceleration table may be built such that the majority of the time a symbol is identified and output. Predictable decisions reduce latency in the code. There may be a small code size, so that the code fits inside a single CPUs L1-Code cache. The simplicity of the code may enable the variables to live in registers and not the stack. The memory transactions may be limited to reading in the bit stream and writing out the decoded symbols. These enhancements enable a performance gain of the order of 3 to 10 times over prior art techniques. This performance gain may be used in multiple ways, such as but not limited to: allowing the use of larger bit-streams than previously possible, e.g. allowing for larger video resolutions to be supported; providing support for current in-the field devices that were previously too slow; allowing less wattage to be used processing existing bit-streams; allowing a hardware device to run using a slower clock rate, thus saving even more power; reducing heating on existing devices; extending battery life on existing devices; or allowing future devices to be built using smaller batteries. The systems and methods disclosed herein may decode any data stream encoded using a variable-length prefix code. In particular, examples described herein are particularly useful for decoding a neural network data stream. In examples described herein, a neural network data stream includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data. As described above, neural network data is data that defines a neural network. For example, neural network data may be data defining parameters (i.e. weights and / or biases) to be applied by nodes (or “neurons”) of a neural network. These examples can improve the efficiency of the exchange of the vast amount of data between computers of a group which operate together to train a large neural network. This can be achieved without changing any of the training methods or any of the proprietary algorithms currently in use. Rather the techniques described herein can change an entropy coder, thereby changing the encoding method used to encode this data for distribution between computational units. The use of the techniques described herein in an entropy decoder radically improves the speed of the entropy decoder, which is often the limiting factor in the entire decoding process (since entropy decoding is a serial process not a parallel process). For example, the techniques described herein improve the speed of an entropy decoder at least three-fold, with independent expert analysists suggesting a typical speed up is x5 to x20 compared to the prior art. It is worth noting that this can be achieved without changing the learning algorithms used in the training process. The systems and methods may accelerate any existing decoders of variable-length prefix code data, such as Huffman, Golomb, Rice, Fibonacci, Exp-Golomb, Unary, Elias Delta and Elias Gamma decoders. Some currently known prefix encoding systems are rarely made use of for compressing data streams in the prior art as they are computationally expensive to decompress. For example Fibonacci encoding is based on Zeckendorf's theorem. Despite offering theoretical benefits, it is rarely used because of the excessive processing effort required to decode a Fibonacci bit stream using prior art methods. In prior art methods, not only must bits be parsed one at a time to determine the length of a symbol, but also for each bit the addition of a Fibonacci number may be required. The Fibonacci sequence is a series of numbers where each number is the sum of the two preceding numbers. For example, the first 25 Fibonacci Numbers (starting with 1 and 2) are: 1,2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181,6765, 10946, 17711,28657, 46368, 75025, 121393. The Fibonacci numbers can be used to encode any natural number as the sum of a combination of the Fibonacci numbers. A trailing T can be used to indicate the end of a number. For example, a bit-string of 1s and 0s can be used to indicate whether or not each particular Fibonacci number in the Fibonacci sequence is to be included in a sum which represents the encoded number. This works because, due to the nature of the Fibonacci sequence, no two consecutive Fibonacci Numbers will be used to represent a natural number. For example, using a trailing 1 to indicate the end of the number, the number 48 can be encoded as a bit-string ‘100001011 ’ which would indicate the sum 1+13+34, which gives 48. To give some more examples: - the number 256 can be encoded as a bit-string ‘0100001000011 ’ which indicates the sum 2+21+233, - the number 65536 can be encoded as a bit-string ‘101000000100101000001011 ’ which indicates the sum 1 +3+ 89+377+987+17711+46368, - the number 376 can be encoded as a bit-string ‘0101010101011’ which indicates the sum 2+5+13+34+89+233 - the number 377 can be encoded as a bit-string ‘6000000000001T. As can be seen in the examples given above 376 is the largest number that can be represented with 13 bits in this Fibonacci encoding scheme. If the Exp-Golomb encoding scheme were used then 17 bits would be used to represent a value of 376. Similarly, the Fibonacci encoding scheme can represent a value of 75024 using just 24 bits (using a bit-string of 101010101010101010101011), whereas in the Exp-Golomb encoding scheme 33 bits would be used to represent a value of 75024. The Fibonacci encoding scheme can encode data using a smaller number of bits than other encoding schemes, and this is particularly the case for larger numbers. For example, if you double a value then the Exp-Golomb encoding scheme will use 2.00 extra bits to encode the value, whereas the Fibonacci encoding scheme will use 1.44 extra bits to encode the value. In general, as the value to be encoded increases, the size of the bit-strings that are used to encode the value using the Fibonacci encoding scheme grows 25% slower than the bit-strings that are used to encode the value using the Exp-Golomb encoding scheme. The decoding methods and systems described herein enable the decoding of a Fibonacci encoded data stream using an acceleration table with the same processing requirements as other encoding schemes. An example of a suitable acceleration table, accessed with 8 bits, for decoding a Fibonacci encoded data stream is shown in Table 3. Some entries have been omitted from Table 3 for clarity. The entries of the table may be listed in any order. As described elsewhere herein, entries may identify an acceleration sub-table e.g. A, B, C etc., to decode the symbol (integer) represented by the bit-string. Table 3: Example of an acceleration table suitable for decompressing a Fibonacci encoded data stream. Use of Fibonacci encoded data may be advantageous as it may lead to a shorter data stream than, for example, Exp-Golomb encoded data. The systems and methods disclosed herein may enable use of unused or little-used encoding schemes that have previously been considered to be too computationally expensive, or new encoding systems. Due to the huge performance gains provided by the decoding techniques described above, it becomes feasible to overcome the inertia in the industry to changing the encoding schemes, and to use a new entropy encoder based on advanced mathematics, such as the Fibonacci encoding scheme. This new entropy encoder provides a theoretical reduction in bit-stream of up to 25%, whilst generating a 100% identical output data stream (i.e. there is no loss of information), and due to the decoding techniques described herein, the encoded data stream can still be decoded at a very high speed. In order, to use the newer smaller bit-stream requires a change to both the encoder and decoder, but it does not change the tools used in the learning algorithm codec itself - rather it replaces the entropy encoder / decoder, which can be done entirely in software. Whilst the systems and methods have been described in terms of decoding ‘bit streams’, they may also function efficiently on other data types, such as hexadecimal data. More broadly, the decoding systems and methods described herein could be used to decode a data stream which includes variable-length character strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme. The data stream is received and an acceleration table can be queried with a fixed number of characters of the received data stream to identify an entry of the acceleration table, where each of a plurality of the entries of the acceleration table indicates a decoded symbol to be returned. In the examples described above, the data stream is a bit stream, the character-strings are bit-strings and the characters are bits. However, in other examples the characters do not necessarily need to be binary bits, for example they could be decimal or hexadecimal numerals, genomic data or protein sequences. The systems and methods disclosed herein may run on all existing processors, boost decoding speeds by more than 3 times existing speeds, and dramatically reduce energy consumption, curbing device overheating and extending battery life. The systems and methods may work with existing encoded streams, without requiring modifications to the encoder. The systems and methods disclosed herein may: allow existing software systems to run more than 3x faster, or use more than 3x less energy; enable existing systems to tackle jobs that are more than 3x bigger; enable tasks that previously needed dedicated hardware to be run entirely in software; allow new-starters to enter the market, without needing to build dedicated hardware; allow existing hardware manufactures to build a next generation solutions with better hardware, securing their market position. Encoding using variable-length prefix code, such as Huffman encoding and Exp-Golomb encoding, has numerous real world applications across various fields. The systems and methods disclosed herein may improve performance in any or all of these applications. The main examples described herein relate to improving the performance of compression / decompression of neural network data, e.g. to be transmitted between different computers over a network for use in training a neural network (which may be referred to as ‘distributed deep neural network training’). The performance may be improved in terms of increasing the speed of processing the neural network data, and / or in terms of reducing the size of the encoded neural network data stream, i.e. the number of bits used to represent the neural network data in the encoded neural network data stream. Some other examples of applications for the systems and methods disclosed herein are included below. Many different processing applications may be improved, for example by improving the performance of natural language processing and text compression / decompression; image and video compression / decompression; Al-generation videos; speech recognition and audio processing; genomic data compression; data compression for the Internet of Things; robotics and autonomous systems; remote sensing and satellite imagery; data transmission in communications systems; handling of trading data in a high-frequency trading environment; virtual reality, extended reality and pixel streaming; and file compression such as Zip, RAR and 7z. Generally, any of the functions, methods, techniques or components described above can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms “module,” “functionality,” “component”, “element”, “unit”, “block” and “logic” may be used herein to generally represent software, firmware, hardware, or any combination thereof. The terms computer program code and computer readable instructions as used herein refer to any kind of executable code for processors, including code expressed 5 in a machine language, an interpreted language or a scripting language. Executable code includes binary code, machine code, bytecode, code defining an integrated circuit (such as a hardware description language or netlist), and code expressed in a programming language code such as C, Java or OpenCL. The applicant hereby discloses in isolation each individual feature described herein 10 and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant 15 indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention. 19 06 25

Claims

1. A computer processing system configured to decode a neural network data stream which includes variable-length character-strings representing symbols which 5 have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data, the computer processing system comprising processing logic configured to:receive the neural network data stream;store a portion of the received neural network data stream in a buffer, wherein io the portion comprises more than a fixed number of characters of the neural network data stream;shift the portion of the received neural network data stream stored in the buffer using a barrel shifter to position the fixed number of characters of the neural network data stream for identifying an entry of the acceleration table at a15 predetermined location within the buffer;access the fixed number of characters of the neural network data stream from the predetermined location within the buffer;query an acceleration table on the computer processing system with the accessed fixed number of characters of the received neural network data stream to20 identify an entry of the acceleration table, wherein each of a plurality of the entries of the acceleration table indicates a decoded symbol to be returned, and wherein the acceleration table has multiple entries which indicate the same decoded symbol represented by a character-string having fewer than said fixed number of characters; and25 if the identified entry indicates a decoded symbol, output the decoded symbolindicated by the identified entry for use in training a neural network.

2. The system of claim 1 wherein the system is configured to process the decoded symbols to determine parameters for configuring neurons in the neural 30 network as part of training the neural network.19 06 253. The system of claim 1 or 2 wherein the system is part of a group of computer processing systems which are configured to operate together to train the neural network.5 4. The system of claim 3 wherein the processing logic is configured to receivethe neural network data stream from another computer processing systems in the group.

5. The system of claim 3 or 4, when dependent upon claim 2, wherein the io system is configured to encode the determined parameters into a further neural network data stream and send the further neural network data stream to a different computer processing systems in the group for further use in training the neural network.15 6. The system of any preceding claim wherein the neural network data stream isa bit stream, the characters are bits, and the character-strings are bit-strings.

7. The system of any preceding claim, wherein each of the plurality of the entries of the acceleration table that indicate a decoded symbol further indicate a character-20 length for the indicated symbol, wherein the character-length is the number of characters in the character-string that represents the symbol indicated by that entry, and wherein the system is further configured to, if the identified entry indicates a decoded symbol, output the indicated character-length for the indicated symbol.25 8. The system of claim 7 when dependent upon claim 6, wherein the character-length is a bit-length.

9. The system of any preceding claim, wherein the fixed number of characters represents an index of the identified entry in the acceleration table and each entry of 30 the acceleration table comprises data, and wherein each of the plurality of the entries of the acceleration table indicates a decoded symbol to be returned using both data of the entry and the index of the entry.19 06 2510. The system of claim 9 when dependent on claim 7 or 8, wherein the data of each of the plurality of entries comprises a character-length for the indicated symbol.

11. The system of any preceding claim wherein the fixed number of characters is 5 eight characters, and wherein the system is configured to store the portion of the received neural network data stream in the buffer by reading from a memory to fetch 32 bits at once.

12. The system of claim 11 when dependent upon claim 7 or 8, further configured io to determine the amount by which to shift the portion of the received neural network data stream in the buffer to position the fixed number of characters of the neural network data stream at the predetermined location based on one or more character-lengths of one or more symbols that have previously been output in respect of the portion of the received neural network data stream that is stored in the buffer.1513. The system of claim 11 or 12, wherein the buffer is a register of the computer processing system.

14. The system of any preceding claim, wherein said fixed number is greater than 20 or equal to the number of characters of each of at least 90% of the character-strings included in the neural network data stream.

15. The system of any preceding claim wherein, for each of the character-strings in the neural network data stream that have a number of characters that is less than 25 or equal to said fixed number, the acceleration table has at least one entry which indicates the decoded symbol represented by that character-string.

16. The system of any preceding claim, wherein the number of entries in the acceleration table is at least the maximum number of entries able to be distinctly 30 identified by the said fixed number of characters.

17. The system of any preceding claim, wherein the acceleration table is formed by an array of data pairs, each data pair forming an entry in the acceleration table and wherein each data pair can be read in the same operation, wherein the data pair19 06 25for each of said plurality of the entries of the acceleration table comprises i) a decoded symbol and ii) the length of the character-string representing the symbol.

18. The system of any preceding claim, wherein one or more of the symbols are5 represented by a respective one or more long character-strings, wherein a long character-string has more than the said fixed number of characters, wherein one or more of the entries of the acceleration table is a long character-string entry for a long character-string representing a symbol, wherein the acceleration table is arranged such that a long character-string entry for a longio character-string is identified when the fixed number of characters used to query the table are an initial portion of the characters of the long character-string.

19. The system of claim 18, wherein each of said one or more long character-string entry of the acceleration table identifies an acceleration sub-table to be15 queried for determining the symbol represented by the long character-string, wherein the system is further configured to, in response to identifying a long character-string entry of the acceleration table:query the identified acceleration sub-table on the computer processing system with a subsequent fixed number of characters of the received neural20 network data stream to identify an entry of the acceleration sub-table, whereineach of a plurality of the entries of the acceleration sub-table indicates a decoded symbol to be returned; andif the identified entry of the acceleration sub-table indicates a decoded symbol, output the decoded symbol indicated by the identified entry of the25 acceleration sub-table.

20. The system of claim 18, wherein the system is further configured to, in response to identifying a long character-string entry of the acceleration table: concatenate a subsequent character of the neural network data stream to the30 fixed number of characters to form a set of characters;determine whether the set of characters matches a long character-string that represents a decoded symbol; andif the set of characters matches a long character-string that represents a decoded symbol, output the decoded symbol.19 06 2521. The system of claim 20 wherein the system is further configured to, if the set of characters does not match a long character-string that represents a decoded symbol:5 concatenate another subsequent character from the neural network datastream to form a further set of characters; anddetermine whether the further set of characters matches a long character-string that represents a decoded symbol.io 22. The system of any preceding claim, wherein the acceleration table is stored in a cache of the computer processing system.

23. The system of any preceding claim, wherein the acceleration table is predetermined and fixed in hardware using fixed-function circuitry in the computer 15 processing system.

24. The system of any of claims 1 to 22, wherein the system is configured to: (i) form the acceleration table in dependence on the received neural network data stream, and (ii) dynamically choose said fixed number in dependence on the20 received neural network data stream.

25. The system of any preceding claim, wherein the variable-length prefix encoding scheme is any one of: Huffman encoding, Golomb encoding, Rice encoding, Elias Delta encoding, Elias Gamma encoding, Exp-Golomb encoding, or 25 Unary encoding.

26. The system of any of claims 1 to 24, wherein the variable-length prefix encoding scheme is Fibonacci encoding.30 27. A computer-implemented method of decoding, on a computer processingsystem, a neural network data stream which includes variable-length character-strings representing symbols which have been encoded in accordance with a variable-length prefix encoding scheme, wherein the symbols represent neural network data, the method comprising:19 06 25receiving the neural network data stream at the computer processing system;storing a portion of the received neural network data stream in a buffer, wherein the portion comprises more than a fixed number of characters of the neural network data stream;5 shifting the portion of the received neural network data stream stored in thebuffer using a barrel shifter to position the fixed number of characters of the neural network data stream for identifying an entry of the acceleration table at a predetermined location within the buffer;accessing the fixed number of characters of the neural network data stream io from the predetermined location within the buffer;querying an acceleration table on the computer processing system with the accessed fixed number of characters of the received neural network data stream to identify an entry of the acceleration table, wherein each of a plurality of the entries of the acceleration table indicates a decoded symbol to be returned, and wherein the15 acceleration table has multiple entries which indicate the same decoded symbol represented by a character-string having fewer than said fixed number of characters; andin response to the identified entry indicating a decoded symbol, outputting the decoded symbol indicated by the identified entry for use in training a neural network.2028. A computer readable storage medium having stored thereon computer readable instructions that, when executed on a computer processing system, cause the computer processing system to perform the method of claim 27.

Images