Mais núcleos de CPU para o Jellyfin: quando é que isso o torna realmente mais rápido?

Um CPU com mais núcleos só torna o Jellyfin mais rápido depois de ambos os candidatos serem comparados no mesmo percurso de reprodução e de a opção com menos núcleos estar comprovadamente limitada pelo CPU; caso contrário, a aceleração multimédia, o desempenho por núcleo, o armazenamento, a rede ou as temperaturas podem decidir primeiro o resultado.

Mantenha o motor multimédia e o percurso de reprodução constantes antes de comparar o número de núcleos

As comparações do número de núcleos tornam-se enganadoras quando um candidato usa Reprodução directa, outro faz transcodificação por software ou apenas um dispõe de um percurso funcional de aceleração por hardware. São cargas de trabalho diferentes, pelo que a primeira regra de comparação é manter constantes o cliente, o ficheiro, o percurso das legendas, a taxa de bits de destino, o método de aceleração e a carga em segundo plano antes de atribuir um resultado ao número de núcleos do CPU.

Um guia de transcodificação por hardware actual mostra por que motivo o suporte dos dispositivos e o passthrough podem alterar todo o percurso de processamento. Se uma plataforma usar QSV, NVENC ou VA-API enquanto a outra recorrer ao software, a comparação diz sobretudo respeito ao motor multimédia e à configuração, não ao número de núcleos.

Inicie a comparação directa apenas depois de ambos os sistemas apresentarem o mesmo modo de reprodução. Se os candidatos não puderem usar o mesmo percurso de aceleração devido a diferenças no hardware, registe isso como uma vantagem da plataforma, em vez de fingir que um CPU com muitos núcleos venceu uma experiência isolada sobre o número de núcleos.

A Reprodução directa resulta num empate quando ambos os CPUs ultrapassam a linha de base

A Reprodução directa não descodifica nem volta a codificar o vídeo, pelo que o trabalho normal do CPU se limita à lógica habitual do servidor, à autenticação, aos metadados e à entrega do ficheiro. Quando ambos os candidatos têm CPU suficiente para essas tarefas, os núcleos adicionais não fazem com que o fluxo multimédia inalterado atravesse a rede mais depressa.

Um guia sobre cargas de trabalho de Reprodução directa mostra como o CPU participa pouco em comparação com uma verdadeira transcodificação de vídeo. Isto torna a Reprodução directa num caso de controlo útil: se ambos os CPUs entregarem o mesmo ficheiro com uma latência estável do servidor, o número de núcleos atingiu uma zona sem efeito para essa carga de trabalho.

O candidato com menos núcleos oferece melhor valor quando ultrapassa esta linha de base com latência, consumo e fiabilidade semelhantes. O candidato com mais núcleos não obtém qualquer vantagem no Jellyfin devido a núcleos não utilizados, a menos que outra carga de trabalho simultânea do CPU altere o resultado ao nível do anfitrião.

A transcodificação por software proporciona uma vitória condicional ao CPU com mais núcleos

A descodificação, a aplicação de filtros e a codificação por software podem usar vários threads, pelo que os núcleos adicionais podem aumentar os fotogramas por segundo ou permitir que várias conversões apenas por CPU coexistam. A vitória é condicional porque o desenho do codec, os filtros, a sincronização, a largura de banda da memória e a sobrecarga dos threads limitam a escala do débito.

Testes controlados de escala de threads no FFmpeg mostram que o débito melhora rapidamente com números de threads mais baixos e depois estabiliza à medida que os threads adicionais contribuem cada vez menos. É este o comportamento que deve procurar no Jellyfin: os núcleos adicionais só importam enquanto a transcodificação real os transformar em débito útil.

O CPU com mais núcleos vence quando o candidato com menos núcleos não consegue manter uma conversão em tempo real ou o número necessário de transcodificações simultâneas por software, enquanto o CPU maior conclui a mesma carga de trabalho com margem. Se ambos já ultrapassarem o objectivo, o débito adicional é uma reserva, não uma experiência de visualização mais rápida.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Menos núcleos mais rápidos podem vencer em trabalhos que não escalam por todo o CPU

O número total de núcleos nada diz sobre o desempenho por núcleo, a geração da arquitectura, o comportamento da frequência sustentada ou os limites de consumo. Algumas tarefas do Jellyfin e processos auxiliares têm threads suficientes para que núcleos individuais mais potentes as concluam mais depressa, mesmo quando outro processador tem mais núcleos no total.

A mesma curva de retornos decrescentes demonstra por que motivo mais threads agendáveis não são automaticamente úteis para uma tarefa. Quando o trabalho paralelo útil se esgota, uma resposta superior num único thread, um melhor comportamento da cache ou uma frequência sustentada mais elevada podem importar mais do que outro conjunto de núcleos inactivos.

É aqui que os testes entre modelos são superiores a uma comparação de especificações. Meça uma operação com poucos threads — como a capacidade de resposta da interface durante um estado controlado em segundo plano — separadamente do débito agregado de transcodificação. Um CPU pode perder o teste com vários threads e, ainda assim, ser mais rápido no percurso interactivo, ou vice-versa.

É na coexistência de cargas de trabalho do CPU que os núcleos adicionais alteram mais vezes o resultado ao nível do anfitrião

A comparação muda quando o Jellyfin partilha a máquina com máquinas virtuais, automação de transferências, cópias de segurança, análise de fotografias, compilações ou IA local. Esses serviços podem consumir CPU ao mesmo tempo que o Jellyfin precisa de capacidade de resposta da aplicação ou de uma alternativa por software, pelo que um CPU com mais núcleos pode preservar margem, mesmo quando o Jellyfin sozinho não a utilizaria.

Uma comparação actual de mini PCs para serviços mistos considera a classe do CPU em conjunto com a RAM, a rede, o consumo e a adequação à virtualização, em vez de presumir que todas as tarefas de um servidor doméstico são limitadas pelo CPU. Essa é a comparação correcta ao nível do anfitrião: os núcleos adicionais importam quando o pico normal combinado os utiliza.

A comparação da aceleração por hardware da ZimaSpace estabelece o limite complementar: transfira primeiro o trabalho de vídeo repetível e, em seguida, decida se os restantes serviços partilhados justificam um CPU maior. Se esses serviços puderem ser agendados para fora do período de reprodução, a opção com menos núcleos pode continuar a ser o melhor anfitrião sempre ligado.

Veredicto condicional: compre mais núcleos apenas depois de o candidato com menos núcleos saturar

Execute o mesmo pico representativo em ambos os candidatos e registe o modo de reprodução, a velocidade de transcodificação quando aplicável, a utilização do CPU, a duração das tarefas, as temperaturas, o consumo e a latência perceptível pelo utilizador. Aumente apenas a parte da carga de trabalho paralelizável pelo CPU até que a máquina com menos núcleos falhe o prazo ou atinja um patamar estável.

Uma comparação de hardware com o mesmo protocolo demonstra a disciplina de comunicação que importa aqui: indique como foram medidos o consumo e a carga e distinga as medições directas dos valores obtidos de fontes. As comparações do Jellyfin devem fazer o mesmo com ficheiros, clientes, estado da aceleração e serviços em segundo plano.

Escolha o CPU com mais núcleos apenas quando o candidato com menos núcleos for o primeiro ponto de estrangulamento do CPU e o CPU maior eliminar esse estrangulamento nas mesmas condições. Se ambos passarem, escolha antes com base no suporte do motor multimédia, no consumo, no preço, na facilidade de manutenção, no armazenamento, na rede ou na recuperação. Mais núcleos só são uma especificação que altera o resultado depois de a carga de trabalho provar que os consegue utilizar.