|
|
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.