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
There are currently multiple types representing 2 dimensional matrices: Vec<Vec<E>>, RowMatrix, ColMatrix, and maybe others. I suggest we only have 2: RowMajorMatrix and ColumnMajorMatrix.
Each have an internal data buffer, similar to what today's RowMatrix has
In each, you can read/write rows and columns; only one of which would be most cache efficient (e.g. RowMajorMatrix would have read/writing rows fastest).
The entire codebase would use these - you would never see Vec<Vec<E>>. For example, EvaluationFragment::update_row() would simply delegate to the internal ColumnMajorMatrix as opposed to (re-)implementing that logic there.
The main benefits of this approach are:
readability: I don't need to wonder if Vec<Vec<E>> stores columns or rows
reusability: any custom logic across the codebase for Vec<Vec<E>> (such as this EvaluationFragment::update_row(), ColMatrix, RowMatrix) would all live in one place
performance: these are more performant than Vec<Vec<E>> (cache locality)
The text was updated successfully, but these errors were encountered:
There are currently multiple types representing 2 dimensional matrices:
Vec<Vec<E>>
,RowMatrix
,ColMatrix
, and maybe others. I suggest we only have 2:RowMajorMatrix
andColumnMajorMatrix
.data
buffer, similar to what today'sRowMatrix
hasVec<Vec<E>>
. For example,EvaluationFragment::update_row()
would simply delegate to the internalColumnMajorMatrix
as opposed to (re-)implementing that logic there.The main benefits of this approach are:
Vec<Vec<E>>
stores columns or rowsVec<Vec<E>>
(such as thisEvaluationFragment::update_row()
,ColMatrix
,RowMatrix
) would all live in one placeVec<Vec<E>>
(cache locality)The text was updated successfully, but these errors were encountered: