Jedox GPU Accelerator FAQ

Today’s graphics cards (GPUs) are capable of processing large data volumes in parallel much faster than CPUs. Calculations in OLAP, such as aggregations, rule functions, and filters, can be significantly accelerated if run on a graphics card, reducing time from minutes to milliseconds. Whenever the same arithmetic operation can be applied on large amounts of data (thousands or millions of cells), then the GPU processing power is fully utilized, and significant speedups over conventional processing with a CPU can be expected.

Current measurements show an average speedup of factor 5 to 10 compared to the CPU version of the Jedox In-Memory DB Server. However, there is no general answer to this question, because of the nature of each particular query and uniqueness of each particular data model. In best-case scenarios, speedup can be much higher, e.g. 70 times faster on GPU, but in worst-case scenarios, there is very little or no speedup whatsoever. For this reason we recommend testing your model/reports on a GPU-enabled server before purchasing GPUs or GPU licenses. For details on how to test your model, see the next question.

We suggest using the GPU Accelerator Advisor that is implemented in Jedox Excel Add-in to determine the GPU recommendation level for a specific cube (for details see GPU Accelerator Advisor). If the result shows a potential for speedup, then the next step can be either of the following:

• Test Jedox GPU Accelerator on Azure NC instances
• Use a comparable consumer GPU (e.g. NVIDIA GeForce GTX 1080 or NVIDIA Titan X) and test on your own server. As of Jedox 7.0, non-Tesla™ GPUs are supported for testing purposes (viable support). Note that non-Tesla™ GPUs have a driver-side CUDA kernel execution timeout (normally 5 seconds) that can reached in extremely computation-intensive operations, such as aggregations or dimension filters. This timeout might be configurable, but Jedox does not provide any support for these types of configuration changes.
• Contact our GPU support team (support@jedox.com) to arrange a trial on our test servers (equipped with state-of-the-art GPUs).

Fully accelerated operations are:

• aggregation (SUM, MAX, MIN, AVG, CNT)
• data filters (ANY, ALL, MAX, MIN, SUM, AVG)
• rules (arithmetic operations, IF statements, PALO.DATA)
• accessing attribute cubes (numerical values)
• all writeback operations

Some features are not processed on GPU yet, such as:

• functions on element names or dimension names
• functions that manipulate strings
• operations on string cells

However, this is transparent for users; i.e., GPU processing is automatically applied whenever suitable, and CPU processing takes over elsewhere.

Note that cube layout changes cannot yet be performed on GPU-activated cubes.

As a general rule of thumb, arrange dimensions according to their sizes (base element count) and start with the smallest one as the first dimension in the cube. Time dimensions and dimensions that are typically reduced to base level in reports (high selectivity) should also be placed among the first dimensions. A dimension that is heavily used in B:Rules is also a candidate to be placed among the first dimensions.

Generally not, because only In-Memory DB (OLAP) operations are accelerated. However, much of the time spent in ETL processes is typically consumed by the In-Memory DB performing READ and WRITE requests. If the processing of the READ requests are the bottleneck (e.g. large aggregations, B:Rule calculations, etc.), then the ETL process can indirectly profit from In-Memory DB Server acceleration, because those requests will be performed faster.