mad.onion

kkkkkkkkkkkkkkkkkkkkkkk esse Charlie já era. Acabei de pensar numa besteira agora pouco. Com o crescimento acelerado dos ARMs e seus fabricantes (Qualcomm, Samsung, Nvidia e etc.), a Intel podia alegar mudança de paradigma e comprar a AMD. Porque não? Tudo indica que o futuro será x86 vs ARM. Se isso acontecesse seria massa demais.

Eu me divirto. As estatísticas do plano de execução que o SQL Server exibe na análise são as mesmas que ele usa para decidir que caminho tomar pra executar uma query. O custo I/O estimado não é baseado somente em leituras físicas, caso contrário o banco poderia acabar não decidindo pelo melhor caminho, por exemplo caso uma determinada página de índice esteja no buffer e um outro índice para a mesma tabela não. De qualquer forma procurei aqui pra ver se achava algo, não achei nada que dissesse que a estimativa I/O é sempre de leitura física. Não posso afirmar que é ou não, mas posso afirmar que a estimativa exibida é a mesma que ele usa pra si mesmo. Então se o plano de execução "me enganou", ele enganou também o próprio banco de dados. Fora isso, não vejo aplicação real para zilhões de núcleos em um servidor cuja tarefa seja apenas banco de dados e geralmente 1 ou 2 bases por máquina (real ou virtual), pelo simples fato de que nenhum banco de dados até então consegue escalar linearmente com quantos cores estiverem disponíveis. Creio que haja um limite de escalonamento, a menos que um mesmo servidor sirva várias bases de dados, mas esse não é a realidade da maioria deles e mesmo se fosse, haveria o limite da memória. Talvez com o aumento do cloud, mas isso ainda está bem longe de se tornar algo palpável. Até lá vamos ter que conviver com o sinônimo de que servidor = CPU-aholic? Não é bem assim.

hmm, os planos de execução me enganaram... ta certo.

Em BD quanto mais núcleo mais rápido será feito o trabalho do CPU, porém em BD o maior gargalo nunca é a CPU. Não importa quantos núcleos o CPU tenha, veja qualquer plano de execução (no SQL Server se tiver um por aí, selecione uma query qualquer e mande um CTRL + L) que você vai ver ele acusar I/O como sendo disparado o maior custo de qualquer query que você medir. Exame que fiz rápido aqui, para uma tabela VAZIA, o custo estimado de I/O ficou quase 30x maior que o estimado de CPU. Tá, a query era ***** e envolvia só um index scan, mas eu trabalho todo dia com querys cabeludas, todas devidamente indexadas e o custo I/O sempre dá mais alto, por sinal muito mais, por mais order by e group by que tenha. Isso de CPU com vários núcleos em servidor de banco de dados é meio ilusão. É importante e quanto mais melhor? Claro que é, mas se e somente se o custo de I/O não for o problema.

É o novo método de trabalho da AMD: primeiro lança o CPU, e se der depois melhora ele com o tempo. No review do Anand a coisa piorou pra AMD. Bom, vou dormir, fui.

Bom, vou dormir... os próximos dias serão bacanas, vamos começar a especular qual cabeça vai rolar na AMD. To pensando em mandar uns CV pra lá, parece ser um lugar bacana, só tem festa e mentiraiada, e no final do mês não é preciso apresentar muitos resultados pra garantir o salário gordo. Fui dormir. Ué, lógico filho, o i5 tem 4 núcleos a menos! Óbvio que eles estariam mais ocupados! Ae, saiu do Anand! não durmo agora ! \o/

Pelo visto você já esqueceu toda conversa que tivemos a umas 40 páginas atrás. kkkkkkkkkkkkkkkkkkkkkkkkk Não é porque o sw é MT que ele vai disparar várias threads a todo instante. Um software com uma thread principal e uma auxiliar que aparece só em momentos críticos já é considerado MT.

Esse papo de CPU pra servidor é estranho.... queria saber a que tipo de servidor eles se referem, porque a maioria dos servidores que conheço são pra banco de dados, completamente gargalados por I/O. Não sei aonde encaixaria 16, 32 ou 1024 núcleos nesses casos aí. Parece que falar a palavra "servidor" está na moda nesses sites de reviews. Sim, já era, por parte da Intel tudo vai continuar como vem sendo, caro e caro. A boa notícia é que qualquer CPU meia boca está rodando com folga o que a maioria dos usuários precisa. Por isso a AMD tem que focar no médio segmento, pelo menos aí a concorrência não pode faltar. Quanto aos tops dos tops, who cares?

E o Ivy promete quanto? rs O "kit playmobil construção" da AMD não vai ter vida fácil pela frente. Sim, ninguém falou explicitamente que não vai fazer, este email é um diálogo inicial a respeito, mas pelo começo de conversa e o ânimo captado .... Bem, por mim eu já nem conto com patch nenhum.

O interessante é o email abaixo do dele:

Veja esse email aqui pra ter uma ideia melhor. http://article.gmane.org/gmane.linux.kernel/1170744 Sinceramente? Se sair vai ser uma gambiarra pra tirar mais uns 2% de desempenho. Umas 10 chineladas no meio da cara! kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk cara, eu "se diverto" com esses lançamentos broxantes.

Antes e agora. UAHUHuhaUahuA, você chegou a ver a reação do Linus em um de seus emails ao saber que teria que fazer uma alteração no kernel pra ganhar "5%" de desempenho para a AMD? Ele começou o email assim: "Argh..." kkkkkkkkkkkk O desempenho é esse aí e se AMD quiser ela que arrume o CPU e não peça para o mundo inteiro se adaptar ao seu produto.

Tomara. .

Vou te dar uma dica: esquece essa "correção de bugs". Essa eu assino embaixo e te garanto, não vai rolar nada.