ti-enxame.com

Quanto esforço devemos gastar para programar para múltiplos núcleos?

Os processadores estão recebendo mais e mais núcleos nos dias de hoje, o que me deixa me perguntando ...

Devemos nós, programadores, nos adaptarmos a esse comportamento e gastar mais esforço na programação para múltiplos núcleos?

Até que ponto devemos fazer e otimizar isso? Fio? Afinidade? Otimizações de hardware? Algo mais?

12
Tamara Wijsman

Não importa quão bom você seja, será improvável que você venha com um melhor esquema de administrar threads etc. do que o equipes Desenvolvendo o idioma e o compilador que você está escrevendo seu código.

Se você precisar que seu aplicativo seja multi-threaded, crie os encadeamentos necessários e deixe o compilador e o sistema operacional com seus trabalhos.

Você precisa estar ciente de como esses tópicos são gerenciados para que você possa fazer o melhor uso dos recursos. Não criar muitos tópicos é uma coisa que molda a mente como exemplo.

Você também precisa estar ciente do que está acontecendo (veja o comentário de Lorenzo) para que você possa fornecer dicas ao gerenciamento de thread (ou substituí-lo em casos especiais), mas eu teria pensado que estes seriam poucos e distantes entre si.

15
ChrisF

Eu sou um programador .NET e sei que o .NET tem uma abstração de alto nível para multithreading chamadas tarefas. Ele protege você de ter que saber muito sobre como fazer multithreading adequado contra o metal. Eu suponho que outras plataformas de desenvolvimento atuais têm abstrações semelhantes. Então, se você vai fazer qualquer coisa com multithreading, tentaria trabalhar nesse nível, se possível.

Agora, para a questão de deveria você se preocupa com a multithreading em sua aplicação específica. A resposta a essa pergunta é muito dependente do aplicativo que você está escrevendo. Se você estiver escrevendo um aplicativo que faz processamento em milhares (ou mais) coisas independentes, e esse processamento pode ser feito em paralelo, então você certamente obterá uma vantagem de multithreading. No entanto, se você estiver escrevendo uma tela simples de entrada de dados, multithreading pode não comprar muito.

No mínimo, você precisa se preocupar com a multithreading quando estiver trabalhando em uma interface do usuário. Você não quer disparar uma operação de longa duração da interface do usuário e tornar-se indiferente porque seqüestrou o fio da interface do usuário para fazer essa operação. Fire fora de um fio de fundo, e pelo menos dê ao usuário um botão de cancelamento para que eles não precisem esperar por ele concluir se cometeram um erro.

5
RationalGeek

Na terra do Objective-C e Mac OS X e iOS, as estruturas (como muitas outras) são escritas para aproveitar esses aumentos nos núcleos do processador e apresentar o desenvolvedor com uma boa interface para fazer uso deles.

Exemplo no Mac OS X e iOS é Grand Central Dispatch. Há adições a libc (eu acredito) para facilitar a multi-threading baseada em fila. Em seguida, os quadros de cacau e fundação (entre outros) estão escritos no topo do GCD, dando ao desenvolvedor fácil acesso a filas de despacho e encadeamento com muito pequeno código de placa de caldeira.

Muitas línguas e estruturas têm conceitos semelhantes.

5
Jasarien

A parte difícil é toda em dividir seu algoritmo intensivo da CPU para pedaços de execução que poderiam ser roscados.

Em seguida, um fio continuamente pulando de um núcleo para outro terá penalidades de desempenho (devido ao cache de CPU de primeiro e segundo perdido), especialmente em arquiteturas onde são empregadas duas matrizes físicas distintas. Neste caso, a afinidade de fios é uma coisa boa.

5
Wizard79

Estamos agora (outubro de 2010) em um tempo de imensa transição.

Podemos hoje comprar uma área de trabalho de 12 núcleos.
[.____] Nós poderíamos comprar um processamento de núcleo 448 cartão (procurar por NVIDIA TESLA).

Há limites para o quanto desenvolvemos podemos trabalhar na ignorância dos ambientes tremendamente paralelos que nossos programas estarão trabalhando no futuro próximo.

Sistemas operacionais, ambientes de tempo de execução e bibliotecas de programação só podem fazer tanto.

No futuro, precisaremos estar particionando nosso processamento em pedaços discretos para processamento independente, usando abstrações como o novo .NET "Framework".

Detalhes, como gerenciamento de cache e afinidade ainda estarão presentes - mas eles serão a Provence do aplicativo ultra-performático apenas. Nenhum mesmo desenvolvedor vai querer gerenciar esses detalhes manualmente através de uma máquina de núcleo de 10K.

3
Bevan

bem, isso realmente depende do que você está desenvolvendo. A resposta, dependendo do que você está desenvolvendo, pode variar de "é insignificante" para "é absolutamente crítico, e esperamos que todos na equipe tenham uma boa compreensão e uso de implementações paralelas".

para a maioria dos casos, uma sólida compreensão e uso de fechaduras, fios e tarefas e conjuntos de tarefas será um bom começo quando a necessidade de paralelismo é necessária. (Varia de Lang/lib)

acrescente a isso as diferenças em projetos que você deve fazer - para multiprocessamento não trivial, é preciso aprender vários novos modelos de programação ou estratégias de paralelização. Nesse caso, a hora de aprender, falhar momentos suficientes para ter uma compreensão sólida, e atualizar os programas existentes pode fazer uma equipe por ano (ou mais). Depois de ter atingido esse ponto, você (esperançosamente!) Não perceber ou abordar problemas/implementações como você faz hoje (desde que você ainda não tenha feito essa transição).

outro obstáculo é que você está efetivamente otimizando um programa para uma certa execução. Se você não tiver muito tempo para otimizar programas, então você realmente não se beneficiará tanto quanto deveria. Parallelização de alto nível (ou óbvia) pode melhorar a velocidade percebida do seu programa com pouco esforço, e isso é tão longe quanto muitas equipes vão hoje: "Parecemos as partes realmente óbvias do aplicativo" - tudo bem em alguns casos. Será que o benefício de tomar a fruta baixa e usar paralização simples será proporcional ao número de núcleos? Muitas vezes, quando há dois a quatro núcleos lógicos, mas não muito além disso. Em muitos casos, isso é um retorno aceitável, dado o investimento em tempo. Este modelo paralelo é a introdução de muitas pessoas para implementar bons usos do paralelismo. É comumente implementado usando iteração paralelizada, tarefas explícitas, fios simples ou multitarefa.

o que você aprende usando esses modelos paralelos triviais não será ideal em todos os cenários paralelos complexos; Aplicando efetivamente os projetos paralelos complexos requer uma compreensão e abordagem muito diferentes. Esses modelos simples são frequentemente destacados ou têm interação trivial com outros componentes do sistema. Além disso, muitas implementações desses modelos triviais não dimensionam bem para sistemas paralelos complexos e efetivamente - um mau design paralelo complexo pode demorar desde executar como o modelo simples. Doente: Ele executa duas vezes mais rápido que o modelo roscado único, enquanto utilizando 8 núcleos lógicos durante a execução. Os exemplos mais comon estão usando/criando muitos segmentos e altos níveis de interferência de sincronização. Em geral, isso é denominado desaceleração paralela. É muito fácil encontrar se você se aproxima de todos os problemas paralelos como problemas simples.

então, digamos que você realmente deve utilizar multithreading eficiente em seus programas (a minoria, no clima de hoje): você precisará empregar o modelo simples de forma eficaz para aprender o modelo complexo e depois se aproximar fluxo de programa e interação. O modelo complexo é onde seu programa deve, em última instância, desde que é onde o hardware é hoje e onde as melhorias mais dominantes serão feitas.

a execução de modelos simples pode ser imaginada como um garfo, e os modelos complexos operam como um complexo, UH, ecossistema. Eu acho que a compreensão de modelos simples, incluindo bloqueio geral e rosqueamento deve ser ou em breve ser esperado de desenvolvedores intermediários quando o domínio (no qual você se desenvolve) o usa. Compreender modelos complexos ainda é um pouco incomum hoje (na maioria dos domínios), mas acho que a demanda aumentará muito rapidamente. Como desenvolvedores, muito mais de nossos programas devem apoiar esses modelos, e a maioria dos usos está muito atrasada em compreensão e implementação desses conceitos. Como os contagens do processador lógico são uma das áreas mais importantes da melhoria de hardware, a demanda por pessoas que entendem e podem implementar sistemas complexos certamente aumentarão.

finalmente, há muitas pessoas que acham que a solução é apenas "adicionar paralelização". Muitas vezes, é melhor tornar a implementação existente mais rapidamente. É muito mais fácil e muito mais simples em muitos casos. Muitos programas no selvagem nunca foram otimizados; Algumas pessoas tinham a impressão de que a versão não optimizada seria eclipsada por hardware algum dia em breve. Melhorar o projeto ou Algos de programas existentes é também uma habilidade importante se o desempenho for importante - lançar mais núcleos em problemas não é necessariamente a melhor ou mais simples solução.

ao direcionar os PCs modernos, a maioria de nós que precisa implementar bons sistemas paralelos não precisará ir além de bibliotecas multithreading, bloqueando, paralelas, valores de leitura de um livro, e muitas experiências escrevendo e testando programas (basicamente, reestruturando significativamente como você abordagem de programas de escrita).

3
justin

Nós fazemos, mas escrevemos software pesado de cálculo, por isso nos beneficiamos diretamente de múltiplos núcleos.

Às vezes, o agendador move tópicos entre núcleos muito. Se isso não for aceitável, você pode jogar com a afinidade central.

2
Toon Krijthe

Como está, a frequência do processador não vai aumentar no futuro próximo. Estamos presos ao redor da marca de 3 Ghz (sem overclock). Certamente, para muitas aplicações, pode não ser necessário ir além de multi-threading muito básico. Obviamente, se você estiver construindo um aplicativo de interface de usuário, qualquer processamento intensivo deve ser feito em um fio de fundo.

Se você estiver construindo um aplicativo que esteja processando grandes quantidades de dados que devem ser em tempo real, então sim, você provavelmente deve olhar para programação multi-threading.

Para programação multi-thread, você descobrirá que você receberá retornos decrescentes no seu desempenho; Você pode passar horas e melhorar o programa em 15%, e depois passar mais uma semana e apenas melhorá-lo por mais 5%.

0
Harry