Por onde andas aquela famosa investigação de Cartel?

Eu fico surpreso que alguém ainda se surpreenda com estas notícias.

Há muito mais coisas acontecendo que tornam este caso com a Futuremark (que já possue rombos em sua reputação) diminutos.

Num mercado de bilhões de dólares, com a mentalidade de um mundo atual onde eu, você e todos querem se dar bem a qualquer custo (leia-se em cima dos outros), a Intel e futuremark só se mostram sinérgicas com o mundo ao qual pertencem...

Eu me preocupo mais em avaliar os discursos e posturas dos meus vizinhos, conhecidos, companheiros de trabalho, amigos e inimigos do que na imagem que uma empresa puramente capitalista tenta me passar.

O mundo vai de mal a pior, e não é por causa de jogadas capitalistas, mas sim (repito) pela cabeça das pessoas, como eu, você e todos nós, independente da posição social ou nível de instrução. E casos e acasos decorrentes no mundo partem deste princípio, pois este sempre será determinado pelas pessoas e não por programas ou objetos materiais.

Vamos acordar galera! Independente da escolha entre Intel, AMD, Nvidia ou Via, todas elas querem a mesma coisa, ganhar nosso dinheiro, o resto é detalhe...

Olha, programação reversa num software desses não é impossível, mas ilógico, no entanto veja que não é apenas nesse programa que o pessoal tá falando, tem também um compilador Intel C++ onde vc o engana, segundo um user, veja nas páginas anteriores. Esse compilador é muito usado em recompilações de qualquer programa e consequente otimização de instruções, pensava-se que esse compilador apenas apontava os novos registradores padronizados, infelizmente faz mais que isso.

Não acho que seja doidera de fã de marca, a AMD reconhece pq esses testes são/eram considerados livres de práticas ilegais desse tipo. O teste da notícia não deixa dúvidas, há sim algo errado e não tem cara de engenharia reversa.

Vou traduzir o meu post anterior (página 4) para melhor compreensão.

Antes, no entanto, alguns breves esclarecimentos para melhor compreensão do texto. O texto em itálico são comentários meus. Sou formado em ciência da computação, assim, pude compreender o que está escrito. O que um compilador faz é traduzir código de alto nível (no caso, C++), para código de baixo nível (assembly). A máquina (processador) só lida com esse código de baixo nível, no entanto, é impraticável que se programe nesse nível, por isso a necessidade de linguagem em alto nível que seja traduzida (papel do compilador).

http://hardware.slashdot.org/hardware/0 ... 2237.shtml (comentário do Eponymous Cowboy em referência a essa matéria sobre a Futuremark)



Vou dar uma chance de 10:1 que a Futuremark simplesmente compilou seu benchmark usando o compilador de C++ da Intel.

Eu escrevi uma explanação detalhada [slashdo.org] ainda em 2005 sobre como o compilador de C++ da Intel gera caminhos de código distintos para operações de memória para fazer parecer que os processadores AMD são significativamente mais lentos, e como você pode enganar o código compilado fazendo-o acreditar que seu processador AMD é um Intel para ver um incrível aumento na performance. Veja este artigo [slashdot.org] para mais detalhes.
========

Agora a explanação (link explanação) a que ele fez referência. Era uma resposta a matéria com título "AMD Alleges Intel Compilers Create Slower AMD Code" ou "AMD alega que compiladores Intel criam código mais lento para AMD" link matéria


É verdade -- e eles sabem disso

Eu notei esse problema ainda em janeiro de 2004, com o (compilador) Intel C++ 8.0, e passei pelo diabo por 9 meses com o suporte ao cliente da Intel para arrumar isso até que eu eventualmente tive que abandonar o compilador deles.

Em qualquer processador não-Intel, o compilador especificamente incluía um caminho alternativo de código para "memcpy" que na realidade usava "rep movsb" para copiar um byte por vez, ao invés de (por exemplo) "rep movsd" para copiar uma doubleword (que, se eu não me engano, tem 8 bytes) por vez (ou instruções MMX para copiar quadwords). Essa provavelmente a tradução de código para "memcpy" mais estúpida que eu já vi, e era aproximadamente 4X mais lenta do que uma típica e inocente tradução assembly de memcpy:

push ecx
shr ecx, 2
rep movsd
pop ecx
and ecx, 3
rep movsb

Suas respostas foram completamente ridículas, tais como:

"Nossa memcpy 8.0 foi realmente otimizada para um processador Pentium(r)4, quando nós retrabalhamos essa rotina nós usamos a implementação mais simples, mais robusta, e mais direta para processadores mais antigos para que não tivessemos a necessidade de código extra para checar por alinhamento, tamanho, sobreposição, e outras condições."

Papo-furado. Eu fui e adicionei a seguinte linha no começo do meu código fonte:

extern "C" int __intel_cpu_indicator;

depois adicionei:

__intel_cpu_indicator = -512;

na função "main".

Isso forçou o [código compilado] Intel C++ a usar o memcpy do "Pentium 4" a despeito de qual processador estivesse na máquina. Aconteceu que o memcpy especial deles para "Pentium 4", que eu testei exaustivamente em todos os tipos de situação, funcionou perfeitamente bem em um processador Athlon AMD e em um Pentium III. Eu disse isso a eles.

Eu recebi a seguinte resposta:

"O memcpy rápido tem mais de 2000 linhas assembly programadas à mão, com muitos casos particulares onde diferentes caminhos de código são escolhidos baseados no alinhamento relativo da fonte e do destino. ... Se a performance do memcpy/memset somente forem melhoradas para Pentium III isso irá satisfazer você?"

Eu respondi "Não," dizendo que eu precisava de suporte para processadores AMD também. Eu também dei a eles uma cópia da minha própria rotina para memcpy que era 50% mais rápida que a deles -- e só usava MMX. Eles fecharam o chamado de suporte e não fizeram nada para resolver a questão.

Eu voltei para o Visual C++ (compilador de C++ da Visual).
===========================

A matéria sobre a (link alegação da AMD)



AMD alega que compiladores Intel criam código mais lento para AMD

edxwelch escreveu "Na recente ação anti-truste da AMD, a AMD tem examinado o compilador Intel e descobriu que ele deliberadamente roda código mais lento quando ele detecta que se trata de um processador AMD. "Para conseguir isso, a Intel projetou seu compilador para compilar código ao longo de diversos caminhos de código alternativos... Por projeto, os caminhos de código não foram criados igualmente. Se o programa detecta um microprocessador "Genuine Intel" (Genuinamente Intel), então ele executa um caminho de código totalmente otimizado e opera com eficiência máxima. No entanto, se o programa detecta um microprocessador "Authentic AMD" (AMD Autêntico), ele executa um caminho de código diferente que irá degradar a performance do programa ou então causar sua falha (crash).

No mundo x86:
word - 2 bytes
doubleword - 4 bytes
quadword - 8 bytes
doublequadword, quaddoubleword, octoword, xmmword - 16 bytes

Outras arquiteturas/empresas podem usar valores diferentes, a IBM quando se refere ao Power usa:
halfword - 2 bytes
word - 4 bytes
doubleword - 8 bytes
quadword - 16 bytes

Essa notícia fará com que muita gurizada que baseia suas vidas em comprar pcs de última geração e passar horas diárias em fóruns tirando capturas do desempenho desses computadores fique realmente chateada, refiro-me aos que utilizam processadores que não os intel.

Há tempos há manipulação em torno de tudo o que gira no mercado de TI, desde sites onde articulistas duvidosos enchem de moral produtos fracassados destinando páginas e mais páginas com conteúdo PARCIAL sobre o que DIZEM ANALISAR.
É fato que empresas pagam, e pagam muito bem às pessoas certas para que façam por elas, o serviço que deveria ser feito pela equipe destinada à criar os produtos, porém há uma inversão de valores, ao invés de se criar bons produtos, cria-se porcaria, contrata-se marketeiros de determinados sites e isso se resolve.

Há também meios como os agora citados, testes de benchmarks, há também formas de pagar empresas para que seus produtos se não melhores, pareçam melhores através de atualizações DUVIDOSAS de drivers ou mesmo firmwares.

A industria da tecnologia deixou de produzir avanços há muito tempo em sua grande maioria, destinando-se atualmente à atender o mercado eye-candy e o de "entusiastas" que para eles não passam de consumidores ávidos, daí surge essa coisa toda de enganação! Mas tenham certeza, não demora a surgir algum grande articulista a usar de palavras altissoantes para defender determinado produto!

Muito obrigado aos colegas acima pelas explicações e traduções, realmente para quem ainda duvida basta fazer o teste por conta própria e se perguntar:

AINDA QUERO SER ENGANADO ???

Na verdade o compilador traduz de uma linguagem de alto nível para a linguagem de máquina, que é basicamente uma representação diferente do Assembly (na verdade é o contrário...).

Para facilitar vou reponder todo o texto usando citação de sua parte no cabeçalho.


Eu não acredito por diversos motivos:

1- Esse é um teste de banda de memória máxima, se eles tiverem feito ele em uma linguagem de alto nível como C++, ou mesmo C ou FORTRAN, ele terá validade nula. Esse tipo de teste deve ser feito em Assembly para ter algum interesse... quase nenhum claro, mas pelo menos algum.

2- O ICC não é muito usado fora do ramo da computação técnica. Bom, na verdade, diria que para a Intel sua principal função é compilar os SPEC e outros programas de teste e servir para uso interno. Claro que ele otimiza muito bem para microprocessadores Intel em certas aplicações, mas a verdade é que ele não é muito confiável ou popular. E quem se importa com otimização?

Enfim, eu concordo com o EduardoS: o teste do Futuremark para largura de banda de memória foi escrito em Assembly otimizado para cada família de microprocessadores, cada um destes códigos otimizados sendo escolhido com base no CPUID: como o Nano é novo, provavelmente o Futuremark está usando o código para C7 ou um código qualquer não-otimizado. Qualquer uma dessas possibilidades gera perda de desempenho. Pelo viso, para esse programa, o Nano funciona melhor com código otimizado para Intels que para AMDs.

De qualquer modo, prova que esse tipo de teste é inútil e deve ser abolido do Universo conhecido.


Ao que eu soubesse o principal problema era a não-utilização de determinadas extensões (SSE, SSE2, etc) em microprocessadores não-Intel, se eles mexeram também nas rotinas de memcpy é outro problema... de qualquer modo, é por essas e outras que somente pessoas "ousadas" (nada de programação comercial) usam ICC.


Se isso aconteceu essa foi feia, usar REP MOVs de Byte em um memcpy de um compilador como o ICC é complicado.


Opa, cara, Visual C++ é O Visual C++, MSVC++, Microsoft Visual C++: o compilador C++ da Microsoft ...

No caso, como posso alterar o CPUID? Seria um tweak no registro? Uma mudança milagrosa?

Uma jogada suja pode se reverter numa otimização tamanha

Abraços!

Desculpem-me pelos erros (doubleword, tradução vs compilação, quem fez o compilador...) no post, mas creio que foram esclarecidos pelos colegas.

Lembrando que apenas traduzi o post do inglês para o português, por considerar muito pertinente. E realmente é.

tenho a mesma dúvida... afinal com mera mudança no CPUID (se não me engano é apenas uma string no registro) o C7 melhorou muito o desempenho, algo muito suspeito e que deixa a dúvida quanto "o quão otimizado o código foi para cada arquitetura?". Será que se testássemos um AMD aí daria algo semelhante?? e os demais programas de benchmark ???

Seria interessante se desenvolvêssemos um programa de benchmark de código aberto, teria que ser simples e pequeno, tipo o SUPERPI (embora esse superPI já não seja recomendado por aí para comparar arquiteturas diferentes).

Outra coisa, como usava o Pascal num curso de introdução a computação, mexi muito nele e o mesmo podia trabalhar em código assembly, nesse conjunto assembly (não me aprofundei pq é mais difícil de aprender) era possível trabalhar com registros (os antigos não sei quanto a registros/instruções novas) mas mesmo usando o compilador padrão do Pascal era possível trabalhar com os mesmos registros do assembly, salvo enganos já que faz um bom tempo que não brinco mais de Pascal.

Achei esse aqui http://www.freepascal.eti.br/

Que acham dele, serviria??

Baixei um daqui http://sourceforge.net/project/showfile ... _id=508970

tem 31.2MB, depois vejo se funciona mas vai demorar, tem versão para 64bits