
EduardoS
Membro VIP-
Posts
6.875 -
Cadastrado em
-
Última visita
Tipo de conteúdo
Artigos
Selos
Livros
Cursos
Análises
Fórum
Tudo que EduardoS postou
-
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Bem... Não exatamente, os processadores da Intel transformaram as AGUs/LS em Store Address, Store Data e Load Data/Address, cada instrução que solicita dados da memória principal usa a terceira unidade, cada instrução que grava usa as duas primeiras, a primeira e a última são unidades capazes de calcular endereços de memória, a segunda é capaz de enviar dados à memória (na verdade, à unidade LS) e a terceira é capaz de buscar. Nos processadores da AMD, só tem as AGUs, e elas só calculam endereços, tanto para operações de escrita, quanto leitura, as operações em si são efetuadas pelas unidades LS, os K-7/8/10 possuem 3 AGUs, o que é um grande exagero já que nunca serão usadas ao mesmo tempo, mas elas são presas a uma ALU e não podem ser compartilhadas com outras, então esse exagero se faz necessário (de qualquer jeto, AGUs são baratas...), no Bulldozer o número de AGUs foi reduzida para duas, aparentemente separadas das ALUs (por isso as ALUs poderiam compartilhar a AGU se só existisse uma ou se existissem mais ALUs) e aparentemente também capazes de realizar tanto operações de escrita quanto leitura, mas isso ainda é incerto, pode ser que escrita e leitura tenha sido separadas como é o caso da Intel, ou do Bobcat... Simplesmente porque AGUs não são tão usadas quanto ALUs, os processadores da Intel possuem 3 ALUs mas apenas 2 "AGUs", quer dizer, nem duas porque uma só serve para leitura e a outra pra escrita, e eles estão muito bem assim, o Bulldozer terá menos ALUs e o mesmo número de AGUs mas (aparentemente) AGUs mais poderosas. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Ainda compartilham o front-end, cache de instruções decodificadores, preditor de desvios, etc. Quando um engenheiro da Intel propôs algo assim por lá ele chamou o "módulo" de "núcleo", chamar de "módulo" ou "núcleo" é mais questão de marketing e licenciamento do que uma questão técnica, pelo que já vi da Intel qualquer coisa que compartilhe mais do que o cache é um núcleo só, outros são mais flexíveis. Diria que esse é um mal sinal e que as versões para servidores terão pouco L3, se fossem monstros realmente bons para OLTP dariam mais importância ao Oracle, por outro lado a Oracle aumentaria o preço das licenças... Pela versão desktop de 8 núcleos? Quer apostar? Deixo minhas fichas nos 40%. A unidade de inteiros (escalares, que é as que tiveram o "aumento" que você citou) é pau a pau com os Cores, os dois possuem 3 ALUs, o Phenom 3 AGUs e não sofrem com read-modify-write e read-execute, os Cores possuem AGU/LS separada que pode executar instruções independentes mas sofrem com read-execute e especialmente com read-modify-write, a maior parte das instruções dessas unidades é mais rápida nos Phenom, em programas de criptografia em geral os Phenom se saem melhor (especialmente se o software em questão faz uso de mul e carry), e isso tudo comparando núcleo por núcleo e clock por clock. Onde os Core realmente são melhores é no subsistema de memória, em especial o i7, o SMT deles ajuda mais a mascarar latências do que a preencher as unidades de inteiros e nos aplicativos geralmente colocados no pote dos "inteiros" (ex: web servers, compactadores de arquivo, compiladores) o subsistema de memória é mais importante do que as unidades de inteiros em si. SSE4.x quando muito ajuda em um benchmark escolhido dos reviews a dedo para mostrar que elas existem, tem poucas instruções, muito específicas, poucas realmente úteis e dessas a maior parte foi tão mal implementada nos Nehalem/Westmare que só ajudam em pouquíssimos casos. E além do mais, a adoção delas foi baixa, ninguém sentiu falta delas quando a Intel deixou de fora das linhas mais baixas... Leve esse "se transformarão" com cautela, a AMD não disse como foi feito, ao invés de transformar duas unidades de 128 bits em uma de 256 bits é muito mais simples transformar uma instrução de 256 bits em uma de 128 bits... E a AMD já fez algo similar nos tempos do K-8. Ah, o que essas unidades tem a mais é as FMAC, propostas nas SSE5, depois propostas pela primeira versão das AVX que depois foram alteradas (capadas...), as instruções que a AMD vai implementar são parecidas com a primeira versão, mas no prefixo XOP. Pro SO isso é transparente, mesmo no caso dos i7 as unidades de inteiros serem compartilhadas não faz diferença nenhuma pro SO. 2 ALUs e 2 AGUs, mas independentes, na verdade esse é um ponto que eu gostaria de maiores esclarecimentos, 2 AGUs independentes para apenas 2 ALUs é exagero, TALVEZ elas possam fazer algo mais, é a única forma de não ser um exagero... Em relação aos K10 núcleo por núcleo, clock por clock isso é um retrocesso, por outro lado deve permitir que o BD atinja clocks maiores. Perai, antes era 100% sobre um 1090T, agora 80%-100% sobre um Deneb? Bem... O chute agora parece mais realista... ps: Toda a modificação da arquitetura não teve como prioridade aumentar a performance por núcleo por clock... -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Não, é a dupla G34/C32, o C32 foi feito baseado no LGA1207 mas os dois não possuem qualquer compatibilidade. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
2 ALUs, 2 AGUs, L1I e todo front-end compartilhado e clocks maiores... É... O café servido na AMD parece normal e dentro do prazo de validade... Que pena... Não gostei muito do L1D de 16kB, o scheduler vai mesmo conseguir mascarar a latência do L2? -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
??? Tem certeza que você não está confundindo ponto flutuante com alguma outra coisa? Em muitos aspectos, GPUs são mais flexíveis do que os vetores das AVX, e ainda assim, nos casos difíceis de vetorizar MADD ainda é melhor do que vetores. A área onde a AMD realmente precisa ralar pra incluir as GPUs na briga é em compressão de video. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
8 operações... FMADD conta como duas? Bons tempos em que uma operação era o mesmo que uma instrução... Agora ta mais perto da "FPU não ser fraca". Adoraria ver um processador com muita força bruta mas do ponto de vista comercial acho que para o JF usar operações como instruções nessa só se alguém tivesse misturado cogumelos alucinógenos no café dos engenheiros que projetaram o Bulldozer... Socket level... Multi-thread... Talvez seja melhor fazer o anti-dopping nos engenheiros da AMD antes de continuar os comentários. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Que usa ou que poderia usar? Que usa - Não. Que poderia usar - Sim. E o mesmo vale para servidores. Não, ninguém vai passar a usar só porque a Intel incluiu essas intruções e a MS incluiu os intríssicos, não é disso que eu to falando. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Se o compilador suportasse de forma mais inteligente, talvez, se essas instruções fossem melhor planejadas talvez os compiladores suportassem de forma mais inteligente. As instruções SIMD da Intel parecem ter sido formuladas pelo Aaron e ele parece só se importar com compressão de video, praticamente para todo o resto falta "aquela" instrução. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
No caso das AVX vai ser complicado mostrarem pra que vieram nos servidores... -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Isso tem muito mais a ver com projeto do que processo. Hoje a AMD compete com os 240mm² da Intel com 700mm², eles precisam melhorar a performance/watt/mm² e alterar o clock alvo é a maneira mais fácil de conseguir isso, se o Bulldozer fica com um tamanho de die mais razoável tipo 400mm² 50% mais performance que o MC vai ser excelente, terá sido muito melhor do que a Intel conseguiu na passagem dos 45nm para os 32nm, quer dizer, a AMD terá conseguido uma grande melhora arquitetural, se for outro monstrengo a AMD ta perdida... Sabe que sou um dos que discordam disso... Estagios mais curtos exigem menos tensão, reduz clock e tensão do Power 7 para ficar nos 125W dos x86, ainda terá um clock mais alto e performance "apropriada". Sim faz sentido, quando junta dois núcleos nesse módulo as partes mais caras e menos sensíveis a latência deveria ser compartilhadas para aumentar a utilização dessas (que se preocupa se a utilização de unidades baratas fica em 10%?), a fpu que é uma dessas partes cara é compartilhada, apostava alto que o front-end do Bulldozer também seria mas informações mais recentes sugerem que não, e 4 unidades de inteiros apesar de baratas ainda parece muito para quem esteja tentando economizar transistores. Nessa comparação existe um item contra o BDZ, o Magny Cours está no limite inferior da frequência/consumo, da para aumentar "muito" a frequência aumentando "pouco" o consumo e o X6 é um exemplo disso, não acredito que o BDZ já vai ser lançado tão perto desse limite ou seja, a vantagem das versões desktop deve ser menor. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Quem falou em clock a clock? Que eu saiba ninguém citou clocks, existe margem para o Bulldozer ter a pena 1GHz com uma performance por clock brutal mas também tem margem para que ele atinja 4GHz com performance por clock ridícula, ninguém sabe qual o clock que ele foi projetado, pode ter sido 5GHz tipo Power6 ou 2GHz tipo Itanium 2, e não é isso que vai deixar o chip bom ou ruim. Para quem vai apenas usar o processador o clock não faz diferença nenhuma, 50% mais rápido que o atual MC faz. Ainda quanto a performance por clock do Bulldozer, dois núcleos compartilham unidades, quem faz isso procura economizar transistores e/ou reduzir o consumo ao invés de garantir uma boa performance individual do núcleo, um forte indício de que a performance extra por núcleo veio de clock extra. Por outro lado cada núcleo tem 4 unidades de inteiros (adoraria, mas ainda duvido) o que não combina muito bem com econmizar transistores. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
O segundo caso vai continuar a ser um problema mesmo com as GPUs TOP sendo discretas, o que vem depois de GDDR5 512 bits? E PCIe uma hora será problema também, daqui a 10 anos as GPU terão que inventar uma forma mais eficiente de usar a banda de memória, o XBox 360 se vira com um "Frame Buffer" de eDram de 10MB... -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Não, os 50% e 80% são em relação ao próprio Bulldozer, no Bulldozer dois núcleos compartilham recursos formando um módulo, esse módulo com dois núcleos é 80% mais rápido e 50% maior do que um núcleo que não compartilhasse recursos com ninguém. Ao menos é isso o que eles dizem. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
E em 1971 é lançado o primeiro microprocessador, com seus 4 bits... E em 1980 vem o 8087. Se for para olhar para traz e começar a ver todos os não-microprocessadores que existiram também vai levantar a discussão do que é 64 bits, o Cray 1 por exemplo, apesar dele ter registradores de 64 bits ele tinha registradores de endereço, de 24 bits. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Acredito que você saiba a diferença entre inteiros 128 bits e pf 128 bits não é? E sabe também que PF de 64 bits existia muito antes dos processadores 32 bits não é? Então, uma coisa não tem nada a ver com a outra, DEC e MIPS se preocuparam com processadores 64 bits porque tava na cara que para o mercado deles (computadores com MUITOS processadores e memória) 4GB de memória virtual não dava nem pro cheiro. Vou concordar com você sempre que disser que a Intel criou as SSE nas coxas, as pressas, que AVX foi mostrada as pressas para jogar areia nas SSE5, etc. Isso tudo é verdade, o problema é quando entra na parte que sugere que SSE5 era perfeito e não sei mais o que, esquece, a AMD publicou SSE5 com antecedência justamente para forçar a Intel a mostrar o jogo e conseguiram, mesmo na época da SSE vs 3DNow! essa última tinha desempenho melhor porque SSE no P3 foi mal implementada, não que realmente existisse uma grande vantagem a favor do 3DNow!. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
PF de 128 bits é um formato de dados, não interfere na bitagem do processador, processador X bits é um processador que seus registradores gerais tem X bits de largura e pode usar eles para endereçar a memória. O processador até pode ter registradores gerais com tamanho diferente da memória endereçada, pra mais ou pra menos, mas isso é pouco prático, o ganho que registradores maiores trazem para endereçar a memória sem precisar de várias instruções extras é muito maior do que poder usar números maiores e endereçar mais memória do que cabe no resgitrador é terrivelmente lento chegando as vezes a ser impraticável. Enfim, uma coisa não tem nada a ver com a outra, um processador 16 bits poderia suportar o formato de PF de 128 bits sem ser chamado de 128 bits, inclusive o 8086 suportava o PF de 80 bits quando acoplado a x87, e nenhum dos dois era chamado de 64 ou 80 bits por causa disso. Só criptografia e para agradar a cientistas loucos... Mas o ponto é, você consegue trabalhar com números de 128 bits em u processador de 64, 32, 16 ou 4 bits, só demora mais, no caso do endereçamento de memória demora MUITO mais. Apesar de existir um pouco de verdade nesse quote ele está um pouco inclinado demais para um dos lados, SSE5 tinha um escopo muito mais limitado que as AVX e um foco um pouco diferente também, fica difícil dizer que é mais "elegante" nessas condições, o formato AVX tem algumas vantagens e já havia sido sugerido algo similar à AMD mas essa teve seus motivos para não adotar, mesmo alguns la dentro achando "muito elegante". -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Altamir, é fake. Dragum, 64 bits endereçam até 16 Etabytes, 256 milhões de vezes mais que 64GB, mesmo limitando a, digamos, 52 bits precisaremos de 64 mil pentes de 64GB para encher isso ai... E os bits não servem só para endereçar memória, nem todos os números usados cabem em 32 bits e ai existe um ganho de performance em usar um processador de 64 bits, o caso mais comum é criptografia. E no caso específico da x86-64 o número de registradores duplicou, o que também gera um pequeno aumento de performance. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Altamir, isso não é marketing, é fake com uma dose de confusão. Não vai ter Windows 8 ou 9 suportando processadores 128 bits tão cedo, não teremos processadores 128 bits tão cedo, tudo não passou de história e já foi desmentido. A "FPU128" do Bulldozer (e que já existia no K-10) se refere a unidades SSE capazes de executar uma instrução completa por ciclo, diferente do K-8 que quebrava em duas. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Minha opinião? Já tem mágica demais nesse processador, melhor esperar pra ver. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Mais uma viagem... Eles estão bem essa semana, vamos ver qual a próxima.A propósito, licença x86 não existe, patente x86 não existe, tecnologia do Hyper-Transport e controlador de memória é que nem tecnologia de camiseta.O famoso acordo entre Intel e AMD trata de patentes sobre detalhes, não sobre uma peça toda. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Ele é bem mais complexo que o K-10 sim, mas o Fudzilla viajou legal, trocou nomes, números e mais tudo que tinha direito. -
AMD Bulldozer / Bobcat / Zambezi - Plataformas.
EduardoS respondeu ao tópico de Guilherme FW Xavier em Processadores
Viajaram, não acredite em tudo que lê no Fudzilla. -
Qual a corrente que passa num processador?
EduardoS respondeu ao tópico de Raimar Lunardi em Processadores
Ta certo, esse é o resultado de muitos anos longe dos livros... Ah... Sabe quando tem um circuito em que passa um formato de onda que não se parece com nada, resistores não lineares, indutores, capacitores e de quebra até transistores? Um simples amplificador de guitarra? Meu primeiro contato com um desses foi traumatizante, achei que fosse mais simples... -
Qual a corrente que passa num processador?
EduardoS respondeu ao tópico de Raimar Lunardi em Processadores
No Pulso do Taser se tem micro-coulomb por micro-segundos, o que da Amperes... -
Qual a corrente que passa num processador?
EduardoS respondeu ao tópico de Raimar Lunardi em Processadores
Quantidade de corrente não existe, isso é o mesmo que falar quantidade de velocidade. Corrente é basicamente a velocidade dos coulombs (se tiver algum físico ai, eu sei, doeu, mas to tentando simplificar ao máximo), quantos coulombs passam em determinado tempo, até faz sentido falar em quantidade de coulombs, que é a carga elétrica, o que esta plotado no gráfico digamos que seja a corrente instantânea (ta, doeu de novo, mas para ficar bem com a analogia da velocidade), e que chega a até 16A, o Taser manda 182 microcoulombs por pulso, com 20 pulsos por segundo da um total de 3640 microcoulombs por segundo, que chega na média de 3,6mA, mas essa média é a mesma que a velocidade média do carro no exemplo anterior, ela só é baixa porque na maior parte do tempo o carro (e o Taser) ficaram simplesmente parados, o pulso do Taser dura 40us, depois ele fica parado por 49960us até disparar o próximo pulso, durante o pulso a corrente média foi de 4,55A atingindo 16A no 6us após o início do pulso, imagine que o carro, durante os 5 minutos que ele se movia, não mantinha uma velocidade constante, mas sim que foi de 0 a 500 e depois voltou a 0 (ele precisa acelerar e freiar né?) dando uma média de 300 km/h nesses 5 minutos. Já ia esquecendo, a área das curvas é a carga elétrica, nesse caso medida em microcoloumbs.
Sobre o Clube do Hardware
No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais
Direitos autorais
Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais