Дори в момента не може да стъпи на малкия пръст на това което е при цпу-тата.
0 1 2 3 4 ...45 46 47 48 49 ...90 91 92 93 94
Дори в момента не може да стъпи на малкия пръст на това което е при цпу-тата.
Кеша яде мм2 от силикона дето са и на гпу-то карантиите. А те хич не са малко. И явно трябва баланс.
The flagship Nvidia consumer GPU (GeForce RTX 5090) features a total of 117.7 MB of on-die cache, while the largest AMD consumer CPU (Ryzen 9 9950X3D2) features a total of 209.3 MB of on-chip cache.
А трябва гпу-то да има порядъци повече кеш, защото има и порядъци повече ядра, не мислиш ли? Съвсем отделен въпрос е латентността при цпу кеша и при гпу кеша, треа некъде все да пише за колко цикъла нвидията чете оттам и за колко амд процесора. Още по-отделен въпрос е асоциативността, при цпу-то отива на към на 16-way, оттам може да си представиш как това се отразява ако достъпваш произволни адреси, не такива наредени последователно у паметта.
Добро е като за рабиняци. Не говори много за новите (те вече не са много нови) тенденции на различни видове disaggregation, няма нищо за KV cache management и т.н.
И гейта и Ребата са прави. По дълъг път до паметта означава по-ниски битрейтс, по-широка шина означава повече енергия (и проблеми с пиновете на процесора). И после въпроса е какво ще ги правиш всичките тези байтове от тази широка памет на CPU-то, в много случаи отиват на боклука.
В HPC средите това беше важна тема когато навлизаше HBM. Изводите бяха, че не винаги помага. Bandwidth vs. latency and all that.
Еми не му трябва, щото не е цпу и може да скрие изчакването. Всъщност приложението което пишем най-големия му проблем, поне според nsight graphics, е instruction cache thrashing.
Еми щом могат да превключват warp-ове докато чакат за памет, значи може би изначално не им и трябва толко много кеш. Аааа момент, освен ако нема какво да се превключи щото кода е memory-intensive и всичките чакат за памет, еее тогава става грИдЪ.
И се случва, wait for it..., cache thrashing. :)
0 1 2 3 4 ...45 46 47 48 49 ...90 91 92 93 94