systemml-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dylan Hutchison (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SYSTEMML-1662) Extended HOP DAG validator
Date Sat, 10 Jun 2017 08:54:18 GMT

    [ https://issues.apache.org/jira/browse/SYSTEMML-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045464#comment-16045464
] 

Dylan Hutchison commented on SYSTEMML-1662:
-------------------------------------------

See extension of Hop Validator at https://github.com/apache/systemml/pull/534

> Extended HOP DAG validator
> --------------------------
>
>                 Key: SYSTEMML-1662
>                 URL: https://issues.apache.org/jira/browse/SYSTEMML-1662
>             Project: SystemML
>          Issue Type: Sub-task
>          Components: Compiler
>            Reporter: Matthias Boehm
>              Labels: beginner
>             Fix For: SystemML 1.0
>
>
> This task aims to extend the existing HOP DAG validator (see {{org.apache.sysml.hops.rewrite.HopDagValidator}},
which can be enabled via {{org.apache.sysml.hops.rewriteProgramRewriter.CHECK}}) in various
ways in order to provide better developer tooling for checking the correctness of new and
existing rewrites.
> So far, this validator, checks only for:
> * Correct parent node linking
> * Correct child node linking
> * Non-empty children (for all hops other than {{DataOp}} and {{LiteralOp}})
> Possible extensions include (but are not limited to):
> * Correct HOP output data types
> * Correct HOP output value types
> * Correct number of expected child nodes
> * Correct output size information wrt input sizes
> * Correct visit status 
> These extensions would be very useful for multiple reasons. First, they would detect
rewrite issues early on in the development process. This is important because rewrite issues
usually lead to strange and non-obvious behavior of real application scripts. Second, the
HOP DAG validator provides a systematic way of debugging optimizer issues. The intended future
workflow is as follows:
> * 1. Disable rewrites via optimization level 1 to determine if rewrites are the issue.
> * 2. Use the extended {{HopDagValidator}} validator to find the source of corruption.
> * 3. If (2) did not find the issue, resort to low-level debugging, and extend the {{HopDagValidator}}
to capture the root cause of the issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message