Melhor resposta
P: Por que os programadores sempre misturam o Halloween com o Natal?
A: Porque 31 de outubro == 25 de dezembro!
Dois bytes se encontram. O primeiro byte pergunta, “Você está doente?”. O segundo byte responde, “Não, estou apenas me sentindo um pouco desconcertado.”
P: quantos programadores são necessários para trocar uma lâmpada?
A: nenhum, isso “sa problema de hardware
P: quantos programadores Microsoft são necessários para trocar uma lâmpada?
R: nenhum, eles apenas tornam a escuridão um padrão e dizem a todos “esse comportamento é intencional “
Um estudante de ciência da computação está estudando debaixo de uma árvore e outro puxa uma bicicleta nova e vistosa. O primeiro aluno pergunta:“ Onde você conseguiu isso? ”. O aluno na bicicleta responde:“ Enquanto eu estudava do lado de fora, uma linda garota parou em sua bicicleta. Ela tirou todas as roupas e disse: Você pode ter o que quiser. ” O primeiro aluno responde: “Boa escolha! As roupas dela provavelmente não caberiam em você.”
Um físico, um engenheiro e um programador estavam em um carro passando por uma íngreme passagem alpina quando os freios falharam. O carro estava ficando cada vez mais rápido, eles lutavam para contornar as curvas e uma ou duas vezes apenas a débil barreira de colisão os salvou de cair da encosta da montanha. Eles tinham certeza de que todos iriam morrer, quando de repente avistaram uma via de escape. Eles entraram na via de escape e pararam em segurança. O físico disse: “Precisamos modelar o atrito nas pastilhas de freio e o aumento de temperatura resultante, para ver se podemos descobrir por que eles falharam”. O engenheiro disse: “Acho que tenho algumas chaves na parte de trás. Vou dar uma olhada e ver se consigo descobrir o que está errado”. O programador disse: “Por que não vamos de novo para ver se é reproduzível?”
P: “Qual é a maneira orientada a objetos de se tornar rico?”
A : Herança
Um programador para seus amigos (também programadores): “Eu conheci uma garota gostosa ontem à noite. Eu a trouxe para casa e começamos a nos beijar furiosamente. Eu a sentei no teclado e …”. Todos os amigos em uníssono disseram “Você tem um computador em casa? Qual é a RAM dele?
Uma consulta SQL vai para uma barra, vai até duas tabelas e pergunta: “Posso me juntar a você?”
Quando o seu martelo está C ++, tudo começa a parecer um polegar.
P: Quantos programadores de prólogo são necessários para trocar uma lâmpada?
A: Sim.
A o programador coloca dois copos na mesinha de cabeceira antes de dormir. Um cheio, caso sinta sede, e um vazio, caso não fique.
Um cara está parado na esquina da rua fumando um cigarro atrás do outro. Uma senhora passando por avisos ele e diz “Ei, você não sabe que essas coisas podem te matar? Quer dizer, você não viu o aviso gigante na caixa ?!” “Tudo bem” diz o cara, bufando casualmente “eu” um programador de computador “.” E daí? O que isso tem a ver com alguma coisa? perguntou a senhora. Ele respondeu: “Não nos importamos com avisos. Nós só nos importamos com erros. “
Existem 10 tipos de pessoas no mundo. Aqueles que entendem de binários e aqueles que fazem sexo normal.
Portanto, este programador sai em um encontro com uma gostosa
Resposta
Eles são muito ruins.
Eles são os tipo de gente que vai entrar e modificar um sistema afinado com uma correção “óbvia” e bagunçar tudo horrivelmente, com as melhores intenções.
Para se ter uma ideia, outro excelente engenheiro que conheço , Jeffrey Hsu, estava trabalhando na ClickArray (agora conhecida como Array Networks) e me contratou lá porque ele precisava de outro tipo de “grande arma” para realizar um trabalho realmente crítico de desempenho.
E conseguimos foi feito.
Em sistemas Pentium 4 de 1,3 GHz (era 2001).
Temos um cache de proxy reverso de até cerca de 38.700 conexões TCP por segundo – o que não é impressionante , até você perceber que existem apenas 16.384 portas utilizáveis para INADDR\_ANY, a menos que você modifique substancialmente fy a pilha TCP / IP, se for um sistema baseado em BSD ou Linux.
Não modificamos a pilha – era uma pilha BSD – então isso significava que também estávamos respondendo às solicitações de carregamento de página inicial mesmo período.
E então passamos para o próximo problema
Cerca de meio mês depois do próximo problema, aparentemente alguém finalmente reservou algum tempo para fazer alguns testes de desempenho nas mudanças que estavam fazendo no resto do código no cache.
Observamos um pânico crescente no escritório por um alguns dias e perguntei várias vezes qual era o problema, e foi-me dito para não se preocupar com isso e continuar trabalhando no que estávamos trabalhando.
Nós fizemos, porque estávamos consertando a máquina de estado finito para ser uma máquina de estado finito real e reestruturar o código do cache no momento. Na verdade, foi uma das coisas que garantiu à empresa sua próxima rodada de financiamento.
Finalmente, seus figurões nos chamaram para ver se poderíamos consertar o problema.
Eles estavam obtendo cerca de 6.300 conexões por segundo.
Eles haviam perdido cerca de 6X no desempenho e não conseguiam descobrir onde.
Demoramos algumas horas e finalmente rastreamos até um commit de “fazer otimização para várias máquinas de CPU”.
Nós o desfizemos e voltamos a cerca de 35.000 conexões por segundo, reajustamos um alguns caminhos de código quente e, no final do dia, voltamos aos números antigos.
Para entender a “otimização” que “ hot shot programmer ”pensava que ele estava fazendo, você tem que entender que threading não era muito de uma coisa na época.
Mesmo que fosse, ainda estávamos trabalhando através da máquina de estado , que precisava ser feito antes que o estado global pudesse ser movido para um único objeto “statite” para torná-lo por thread e evitar que as instâncias interferissem umas nas outras.
Portanto, o modelo de escala deveria tem vários motores de “trabalho a fazer” como p processos e, em seguida, um processo “gatekeeper” que permitiria que um processo funcionasse em uma solicitação conforme chegava. Ele via todas as solicitações e, em seguida, “deixava o processo ir”; se houvesse mais solicitações, o kqueue no gatekeeper “deixaria outro processo ir” e assim por diante.
Nosso “hot shot” notou que um processo estava fazendo quase todo o atendimento da solicitação, enquanto o outros processos estavam (principalmente) ociosos.
Isso ocorre porque eu tinha usado intencionalmente um UEPS em vez de um PEPS para os processos que aguardavam “trabalho a fazer”.
Então ele “consertou ”Mudando-o para um FIFO.
E o desempenho foi péssimo.
A razão pela qual eu usei um LIFO em o primeiro lugar, embora eu soubesse que não necessariamente dividiria a carga entre os núcleos, era porque eu sabia algumas coisas que o “hot shot” não sabia.
Eu sabia disso:
- Como um dispositivo de rede, quase sempre estaríamos ligados a I / O, em vez de CPU, a menos que estivéssemos carregando em um módulo para fazer algo como remoção de espaço em branco ou reescrita de conteúdo para fins publicitários
- Mais especificamente, eu sabia que o último processo para entrar na fila estava indo g ter todas as suas páginas no núcleo, enquanto aquela que estava ociosa por mais tempo provavelmente não teria todas as suas páginas no núcleo
- Além disso, eu novo que haveria colisões de cache TLB, uma vez que todos os processos de espaço dos usuários foram mapeados no mesmo intervalo de endereços, resultando em liberações
- O que significava que teria que haver recarregamentos de cache, o que significava minimamente ir para pelo menos o cache L1, e provavelmente o cache L2
- Combinado, isso resultaria em paralisações de pipeline de instrução adicionais, porque não havia cache L3 na arquitetura P4
- E então eu intencionalmente troquei o que eu sabia que provavelmente seriam ciclos de CPU ociosos em outros núcleos pelo que eu sabia que teriam o melhor desempenho de limite de E / S
Então, eu intencionalmente escolhi um pedido LIFO e verifiquei uma melhoria de desempenho, usando uma técnica que usei pela primeira vez em 1994 ou então chamado (por mim, já que eu tinha inventado a técnica) “escalonamento do motor quente”.
Então, esse “tiro quente” destruiu o pe rformance por causa da mudança.
E então, após a suposta “otimização”, falhou ao executar um teste de desempenho para verificar se era de fato uma otimização.
A única coisa que ele d verificado foi que, sob carga, os processos estavam todos marcando aproximadamente o mesmo uso total da CPU, ao longo do tempo, o que ele achava que significava que obteria uma melhor utilização de vários núcleos.
Os piores engenheiros de software são aqueles que são bons o suficiente para serem perigosos, mas não bons o suficiente para reconhecer quando estão tomando uma decisão errada.
Eles ficam ainda piores por não verificar depois do fato de que a decisão foi de fato ruim, medindo os resultados de suas mudanças usando alguma régua imparcial.