GitLab

Bugzilla Link	1030
Created on	Oct 09, 2012 15:46
Version	svn
OS	Linux
Architecture	PC
Attachments	convonEach.sac

Extended Description

Created an attachment (id=936)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
 developer rev 18245:MODIFIED linux-gnu_x86_64
 (Mon Oct  8 15:37:33 EDT 2012 by sac)
The nested array code has a number of distinct problems:
1. The generated code does not use _type_conv for enclose and
   disclose. Instead, it uses new primitives:
   sac2c convonEach.sac -O3 -v1 -wls_aggressive  -doawlf -nowlf -bopt >crud.awlf
  _pinl_8311_result = _enclose_( double[.], hidden(11), _pinl_8320__icc_3577);
  _pinl_8223_result = _disclose_( hidden(11), double[.], _pinl_8311_result);
  Bodo expressed a preference for use of _type_conv() here. I am not
  sure of his exact reasoning, so perhaps he can expand this comment with
  his rationale.
2. The type of _pinl_8311_result is "hidden(11)". I do not know what
   this means. Can someone please provide appropriate documentation for
   same, so that we can make CF and other optimizations work on
   nested arrays?
3. This is a more fundamental design problem: All AVIS son information
   about the _enclose_() argument is lost in its result, from what I
   can see.
   This means that AWLF and even WLF are unable to operate on disclosed
   array elements, resulting in dismal performance. 
   Consider the convolution example in convonEach.sac: It is effectively
   doing:
   
      matmul( filter, take(shape(filter), drop(k, trace)));
   In order to perform WLF, it at least needs to know the shape of trace
   (the disclosed signal vector). This information has been lost.
   In this degenerate case of enclose/disclose, once (1) and (2) have
   been solved, then CF should be able to eliminate the enclose/disclose
   pair, which would solve this particular problem.
   However, consider the more general case of something like:
    traces = ( enclose( trace0) ++ enclose( trace1) ++ enclose(trace2)...);
    z = matmulEach( (enclose( filter), traces);
   We now have no guarantee that the shapes of the traces are the same.
   Worse yet, in the generalvector-matrix multiply case, we need to
   know only that shape(filter)== take(1, shape(trace)) for all traces.
As a result of the absence of vital information for WLF/WLF to operate,
performance of the convonEach benchmark is dismal: roughly 130sec,
versus less than 1sec for the non-enclosed version.
What this tells me is that we need to rethink the whole idea of invariant
properties, in the light of nested arrays, and how we can apply optimizations
on such arrays.