User types in dense containers

User types in dense containers

Hello.

The tutorial (http://software.intel.com/en-us/articles/sc10-tutorial-intel-arbb/) mentions user_types, structs composed of arbb types. It seems to me that the arbb-vmapi only handles dense of basetypes. When using the C++ frontend (ArBB) to the vmapi are dense "compiled" into several dense containers of base types ? Essentially turning dense_of_struct into struct_of_dense. Is there a doc describing how this works?

Thanks

publicaciones de 7 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Hi! Thanks for your interest in the Virtual Machine API! Please check this past forum post for a comprehensive list of resources to look through. I think looking through those documents will explain much better than can go through here. Please let me know if you have any more questions after reading the spec.

Thanks,

Noah

Hi! Thanks for your interest in the Virtual Machine API! Please check this past forum post for a comprehensive list of resources to look through. I think looking through those documents will explain much better than can go through here. Please let me know if you have any more questions after reading the spec.

Thanks,

Noah

Best Reply

There is no specific document describing this transformation, but it does happen that way. The C++ frontend performs this transformation using runtime type capture. You can see this implemented in the frontend headers. This same mechanism allows the frontend to have free and member functions on class types "lifted" to apply to dense containers of those types.

In essence, the frontend container type instantiates an object of its element type after setting some thread local state to tell primitive ArBB types (which map to VM types) to register themselves on a stack of types. This in turn allows the container type to determine what its constituent types are, and construct VM containers of those types. Any operations on the container are turned into "map" functions where again the element types are instantiated and operations are performed on them as defined by the lifted operators. This results in the same operations that would apply to an instance of the element type end up being applied across entire containers. When these map functions are called by another VM function - in the C++ frontend, a closure that was captured from a C++ function - the VM knows enough about the functions to fuse them together and thus vectorize them effectively (keeping the number of loops small and packing them full of code that can be optimized together).

The end result is that you can instantiate containers of user-defined class types and things "just work". :)

Thank you for answering.

I will take a look into those headers and see what I can read out of them.

A followup question to get perhaps a bit better grasp on this. If I have a struct consisting of two I32_ fields
I could define a zero (0,0) and a plus operation on it (a,b) + (c,d) = (a+c,b+d). Then I should also be able
to define addReduce on a dense of such structs. How would addReduce be defined for such a struct.
Defining this addReduce must be up to the programmer right ?

Good thought! Actually, the init/oppair of functionsis the way you can customize reductions using Intel Cilk Plus ("reducer"). Anyhow, in ArBB we have not prepared the ArBB frontend to liftuser-defined types to apply tocollective operations. If you somehow need to run areduction over an user-defined type, you can access the structure of array (SoA) behind an ArBB collection. The reduction operation can then run on eachcomponent. Please have a look at dense::get/dense::get_field, and dense::set/dense::set_field.

The ArBB runtime likelyfusesthesereductions over dense containers of the same shape. This also extends todifferent operators over the same shape. BTW, this is the key togetfused code foran "user-defined reduction operator" that runs overan user-defined dense container. Another note, you need to treat complex numbers in a similar fashion -- this is also an example where you need to access the components (real/imag) since it's likely required to"interweave" real/imag (in order to definea reduction that makes sense).

Thank you.

That helped me a lot.

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya