¿Por qué no se permiten bitfields en OpenCL?

Los campos de bits no son compatibles con el lenguaje OpenCL. ¿Cuál fue la razón para no apoyarlos? A diferencia de otras piezas omitidas (recursividad, punteros a funciones, ...), donde hay una razón obvia para no darles soporte, no veo uno para bitfields. Estoy seguro de que no es un descuido en nombre del comité, pero ¿cuál es el motivo?¿Por qué no se permiten bitfields en OpenCL?

(Guardo algunos bits empaquetados en ints, y el código sería más agradable de leer con ellos. Entiendo los campos de bits como una buena sintaxis para evitar el cambio de bits y el enmascaramiento de ida y vuelta, que es lo que traducen al ensamblar de todos modos .)

Fuente

2012-01-27 eudoxos

Pude hacer esta pregunta a alguien involucrado en el grupo de trabajo. Esto es lo que tenía que decir:

campos de bits no son portátiles - por lo que no podrían utilizarse en los tipos utilizados para argumentos del núcleo.

El único lugar en el que podría ser usado es para los tipos para las variables locales declaradas dentro de un kernel.

El grupo de trabajo OpenCL no estaba convencido de que esto fuera muy útil. En el Además, existía la preocupación de que los compiladores no puedan generar el código eficiente al usar bitfields. Todo esto llevó al grupo de trabajo a la decisión de no apoyar a los campos de bits en OpenCL C

Fuente

2012-01-28 00:07:46 James

Es importante recordar que OpenCL permite cosas como un host little-endian y un dispositivo big-endian. Permitir campos de bits solo serviría para complicar aún más el soporte de endios mixtos. – user57368

No es portátil ... el argumento de que funciona solo con el mismo endianness es débil. Muchos códigos OpenCL (incluidos los míos) se escribirán para un hardware específico. El programador debería saber mejor qué usar y qué no. (Tengo un código para acceder a grupos de bits dentro de un int; sería mucho más fácil con bitfields: - |) – eudoxos

Wikipedia tiene algo de información sobre las drawbacks of bitfields:

miembros de bits en las estructuras como se presenta anteriormente tienen potencial inconvenientes prácticos. En primer lugar, el orden de los bits en la memoria depende de la CPU y las reglas de relleno de la memoria pueden variar entre los compiladores. Además, los compiladores menos optimizados a veces generan código de baja calidad para leer y escribir miembros de bit y potencialmente hay problemas de seguridad de subprocesos relacionados con campos de bit porque la mayoría de las máquinas no pueden manipular conjuntos arbitrarios de bits en la memoria, sino que deben cargar y almacenar palabras completas .

Creo que todos estos inconvenientes son relevantes en un entorno OpenCL.

Fuente

2012-01-30 20:23:38 vocaro

Los tipos OpenCL tienen (en conformidad con la implementación) el mismo diseño de memoria, de lo contrario, copiar los almacenamientos intermedios del host al dispositivo haría sin sentido. Punto tomado para ordenar los bits. Por lo demás (seguridad de hilo, calidad del compilador), eso no es diferente de las CPU. Podría pegar mi código para bitfields empaquetados en ints: es extremadamente poco elegante. – eudoxos

¿Presumiblemente, endianness solo afecta a matrices de longs y demás? Si almacenamos/enviamos como una matriz de caracteres sin signo, entonces se garantiza el orden de los bytes y el orden de los bits dentro de los bytes. –

¿Por qué no se permiten bitfields en OpenCL?

Respuesta

Cuestiones relacionadas