AMD Bulldozer / Bobcat / Zambezi - Plataformas.

Guilherme FW Xavier · 30 de maio de 2012

O mistério do Bulldozer, porque deu errado (em inglês):

http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/1

jonny_br · 30 de maio de 2012

O mistério do Bulldozer, porque deu errado (em inglês):
http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/1

Cara, falar a verdade...

Mesmo se esse artigo fosse escrito em português, eu não ia compreender o autor.

No entanto, o Xeon 5600 é equipado com o gerenciamento de energia muito melhor e o Xeon venceu a batalha de performance/watt na maioria das aplicações, com exceção de aplicações de HPC.

Eu vou dar 1000U$ num Interlagos pra ficar brincando de benchmark em casa.

Isso significa que Bulldozer deve ser melhor na extração de ILP (Paralelismo nível de instrução) de código que tem baixo IPC (instruções por ciclo).

Tudo bem, sou leigo demais para entende, mas, "Beiço de Jegue não é arroz-doce".

sirroman · 31 de maio de 2012

Cara, falar a verdade...
Mesmo se esse artigo fosse escrito em português, eu não ia compreender o autor.

Eu vou dar 1000U$ num Interlagos pra ficar brincando de benchmark em casa.

Tudo bem, sou leigo demais para entende, mas, "Beiço de Jegue não é arroz-doce".

Pelo que eu entendi o problema é que um erro de previsão demora muito para ser corrigido no BDZ e que supostamente o "cache L1 de instruções" é pequeno demais para suportar dois núcleos, eis porque ativar o segundo núcleo atrapalha o outro mais que o esperado.

Fora isso, a latência do cache L2 em regra só atrapalha em programas de usuário final, não em servers.

Pistigrilo · 31 de maio de 2012

Pelo que eu entendi o problema é que um erro de previsão demora muito para ser corrigido no BDZ e que supostamente o "cache L1 de instruções" é pequeno demais para suportar dois núcleos, eis porque ativar o segundo núcleo atrapalha o outro mais que o esperado.
Fora isso, a latência do cache L2 em regra só atrapalha em programas de usuário final, não em servers.

Esses problemas serão corrigidos no Vishera ou vai continuar essa caca?

Evandro · 31 de maio de 2012

A tradução resumida do artigo, pelo Mestre em pessoa:

http://www.doompc.com/forum/viewtopic.php?f=9&t=42&start=1670#p5030

Eu estou sem saco total pra ler o original, e o Alê entende isso bem mais que eu, então, confio no que ele disse.

sirroman · 31 de maio de 2012

Esses problemas serão corrigidos no Vishera ou vai continuar essa caca?

Eu não lembro do "sistema auxiliar" ao branch predictor que o Ziebert fala no link do Evandro, mas eu acho que se confirmar isso que o pessoal do Anand o caminho mais simples seria ajustar melhor o cache L2 e aumentar o Cache L1 de instruções.

Se o que o Charlie fala é verdade pelo artigo dele (passei o olho para ver o geral das mudanças) e somando com o que o Ziebert falou do branch predictor, então parece que a AMD realmente tocou (ao menos um pouco) em quase todos esses gargalos do BDZ. Menos no cache L1 de instruções que eu não vi ninguém falando se cresceu ou não.

Mas o maior ganho vai ser do clock. Se o Vishera vier com o clock que o BDZ queria ter, e manter (ou melhorar um pouco) o ganho de IPC que a gente viu no trinity ele vai ser bem mais competitivo que o BDZ.

No fim das contas depende do clock.

A tradução resumida do artigo, pelo Mestre em pessoa:
http://www.doompc.com/forum/viewtopic.php?f=9&t=42&start=1670#p5030

Eu estou sem saco total pra ler o original, e o Alê entende isso bem mais que eu, então, confio no que ele disse.

Verdade. Só faltou observar que o artigo não deve ter falado em FPU porque deve tocar isso na suposta "segunda parte" que o tal do Johan está esperando mais testes para confirmar umas coisas e fechar o texto.

EduardoS · 31 de maio de 2012

O mistério do Bulldozer, porque deu errado (em inglês):
http://www.anandtech.com/show/5057/the-bulldozer-aftermath-delving-even-deeper/1

Não gostei do artigo (na verdade odiei), poderia ficar a madrugada toda citando os motivos mas vou citar só os principais:

1) Usou fontes de dados externas sem citação;

2) Dados apresentados de forma incompleta, impedem o leitor de tirar conclusões;

3) Nenhuma matemática, nenhuma lógica, dados apresentados e conclusões chutadas, até passou perto dos motivos que não fazem o BD lento mas sem chegar perto do que o torna lento, que era o objetivo do artigo.

aziebert · 31 de maio de 2012

Eu não lembro do "sistema auxiliar" ao branch predictor que o Ziebert fala no link do Evandro, mas eu acho que se confirmar isso que o pessoal do Anand o caminho mais simples seria ajustar melhor o cache L2 e aumentar o Cache L1 de instruções.

Não estou achando o artigo específico que falava sobre esse perceptron branch predictor, mas a ideia básica é que normalmente eles concordam, mas se o processador ficar na dúvida ele vai pelo mais exótico.

Another change is that Piledriver includes a perceptron branch predictor that supplements the primary branch predictor in Bulldozer. The perceptron algorithm is a history based predictor that's better suited for predicting certain branches. It works in parallel with the old predictor and simply tags branches that it is known to be good at predicting. If the old predictor and the perceptron predictor disagree on a tagged branch, the perceptron's path is taken. Improving branch prediction accuracy is a challenge, but it's necessary in highly pipelined designs. These sorts of secondary predictors are a must as there's no one-size-fits-all when it comes to branch prediction.

http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope

sirroman · 31 de maio de 2012

Não gostei do artigo (na verdade odiei), poderia ficar a madrugada toda citando os motivos mas vou citar só os principais:
1) Usou fontes de dados externas sem citação;

2) Dados apresentados de forma incompleta, impedem o leitor de tirar conclusões;

3) Nenhuma matemática, nenhuma lógica, dados apresentados e conclusões chutadas, até passou perto dos motivos que não fazem o BD lento mas sem chegar perto do que o torna lento, que era o objetivo do artigo.

Está mais para uma tentativa de entender características boas/ruins da arquitetura. E nisso ele até agora é o melhor que vi jogarem na net (mas eu tb nao estou acompanhando muito). Mas realmente a metodologia deve dar a desejar.

Ele diverge em algum ponto do que você (e outros que podem falar disso com propriedade) vê quando olha os resultados? Eu sei que não posso pedir uma crítica nem uma análise completa e técnica sobre tudo do BDZ (ou do artigo) mas algum comentário mais específico iria engrandecer muito o tópico.

Não estou achando o artigo específico que falava sobre esse perceptron branch predictor, mas a ideia básica é que normalmente eles concordam, mas se o processador ficar na dúvida ele vai pelo mais exótico.
http://www.anandtech.com/show/5831/amd-trinity-review-a10-4600m-a-new-hope

Aaaaah tá. Nem lembrava disso ai. vlwz.

EduardoS · 1 de junho de 2012

Está mais para uma tentativa de entender características boas/ruins da arquitetura. E nisso ele até agora é o melhor que vi jogarem na net (mas eu tb nao estou acompanhando muito). Mas realmente a metodologia deve dar a desejar.

O documento abaixo contém uma analise mais completa e correta da arquitetura: http://www.agner.org/optimize/microarchitecture.pdf

Ele diverge em algum ponto do que você (e outros que podem falar disso com propriedade) vê quando olha os resultados?

Olhando o artigo com mais calma ele concorda (comigo, porque parece que tirando o Agner, que escreveu o documento acima, todo mundo discorda de mim) no que não é o culpado pela baixa performance, alguns pontos que ele cita serem problemáticos provavelmente são uma intepretação errada dos dados publicados (e pelo que foi publicado só é possível saber que ele dividiu bananas por maçãs e chegou a uma conclusão errada porque sabemos que essa divisão não faz sentido, mas ele não cita o número de bananas e maçãs, assim leitores - nós - não saberemos se é problema ou não.) por outro lado, em um gráfico onde o BD se mostra excepcional provavelmente ele diviviu os números errados de novo.

Eu sei que não posso pedir uma crítica nem uma análise completa e técnica sobre tudo do BDZ (ou do artigo) mas algum comentário mais específico iria engrandecer muito o tópico.

Bem... Já que eu acusei ele de dividir números errados... Vai uns exemplos:

1) Pagina 10, Instruction Cache Hit Rate:

a) Esse gráfico só é relevante para o SQL Server, os outros dois tiveram números muito altos com todos os processadores, o SQL Server é realmente uma exceção, o tamanho do código é muito grande, é perigoso tirar conclusões gerais a partir dessas exceções;

Ele conclui que 64kb para duas threads é muito pouco... E esqueceu que os Xeons tem 32kb para duas threads... Ainda assim o Xeon conseguiu um hit rate maior e ele não deconfiou de nada

c) Esse "Instruction Cache Hit Rate" nos processadores da AMD é o número de "instruction fetches" servidos a partir do cache L1 dividido pelo total, acontece que um "instruction fetch" para a AMD são 32 bytes enquanto que para a Intel são 16 bytes (assumindo que a Intel usa a mesma nomenclatura, pode não usar), em 32 bytes cabem muitas instruções, mais especificamente 2 vezes mais que em 16 bytes, desvios vão diminuir o número de instruções efetivas nesse pacote, mesmo assim é seguro afirmar que há menos "instruction fetches" nos processadores da AMD do que nos processadores da Intel, e por fim, nesse quesito o que deixa o processador lento é o número absoluto de "instruction fetches" que não vieram do cache de instruções, se esse número tivesse sido divulgado ficaria claro que o cache de instruções não é tão pequeno assim.

2) Pagina 10, L2 Cache Hit Rate:

a) Ele corretamente concluiu que algumas porcentagens são muitos baixas porque os valores do L1 são muito altos;

Concluindo a porque não postou número absolutos? Agora nóes que temos que fazer as contas com os dois gráficos para chegar a números pouco precisos?

c) Juntando os dois gráficos para estimar o total de loads que seriam servidos pelo L2 se o L1 não existisse, teríamos algo como 99% a 99,9% para os Xeon e antigo Opteron e 99,99% a 99,996% para o Bulldozer, ta certo que o L2 do BD é maior e ele tem um bom prefetcher mas mesmo assim a diferença é absurda, duas ordens de magnitude e o autor não desconfiou de nada... O "L2 Cache Hit Rate" é o número de requisições atendidas pelo L2 dividido pelo número total de requisições ao L2, o provável problema é que as requisições ao L2 nem sempre são de "misses" do L1, no caso dos Xeons e antigo Opteron quase todas são porque eles tem caches write-back, mas os caches do Bulldozer são write-through, quer dizer, o que é escrito no L1 também é escrito no L2 e isso provavelmente conta como acesso ao L2, mas um acesso que nunca vai gerar um miss, a slução para isso e para termos dados úteis é simples, publicar o número total de requisições que o L2 não deu conta.

3) Cade os dados do L3?

4) Pagina 7, Libquantum, sem gráfico, sem dados, vale a menção pelas conclusões, os dados que ele usou são de publicações oficiais no site spec.org e de um estudo antigo em cima do Core 2 Duo (e nenhum link), aqui ele acha que o BD foi melhor no Libquantum por causa do prefetcher... Anh... É estranho alguém publicar um artigo sobre algo que desconhce (até porque ele criticou o SPEC nesse mesmo artigo, então ele devia conhecer...), mas vou assumir que ele de fato desconhece o teste e foi um erro inocente... A questão é, o Libquantum é fácil de vetorizar e esse trabalho de vetorização é feito pelo compilador, um compilador melhor produz resultados muito melhores, no caso do BD ele possui instruções novas (XOP, e de quebra AVX) além de ter usado um compilador mais recente, o compilador e as novas instruções, e não o prefetcher, devem ter sido os responsáveis por essa melhora absurda, esse teste em especial é famoso pelo efeito dos compiladores.

sirroman · 1 de junho de 2012

O documento abaixo contém uma analise mais completa e correta da arquitetura: http://www.agner.org/optimize/microarchitecture.pdf
Olhando o artigo com mais calma ele concorda (comigo, porque parece que tirando o Agner, que escreveu o documento acima, todo mundo discorda de mim) no que não é o culpado pela baixa performance, alguns pontos que ele cita serem problemáticos provavelmente são uma intepretação errada dos dados publicados (e pelo que foi publicado só é possível saber que ele dividiu bananas por maçãs e chegou a uma conclusão errada porque sabemos que essa divisão não faz sentido, mas ele não cita o número de bananas e maçãs, assim leitores - nós - não saberemos se é problema ou não.) por outro lado, em um gráfico onde o BD se mostra excepcional provavelmente ele diviviu os números errados de novo.

Bem... Já que eu acusei ele de dividir números errados... Vai uns exemplos:

1) Pagina 10, Instruction Cache Hit Rate:

a) Esse gráfico só é relevante para o SQL Server, os outros dois tiveram números muito altos com todos os processadores, o SQL Server é realmente uma exceção, o tamanho do código é muito grande, é perigoso tirar conclusões gerais a partir dessas exceções;

Ele conclui que 64kb para duas threads é muito pouco... E esqueceu que os Xeons tem 32kb para duas threads... Ainda assim o Xeon conseguiu um hit rate maior e ele não deconfiou de nada

c) Esse "Instruction Cache Hit Rate" nos processadores da AMD é o número de "instruction fetches" servidos a partir do cache L1 dividido pelo total, acontece que um "instruction fetch" para a AMD são 32 bytes enquanto que para a Intel são 16 bytes (assumindo que a Intel usa a mesma nomenclatura, pode não usar), em 32 bytes cabem muitas instruções, mais especificamente 2 vezes mais que em 16 bytes, desvios vão diminuir o número de instruções efetivas nesse pacote, mesmo assim é seguro afirmar que há menos "instruction fetches" nos processadores da AMD do que nos processadores da Intel, e por fim, nesse quesito o que deixa o processador lento é o número absoluto de "instruction fetches" que não vieram do cache de instruções, se esse número tivesse sido divulgado ficaria claro que o cache de instruções não é tão pequeno assim.

2) Pagina 10, L2 Cache Hit Rate:

a) Ele corretamente concluiu que algumas porcentagens são muitos baixas porque os valores do L1 são muito altos;

Concluindo a porque não postou número absolutos? Agora nóes que temos que fazer as contas com os dois gráficos para chegar a números pouco precisos?

c) Juntando os dois gráficos para estimar o total de loads que seriam servidos pelo L2 se o L1 não existisse, teríamos algo como 99% a 99,9% para os Xeon e antigo Opteron e 99,99% a 99,996% para o Bulldozer, ta certo que o L2 do BD é maior e ele tem um bom prefetcher mas mesmo assim a diferença é absurda, duas ordens de magnitude e o autor não desconfiou de nada... O "L2 Cache Hit Rate" é o número de requisições atendidas pelo L2 dividido pelo número total de requisições ao L2, o provável problema é que as requisições ao L2 nem sempre são de "misses" do L1, no caso dos Xeons e antigo Opteron quase todas são porque eles tem caches write-back, mas os caches do Bulldozer são write-through, quer dizer, o que é escrito no L1 também é escrito no L2 e isso provavelmente conta como acesso ao L2, mas um acesso que nunca vai gerar um miss, a slução para isso e para termos dados úteis é simples, publicar o número total de requisições que o L2 não deu conta.

3) Cade os dados do L3?

4) Pagina 7, Libquantum, sem gráfico, sem dados, vale a menção pelas conclusões, os dados que ele usou são de publicações oficiais no site spec.org e de um estudo antigo em cima do Core 2 Duo (e nenhum link), aqui ele acha que o BD foi melhor no Libquantum por causa do prefetcher... Anh... É estranho alguém publicar um artigo sobre algo que desconhce (até porque ele criticou o SPEC nesse mesmo artigo, então ele devia conhecer...), mas vou assumir que ele de fato desconhece o teste e foi um erro inocente... A questão é, o Libquantum é fácil de vetorizar e esse trabalho de vetorização é feito pelo compilador, um compilador melhor produz resultados muito melhores, no caso do BD ele possui instruções novas (XOP, e de quebra AVX) além de ter usado um compilador mais recente, o compilador e as novas instruções, e não o prefetcher, devem ter sido os responsáveis por essa melhora absurda, esse teste em especial é famoso pelo efeito dos compiladores.

Não sei se tão falando algo assim por lá, mas já que ele supostamente vai soltar outro artigo talvez pudesse publicar os dados "brutos", vamos torcer para ele fazer isso, assim eles podem por qualquer um que tenha o interesse. O "mercado" de reviewers está assolado de gente que tem acesso ao equipamento e tem muito tempo sobrando, mas ou não tem gabarito para analisar ou não é parcial o suficiente, e já viu.

Eu já tinha visto um pedaço desse artigo do agner, bem lembrado e eu até quero dar uma olhada nele. Mas a leitura por vezes é bem pesada (como não pode deixar de ser), por isso que eu esperava que o artigo do johan tivesse alcançado algo parecido de uma forma bem mais "visível".

E o lobo mau comeu o L3. XD

jonny_br · 1 de junho de 2012

O documento abaixo contém uma analise mais completa e correta da arquitetura: http://www.agner.org/optimize/microarchitecture.pdf
Olhando o artigo com mais calma ele ...

é disso que agente precisa e busca.

Muito obrigado^_^

EL ETRO · 3 de junho de 2012

Pelo que eu entendi o problema é que um erro de previsão demora muito para ser corrigido no BDZ e que supostamente o "cache L1 de instruções" é pequeno demais para suportar dois núcleos, eis porque ativar o segundo núcleo atrapalha o outro mais que o esperado.
Fora isso, a latência do cache L2 em regra só atrapalha em programas de usuário final, não em servers.

Sirroman, manda na lata pra gente, por favor: eles vão corrigir essas imprecisões de cache e tempos de acesso do o Trinty/PDVishera, mas nada fizeram pra otimizar o scheduling dentro do módulo(por causa daquele teste onde desativaram 1 núcleos por módulo...)?

O Trinty tá legal por hora, só o IPC dele que tá uns 6 atrasado...

sirroman · 3 de junho de 2012

Sirroman, manda na lata pra gente, por favor: eles vão corrigir essas imprecisões de cache e tempos de acesso do o Trinty/PDVishera, mas nada fizeram pra otimizar o scheduling dentro do módulo(por causa daquele teste onde desativaram 1 núcleos por módulo...)?
O Trinty tá legal por hora, só o IPC dele que tá uns 6 atrasado...

Se eu fosse você perguntava para o EduadoS isso.

EduardoS · 3 de junho de 2012

Sirroman, manda na lata pra gente, por favor:

Já que o Sirroman pediu...

eles vão corrigir essas imprecisões de cache e tempos de acesso do o Trinty/PDVishera,

A única mudança que teve no cache foi a duplicação da banda de escrita do L2, o que é muito importante em caches "write-through", não houve redução no tempo de acesso.

É um ponto que quase todo mundo discorda de mim mas, na minha opinião o tempo de acesso dos caches não causa problemas e toda a estrura de caches está bem dimensionada para o núcleo do Bulldozer, sim, é diferente de todos os outros processadores, mas todos os outros processadores tem núcleos diferentes, que eu me lembre o Bulldozer é o primeiro processador nesse estilo "CMT".

mas nada fizeram pra otimizar o scheduling dentro do módulo(por causa daquele teste onde desativaram 1 núcleos por módulo...)?

Que scheduling? Tirando o scheduler do Windows, que não tem nada a ver com a AMD, nenhum teste mostrou problemas no scheduler.

Pessoalmente acho que o buffer deveria ser maior, mas é só um chute, não tenho informações suficientes para ter certeza disso.

O Trinty tá legal por hora, só o IPC dele que tá uns 6 atrasado...

6 o que? Meses? Anos? Se fosse lançado em 2006 sem dúvida seria uma grande evolução.

sirroman · 4 de junho de 2012

EduardoS, qual é a sua opinião quanto aos Decoders?

(Para dar uma direção sobre a pergunta, você tá junto de uma penca de gente que acredita que os Decoders serão um ponto que a AMD vai mudar consideravelmente no Steamroller (falam em duplicar os decoders, dedicando um para cada núcleo) ou você pensa diferente?)

E você realmente não acha que os caches estão com latência muito alta não? Essa é uma crítica praticamente universal o.o, o que especificamente faz você pensar diferente?

EduardoS · 4 de junho de 2012

EduardoS, qual é a sua opinião quanto aos Decoders?
(Para dar uma direção sobre a pergunta, você tá junto de uma penca de gente que acredita que os Decoders serão um ponto que a AMD vai mudar consideravelmente no Steamroller (falam em duplicar os decoders, dedicando um para cada núcleo) ou você pensa diferente?)

Dedicar decoders para cada núcleo não vai resolver nada, existe um grande ganho em área mantendo eles compartilhados, ainda não estou convencido de que um núcleo realmente seja capaz de manter a execução de mais de 2 instruções por ciclo mesmo operando sozinho, se isso não mudar não tem porque aumentar os decoders.

E você realmente não acha que os caches estão com latência muito alta não? Essa é uma crítica praticamente universal o.o, o que especificamente faz você pensar diferente?

1) O BD se sai melhor em testes que estressam os caches.

2) É uma arquitetura voltados a clocks altos, a latência do cache nunca chegaria perto do Sandy Bridge ou K-8.

3) A unidade de load/store foi muito melhorada no Bulldozer, parece estar a frente inclusive do Sandy Bridge, há 40 slots na fila dos loads, um para cada slot no agendador (será que são os mesmos slots?) e isso é suficiente para que alguns acessos ao L2 passe desapercebidos (ao contrário do L2 do Llano, apesar da latência desse último ser apenas 12 ciclos).

Enfim, a arquitetura foi desenvolvida voltada para servidores, nesses sistemas a unidade load/store é muito importante e a AMD parece ter desenvolvido primeiro essa unidade (e muito bem por sinal) e depois feito o resto do processador em volta dela (ai nem tudo ficou muito bom...), os benchmarks mostram o resultado disso, a lógica que a maioria das pessoas parece adotar é: "é diferente da Intel? Então é ruim!", seguido por um grupo que pensa: "20 > 12, lento".

4) Essa até parece óbvio... Reduzir o tamanho do cache é muito, mas muito simples, isso permitira reduzir a latência (uns 18 ciclos se reduzisse para 1MB, talvez 16 se dedicasse 512kB para cada núcleo, mas não muito menos que isso, lembra do item 2?), mas sendo tão simples assim, se a AMD ainda não fez isso, será que podemos concluir que não aumentaria a performance? Tem tanta coisa difícil de mexer que parece insuficiente, vão botar a culpa justo no mais simples?

Guilherme FW Xavier · 5 de junho de 2012

Alguém já instalou o Windows 8 para testar?

jonny_br · 5 de junho de 2012

Alguém já instalou o Windows 8 para testar?

Sim, e já saiu a versão RP com o IE10 que vem com DNT ativado como padrão.

Guilherme FW Xavier · 5 de junho de 2012

Sim, e já saiu a versão RP com o IE10 que vem com DNT ativado como padrão.

Traduçào.??????

Talvez a pergunta tenha sido incompleta: alguém já instalou o windows 8 no BDZ para testar?

jonny_br · 5 de junho de 2012

Traduçào.??????
Talvez a pergunta tenha sido incompleta: alguém já instalou o windows 8 no BDZ para testar?

Tem estes testes ai espalhados na Web, se não me engano, um famoso a fazer foi Tom´s Hardware, mas, melhorias foram poucas, quase nada

EL ETRO · 5 de junho de 2012

Sheduling que eu falei é o CMT, por isso que eu pedi pro Sirroman explicar(sou leigo pra caramba nisso)...

Tem estes testes ai espalhados na Web, se não me engano, um famoso a fazer foi Tom´s Hardware, mas, melhorias foram poucas, quase nada

Tem uns testes aí dando até 10% de ganho... mas parece que o windows 8, além de vir mais barato, tá superior ténicamente em todos os aspectos... 3,3Gb de donwload pra(segundo fontes fudzilisticas de informação) 1/3 do tempo de instalação... e parece que vai custar bem menos(tipo, pro win8 standard escpeculam(fontes "fudzilistas-like") que vai custar alguma coisa entre o preço do W7 Home premium e o do Win7 professional, talvez menos. E esta versão standard vai vir com as funcionalidades do Win7 Ultimate e alguns "plus").

jonny_br · 6 de junho de 2012

AMD solta Brazos 2.0

http://semiaccurate.com/2012/06/05/amd-launches-brazos-2-0/

750~900mW aplica-se ao Chipset ou ao conjunto?

Como fica a vida de Brazos depois de Trinity 17W?

Guilherme FW Xavier · 6 de junho de 2012

Estou com o Win 8 instalado no meu E-350. Parece bastante operacional, foi mais rápido de instalar e parece mais leve, mas a aparencia ainda não está finalizada (janelas sem borda redonda. Sem muita firula visual, fica bem bacana. O E-350 suporta numa boa. Até parece mais rápido.