GPU Accelerator Advisor

The GPU Accelerator Advisor is a cube-level check for compatibility with Jedox GPU Accelerator. It is available both in Jedox Web and in the Excel Add-in. To run it, select a cube in the Modeler and open the cube properties tab. The GPU Accelerator Advisor can be found at the bottom of the cube properties options, as shown below:

The result of the check is a usage recommendation level (e.g. highly recommended or not recommended) that reflects the expected speedup potential of the Jedox GPU Accelerator on the specified cube. Along with this result, the graphical overview displays the most important cube features that were taken into account for the evaluation, as well as their respective evaluated values:

The charts show the evaluated values calculated by the Advisor for Cube (% suitability for GPU) and Rules (% supported by GPU) properties. The Usage of Accelerator recommendation can be any of the following:

highly recommended (speedup expected)
recommended (speedup is likely)
candidate (potential for speedup)
not recommended (no speedup expected)

The evaluated parameters are described below.

Cube:

Data volume: can be low, medium, high, or big, according to cell count
Cell count: number of filled cells in the cube
Storage size: expected cube size (in megabytes) in GPU memory*
String elements: aggregated number of string elements in all dimensions of the cube

*Note: the storage size is provided for information purposes only and is not evaluated by the GPU Accelerator Advisor. This number may be relevant if the size exceeds the available memory of a GPU card, which currently holds 12-32GB.

Rules:

X of Y are supported: X = number of rules that are supported on GPU Accelerator; Y = number of active rules
Cube dependencies: number of cubes that are referenced as data sources in rules in the specified cube
Total coverage: percentage of rule-calculated cells in the cube
Supported coverage: percentage of GPU-supported rule-calculated cells in the cube

Rule Evaluation

This section evaluates each rule in the cube.

Rule ID	Rule ID as shown in Rule Editor
Position	rule position as shown in Rule Editor
Rule	rule definition as shown in Rule Editor
Supported type	GPU engine rule support status. Can be any of the following: supported: the rule can be calculated by the GPU engine. partial: parts of the rule can be calculated by GPU engine. Example: ['2016', 'Budget'] = B: ['2015', 'Actual'] with unspecified dimension Month containing string element Comment. The rule is supported for all Month elements except the string element. Hence, the support type is partial. unsupported: the rule cannot be calculated by the GPU engine (see Reason below).
Reason	If the rule is not fully supported on the GPU, the reason can be any of the following: non-numerical storage: source data of the rule is (in part) non-numeric, e.g. references string type elements. legacy rule: the rule is not compliant with the DDE rule engine, but might be supported in future releases. For more information about legacy rules and DDE, please read the article Rule Engines in Jedox. rule error: the rule cannot be calculated due to an error. Reasons can be circular references (e.g. ['2016'] = B: ['2016'] + 1), invalid database or cube name (e.g. ['2016'] = B:PALO.DATA("MissingDB", "DeletedCube", ...), rule parsing errors, etc. rights check: rule calculation depends on user rights. string constant: rule definition contains string constants (e.g. ['2017','Comment'] = B:"important"). median function: rule involves median calculation. evaluation error: an unexpected error occurred during rule evaluation. complex rule: rule calculation is too complex to be processed completely on GPU (the most common case is when the rule spans too many levels of recursion).

Best practices

Analyzing rule issues

If a rule support result is not obvious at first glance (e.g. rule evaluation error, rule error, or unsupported type), you should first isolate that rule. Note that dependencies between rules can lead to scenarios in which many rules will have issues if a bottom-level rule in the dependency chain has issues.

Example:

R1 = A * B
R2 = R1 * C

If there is a rule error in R1, this will propagate into R2, because R2 operates on results of R1.

To isolate a rule, we recommend the following procedure:

Initially deactivate all rules (only active rules are taken into account in the check).
Iteratively reactivate (blocks of) rules in the order of their dependency level, i.e. start from the bottom (R1 in the example above).
Restart the check

In the example, this exercise would clarify that R1 is not erroneous itself, but only in combination with R2. Thus R2 is the rule of interest.

An already isolated rule can be analyzed in more detail by temporarily removing parts of the rule.

Example:

R1 = A * B can be temporarily rewritten as R1 = A, or R1 = B. Restarting the Advisor on the changed rules might give further insights about problematic parts.

Note that in rule constructs involving the CONTINUE() statement lower ordered rules targeting the same area or a subarea will not be listed in the Advisor result.

Example:
R1: ['2018'] = B: IF(['2017'] > ['2016'], STET(), CONTINUE())
R2: ['2018', 'Jan'] = B: 100

In this example, R2 will not be listed in the Advisor result. Still, if R1 is shown as "supported", this implies that R2 is supported as well. If R1 is shown as "unsupported", this implies that R2 is also unsupported.

We recommend disabling the highest-ordered rule (R1 in this example) and running the Advisor again to obtain the support status of lower-ordered rules (R2 in this example).

Long-running checks

When a cube contains many complex rules (e.g. hundreds of rules with dependencies on other rules), the Advisor check can take several minutes or even hours to complete. If the timeout is reached, the check will stop without a result. To obtain complete results, the timeout can be increased via the input field next to the Check Performance button. Status information about a running check can be obtained by viewing the OLAP log file, which is updated in regular intervals during the check.

Note that the check requires system resources on the server, so it is not recommended to run the check on servers running low on resources.

To approximate the complete results more quickly, following procedure is recommended:

Initially deactivate all rules (only active rules are taken into account in the check).
Iteratively reactivate (blocks of) rules in the order of their importance.
Restart the Advisor check in each iteration

If you want to cancel a running check choose either of the following options:

Stop the corresponding cube/info job: in Jedox Web, go to Administration → Sessions and select the corresponding <User> to show active jobs and stop the job.
If you are using Excel, close it (forcefully, if necessary).

Note that closing the loading panel does not stop the active job on the server. Hence, following either a) or b) is vital to freeing system resources on the server.

Next steps

Try before you buy! If you are interested in the performance of your model on a state-of-the-art GPU server, please contact us at gpu.support@jedox.com.

Updated September 27, 2022