Portada
mis comunidades
otras secciones
#5:
Me leí todo el hilo original y la respuesta en Phoronix hace unos días, y tengo que darle toda la razón a Linus. Resulta que en lugar de utilizar un mutex (o un futex si querían mucho rendimiento), se programaron ellos mismos un spinlock. Y, como cabía esperar, se encuentran con que el rendimiento es una mierda. Lo cambiaron por un mutex y funcionó todo perfectamente, pero aún así le echan la culpa al planificador de Linux.
Es cierto que en el artículo original del programador (https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ ) hay mucha información interesante, como por ejemplo por qué AMD recomienda utilizar test-and-test-and-set en lugar de test-and-set para spinlocks. Aunque sus conclusiones son erróneas, es una lectura muy interesante y con muchos datos interesantes.
Es cierto que en el artículo original del programador (https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ ) hay mucha información interesante, como por ejemplo por qué AMD recomienda utilizar test-and-test-and-set en lugar de test-and-set para spinlocks. Aunque sus conclusiones son erróneas, es una lectura muy interesante y con muchos datos interesantes.
#6:
Traducción: básicamente lo que pasa es algo bastante usual. El programador no sabe usar algo y le echa la culpa al lenguaje/bibliotecas/sistema operativo.
Se quejan de que funciona lento algo que no deberían estar usando.
Se quejan de que funciona lento algo que no deberían estar usando.
Comentarios
Me leí todo el hilo original y la respuesta en Phoronix hace unos días, y tengo que darle toda la razón a Linus. Resulta que en lugar de utilizar un mutex (o un futex si querían mucho rendimiento), se programaron ellos mismos un spinlock. Y, como cabía esperar, se encuentran con que el rendimiento es una mierda. Lo cambiaron por un mutex y funcionó todo perfectamente, pero aún así le echan la culpa al planificador de Linux.
Es cierto que en el artículo original del programador (https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/ ) hay mucha información interesante, como por ejemplo por qué AMD recomienda utilizar test-and-test-and-set en lugar de test-and-set para spinlocks. Aunque sus conclusiones son erróneas, es una lectura muy interesante y con muchos datos interesantes.
Traducción: básicamente lo que pasa es algo bastante usual. El programador no sabe usar algo y le echa la culpa al lenguaje/bibliotecas/sistema operativo.
Se quejan de que funciona lento algo que no deberían estar usando.
#6 PICNIC.
Hasta Ricardo Galli se apunta a meter caña.
"un sistema de bloqueo que le diga al sistema que queda a la espera, en el que el hilo de desbloqueo le haga saber cuándo está listo. Así el planificador [de procesos] trabajará con ellos, en lugar de en su contra. Repito: no utilicéis spinlocks en el espacio de usuario, a menos que realmente sepas lo que estás haciendo. Y debes tener en cuenta que la probabilidad de que lo sepáis tiende a cero".
Elegante, muy elegante.
#1 (El creador de) Linux / Linus Torvalds
Pero "Linux" no es una persona que califique nada
#2 Linux es casi una IA.
#1 Efectivamente, no es elegante utilizar spinlocks en el espacio de usuario y me atrevería decir que en el modo kernel también porque utilizan un hilo de ejecución enterito para cada spinlock y si además tenemos en cuenta que el procesador de Stadio no debe tener muchos hilos entonces es probable que se bloqueé con frecuencia.
Existen varias maneras de esperar hasta que un recurso no este ocupado y eso dependerá del tipo de recurso y de la estrategia a usar:
- Si es un archivo o un socket se puede esperar a que se cierre el archivo utilizando los eventos del kernel. Yo por ejemplo utilizo libevent para saber cuando un archivo se cierra y pedirle al planificador de tareas de mi aplicación que lo abra con el siguiente proceso. La ventaja es que es rápido y utiliza los eventos del kernel con lo cual no tengo que utilizar totalmente un hilo de ejecución solo para esta tarea.
- Si es un recurso en memoria se puede implementar un sistema de semáforos en el planificador de tareas de la aplicación que responda a señales POSIX recibidas desde otros procesos (IPC) cuando estos dejen de utilizar el recurso. Este método tiene desventajas y problemas pero es muy rápido y tampoco requiere de utilización de un hilo dedicado.
Existen muchas mas estrategias de que nos permiten compartir recursos en un sistema concurrente, pero ciertamente los spinlocks no son la mejor manera.
Quiero también dejar claro que no estoy criticando al desarrollador del juego por utilizarlos, tal vez por desconocimiento o tal vez porque tiene que intentar resolver alguna limitación del sistema (Android no es 100% Linux) ha empezado a utilizarlos. En meneame nos gusta ser un poco cuñados hasta el día que nos ponemos en el cuello de los que criticamos
#12 Sobre tu párrafo final, el cuñado parece ser el desarrollador, el cual echa la culpa al sistema operativo de algo que no sabe usar bien. No voy a ser yo quien lo critique, ya se ha comido el bonito zasca de Linus y a la vez le ha resuelto el problema, todos contentos.
Google Stadia es la repetición del juego ET el extraterrestre de Atari. Mucho marketing, mucho jefazo de saco y corbata o zapatos de tacón alto.... Y poca discusión tecnológica.
#4 No veo por qué. Las pruebas en Chromecast muestran que funciona como mínimo igual de bien que un juego en consola.
Las pruebas en pc con Chrome sí que tienen pérdidas de frames, pero es razonable porque están sumando las latencias del sistema operativo al usar el mando conectado por USB en lugar de que vaya directo a internet como ocurre con Chromecast.
Habrá que ver comité evoluciona la cosa pero queda claro que es el futuro porque todos se están colocando de lleno a eso. El próximo competidor será Amazon.
#7 hasta no ver no creer. Me cuesta creer que vaya igual que en una consola como la xbox one x.
Ningún proyecto similar lo ha conseguido y hay críticas de que los juegos portados son un poco mierder
#7 Es totalmente imposible que vaya igual. Para que vaya igual tendría que tener una latencia de red igual a cero. Y la magia para Harry Potter
#13 Lo que dices es completamente lógico.
Es razonable pensar que la transmisión por internet tiene que tener una latencia considerable.
Pero... los sistemas "tradicionales" también tienen su latencia... ¿Y si la latencia de un PC normal fuera mucho más grande de lo que debería pero lo suficientemente peque para que no lo notemos si estamos acostumbrados?
Eso es lo que dicen que pasa con Stadia: al parecer no es que tenga poca latencia. Es que los PCs tienen mucha. ¿Por qué tendría mucha latencia un PC? Porque funciona con un sistema operativo de uso general, no diseñado para juegos.
Imagina que pudieras correr el juego sobre un sistema que ni siquiera necesita proteger la memoria: que tienes toda la memoria para ti mismo y el núcleo del sistema no tiene que administrar permisos de acceso, bloqueos de memoria, aleatorización para evita hackeos, etc. En un PC hay un montón de cosas que no harían falta si sólo vas a ejecutar un único programa.
A demás, tienes un montón de capas de compatibilidad. Por ejemplo el sonido: muchos chips de sonido soportan diferentes bitrates. Algunos van a 44100, otros a 44800, y cosas así. El software algunas veces envía a 22000, otras veces a 44100, y el sistema operativo se encarga de hacer de intermediario para enviar los datos al chip de sonido según lo que soporte. Si pudieras deshacerte de todo eso reducirías mucho la latencia. Lo mismo ocurre con el vídeo y con los mandos.
En un PC hay un montón de "peso extra" que se puede eliminar cuando estás seguro de que en el ordenador sólo se ejecutará un programa y que ni siquiera necesita tener protecciones anticopia.
Todo eso probablemente sea suficiente para compensar la latencia de internet y, según algunos, hasta que funcione mejor.
El problema viene cuando intentas ejecutar Stadia en un PC. En ese caso sumas la latencia del PC más la latencia de Stadia, y ahí es cuando se obtienen los resultados malos que han mostrado algunas reviews. Cuando lo usas directamente con un Chromecast, según dicen algunos, va igual y hasta unos milisegundos meujor que en PC.
Pero bueno, será cosa de ver cómo evoluciona todo esto.
#15 entonces Google debe olvidarse del PC y apostar todo al Chromecast (así tenga que venderlo a pérdida), porque sería un hardware absolutamente dedicado al servicio Stadia.
#17 Sí... no se por qué permitieron jugar en PC. Tal vez para que no se dijera que era caro por tener que comprar el chromecast. Pero al final ha sido peor porque las reviews han sido malísimas.
Sólo he visto una en que usaban una cámara de alta velocidad para medir los milisegundos que pasaban entre que se presionaba un botón y se reflejaba en la pantalla, y resultaba que la latencia medida con el juego corriendo en PC (sin Stadia) era bastante peor que en XBox One. Y la de Stadia con chromecast estaba muy cerca de la respuesta de XBox.
No lo encuentro ahora pero mira estos:
En este, en Inglés, cuantan los frames de la grabación para ver el tiempo:
Es un vídeo con los primeros minutos de gameplay de Destiny 2 jugado desde el PC con teclado y ratón. Podéis apreciar la latencia (que es sorprendentemente nula) mientras se juega y un horror cuando se está en el menú (que pinta más que sea una cosa del juego).
Otros donde hablan del asunto:
Esto me recuerda cuando algunos estudios de videojuegos compraban el idtech de idsoftware y luego se quejaban de que era muy difícil utilizarlo.
Incluso en el plano personal aun recuerdo un "petadon" de un servicio critico en empresa ibex. Un mánager metido a DBA pensó que el SID de v$session en Oracle DB era el pid de hpux y le aplico un kill en el sistema. Tubo la mala suerte que ese id de proceso oracle coincidía con el "servicio/demonio" lvm y el resultado ya se lo pueden imaginar. Luego decía que la culpa era la nomenclatura de Oracle DB con respecto a los procesos.
#8 No sé si será porque no se está utilizando bien, pero no quiero el IDTech ni gratis. Todos los juegos que lo usan tienen un montón de problemas de artefactos gráficos, rendimiento pésimo y otras mil cosas inexplicables. Bethesda está vetada en mi biblioteca
#14 No sera el caso de Quake Champions o Doom (2016), incluso este ultimo se utiliza como prueba de rendimiento.