More docs for discoverability of which choices for vectorization are ok

[torsteingrindvik]

The repo's README.md has an example which uses vectorization=4.
But why this? And which other values are ok?

The docs on the ArrayArg from_raw_parts as well as TensorArg from_raw_parts API should provide some more info, by e.g. stating which sizes are supported by the different runtimes, and/or linking to supported_line_sizes on the Runtime trait.

Pointers on what to expect in terms of performance impact on the choice of vectorization factor would also be great.

[Quba1]

Jumping on that it would be great to also have info what role Line plays in vectorization (if any).

For example, why does GELU example uses Array<Line<F>> as input, but fusing example uses Array<F>?

cubecl/examples/gelu/src/lib.rs

Line 6 in 3c57804

fn gelu_array<F: Float>(input: &Array<Line<F>>, output: &mut Array<Line<F>>) {

cubecl/examples/fusing/src/lib.rs

Lines 17 to 20 in 3c57804

	fn fusing<F: Float>(
	inputs: &Sequence<Array<F>>,
	outputs: &mut Sequence<Array<F>>,
	#[comptime] ops: Sequence<Operation>,

Or what is the difference between vectorized and lined SharedMemory?

[nathanielsimard]

@Quba1 Line is a new concept to make it more explicit what elements are vectorized. At some point we will probably make it impossible to vectorize other stuff. But I'm still unsure if we should have Array<F> always return Line<F> when accessed vs. needing to add Line in the type.

fn kernel<F: Float>(array: Array<F>) {
   let value: Line<F> = array[0]; // What we could have.
   let value: F = array[0]; // What we have.
}

The question is what we want to make the default (or less verbose), the vectorized or the unvectorized cases.