[
https://issues.apache.org/jira/browse/SYSTEMML-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Boehm closed SYSTEMML-1908.
------------------------------------
Resolution: Fixed
Assignee: Matthias Boehm
Fix Version/s: SystemML 1.0
> Non-deterministic number of fused operators on GLM
> --------------------------------------------------
>
> Key: SYSTEMML-1908
> URL: https://issues.apache.org/jira/browse/SYSTEMML-1908
> Project: SystemML
> Issue Type: Bug
> Reporter: Matthias Boehm
> Assignee: Matthias Boehm
> Fix For: SystemML 1.0
>
>
> Experiments regarding the codegen compilation overhead on GLM, revealed a
> non-deterministic number of fused operators, which should not be the case
> given constant inputs and the deterministic algorithm. The same can be
> reproduced, for instance, with the codegen unit test: {{GLM Binomial Dense w/
> rewrite dense}}. Different runs give the following output:
> {code}
> Codegen compile (DAG,CP,JC): 974/134/72.
> Codegen enum (ALLt/p,EVALt/p): 264380/262794/8971/8858.
> Codegen compile times (DAG,JC): 1.045/0.547 sec.
> Codegen plan cache hits: 31/103.
> {code}
> {code}
> Codegen compile (DAG,CP,JC): 974/134/69.
> Codegen enum (ALLt/p,EVALt/p): 264380/262794/8971/8858.
> Codegen compile times (DAG,JC): 1.034/0.509 sec.
> Codegen plan cache hits: 34/103.
> {code}
> After debugging this issue, it turns out that is was caused by
> non-deterministic ordering of scalars and dense inputs (by the number of
> non-zeros). Since the ordering of inputs (per category of matrices, vectors,
> scalars) is only beneficial for sparse inputs, this task aims to harden these
> ordering conditions. Overall, fixing this issue leads to fewer fusion
> operators (more reuse) and thus, less java compilation and JIT compilation
> overheads.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)