Trexando os blocos de construção (TBB) para estripador de CD baseado em QT?

Question

Estou construindo uma aplicação de cd ripper em C ++ e Qt. Gostaria de paralelizar o aplicativo de modo que várias faixas possam ser codificadas simultaneamente. Portanto, estruturei o aplicativo de tal maneira que codificar uma faixa é uma "tarefa" e estou trabalhando em um mecanismo para executar algumas dessas tarefas simultaneamente. Obviamente, eu poderia fazer isso usando threads e escrever minha própria fila de tarefas ou gerente de trabalho, mas achei que os blocos de construção de encadeamento da Intel (TBB) poderiam ser uma ferramenta melhor para o trabalho. Eu tenho algumas perguntas, no entanto.

1. A codificação é um arquivo WAV em um arquivo FLAC, OGG Vorbis ou MP3, algo que funcionaria bem como uma tarefa TBB ::? O documento do tutorial afirma que "se os threads blocos com frequência, há uma perda de desempenho ao usar o agendador de tarefas". Não acho que minhas tarefas de codificação bloqueassem mutexes com frequência, mas a vontade de acessar o disco com relativa frequência, pois eles devem ler os dados do WAV do disco para codificar. Esse nível de atividade do disco é problemático no sentido descrito pelo tutorial?
2. O TBB funciona bem com o QT? Ao usar threads QT, você pode usar o mecanismo de sinais/slots do QT de forma transparente nos threads. O mesmo seria verdadeiro se eu estivesse usando TBB :: Tarefas em vez de threads QT? Haveria algum outro "Gotchas"?

Obrigado por quaisquer idéias que você possa fornecer.

Answer 1

O TBB deve funcionar bem, mesmo de forma transparente, com outros mecanismos de rosqueamento, de modo que, teoricamente, não deve haver nada para que você use as classes de threads do QT no mesmo programa. Se houver algo que funcione mais naturalmente com os threads QT, como a GUI, use -os e mantenha o material TBB segregado da melhor maneira possível ou deseja.

Não vejo que você esteja fazendo o melhor uso do TBB, pois atualmente descreveu seu design. Você paralaliza no nível mais bruto, o arquivo. Como você suspeita, como o CD é um dispositivo bastante lento, você pode gastar mais tempo procurando dados para dados de vários arquivos do que você realmente salva.

O verdadeiro retorno do BURN com TBB deve envolver a exploração de todos os dados e/ou o paralelismo da tarefa que existe no processo de transformação. Você pode, por exemplo, puxar qualquer bloco de bytes para fora do fluxo e aplicar qualquer transformação a ele independentemente de qualquer parte do fluxo antes ou depois? Existem várias etapas para a transformação que podem ser paralelas?

Answer 2

Por que não usar Qt simultâneo ?