Issue 1 sparse zero write lifecycle#5
Conversation
aliaksandr-vasilenka-vention
commented
Jul 6, 2026
aliaksandr-vasilenka-vention
commented
- Separates Tensors into Dense and Sparse, only places for branching are create and load
- Adds tests for Sparse-zero policy cases
- Implements Sparse-zero policy cases
- Fixes incorrect read value logic when block is missing and index is present for Sparse tensor to follow close fail path
| self.write_block(block_id, block).await | ||
| } | ||
|
|
||
| async fn delete_block(&self, block_id: u64) { |
There was a problem hiding this comment.
How do we handle the case where the entries in a sparse tensor (the blocks) are larger than the configured block size for a dense tensor? We should not support "unlimited block size" in any case
There was a problem hiding this comment.
Not sure what part of code is referenced here. Could you please clarify?
There was a problem hiding this comment.
This is more of an architectural question. Say the block size is 4096 elements. A user creates a sparse tensor of shape [1000, 1000, 64, 64, 64] where axis 1 is the sparse axis. That means each entry on the sparse axis must be represented using multiple blocks on the filesystem (not just one per entry). Is this handled correctly now or is this something we need to address as a follow-up?
There was a problem hiding this comment.
Need to check it out
| strides.into() | ||
| } | ||
|
|
||
| fn checked_product(shape: &[usize]) -> FResult<usize> { |
There was a problem hiding this comment.
I think a u64 is correct here since the dimensions are u64, no?
There was a problem hiding this comment.
Good catch. Will fix it
| let checksum = u64::from_le_bytes(payload[8..16].try_into().unwrap()); | ||
| Ok(Elem::Trailer { count, checksum }) | ||
| } | ||
| ELEM_TAG_ERROR => { |
There was a problem hiding this comment.
I think we can get rid of the tag by making the error detection implicit. The only possible error cases are 1) malformed coordinate (in the sparse case) and 2) incorrect number of elements (in the dense case). Further validation is application-dependent and doesn't need to be baked into the tensor representation itself.
There was a problem hiding this comment.
Make sense
| /// crosses a machine boundary; only which failure shape occurred survives. | ||
| #[derive(Debug, Clone, Copy)] | ||
| #[repr(u8)] | ||
| enum ElemErrorCode { |
There was a problem hiding this comment.
Again, I don't want to create a bespoke error code for this one application because it creates confusion with our standard HTTP error codes and it could be interpreted as a numerical element. Please just serialize a TCError or io::Error inline if there is an actual error during serialization (e.g. a file I/O error).
There was a problem hiding this comment.
Your concern regarding errors was noticed. It seems destream states that it can serialized/deserialize Option values and Result values. But I found only full serialization/deserialization for Option. Result on other hand during serialization is serialiazing only data inside Ok and Error values. I was thinking to use that functionality, but now I see that it is to be implemented
| hash | ||
| } | ||
|
|
||
| enum Elem<T> { |
There was a problem hiding this comment.
You should not need this enum (see above); if an element doesn't decode as (Coord, T), try to decode it as an error, and if it doesn't decode as an error, return a new error
There was a problem hiding this comment.
That is the plan. To get rid of that enum
2 participants
