Więcej rdzeni procesora w Jellyfin: kiedy faktycznie przyspieszają działanie?

Procesor z większą liczbą rdzeni przyspiesza Jellyfin dopiero wtedy, gdy oba rozwiązania zostaną porównane przy użyciu tej samej ścieżki odtwarzania, a wariant z mniejszą liczbą rdzeni jest mierzalnie ograniczany przez CPU; w przeciwnym razie o wyniku mogą najpierw zdecydować akceleracja multimediów, wydajność pojedynczego rdzenia, pamięć masowa, sieć lub temperatury.

Przed porównaniem liczby rdzeni zachowaj stały silnik multimediów i ścieżkę odtwarzania

Porównania liczby rdzeni stają się mylące, gdy jeden kandydat korzysta z odtwarzania bezpośredniego, drugi z transkodowania programowego albo tylko jeden ma działającą ścieżkę akceleracji sprzętowej. Są to różne obciążenia, dlatego pierwsza zasada porównania mówi, aby przed przypisaniem wyniku liczbie rdzeni zachować stałe: klienta, plik, ścieżkę napisów, docelową przepływność, metodę akceleracji i obciążenie w tle.

Aktualny przewodnik po transkodowaniu sprzętowym pokazuje, dlaczego obsługa urządzeń i przekazywanie urządzeń mogą całkowicie zmienić ścieżkę przetwarzania. Jeśli jedna platforma korzysta z QSV, NVENC lub VA-API, a druga przechodzi na tryb programowy, porównanie dotyczy przede wszystkim silnika multimediów i konfiguracji, a nie liczby rdzeni.

Rozpocznij bezpośrednie porównanie dopiero wtedy, gdy oba systemy pokazują ten sam tryb odtwarzania. Jeśli kandydaci nie mogą korzystać z tej samej ścieżki akceleracji z powodu różnic sprzętowych, przedstaw to jako przewagę platformy, zamiast udawać, że procesor z większą liczbą rdzeni wygrał odizolowany eksperyment dotyczący liczby rdzeni.

Odtwarzanie bezpośrednie kończy się remisem, gdy oba procesory przekraczają poziom bazowy

Odtwarzanie bezpośrednie nie dekoduje ani nie koduje ponownie wideo, dlatego ogólne obciążenie CPU ogranicza się do zwykłej logiki serwera, uwierzytelniania, metadanych i dostarczania pliku. Gdy oba kandydaty mają wystarczającą moc obliczeniową do tych zadań, dodatkowe rdzenie nie sprawią, że niezmieniony strumień multimedialny szybciej przejdzie przez sieć.

Przewodnik po obciążeniu związanym z odtwarzaniem bezpośrednim pokazuje, jak niewielki jest udział CPU w porównaniu z rzeczywistym transkodowaniem wideo. Dzięki temu odtwarzanie bezpośrednie jest użytecznym przypadkiem kontrolnym: jeśli oba procesory dostarczają ten sam plik przy stabilnych opóźnieniach serwera, liczba rdzeni nie ma znaczenia dla tego obciążenia.

Kandydat z mniejszą liczbą rdzeni wygrywa pod względem opłacalności, gdy osiąga ten poziom bazowy przy podobnych opóźnieniach, zużyciu energii i niezawodności. Procesor z większą liczbą rdzeni nie zapewnia przewagi w Jellyfin dzięki niewykorzystanym rdzeniom, chyba że inne równoczesne obciążenie CPU zmieni wynik na poziomie całego hosta.

Transkodowanie programowe daje procesorowi z większą liczbą rdzeni warunkową przewagę

Programowe dekodowanie, filtrowanie i kodowanie mogą korzystać z wielu wątków, dlatego dodatkowe rdzenie mogą zwiększyć liczbę klatek na sekundę lub umożliwić jednoczesne wykonywanie kilku konwersji wyłącznie programowych. Przewaga jest warunkowa, ponieważ konstrukcja kodeka, filtry, synchronizacja, przepustowość pamięci i narzut wątków ograniczają skalowanie przepustowości.

Kontrolowane testy skalowania liczby wątków FFmpeg pokazują, że przepustowość szybko rośnie przy mniejszej liczbie wątków, a następnie się wypłaszcza, gdy kolejne wątki wnoszą coraz mniej. Tego zachowania należy szukać w porównaniu Jellyfin: dodatkowe rdzenie mają znaczenie tylko wtedy, gdy rzeczywiste transkodowanie nadal przekłada je na użyteczną przepustowość.

Procesor z większą liczbą rdzeni wygrywa, gdy kandydat z mniejszą liczbą rdzeni nie może utrzymać konwersji w czasie rzeczywistym lub wymaganej liczby jednoczesnych transkodowań programowych, a mocniejszy procesor wykonuje identyczne obciążenie z zapasem. Jeśli oba procesory już przekraczają wymagany poziom, dodatkowa przepustowość jest rezerwą, a nie sposobem na szybsze oglądanie.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Mniejsza liczba szybszych rdzeni może wygrać w zadaniach, które nie skalują się na cały procesor

Łączna liczba rdzeni nie mówi nic o wydajności pojedynczego rdzenia, generacji architektury, utrzymywaniu taktowania ani limitach mocy. Niektóre zadania Jellyfin i procesy pomocnicze są na tyle słabo wielowątkowe, że mocniejsze pojedyncze rdzenie kończą je szybciej, nawet gdy inny procesor ma więcej rdzeni łącznie.

Ta sama krzywa malejących korzyści pokazuje, dlaczego większa liczba planowalnych wątków nie zawsze jest użyteczna dla jednego zadania. Po wyczerpaniu użytecznej pracy równoległej większe znaczenie mogą mieć wyższa wydajność jednowątkowa, zachowanie pamięci podręcznej lub utrzymywana częstotliwość niż kolejny zestaw bezczynnych rdzeni.

W tym miejscu testy konkretnych modeli są lepsze niż porównanie specyfikacji. Zmierz oddzielnie jedno zadanie słabo wielowątkowe — na przykład responsywność interfejsu przy kontrolowanym obciążeniu w tle — oraz łączną przepustowość transkodowania. Procesor może przegrać test wielowątkowy, a mimo to być szybszy w ścieżce interaktywnej, lub odwrotnie.

Współdzielone obciążenia CPU najczęściej zmieniają wynik na poziomie całego hosta

Porównanie zmienia się, gdy Jellyfin współdzieli komputer z maszynami wirtualnymi, automatyzacją pobierania, kopiami zapasowymi, analizą zdjęć, kompilacjami lub lokalną sztuczną inteligencją. Usługi te mogą jednocześnie zużywać CPU, gdy Jellyfin potrzebuje responsywności aplikacji lub programowego trybu awaryjnego, dlatego procesor z większą liczbą rdzeni może zachować zapas mocy, nawet jeśli sam Jellyfin nie wykorzystałby tych rdzeni.

Aktualne porównanie minikomputerów dla wielu usług uwzględnia klasę procesora razem z pamięcią RAM, siecią, zużyciem energii i przydatnością do wirtualizacji, zamiast zakładać, że każde zadanie serwera domowego jest ograniczane przez CPU. To właściwe porównanie na poziomie hosta: dodatkowe rdzenie mają znaczenie, gdy łączne typowe obciążenie szczytowe rzeczywiście je wykorzystuje.

Porównanie akceleracji sprzętowej firmy ZimaSpace wyznacza uzupełniającą granicę: najpierw przenieś powtarzalną pracę związaną z wideo na wyspecjalizowany sprzęt, a dopiero potem zdecyduj, czy pozostałe współdzielone usługi uzasadniają większy procesor. Jeśli te usługi można zaplanować poza czasem odtwarzania, wariant z mniejszą liczbą rdzeni nadal może być lepszym hostem pracującym stale.

Werdykt warunkowy: kup więcej rdzeni dopiero po nasyceniu wariantu z mniejszą liczbą rdzeni

Uruchom na obu kandydatach to samo reprezentatywne obciążenie szczytowe i zapisz tryb odtwarzania, szybkość transkodowania, jeśli ma zastosowanie, wykorzystanie CPU, czas trwania zadań, temperatury, zużycie energii oraz opóźnienie odczuwalne przez użytkownika. Zwiększaj wyłącznie równoległą część obciążenia procesora, aż komputer z mniejszą liczbą rdzeni albo nie dotrzyma terminu, albo osiągnie stabilne wypłaszczenie wyników.

Zmierzona porównywalność sprzętu przy tym samym protokole pokazuje dyscyplinę raportowania, która ma tu znaczenie: określ, jak mierzono zużycie energii i obciążenie, oraz odróżnij pomiary bezpośrednie od danych ze źródeł. Porównania Jellyfin powinny robić to samo w odniesieniu do plików, klientów, stanu akceleracji i usług działających w tle.

Wybierz procesor z większą liczbą rdzeni tylko wtedy, gdy kandydat z mniejszą liczbą rdzeni jako pierwszy napotyka ograniczenie CPU, a większy procesor usuwa to ograniczenie w tych samych warunkach. Jeśli oba rozwiązania przechodzą test, wybierz na podstawie obsługi silnika multimediów, zużycia energii, ceny, serwisowalności, pamięci masowej, sieci lub możliwości odzyskiwania danych. Większa liczba rdzeni jest specyfikacją zmieniającą wynik dopiero wtedy, gdy obciążenie udowodni, że potrafi je wykorzystać.