can't use types with internal mutability such as mutex.

[alkeryn]

if you try to use let's say a mutex within a soar struct, the compiler will complain.

[tim-harding]

Seems that this is an issue related to const-initialization of Array types related to rust-lang/rust#80384. These types are no longer generated in 0.6.1 unless #[soa_array] is specified.

[alkeryn]

hey thank you for fixing it that quickly !
btw i was wondering if it is possible for a soa array to have a specific field that is not turned into an array.

let's say you wanted a field shared for all instances but the others to be classic soa ?

btw this crate rocks !

[tim-harding]

If what you're after is the SOA array with interior mutability, I think a better option would be to conditionally disable const for the constructor and keep all the same fields. You wouldn't be able to create arrays in const contexts, but for local variables it might still be zero-cost after inlining and constant propagation.

[tim-harding]

Following up @alkeryn, is that something that would work for your problem?

[alkeryn]

i'm not exactly sure, the reason i'd have done it is to have a mutable type multiple thread can work on without locking the whole structure if they only need to access the nth index.

regarding the single variable thing what i meant is to have fields that are soa and some where there is only one instance for all structs.
one example of the generated struct would be:

struct Foo {
field1: Vec<u32>,
field2: String // this field would not generate a vec
}

also how does nesting works with this crate?
i like the way soa-derive kind of suport it :

but i'm not sure i can do something like

struct foo {}
struct bar {
foo: Soa<foo>
}
struct foobar {
bar: Soa<bar>
}

[tim-harding]

I'm pretty sure with a Mutex field you would still be able to take the lock for a particular element without locking the whole structure. For the single field thing, I'd suggest just putting the SOA inside another struct with the field you don't want to duplicate. The SOA nesting is pretty cool and I would like to add it at some point, but for now you just have to do some copy-paste if you want the same fields in different SOA types.

[alkeryn]

alright, well either way, thank you for this wonderful crate !
also i can attest to the amazing performance, i'd like to dig into it futher into exactly how it is that much faster but it does perform faster than soa-derive or just a manual implementation with Vec and preallocated size.
soa-derive was around the same ballparck as manual by maybe 1%.

on some custom spiking neural network code this crate was 30% faster than either soa-derive or the manual implementation with vec without changing the algo at all.
thank you ! :)

[tim-harding]

Glad to hear you were able to achieve some real-world performance wins. That's gratifying to hear :)