La mejor respuesta
P: ¿Por qué los programadores siempre mezclan Halloween y Navidad?
R: ¡Porque 31 de octubre == 25 de diciembre!
Dos bytes se encuentran. El primer byte pregunta: «¿Estás enfermo?». El segundo byte responde: «No, me siento un poco mal».
P: ¿cuántos programadores se necesitan para cambiar una bombilla?
R: ninguno, eso es «sa problema de hardware
P: ¿cuántos programadores de Microsoft se necesitan para cambiar una bombilla?
R: ninguno, simplemente hacen de la oscuridad un estándar y les dicen a todos «este comportamiento es por diseño «
Un estudiante de ciencias de la computación está estudiando debajo de un árbol y otro se detiene en una bicicleta nueva y llamativa. El primer estudiante pregunta:» ¿De dónde sacaste eso? «. El estudiante en la bicicleta responde:» Mientras estudiaba afuera, una hermosa niña se detuvo en su bicicleta. Se quitó toda la ropa y dijo: Puedes tener lo que quieras ”. El primer estudiante responde: «¡Buena elección! Su ropa probablemente no te hubiera quedado».
Un físico, un ingeniero y un programador estaban en un automóvil conduciendo por un paso alpino empinado cuando fallaron los frenos. El coche iba cada vez más rápido, estaban luchando por doblar las esquinas y una o dos veces solo la débil barrera de seguridad los salvó de estrellarse por la ladera de la montaña. Estaban seguros de que todos iban a morir, cuando de repente vieron El físico dijo: «Tenemos que modelar la fricción en las pastillas de freno y el aumento de temperatura resultante, ver si podemos averiguar por qué fallaron». El ingeniero dijo: «Creo que tengo algunas llaves en la parte de atrás. Voy a echar un vistazo y ver si puedo averiguar qué es lo que está mal». El programador dijo: «¿Por qué no nos ponemos en marcha de nuevo y vemos si es reproducible?».
P: «¿Cuál es la forma orientada a objetos para hacerse rico?»
A : Herencia
Un programador a sus amigos (también programadores): «Anoche conocí a una chica caliente. La traje a casa y comenzamos a besarnos furiosamente. La senté en el teclado y …». Todos los amigos al unísono dijeron: «¿Tienes una computadora en casa?» ¿Cuál es su RAM?
Una consulta SQL entra en una barra, camina hasta dos mesas y pregunta: «¿Puedo unirme a ustedes?» C ++, todo comienza a verse como un pulgar.
P: ¿Cuántos programadores de prolog se necesitan para cambiar una bombilla?
R: Sí.
A El programador pone dos vasos en su mesita de noche antes de irse a dormir. Uno lleno, en caso de que tenga sed, y uno vacío, en caso de que no.
Un tipo está parado en la esquina de la calle fumando un cigarrillo tras otro. Una señora que pasa por allí se da cuenta él y le dice: «Oye, ¿no sabes que esas cosas pueden matarte? Quiero decir, ¿no viste la advertencia gigante en la caja?». «Eso está bien», dice el tipo, resoplando casualmente «Yo» ma programador informático «.» ¿Y? ¿Qué tiene que ver eso con algo? preguntó la señora. Él respondió: «No nos importan las advertencias». Solo nos preocupan los errores «.
Hay 10 tipos de personas en el mundo. Aquellos que entienden el binario y aquellos que tienen sexo regular.
Así que este programador tiene una cita con una chica caliente
Responder
Son muy malos.
Son los tipo de gente que entrará y modificará un sistema finamente ajustado con una solución «obvia», y arruinará todo horriblemente, con las mejores intenciones.
Para darle una idea, otro excelente ingeniero que conozco , Jeffrey Hsu, estaba trabajando en ClickArray (ahora conocido como Array Networks) y me contrató allí porque necesitaba otro tipo de «arma grande» para realizar un trabajo realmente crítico para el rendimiento.
Y lo conseguimos. hecho.
En sistemas Pentium 4 de 1.3GHz (era 2001).
Tenemos un caché de proxy inverso de hasta algo más de 38,700 conexiones TCP por segundo, lo cual no es impresionante , hasta que se dé cuenta de que solo hay 16,384 puertos utilizables para INADDR\_ANY, a menos que modifique sustancialmente fy la pila TCP / IP, si es un sistema basado en BSD o Linux.
No habíamos modificado la pila, era una pila BSD, por lo que significaba que también estábamos respondiendo a las solicitudes de carga de página iniciales en ese mismo período de tiempo.
Y luego pasamos al siguiente problema
Aproximadamente medio mes después del siguiente problema, aparentemente alguien finalmente había hecho algo de tiempo para hacer algunas pruebas de rendimiento en los cambios que habían estado haciendo en el resto del código en la caché.
Pudimos ver un pánico creciente en la oficina por un un par de días, y pregunté varias veces cuál era el problema, y me dijeron que no se preocupara por eso y que siguiera trabajando en lo que estábamos trabajando.
Lo hicimos, porque estábamos arreglando la máquina de estados finitos para ser una máquina de estados finitos real, y reestructurando el código de caché en ese momento. De hecho, es una de las cosas que le dieron a la empresa su próxima ronda de financiación.
Finalmente, sus expertos nos llamaron para ver si podíamos solucionar su problema.
Estaban obteniendo alrededor de 6.300 conexiones por segundo.
Habían perdido aproximadamente un factor de 6 veces en rendimiento y no podían averiguar dónde.
Nos tomó un par de horas, y finalmente lo rastreamos hasta una confirmación de «optimización para múltiples máquinas de CPU».
Lo deshicimos, y volvimos a aproximadamente 35,000 conexiones por segundo, volvimos a sintonizar un un par de rutas de código activo, y al final del día volvimos a los números anteriores.
Para comprender la «optimización» que el » «hot shot programmer» pensó que estaba haciendo, tienes que entender que el subproceso no era una gran cosa en ese momento.
Incluso si lo hubiera sido, todavía estábamos trabajando en la máquina de estado , que tenía que hacerse antes de que el estado global pudiera haberse movido a un solo objeto «statite» para hacerlo por subproceso y evitar que las instancias interfirieran entre sí.
Así que el modelo de escala era para tener varios motores de «trabajo por hacer» como p procesos, y luego un proceso «guardián» que dejaba que un proceso funcionara en una solicitud a medida que ingresaba. Veía todas las solicitudes y luego «dejaba ir el proceso»; si hubiera más solicitudes, la kqueue en el gatekeeper «dejaría ir a otro proceso», y así sucesivamente.
Nuestro «hot shot» había notado que un proceso estaba haciendo casi todo el servicio de solicitudes, mientras que el otros procesos estaban (en su mayoría) inactivos.
Esto se debe a que había usado intencionalmente un LIFO en lugar de un FIFO para los procesos que esperaban «trabajo por hacer».
Así que él «arregló ”Cambiándolo a FIFO.
Y el rendimiento se fue al infierno.
La razón por la que usé un LIFO en el primer lugar, aunque sabía que no necesariamente compartiría la carga entre los núcleos, fue porque sabía algunas cosas que el «hot shot» no sabía.
Sabía que:
- Como dispositivo de red, casi siempre íbamos a estar vinculados a la E / S, en lugar de a la CPU, a menos que estuviéramos cargando un módulo para hacer algo como la eliminación de espacios en blanco o la reescritura de contenido con fines publicitarios
- Más concretamente, sabía que el último proceso para hacer fila era ir g para tener todas sus páginas en el núcleo, mientras que la que había estado inactiva por más tiempo probablemente no tendría todas sus páginas en el núcleo
- Además, sabía que habría colisiones de caché TLB, ya que todos los procesos de espacio de los usuarios se mapearon en el mismo rango de direcciones, lo que resultó en descargas
- Lo que significaba que tendría que haber recargas de caché, lo que mínimamente significaba salir al menos a L1, y probablemente a L2,
- Combinado, esto daría lugar a paradas adicionales de la canalización de instrucciones, porque no había caché L3 en la arquitectura P4
- Y por eso cambié intencionalmente lo que sabía que probablemente iban a ser ciclos inactivos de CPU en el adicional núcleos para lo que sabía que tendría el mejor rendimiento de enlace de E / S
Así que elegí intencionalmente un orden LIFO y verifiqué una mejora en el rendimiento, utilizando una técnica que usé por primera vez en 1994 o así llamado (por mí, ya que había inventado la técnica) «programación de motor caliente».
Así que este «tiro caliente» había destruido el pe rendimiento debido al cambio.
Y luego, después de la supuesta «optimización», no pudo ejecutar una prueba de rendimiento para verificar que en realidad se trataba de una optimización.
Lo único que él Lo que comprobó fue que, bajo carga, todos los procesos marcaban aproximadamente el mismo uso total de CPU, a lo largo del tiempo, que es lo que pensó que quería decir que iba a obtener una mejor utilización multinúcleo.
Los peores ingenieros de software son aquellos que son lo suficientemente buenos para ser peligrosos, pero no lo suficientemente buenos para reconocer cuando están tomando una mala decisión.
Se agravan aún más al no verificar después del hecho de que la decisión fue de hecho mala al medir los resultados de sus cambios usando una regla imparcial.