View Full Version : Cpu's com 8 cores e 12mb de cache em 2008?


InterTwined
05-12-2005, 15:39
Yorkfield e Hapertown são os nomes dos bixos...

http://www.tomshardware.com/cpu/20051203/top_secret_intel_processor_plans_uncovered-06.html

muddymind
05-12-2005, 17:20
"i had a dream..."... sinceramente... a intel nem dual core consegue fazer decentemente :P e gostava de ver onde é q eles iam buscar espaço no IC pra por tanta cache...

CrazyBomber
05-12-2005, 17:27
É 8 cores e 10GHz. Ainda acreditam no pai natal? :P
Previsões dessas podem mandar à vontade. Não que me importasse de ter realmente processadores com 8 cores em 2008, mas é difícil de acreditar...

timber
05-12-2005, 19:05
Temos 2 cores em 2005
Se tivermos 4 cores para o meio de 2006
Não me aprece nada estranho ter 8 cores em 2008
Se os shrinks forem correndo bem
Isto independentemente da sincronização entre eles ser boa, buses etc...
Mas enfiar 8 cores em 2008 acho muito razoável.
O software é que tem que acompanhar dentor do possível esta multicorização

Winjer
05-12-2005, 21:09
Agora parece incrivél. Mas é preciso ter em conta que 2008 ainda está bem longe.
O que interessa agora é mostrar aos investidores que a empresa tem planos para o futuro, e quanto mais grandiosos mais os accionistas ficam contentes.

Koncaman
05-12-2005, 21:33
se eles optarem por um core, digamos, menos centralizado, é possivel fazer os tais 8 cores... mas são cores relativamente burros.
ha alguma diagrama de blocos do que poderá ser esta maquina?

isto cheira-me a Itanium...

blastarr
05-12-2005, 21:49
Nop.
Estes 8 cores são na verdade 4+4, um em cada die, tal como o P4 "Presler" difere do Pentium D "Smithfield" actual.
O "Presler" tem cada core em dies separadas, permitindo combinar chip's de diferentes partes da waffer para aumentar os yelds -cores funcionais-, o "Smithfield" tem os dois cores na mesma die, o que significa que, caso um dos cores esteja estragado, o que está mesmo ao lado na waffer para se juntar a ele num Pentium D também fica inutilizado, mesmo que estivesse a funcionar.

Exemplo:

"Novo" Pentium D:
http://www.hardwareportal.ru/News/Pictures/April.2005/Presler.jpg
---------------------------------------------------------------------------

"Antigo" Pentium D:
http://img.ferra.ru/pubimages/73572.jpg
http://www.hardware.no/nyheter/images/intel_smithfield_stor.jpg

Se há alguma conclusão a retirar desta estratégia, é apenas o facto quase certo de que não vão adoptar o controlador de memória integrado, que tanto sucesso tem dado à AMD nos Athlon 64/Opteron/Turion/Sempron, etc.

Koncaman
05-12-2005, 22:19
o facto de ter os dois cores separados também mete mais trabalho simbiotico no chipset. fica ele o principal encarregado de garantir que os dois cores recebem trabalho...
se o trabalho não é bem distribuido a relação fica antagonica, e todo o sistema perde com isso, em relação a um single core evoluido.
na AMD o trabalho é distribuido mais inteligentemente.

assim isto difere muito pouco de um sistema multi-processador, e um multi-core pode ser mais que isso.

Metro
05-12-2005, 22:22
Há muitas pontas soltas no artigo mas é interessante ver que eles já têm a funcionar o Allendale Dual core com 2MB L2 e o Kentsfield.

Espero grandes coisas do Conroe.
Uma coisa é certa. A Intel tem os recursos. Eu vou esperar pelos próximos capitulos. Intel ou AMD tanto se me dá. A história tem-se encarregado de mostrar que umas vezes a AMD está melhor e depois a Intel. Parece.me que a Intel daqui a um ano estará ao mesmo nivel ou melhor que a AMD. O Yonah em Janeiro já nos dirá alguma coisa. A performance tão perto do X2 3800+ em portatil dá que pensar.

destr0yer
05-12-2005, 22:55
8 cores... Um dos problemas que se nota em processadores dual core é a perda de performance se utilizar memórias lentas...Tem mais impacto que num sistema single core...

Quero ver 8 cores a lutar por bandwitch com mens lentas...

Já num x2, um super PI faz 30s, com 2 super PI faz 33s (por exemplo)

Penso que para haver uma boa performance neste campo, teriamos que ter a memória a 256 bits de bus e a operar na casa dos 2 ghz...

Ou 2 canais duplos de 128 bits, a operar a elevadas frequencias (2000,senão 3000 mhz), a alimentar cada quad core

Mas havia de ser bonito, cpu com uns 2000 pinos, 8 slots de ram e várias camadas de PCB para acomodar tantas pistas... Uma board assim seria enorme (eATX) e provavelmente muito cara, para não falar que um CPU com 2000 pinos seria maior que um A64 (provavelmente maior até que um XP socket 462)

Zar0n
06-12-2005, 03:12
Ficava mais impressionado a ver uma aplicação desktop k tenha 8 threads em simultaneo do k um cpu 8 cores. :rolleyes:

Borat Sagdiyev
08-12-2005, 18:55
Ficava mais impressionado a ver uma aplicação desktop k tenha 8 threads em simultaneo do k um cpu 8 cores. :rolleyes: Folding? :x2:

Zar0n
08-12-2005, 19:23
Folding? :x2:
Bem folding enquadra-se mais nas aplicações server, ai há muita computação distribuída.
Mas n tem utilidade nenhuma para o average joe.

Já agora a minha opinião sobre folding (vai-me cair tudo em cima, mas vou dizer a mesma :P )
É um total desperdício de recursos! energia, tempo de vida dos componentes, ruído etc...

Mais valia cada pessoa interessada contribuir com uns 50€ para 1 cluster k este fazia um melhor trabalho.

DJS
08-12-2005, 21:35
Já agora a minha opinião sobre folding (vai-me cair tudo em cima, mas vou dizer a mesma :P )
É um total desperdício de recursos! energia, tempo de vida dos componentes, ruído etc...

:smlot:
espero k tenhas a noção k te vão incendiar a casa e te vao crucificar e torturar ate à morte em praça publica:x2:

Metro
08-12-2005, 22:44
:smlot:
espero k tenhas a noção k te vão incendiar a casa e te vao crucificar e torturar ate à morte em praça publica:x2:


Aqui ninguem incendeia ninguem.
É a opinião dele. É errada e um cluster não resolve o problema. É o que dá falar sem saber.
De resto stay on topic sff.

O futuro vai ser multi core. Um exemplo bom é termos disponiveis á imenso tempo 64 bits e ainda não termos software a tirar partido dele. Com os multiplos cores tb não. Mas qd sair software a tirar partido disso vão mudar todos de opinião.
Eu sei o que farei. Não voltarei a comprar single core. Mas cada um fala de si.

greven
09-12-2005, 06:48
Subscrevo a opinião do Metro. 64Bits e Dual Core só ainda não são padrão porque não existe o Software que acompanhe o Hardware. Daí não investir já em Dual Core, agora ainda não vale a pena. Para o fim de 2006 vão todos mudar de opinião (os que ainda não vêem vantagem no dual core ou multicore).

MaTreCo
09-12-2005, 10:38
Isso é como tudo na vida: não havia aplicações multi-threaded porque não havia processadores multi-core para tirar partido delas, e não havia processadores porque não havia aplicações que os aproveitassem. Agora, o primeiro passo já foi dado e já temos os processadores. Também já se começam a ver algumas aplicações, entre elas jogos, que são multi-thread, por isso, é só uma questão de tempo. :)

Zar0n
09-12-2005, 12:54
Eu axo k o ideal era o hardware pararelizar as instruções, assim n era exigido ao programador o esforço de o fazer, ja k isso gasta imenso tempo e recursos.

Uma aplicação fica muito mais cara de desenvolver graças ao ao tempo gasto para criar as pararelizações.
Afinal o custo software é 99% de mão de obra dos programadores/artistas gráficos.

Soz pelo OT mas Metro n é "É o que dá falar sem saber."
Imagina um cluster como um central de produção de energia elétrica.
Folding são "10.000" gajos com geradores portáteis com motores de motoserra a produzir energia.
Claro se forem suficientes conseguem produzir a mesma energia, mas a custo de muito mais recursos, logo uma produção muito menos eficaz.
Era mais simples juntarem-se tds e comprar uma nova central eléctrica.
Claro k ai n havia o brag de dizer: "fiz 1000 pontos no boink" mas isso é outra questão :)

MaTreCo
09-12-2005, 15:51
Eu axo k o ideal era o hardware pararelizar as instruções, assim n era exigido ao programador o esforço de o fazer, ja k isso gasta imenso tempo e recursos.

Isso parece-me algo ... impossível. O problema não está em "pararelizar" instruções. Se um programa só executa em uma única thread, como é que o hardware, por muito inteligente que seja, consegue alterar em runtime o código, de maneira a "parti-la" em duas ??

BlueBird
09-12-2005, 15:56
8 cores... Um dos problemas que se nota em processadores dual core é a perda de performance se utilizar memórias lentas...Tem mais impacto que num sistema single core...

Quero ver 8 cores a lutar por bandwitch com mens lentas...

Já num x2, um super PI faz 30s, com 2 super PI faz 33s (por exemplo)

Penso que para haver uma boa performance neste campo, teriamos que ter a memória a 256 bits de bus e a operar na casa dos 2 ghz...

Ou 2 canais duplos de 128 bits, a operar a elevadas frequencias (2000,senão 3000 mhz), a alimentar cada quad core

Mas havia de ser bonito, cpu com uns 2000 pinos, 8 slots de ram e várias camadas de PCB para acomodar tantas pistas... Uma board assim seria enorme (eATX) e provavelmente muito cara, para não falar que um CPU com 2000 pinos seria maior que um A64 (provavelmente maior até que um XP socket 462)
Não estás a exagerar?
Em vez de se pensar em sistemas de memórias com 2 (dois canais) * 2 (duplos) * 128 (bits/canal) * 3000 * 1000 * 1000 (3Ghz) = 192GB/s de largura de banda máxima (teórica) pode-se optar por soluções bem mais "em conta" e realistas como por exemplo um terceiro nível de cache (a AMD tem no roadmap para 2007 cache L3) partilhado pelos cores, controlador de memória integrado para reduzir as latências (práticamente em todos os processador AMD).
Mas numa coisa tens toda a razão, não se pode aumentar o número de cores do cpu e continar a alimentá-los como se de um core apenas se tratasse.

Zar0n
09-12-2005, 17:26
Isso parece-me algo ... impossível. O problema não está em "pararelizar" instruções. Se um programa só executa em uma única thread, como é que o hardware, por muito inteligente que seja, consegue alterar em runtime o código, de maneira a "parti-la" em duas ??

Os progamas são feitos em linguagem de alto nivel como o C++, mas o hadware podia distribuir as intruções de assembly pelos varios cores desde k n haja dependencys entre elas.
Deste modo era possivel usar varios cores com aplicações single thread.

destr0yer
09-12-2005, 20:03
Não estás a exagerar?
Em vez de se pensar em sistemas de memórias com 2 (dois canais) * 2 (duplos) * 128 (bits/canal) * 3000 * 1000 * 1000 (3Ghz) = 192GB/s de largura de banda máxima (teórica) pode-se optar por soluções bem mais "em conta" e realistas como por exemplo um terceiro nível de cache (a AMD tem no roadmap para 2007 cache L3) partilhado pelos cores, controlador de memória integrado para reduzir as latências (práticamente em todos os processador AMD).
Mas numa coisa tens toda a razão, não se pode aumentar o número de cores do cpu e continar a alimentá-los como se de um core apenas se tratasse.
Ora bem, suponhando um bus de 256 bits (dual channel 128 ou quad channel 64) a 3 ghz... daria 96 gigas/s e não 192 :P

Quando quiz dizer controlador duplo de 128 era 2x 128, e não 2x dual 128 que vai dar no mesmo que 1x 256 (pense numa mobo dual socket 940 para opteron, cada socket tem (em geral, nem todos!) o seus pares de men, o que dá 2x 128 se pensar assim :P)

É caro? É complicado? As GTX DE HOJE possuem 512 megas alimentados com 256 bits de bus a quase 2 ghz :P

96/8 = 12 gigas/s por core teórico... Assim teriamos uma EXCELENTE performance :D

Mas eu penso que o futuro das mens nos multi core se calhar estará nas FB-dimm e X-ram,

BlueBird
11-12-2005, 17:35
Ora bem, suponhando um bus de 256 bits (dual channel 128 ou quad channel 64) a 3 ghz... daria 96 gigas/s e não 192 :P

Quando quiz dizer controlador duplo de 128 era 2x 128, e não 2x dual 128 que vai dar no mesmo que 1x 256 (pense numa mobo dual socket 940 para opteron, cada socket tem (em geral, nem todos!) o seus pares de men, o que dá 2x 128 se pensar assim :P)
"[...] 2 canais duplos de 128 bits [...]" é diferente de 1 canal duplo ou de 2 canis (simples e não duplos)....

É caro? É complicado? As GTX DE HOJE possuem 512 megas alimentados com 256 bits de bus a quase 2 ghz :P

96/8 = 12 gigas/s por core teórico... Assim teriamos uma EXCELENTE performance :D
Sabe-se bem como é a disponibilidade dessas memórias... nem a ATI consegue arranjar. O preço delas deve ser praí metade do preço final da gráfica, que não é muito barata.

destr0yer
11-12-2005, 18:29
"[...] 2 canais duplos de 128 bits [...]" é diferente de 1 canal duplo ou de 2 canis (simples e não duplos)....
lol, mas o que eu quiz dizer foi mesmo dual 128 bits!! (ou seja um BUS total de 256 bits, os sistemas dual channel actuais são 128 bits)
Sabe-se bem como é a disponibilidade dessas memórias... nem a ATI consegue arranjar. O preço delas deve ser praí metade do preço final da gráfica, que não é muito barata.
Estamos em 2005, estou a falar de mens para 2008, até lá as mens das VGA's já vão em GDDR4 de 5 ghz

blastarr
11-12-2005, 19:21
Tão cedo não vão ver bus de 256bit em RAM para PC's, pelo simples facto de necessitarem de muito mais traces na motherboard, logo, mais layers, logo, mais custos e mais dificuldades na definição do layout de determinado chipset.

BlueBird
12-12-2005, 23:15
Há outra coisa que também não ajuda... as memórias de uma gráfica ficam a poucos cm's do gpu e são soldadas, enquanto que os modulos de RAM são encaixados e a distancia entre o cpu e as memórias é bem maior, tudo isto só ajuda a criar "ruído".

[N]
12-12-2005, 23:35
O meu é verde...

Raden
13-12-2005, 02:20
lol

8 cores e temos todos q ter cascatas n? :P

eof