Skip to content

Reimplement IxDyn #285

@bluss

Description

@bluss
Member

It's using a Vec right now; it should be simplified.

  • Use “small vec” optimization; no allocation for small dimensions
  • Cap maximum number of axes to some limit (u16?)

Activity

Robbepop

Robbepop commented on Mar 28, 2017

@Robbepop

I think even a maximum dynamic dimensionality representable by u8 (256) would never be used anywhere since the element number grows exponentially with the dimensionality and even 2^100 < 2^128 (representable by u7) bytes memory usage is already really out of bounds.

The idea to use another data structure than Vec sounds also good since Vec offers much more flexibility (growing and shrinking) that is not required at all. Even a Box<[usize]> would be a better fit.

Using SmallVec has the advantage of having no dyn memory alloc up to a certain size but with this approach we could model the whole entirety of Ix and besides that SmallVec is again growable and shrinkable. Better would be a SmallBoxedSlice which does not exist, ... yet.

bluss

bluss commented on Mar 28, 2017

@bluss
MemberAuthor

This is supported right now. I agree it's pointless. In this case all dimensions are 1, so the len of the array is 1 element, even if it has 1 << 16 axes.

Array::zeros(vec![1; 1 << 16])

I'd like to do a custom implementation here, SmallVec for example is too bulky, would not be a big gain.

Robbepop

Robbepop commented on Mar 28, 2017

@Robbepop

Yeah it is a real edge case but for a general approach you may be right!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @bluss@Robbepop

        Issue actions

          Reimplement IxDyn · Issue #285 · rust-ndarray/ndarray