As CPUs dual core são efetivamente padrão hoje em dia, e por um bom motivo: há melhorias substanciais e demonstráveis no desempenho que podem ser obtidas com uma segunda CPU em espera para atender às solicitações que a primeira CPU está ocupada demais para atender. Se não houver mais nada, CPUs dual-core protegem o senhor de softwares mal escritosSe um programa travado consumir todo o tempo possível da CPU, tudo o que ele poderá obter é 50% da sua CPU. Há ainda outra CPU disponível para garantir que o sistema operacional permita que o senhor elimine o CrashyApp 5.80 SP1 Enterprise Edition de forma razoável. É a sistema de amigos em forma de silício.
Meu post anterior sobre a atualização da CPU em seu PC foi mais polêmico do que eu pretendia. Aqui está o que escrevi:
Na minha opinião, as CPUs quad-core ainda são uma desperdício de eletricidade a menos que o senhor os coloque em um servidor. Quatro núcleos no desktop são ótimos para o direito de se gabar e para a superioridade matemática (sim, 4 > 2), mas esses quatro núcleos não proporcionam quase nenhum aprimoramento de benchmark no tipo de aplicativos que a maioria das pessoas usa. Incluindo ferramentas de desenvolvimento de software.
É lamentável, pois essa declaração ofuscou o restante da postagem. Tudo o que eu queria fazer aqui era incentivar as pessoas a fazer um informado ao selecionar uma CPU. Na verdade, escolha a CPU que quiser; a parte importante dessa postagem é não ter medo de atualizar seu PC. Se o parágrafo acima distraiu os leitores desse objetivo, peço desculpas.
No entanto, tenho sentimentos fortes sobre esse assunto. Com muita frequência, vejo usuários seduzidos pelo departamento de marketing da Intel, supondo cegamente que, se dois núcleos de CPU são mais rápidos do que um núcleo de CPU, então, bem… quatro, oito ou dezesseis devem ser insanamente rápido! E o senhor tira a carteira deles. Temo que muitos usuários sejam vítimas das fraudes de marketing e acabem pagando um preço mais alto por um desempenho que, para eles, nunca se concretizará. É como os velhos tempos ruins do Pentium 4 novamente, exceto pelas velocidades de clock absurdas de megahertz, substituindo um número absurdo de núcleos de CPU.
Quero que as pessoas entendam que o existem apenas alguns aplicativos que podem realmente se beneficiar de mais de 2 núcleos de CPUe eles tendem a se agrupar em torno de determinadas áreas especializadas. Para mim, o que importa é o benchmark dadose os benchmarks simplesmente não mostram nenhum motivo convincente para optar pelo quad-core, a menos que o senhor faça regularmente uma das seguintes ações:
- “ripar” ou codificar vídeo
- renderizar cenas 3D profissionalmente
- executar simulações científicas
Se o senhor faz frequentemente qualquer uma das coisas acima, há sem dúvida que um quad-core (ou octa-core) é a escolha certa. Mas essa é apenas minha recomendação com base nos dados de benchmark, e não um fato irrefutável. O dinheiro é do senhor. Gaste-o como o senhor quiser. Tudo o que estou propondo é que o senhor o gaste com conhecimento de causa.
Ah, mas há também o argumento da multitarefa. Eu implorei aos comentaristas que estavam convencidos dos benefícios do quad-core que me indicassem benchmarks de multitarefa que mostrassem uma profunda diferença de desempenho entre 2 e mais de 2 núcleos de CPU. Isso é curioso. A Web está repleta de zilhões de sites de análise de hardware, mas o senhor quase não encontra benchmarks de multitarefa em nenhum deles. Acho que isso se deve ao fato de que o a quantidade de multitarefa necessária para carregar seriamente mais de dois núcleos de CPU beira o absurdo, como Anand aponta:
Quando estávamos tentando pensar em novos benchmarks de multitarefa para realmente enfatizar o Kentsfield e o Quad FX [quad-core] encontrávamos sempre esses cenários interessantes, mas bastante distantes, que faziam um ótimo trabalho para estressar nossos bancos de testes, mas um péssimo trabalho para mostrar como o senhor poderia usar o quad-core hoje.
O que os senhores encontrarão, no entanto, é esse refrão de benchmarking repetido várias vezes novamente:
Como a maioria dos aplicativos de desktop existentes atualmente, incluindo seus aplicativos componentes, o WorldBench não ganha muito com mais de dois núcleos de CPU.
Dito isso, acho que cometi um erro em minha declaração original. Os desenvolvedores de software não são usuários típicos. Na verdade, o senhor pode argumentar que os desenvolvedores de software são, quase por definição, condições extremas e, portanto, devem procurar CPUs de muitos núcleos, como Kevin disse nos comentários:
Como o senhor sugere que os desenvolvedores escrevam aplicativos (isso é o que somos e o que fazemos, certo?) que possam realmente aproveitar 4, 8, etc.? núcleos de CPU se estivermos executando sistemas solo ou dual core? Eu coloco isso no mesmo patamar de ter vários monitores. Os desenvolvedores precisam deles, e não apenas para aumentar a produtividade, mas porque eles não entenderão o quanto seus aplicativos são mal executados em vários monitores, a menos que realmente os utilizem. O mesmo acontece com as CPUs de vários núcleos.
Tenho duas respostas para isso. Uma delas o senhor provavelmente não vai gostar.
Vamos começar com a primeira. Concordo plenamente que é importante que os desenvolvedores de software considerem o desenvolvimento de software com vários núcleose ter um em seu desktop é um pré-requisito. Escrevi originalmente sobre isso em 2004 no Threading, simultaneidade e o explosivo psicocinético mais poderoso do universo. Na verdade, duas das pessoas que citei naquele artigo antigo – verdadeiros líderes no campo da programação simultânea – postaram respostas diretas ao meu artigo ontem, e elas merecem uma resposta.
Rick Brewster, da projeto Paint.NET seriamente incrível, disse o seguinte em um comentário:
O que o senhor acha? O Paint.NET, por exemplo, mostra grandes ganhos em sistemas quad-core em comparação com sistemas dual-core. Há até mesmo o um benchmark. Eu diria que isso se qualifica como “aplicativos que a maioria das pessoas usa”.
Ele está absolutamente certo. Um Q6700 de quatro núcleos a 2,66 GHz supera meu E8500 de dois núcleos a 4,0 GHz nesse benchmark, com 26 segundos contra 31 segundos. Mas com todo o respeito ao Rick – e, falando sério, eu adoro o Paint.NET e seu código multithreading é incrível — Acho que esse benchmark testa mais os filtros especializados (e altamente paralelizáveis) do que a funcionalidade principal. Há uma longa história de benchmarking do Photoshop na mesma linha; é o caso da renderização 3D menos uma dimensão. Se o senhor passa uma parte significativa do seu dia no Photoshop, deve escolher a plataforma que o executa mais rapidamente.
Mas nós somos desenvolvedores, não designers. Passamos o tempo todo conversando com compiladores, interpretadores e editores de vários tipos. Herb Sutter publicou um post inteiro no blog esclarecendo isso, de fato, as ferramentas de desenvolvimento de software aproveitam as vantagens das CPUs quad-core:
O senhor não deve estar usando as ferramentas certas 🙂 Por exemplo, aqui estão três com as quais estou familiarizado:
- Visual C++ 2008’s sinalizador /MP diz ao compilador para compilar arquivos no mesmo projeto em paralelo.
- Desde o Visual Studio 2005, oferecemos suporte a compilações paralelas de projetos no modo Batch Build
- O Excel 2007 faz recálculo paralelo. Supondo que a planilha seja grande e não contenha apenas dependências sequenciais entre as células, ela geralmente é escalonada linearmente até pelo menos 8 núcleos.
Herb é um especialista do setor em programação simultânea e guru geral do C++ e, é claro, ele está certo em todos os três aspectos. Eu havia me esquecido completamente da compilação de C++, ou talvez seja mais justo dizer Eu bloqueei isso. O que o senhor espera de um cara com formação em BASIC? O tempo de compilação é um enorme dreno de produtividade para os desenvolvedores de C++ que trabalham em grandes projetos. O tempo de compilação usando gcc e time make -j<# of cores + 1> é o avô de todos os benchmarks de programadores com vários núcleos. Aqui está um resultado representativo para compilando o código-fonte do LAME 3.97:
| 1 | Xeon E5150 (2,66 GHz Dual-Core) | 12,06 segundos |
| 1 | Xeon E5320 (1,86 GHz Quad-Core) | 11,08 segundos |
| 2x | Xeon E5150 | 8,26 seg |
| 2x | Xeon E5320 | 8.45 seg |
Os números absolutos parecem pequenos, mas as porcentagens são incrivelmente convincentes, principalmente quando o senhor soma o número de vezes que compila todos os dias. Se for um desenvolvedor de C++, o senhor precisa uma CPU quad-core ontem. Exigir.
Mas e quanto a nós, desenvolvedores de código gerenciado, com nossa falta de ponteiros e alocações explícitas de memória? Herb mencionou a configuração de compilações paralelas de projetos no Visual Studio 2008; ela está em Tools, Options, Projects and Solutions, Build and Run.
Como prometido, o padrão é o número de núcleos que tenho em meu PC: dois. Fiz o download do maior projeto .NET que consegui imaginar, SharpDevelop. A solução é satisfatoriamente grande; contém 60 projetos. Eu a compilei algumas vezes no Visual Studio 2008, mas o gerenciador de tarefas não estava mostrando muito uso nem mesmo dos meus míseros dois núcleos:
Vi alguns picos acima de 50%, mas é um resultado muito morno em comparação com o make -j4 . Não vejo nada aqui que indique qualquer tipo de possível melhoria no desempenho do tempo de compilação do código gerenciado ao passar para mais de dois núcleos. Estou curioso para saber se os compiladores Java (ou outros compiladores de linguagens semelhantes a .NET) fazem um trabalho melhor nesse sentido.
Voltando à pergunta do Kevin: sim, se o senhor for um desenvolvedor de software escrevendo um aplicativo de desktop que tenha algo remotamente paralelizável, o senhor deve ter qualquer número de núcleos de CPU no desktop de que precisa para testar e depurar seu código. Sugiro começar com a meta de escalonar bem para dois núcleos, pois essa parece ser a parte mais desafiadora da jornada. Além disso, boa sorte e boa sorte, porque tudo o que já li sobre o tópico de escrever software escalável e concorrente se esforça para explicar em detalhes excruciantes como esse tipo de código é extremamente difícil de escrever.
Aqui está a segunda parte da resposta que prometi ao senhor anteriormente. A que o senhor talvez não goste. A maioria dos desenvolvedores não são escrevendo aplicativos de desktop hoje. Eles estão escrevendo aplicativos da Web. Muitos deles podem estar escrevendo em linguagens de script que não são compiladas, mas interpretadas, como Ruby, Python ou PHP. É provável que nem mesmo tenham threads. E, no entanto, esse código, de alguma forma, atinge níveis maciços de simultaneidade, é dimensionado para cargas de trabalho enormes e impulsiona alguns dos maiores sites da Internet. Tudo isso sem pensar nem um pouco em concorrência, threading ou reentrada. É algo mágico, se o senhor pensar bem.
Portanto, no sentido de que os principais desenvolvedores estão modelando cargas de trabalho de servidor em seus desktops, concordo, eles fazem provavelmente precisam do máximo de núcleos que puderem obter.