[Major Change] Enforcing tensor alignment

[Narsil]

• Now the header will automatically align itself to 8 bytes (f64) with
  appending extra spaces as necessary.
• This will allow extra fast memory mapping by reinterpreting bytes as
  f32/f64 etc.. Unaligned bytes do not allow for this. https://www.reddit.com/r/rust/comments/tanaxm/mutating_a_buffer_of_u8s_as_f32s_in_place/
• This does not change contiguousness of tensors
• This does not change the actual spec (we're just putting extra valid bytes
  in the header and using a different serialization ordering)
• Readers should still be able to read old files, they would just need
  to be copied before being cast as their final destination when using
  mmap
• This has no effect for GPU since copy is already necessary (I think,
  depends on the cuda API actually if it allows filling f32 addresses
  from raw unaligned bytes).

This change will only be interesting if things like https://github.com/Narsil/fast_gpt2
actually pick up. And even with the copy, load times are still vastly
faster than pytorch/transformers.

[julien-c]

would this change require changes to #44? or would it be transparent?

And even with the copy, load times are still vastly
superior to pytorch/transformers.

superior is ambiguous, I would add "(i.e., lower then)"

[Narsil]

would this change require changes to #44? or would it be transparent?

Transparent, it's only making sure the header JSON is of the appropriate size by adding extra padding.
(Also tensor order is modified, which readers should be agnostic to anyway).

And even with the copy, load times are still vastly
superior to pytorch/transformers.

superior is ambiguous, I would add "(i.e., lower then)"

True!

[McPatate]

lgtm, what prompted the change from BTreeMap to HashMap ?

[Narsil]

lgtm, what prompted the change from BTreeMap to HashMap ?

complexity. O(log (n) ) vs O(1). Shouldn't matter in practice really, but since I don't rely on the structure for ordering anymore, I don't need BTree anymore.