x86 y otras arquitecturas proporcionan instrucciones atómicas especiales (bloqueo, cmpxchg, etc.) que le permiten escribir estructuras de datos "sin bloqueo". Pero a medida que se agregan más núcleos, parece que el trabajo que estas instrucciones realmente tendrán que hacer detrás de las escenas crecerá (¿al menos para mantener la coherencia de la memoria caché?). Si un agregado atómico lleva ~ 100 ciclos hoy en día en un sistema dual core, ¿podría tomar mucho más tiempo en las 80 máquinas centrales del futuro? Si está escribiendo código para durar, ¿podría ser una mejor idea usar bloqueos incluso si son más lentos hoy?¿Se vuelven más lentas las operaciones atómicas a medida que se agregan más CPU?
Respuesta
Tiene razón en que las limitaciones de topología aumentarán, de una forma u otra, la latencia de la comunicación entre los núcleos, una vez que los recuentos comiencen a ser superiores a un par de docenas. Realmente no sé cuáles son las intenciones de las compañías x86 para lidiar con ese tipo de escala.
Pero los bloqueos se implementan en términos de operaciones atómicas. Entonces, realmente no ganas intentando cambiar a ellos, a menos que se implementen de una manera más escalable que lo que se intentaría con tus propias operaciones atómicas laminadas a mano. Creo que, en general, para las contiendas tipo token único, las primitivas atómicas siempre serán la forma más rápida, independientemente de la cantidad de núcleos que tenga.
Como Cray descubrió hace mucho tiempo, aquí no hay almuerzo gratis. El diseño de software de alto nivel, donde intenta utilizar recursos potencialmente polémicos de la forma más infrecuente posible, siempre generará el mayor pago en aplicaciones masivamente paralelizadas. Esto significa hacer tanto trabajo como sea posible como resultado de una adquisición de bloqueo, pero lo más rápido posible también. En situaciones extremas, esto puede significar calcular previamente su trabajo en el supuesto de un bloqueo adquirido con éxito, tratar de agarrarlo, y simplemente completar lo más rápido posible el éxito, de lo contrario, se descarta su trabajo y se reintenta al error.
Para la pregunta planteada en el título, la respuesta breve es "sí", la respuesta larga es "es complicado".
Con respecto a las cerraduras es mejor, no. Internamente, un bloqueo tiene que empujar al menos tanto tráfico (si no más) sobre el bus. Piénselo de esta manera, si el procesador solo tiene una operación atómica, una comparación atómica y un intercambio, podría usarla para implementar bloqueos e incrementos atómicos. Bueno, en el nivel de protocolo de bus, solo hay algunas primitivas que se usan. Los bloqueos no son más lentos que las operaciones atómicas porque están haciendo algo diferente, son más lentos porque hacen más de lo mismo (desde el punto de vista de la coherencia). Así que a medida que las operaciones atómicas disminuyen, las cerraduras tenderán a desacelerarse de forma comparable.
Habiendo dicho eso, hay montones de documentos sobre el tema y los casos particulares son complicados. No me preocuparía cómo se va a escalar su código en las CPU de 80 núcleos que tienen características de rendimiento impredecibles (porque no sabemos cómo se diseñarán). O se comportarán como nuestras CPU actuales y tu código funcionará bien, o no lo harán, y lo que sea que hayas adivinado ahora resultará incorrecto. En la mayoría de los casos, resultará que el código no es sensible al rendimiento de todos modos, por lo que no importa, pero si lo hace, lo apropiado será arreglarlo en el futuro cuando comprenda las características arquitectónicas y de rendimiento. de tus procesadores objetivo
¿Hay algún "bus" que deba ser bloqueado en las CPU modernas? ¿O usan operaciones atmoicas basadas en coherencia de caché? – osgx
No creo que el problema sea que las operaciones atómicas tomarán más tiempo ellas mismas; el verdadero problema podría ser que una operación atómica podría bloquear las operaciones de bus en otros procesadores (incluso si realizan operaciones no atómicas).
Si quiere escribir el último código, intente evitar el bloqueo en primer lugar.
Si te entiendo correctamente, ¿estás diciendo que una operación atómica que se está ejecutando en un procesador puede causar una desaceleración en todos los demás procesadores? Entonces, ¿el costo del ciclo ~ 100 de una instrucción de bloqueo no se paga solo en el hilo actual o procesa la CPU, sino que se paga en todos los flujos de ejecución actuales? –
IIUC, una instrucción de bloqueo causará un bloqueo de bus, bloqueando todas las operaciones de memoria en todos los procesadores, siempre y cuando se asegure el bloqueo (otros procesadores pueden continuar usando sus cachés locales, aún así, IIUC). –
Eso es correcto, es la forma principal en que un 'cmpxchg' atómico asegura que la memoria no se actualizará" debajo de sus pies "por otro núcleo de la CPU, obliga a un ciclo de escritura en el bus incluso si no está realmente escribiendo. – Blindy
En una nota lateral a esta pregunta, vale la pena mencionar que el futuro al que se refiere ya es una tecnología presente en las GPU.una GPU Quadro moderna tiene hasta 256 núcleos y puede pefrorm operaciones atómicas en la memoria global (pantalla).
No estoy seguro de cómo se logra esto, pero el hecho es que ya está sucediendo.
No, las GPU no realizan operaciones atómicas en el búfer de visualización. De hecho, la diferencia fundamental entre un núcleo de GPGPU moderno y un núcleo de CPU es que el núcleo de GPU no es coherente. –
No en el búfer de visualización, pero CUDA tiene una operación atómica incorporada para la memoria de video. – shoosh
@LouisGerbarg: la representación con mezcla alfa es un tipo de actualizaciones atómicas del búfer de visualización. – ybungalobill
- 1. Las inserciones SQLite se vuelven más lentas incluso con transacciones
- 2. ¿Por qué las funciones de valor escalar de SQL Server se vuelven más lentas?
- 3. C++ AMP con GPU rápidas más lentas que la CPU
- 4. Operaciones atómicas en ARM
- 5. por qué std :: shared_ptr usa operaciones de CPU atómicas
- 6. ¿Qué operaciones en Java se consideran atómicas?
- 7. En un ListBox de WPF con más de 1000 elementos de imagen, las imágenes de zoom se vuelven lentas
- 8. Cómo encontrar las consultas más lentas
- 9. ¿Qué operaciones son operaciones atómicas
- 10. Operaciones atómicas en Django?
- 11. Reduzca la velocidad de la CPU para simular computadoras más lentas en las pruebas del navegador
- 12. ¿Por qué los tr/\ n // de Perl se vuelven cada vez más lentos a medida que aumenta la longitud de las líneas?
- 13. ¿Las operaciones de rsync son atómicas a nivel de archivo?
- 14. operaciones atómicas en C++
- 15. ¿Se puede acceder a IEnumerable a medida que se devuelve?
- 16. ¿Qué es más eficiente? Más núcleos o más CPU
- 17. ¿Las operaciones más caras en PHP?
- 18. ¿Cuáles son algunas buenas estrategias para corregir errores a medida que el código se vuelve más complejo?
- 19. Operaciones atómicas: debajo del capó
- 20. Fetch-and-add usando las operaciones atómicas de OpenMP
- 21. ¿Cómo se configura Tomcat para usar más de 1 CPU?
- 22. operaciones atómicas Hilo de seguridad en gcc
- 23. ¿Cómo se especifican las operaciones que se basan en Memcached?
- 24. CUDA Lista de operaciones atómicas
- 25. ¿Cómo es que las consultas no se agregan a Db.connection.queries de Django en las pruebas?
- 26. Obtener ID para las vistas que se agregan dinámicamente
- 27. Operaciones atómicas MySQL y bloqueo de tabla
- 28. Memcached - ¿Las operaciones GET y SET son atómicas?
- 29. haciendo que las fuentes se agranden en pantallas más grandes
- 30. Las operaciones de atomic.h parecen no ser atómicas
A menudo me he encontrado pensando que el concepto de "puntero de memoria lineal" debería abandonarse, y debería haber un retorno a algo más parecido a un modelo de memoria segmentada, pero usando un segmento por "objeto". Esto permitiría a muchas aplicaciones permitir referencias de objetos de 32 bits para acceder a muchos gigabytes de memoria (duplicando el número de referencias de objetos que caben en cada línea de caché). Además, dependiendo de la implementación, dicho sistema podría permitir que un procesador "revise" un objeto en su tienda exclusiva donde cosas como CAS no requerirían ningún enclavamiento ... – supercat
... a menos que otro procesador haya solicitado que el objeto se copiará a la memoria principal para que pueda usarlo (sé que bajo los protocolos de hoy, las líneas de caché están desprotegidas, pero eso requiere que todos los procesadores sepan qué líneas están siendo revisadas por todos los demás. Si un procesador escribe en un la información del objeto en la memoria principal que desea un uso exclusivo, y puede saber que la escritura se ha completado antes de que nadie más intente usarla, ya no necesita supervisar ese objeto a menos que se lo solicite explícitamente). – supercat