Feda /dev/ - No Javascript allowed

Mucho ha tardado en salir la foto del chuletón desde que se ha empezado a hablar de veganismo.

es que eres un provocador wei

#23826 no a todo, no tiene gran angular

#23828 tu también te follas a tu becaria e warro

El seitan no està mal. Yo lo pillo en el mercadona y (me) lo cocino (/an) en salsa barbacoa.

skizor hijo de puta

Ellos están pendiente' de mí
Me tienen puesta la mira
Pero yo siempre vuelvo, baby
Porque tus santos me cuidan

os recuerdo que podeis votar el horario de el stream aqui https://strawpoll.com/a81vfyeyo dependiendo de la hora y los colaboradores (registrados bajo mi nombre) que esten disponibles haremos una cosa u otra.

#23835 Yo hoy no he parado.

Desde las 8.30 dandole duro al CSS, html y javascript.

tengo que admitirlo.

he llorado.

poesia.

#23834 yo tengo uno de estos con leds azules, como recomendación te diría que con que puedas regularle la altura ya va bien xD

Busy polling is a relatively obscure (and not very well documented) networking feature that has existed since 2013 (kernel 3.11). It is designed for use cases where low latency is of the utmost importance. By default, it works by allowing a blocked socket to trigger polling for incoming data at the expense of additional CPU cycles and power usage.

The biggest downside of busy polling is the additional power and CPU usage that comes from polling for new data in a tight loop. The recommended value for net.core.busy_poll is between 50μs and 100μs, however in my testing I determined that I can still get all the benefits of busy polling (with almost none of the downside) with a value as low as 1μs. With net.core.busy_poll=50 the additional CPU usage of running the benchmark with just 8 connections is more than 45%, whereas with net.core.busy_poll=1 the additional CPU usage is only 1-2%.

Nunca llegué a pensar siquiera que el busy polling pudiese ser tan determinante, estas son las cosas que te mencionan una o dos veces de pasada y no te paras a pensar los efectos que pueden llegar a tener

#23843 Si claro, pero me parece interesante el approach.

Esto es escalabilidad.

Mucha gente cuando piensa en escalabilidad solo piensa en 2 ejes, el X y el Y.

Escalabilidad horizontal = mas maquinas
Escalabilidad vertical = maquina mas potente

Pero existe otro eje, el Z, que es el mas olvidado por el pajeet medio que seria la escalabilidad en rendimiento/eficiencia de tu solución. La profunidad!

Este tío a optimizado una solución y le ha sacado un x6 de rendimiento.

Es importante porque el approach de primero optimizar tu código, para una CPU (antes de paralelizar), para una maquina (antes de distribuir) es el primero que debería seguir todo programador.

No me lo he podido mirar porque me he ido a almorzar al bar, pero ahora le echo un ojo.

Sobre este tema de los 3 ejes, pienso escribir en el blog una entrada.

#23847 Felicidades!!! A disfrutar de la playita y el solecito veraniego valenciano