Powołując się na informacje wygooglane na szybko:
https://en.wikipedia.org/wiki/Instructions_per_cycle
Dzięki, jak szukałem haseł w stylu "Intel Skylake IPC" Google złośliwie ukrył przede mną Wikipedię. Poważnie.
Ale ok, mea culpa, użyłem sformułowania IPC na określenie wskaźnika teoretycznego, a nie praktycznego.
, wskaźnik IPC to wskaźnik wynikający z praktyki, z wykonania kodu.
**Teoretyczną **wydajność oblicza się następująco:
To get a theoretical GFLOPS (Billions of FLOPS) rating for a given CPU, multiply the number in this chart by the number of cores and then by the stock clock (in GHz) of a particular CPU model. For example, a Coffee Lake i7-8700K theoretically handles 32 Single-Precision floats per cycle, has 6 cores and a 3.7 GHz base clock. This gives it 32 x 6 x 3.7 = 710.4 GFLOPS.
I wszystko kręci się wokół tego, ile instrukcji zmiennoprzecinkowych procesor jest w stanie teoretycznie przemielić w jednym takcie. Problem mam ze znalezieniem wiarygodnego źródła tej informacji, nie z przemnożeniem trzech liczb. Nie kłamię.
Obstawiam, że odpowiedzią może być fpus_per_core * doubles_per_vector_register
, ale nie mam całkowitej pewności i chciałbym się upewnić. Dla laptopowego Skylake i7 dawałoby to 2 FPU * 4 DP/rejestr, czyli teoretycznie 8 operacji zmiennoprzecinkowych podwójnej precyzji w cyklu, co z kolei daje ~20GFlops na jednym rdzeniu. Miałoby to sens, gdyby Xeon rzeczywiście miał większe rejestry wektorowe (a najprawdopodobniej nie ma) lub więcej potoków przetwarzania operacji wektorowych (czego nie wiem) - alternatywą jest błędna metodologia wyznaczania liczby operacji na cykl, dlatego chcę się upewnić. Oczywiście pomijam latencję, iloczyn skalarny raczej nie jest operacją zdolną rozwalić przetwarzanie potokowe.
Odnośnie założenia o 40% wydajności, czy masz na myśli wydajność teoretyczną, czy praktyczną?
Teoretyczną. Praktyczna z benchmarków i tak mnie w tym przypadku nie urządza.
Chciałbym zauważyć, że procesor desktop, mobile, server jest prawie zawsze rżnięty z jednego i tego samego kawałka krzemu, a dopiero proces koszykowania (binning) powoduje, że procki z lepszymi wskaźnikami typu iloraz realne TDP do taktowania, max stabilne taktowanie, powodują zakwalifikowanie danego kawałka krzemu do danego koszyka.
Wspaniale, tylko w tej chwili nie ma dla mnie znaczenia, czy różnice w poszczególnych modelach jednej serii wprowadzane są celowo, czy może jeden model to w rzeczywistości udane procesory z serii X, a drugi to wybrakowane procesory z serii X, w których nie działa pewien ficzer. Dla mnie istotna jest finalna specyfikacja danego modelu.
Różnicy w wydajności teoretycznej nie powinno być więc wcale dla tego samego taktowania
Pod warunkiem, że dane dwa modele faktycznie wywodzą się z jednej architektury, jednej serii i miałyby tyle samo potoków, tej samej szerokości rejestry wektorowe itp. itd. Choć i tak nie ma gwarancji, bo skoro czasem coś się rypnie i procesor ma 2 sprawne rdzenie zamiast 4 albo musi pracować na obniżonej częstotliwości, to równie dobrze może mieć 2 sprawne potoki przetwarzania zamiast 4 itd.
różnica w wydajności praktycznej może być ogromna, ze względu np. na rozmiar cache L3, który w procesorach serwerowych może być ogromnych rozmiarów. To czy procek śpi czekając na dane przez 20% czy 80% obliczeń ma kolosalny wpływ na realną wydajność, tj. na IPC (wydajność praktyczną).
Od paru miesięcy wałkuję optymalizowanie dostępu do pamięci, żeby podbić wydajność praktyczną tego i tamtego. Wprawdzie nie komercyjnie, ale i tak możemy dość odważnie założyć, że kwestia wpływu rozmiaru cache, wielodrożności, mechanizmów zwalniania cache, prefetchingu, miss rate w L1/LL cache i całej reszty zagadnień przynajmniej raz musiała obić mi się o uszy, a w dodatku nie jest odpowiedzią na mój problem.
Problem mam ze znalezieniem wiarygodnego źródła parametrów procesora ciut bardziej... szczegółowych niż te, o których każdy huczy w celach marketingowych. Potrzebuję ich po to, by wiedzieć, ile operacji zmiennoprzecinkowych procesor teoretycznie jest w stanie rozpocząć w jednym takcie, tak, by móc z tego wyznaczyć teoretyczną wydajność tego czy siamtego procesora. Czemu akurat tak - bo muszę do czegoś odnieść uzyskiwaną wydajność praktyczną. Czemu nie mogę do benchmarku - raz, bo nie ja decyduję, dwa, że i tak nie miałbym jak zrobić porządnego przy tym, co mam i w sensownym czasie.