You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When looking at restricting the alignment of pieces of the array for the purpose of SIMD, it's unclear what restrictions are the most appropriate. Simply restricting the alignment of the first element doesn't seem especially useful except in the 1-D case. For example, if I have a row-major array and the stride between rows is not a multiple of 64 bytes, then many of the rows will not be 64-byte aligned. As a result, if I want to iterate along the rows, I'll have to deal with alignment issues regardless of whether or not the first element (i.e. the first row) is aligned. To avoid this, we'd need to insert padding between rows to make them be 64-byte aligned. There's also the question of slicing -- should we worry about the fact that slicing an array will usually make the first element no longer be 64-byte aligned?
Does anyone have thoughts about what sort of alignment restrictions would be appropriate?
Edit: On second thought, alignment of the first element is sufficient when the arrays being operated on are contiguous, they're in the same order, and the operation is elementwise (e.g. computing the sin of all the elements in an array or adding two arrays together) because in this case the iteration can be flattened into a single loop. This is probably the most common case, so I can understand aligning the first element when possible and not worrying about the misalignment in other cases.
Alignment, also of each row, would be good to eventually support, but it requires us to handle internal padding of rows - which internally means stretches of uninitialized elements in memory; and this the owned arrays don't support today.
Design is needed. What's the approach here? All owned arrays could be allocated with data with a minimum alignment (This requires dropping no-copy initialization from Vec). Should there be padding for rows/columns?
What algorithms would take advantage of this? Would they also have a fallback to other alignments? Keep in mind that slices (array views) could have arbitrary other valid alignment for the element type.
If fallbacks are implemented, and there can't be a guarantee for array views, is the status quo good enough?
Activity
paddyhoran commentedon Jan 19, 2020
FYI #771, which if adopted would address this.
jturner314 commentedon Jan 21, 2020
When looking at restricting the alignment of pieces of the array for the purpose of SIMD, it's unclear what restrictions are the most appropriate. Simply restricting the alignment of the first element doesn't seem especially useful except in the 1-D case. For example, if I have a row-major array and the stride between rows is not a multiple of 64 bytes, then many of the rows will not be 64-byte aligned. As a result, if I want to iterate along the rows, I'll have to deal with alignment issues regardless of whether or not the first element (i.e. the first row) is aligned. To avoid this, we'd need to insert padding between rows to make them be 64-byte aligned. There's also the question of slicing -- should we worry about the fact that slicing an array will usually make the first element no longer be 64-byte aligned?
Does anyone have thoughts about what sort of alignment restrictions would be appropriate?
Edit: On second thought, alignment of the first element is sufficient when the arrays being operated on are contiguous, they're in the same order, and the operation is elementwise (e.g. computing the
sinof all the elements in an array or adding two arrays together) because in this case the iteration can be flattened into a single loop. This is probably the most common case, so I can understand aligning the first element when possible and not worrying about the misalignment in other cases.bluss commentedon Apr 11, 2020
Alignment, also of each row, would be good to eventually support, but it requires us to handle internal padding of rows - which internally means stretches of uninitialized elements in memory; and this the owned arrays don't support today.
bluss commentedon Apr 25, 2020
Design is needed. What's the approach here? All owned arrays could be allocated with data with a minimum alignment (This requires dropping no-copy initialization from Vec). Should there be padding for rows/columns?
What algorithms would take advantage of this? Would they also have a fallback to other alignments? Keep in mind that slices (array views) could have arbitrary other valid alignment for the element type.
If fallbacks are implemented, and there can't be a guarantee for array views, is the status quo good enough?