You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@systemml.apache.org by "Matthias Boehm (JIRA)" <ji...@apache.org> on 2017/09/15 05:56:00 UTC

[jira] [Created] (SYSTEMML-1908) Non-deterministic number of fused operators on GLM

Matthias Boehm created SYSTEMML-1908:
----------------------------------------

             Summary: 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


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)