Продолжение темы здесь
Кураторы: Romaker, deadlock x86, arm, power, sparc, gpu, cell, amd, intel
Страницы:Кликните, чтобы указать произвольную страницуназад123139140141142143144145146147148149198199200далее
исчезающий: x86 против arm, power, sparc, gpu, cell и других. (часть 8)
вопросы/предложения по ветке обсуждаются в привате -
http://forum.ixbt.com/topic.cgi?id=0:70167
подключает (просьбы подключить к привату) - Romaker
bess_temporary
Member
1011/1014 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 01 сентября 2018 12:01
lkj

> Сложнее. Главная фишка direct-mapped в том, что мы читаем тег и данные за одно обращение.

Еще раз, медленно. Для особо одаренных. Не direct-mapped, а кэш, сделанный без отдельно лежащих быстрых тэгов. Сложите наконец последовательность в голове: 1) direct-mapped без отдельных тэгов, 2) direct-mapped с быстрыми тэгами, 3) ассоциативность = 2, 4) ассоциативность > 2.

С вариантом 1) все понятно - "я его слепила из того, что было". Имеет смысл сравнивать 2) и 3). По сложности они почти не различаются. Зато ассоциативность = 2 очень важна для алгоритмов, когда имеется рабочее множество в кэше плюс к этому большой потоковый трафик основной памяти. В direct-mapped этот трафик будет смывать кэш и существенно снизит его эффективность. В ассоциативном кэше он займет один "путь", а данные в остальной части кэше останутся нетронутыми.

> Теги для кэша в 32 GB будут занимать 2 GB для строк в 64 байта.

Никакой идиот так делать не будет. Вы зациклились. Впрочем, если вам не интересно обсуждать организацию нормальных эффективных кэшей, то давайте не будем. Хотя вы сами начали разговор на эту тему.

> Если сократить кэш до 16 GB, тогда теги будут занимать 60 MB.

Хватит фантазировать и капризничать. Легко посчитать, что для блока в 4K можно уложиться в 10-20 MB хоть для direct-mapped, хоть для ассоциативного = 2. А если сделать микротэги, то еще меньше. Для современного процессора такой размер - мелочь. Ах, да, вы почему-то любите подсчитывать транзисторы. Хоть это и не очень адекватный показатель, но почему бы и нет ? По достаточно консервативному и округленному подсчету 10-20 MB превращается в 0.75-1.5 миллиарда самых плотных транзисторов.

> Но большие сектора по 2 KB могут показать провалы производительности для случайных обращений.

Если рассматривать вопрос в целом, то легко догадаться, что для случайных обращений HBM-кэш никакого выигрыша не даст. И предназначен он в первую очередь не для этого.

> Кстати, CLX-AP вероятно не сможет нагрузить 1 TB/s HBM2 полностью.

Не будет там никакого HBM2.

> Так два больших чипа CLX-AP по 600 mm2 (1200 mm2 в сумме) будут проигрывать одному небольшому чипу a64fx размером примерно 330 mm2

У этих продуктов разное назначение.
VLev
Expert
8185/15569 ответов, #2 в рейтинге
23 года на iXBT, с января 2002
6 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (64%)
Россия, Moscow
Инфо
V
VLev Expert
6 лет назад / 01 сентября 2018 12:09
lkj
Кстати, CLX-AP вероятно не сможет нагрузить 1 TB/s HBM2 полностью.
ну дык
а размер строки - до 128 байт.
я бы и больше сделал.
По крайней мере
размер сектора до 2 KB
скажем, 4K/2M - собственно, размер страниц.
lkj
Member
1764/1860 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 01 сентября 2018 12:52
bess_temporary
В ассоциативном кэше он займет один "путь", а данные в остальной части кэше останутся нетронутыми.

Тогда вам еще надо будет сообщать в этот кэш информацию из ядер, что какой-то путь важнее других, что сложно сделать.

Легко посчитать, что для блока в 4K можно уложиться в 10-20 MB

Еще легко посчитать, что для каждой строки кэша (128 или 64 байта) надо хранить несколько состояний - invalid, read, modified - это уже 2 бита для каждой строки. Только для этих состояний нужно затратить 64 MB для кэша в 32 GB, если размер строки 128 байтов. Если увеличивать размер блока, то все обращения в основную память надо делать огромными кусками. Но мы хотим получить универсальный процессор, который даже на случайных обращениях в основную память может оперировать небольшими порциями по 64 или 128 байт.

На самом деле есть много статей про dram cache для процессоров.
Я их смотрел мельком. Там рассматривают все схемы. И там была четкая тенденция - direct-mapped с хранением тегов рядом с данными выигрывает у всех других схем. Тут еще повезло, что HBM поддерживает массив для ECC, где можно хранить тег. Без этого дополнительного пространства все было бы сложнее.
Но вообще даже эта лучшая direct-mapped схема обладает недостатками, и поэтому проиграет схеме с чистым HBM (A64FX) в итоге.
А единственная реальная реализация в phi использовала медленную MCDRAM.
Поэтому пока нельзя было оценить реальные возможности dram cache на том примере. Скорость кэша HBM2 должна быть лучше.

VLev
скажем, 4K/2M - собственно, размер страниц.

Сдохнет на случайном доступе.
Например, кэш 32 GB и 256 GB основной памяти DDR4.
И у нас паттерн случайного доступа: 80% - кэш / 20% - DDR4.
Если на каждое обращение в эти 20%, мы будем пересылать по 4 KB в обе стороны, тогда ограниченная ПСП DDR4 быстро закончится.
8 каналов DDR4: 170 GB/s / 4 KB = 40 MT/s
40 MT/s разделить на 80 потоков (40 ядер + Hyper-threading) - это 2000 ns на одно случайное обращение из одного потока, что в 20 раз медленнее нормальной задержки DDR4.
А мы хотим получить ускорение от кэша по ПСП, но все еще сохранить хорошую латентность и для основной памяти.
VLev
Expert
8186/15570 ответов, #2 в рейтинге
23 года на iXBT, с января 2002
6 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (64%)
Россия, Moscow
Инфо
V
VLev Expert
6 лет назад / 01 сентября 2018 13:06
lkj Сдохнет на случайном доступе.
да и не жалко.

И у нас паттерн случайного доступа: 80% - кэш / 20% - DDR4.
нет конечно (как по мне). "кэш" - это накристальный кэш, ну или как минимум SRAM.
А DDR4 при наличии HBM --- это хранилище для swap-а
lkj
Member
1765/1861 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 01 сентября 2018 13:08
bess_temporary
У этих продуктов разное назначение.

Одинаковое - HPC.
И характеристики CLX-AP / A64FX похожи:
44-48 ядер, и каждое ядро поддерживает dual FMA-512.
Частота примерно по 1.8 GHz у обоих.
Разнице только в объемах поддерживаемой памяти и кэша.
Но если для задачи хватит 32 GB, тогда A64FX должен выигрывать.
Boris Usievich
Member
14758/39678 ответов, #6 в рейтинге
22 года на iXBT, с октября 2002
Чаще пишет РІ "Процессоры" (44%)
Инфо
B
Boris Usievich Member
6 лет назад / 01 сентября 2018 13:11
lkj
И характеристики CLX-AP вы честно высосали из пальца?
bess_temporary
Member
1012/1015 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 01 сентября 2018 13:15
lkj

> Тогда вам еще надо будет сообщать в этот кэш информацию из ядер, что какой-то путь важнее других, что сложно сделать.

Вы чего-то не поняли (вероятно, никогда не программировали с учетом поведения кэша). LRU сам все сделает автоматически.

> Еще легко посчитать, что для каждой строки кэша (128 или 64 байта) надо хранить несколько состояний - invalid, read, modified - это уже 2 бита для каждой строки

(это не строка, а сектор внутри кэшевого блока) Почему 64-128, а не 256 ? И состояния тоже можно хранить общие. Кстати, 3 состояния - это не 2 бита, а log2(3)

> на случайных обращениях

Не увлекайтесь случайными обращениями, мы стремимся к высокому ПСП. Впрочем, для HBM2 и DDR5 случайное обращение на 256 байт мало отличается от 128 или 64 - посмотрите на их внутреннюю организацию.

> И там была четкая тенденция - direct-mapped с хранением тегов рядом с данными выигрывает у всех других схем.

Это у теоретиков, которые не знают задач.

> Сдохнет на случайном доступе.

На случайном доступе и сейчас все сдыхает. Если программист не заботится, например, об переупорядочении разреженной матрицы.

> И у нас паттерн случайного доступа: 80% - кэш / 20% - DDR4.
Если на каждое обращение в эти 20%, мы будем пересылать по 4 KB в обе стороны, тогда ограниченная ПСП DDR4 быстро закончится.


Здесь у вас сферические кони в разреженной атмосфере (кстати, почему 4K, если кэшевый блок секционирован ? кончайте передергивать)

> но все еще сохранить хорошую латентность и для основной памяти.

Ваша любимая схема гарантирует очень плохую латентность.

Добавление от 01.09.2018 13:18:

> Одинаковое - HPC.

Смешно. Нет такого приложения "HPC". Есть множество программ с различными характеристиками. В том числе с требованию по размеру памяти. Если бы всем хватало 32G, Интел плюнул бы на DDR и сделал только Fast. Но он это даже на устаревающем Phi2 не сделал.
lkj
Member
1766/1862 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 01 сентября 2018 13:25
VLev
да и не жалко.

Так пока не было таких решений.
PHI не подыхал окончательно на случайном доступе к DDR4.
Поэтому никто и не жаловался.

Тут еще соотношения играют роль.
Популярное соотношение для phi: 16 GB встроенной против 96 GB основной памяти - это 1/6. Это бессмысленное сочетание. Например, можно было сделать 48-64 GB быстрой встроенной памяти вместо той комбинации, и всем было бы лучше.
Но если бы было 16 GB кэша и 1 TB основной, тогда конструкция с двумя уровнями уже будет более сбалансированной. Но 1 TB на каждый серверный процессор нельзя поставить экономически - не хватит производственных мощностей DRAM. Поэтому ставить в серверы все равно будут относительно мало внешней памяти - 64-256 GB на один серверный процессор. А 128 GB предположительно можно будет запихнуть в 4 чипа HBM3. И тогда внешнюю память можно не делать вообще, если стоимость HBM3 будет не сильно превышать стоимость DDR4.

Добавление от 01.09.2018 13:43:

bess_temporary
LRU сам все сделает автоматически.

LRU у кэша L4 не видит LRU статистику у кэша L1, и поэтому LRU-L4 не обладает информацией для умного вытеснения строк в момент чтения строк из DDR4.

(кстати, почему 4K, если кэшевый блок секционирован ? кончайте передергивать)

Про 4K я отвечал не вам, а VLev, который и предложил подкачивать по 4 KB.
Можно выбрать любой размер блока: 128/256/512/1024/2048.
Маленький размер блока - много SRAM памяти.
Большой размер блока - медленные DDR4 обращения.
И даже для некоторой "золотой" середины в этой схеме для большого кэша мы все еще получим значительное ухудшение для доступа в DDR4 и относительно дорогую SRAM директорию с тегами. Поэтому и выбирают direct-mapped вместо этого.

Ваша любимая схема гарантирует очень плохую латентность.

1) Она не моя "любимая" схема. Моя "любимая" схема - чистый HBM без DDR. 2) Но direct-mapped все еще лучшая схема из гибридных схем.
Пример по латентности для паттерна 80%/20%:
80% - 100 нс HBM2
20% - 100 нс HBM2+ 100 нс DDR4
в среднем - 120нс, что только на 20% хуже чистой латентности DDR4. Никакой катастрофы там нет.

Исправлено: lkj, 01.09.2018 13:50

VLev
Expert
8187/15571 ответов, #2 в рейтинге
23 года на iXBT, с января 2002
6 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (64%)
Россия, Moscow
Инфо
V
VLev Expert
6 лет назад / 01 сентября 2018 14:14
lkj:
16 GB встроенной против 96 GB основной памяти - это 1/6. Это бессмысленное сочетание.
тут согласен.

Добавление от 01.09.2018 14:15:

но скорее всего это по цене сбалансировано

Добавление от 01.09.2018 14:17:

в любом случае, меньше 8:1 делать бессмысленно, а, учитывая число каналов, 12:1 ещё куда ни шло, т.е. 16+192GB
lkj
Member
1767/1863 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 01 сентября 2018 14:47
bess_temporary
В том числе с требованию по размеру памяти. Если бы всем хватало 32G, Интел плюнул бы на DDR и сделал только Fast. Но он это даже на устаревающем Phi2 не сделал.

Во времена разработки Phi2 еще не было HBM2, где увеличили объем памяти в 4-8 раз. И соотношения цен на память были другие.
Теперь ситуация изменяется. Появились крупные чипы HBM2 по 8 GB, и будет еще в 4 раза (предположительно) больше в HBM3.
А соотношения CPU / объем памяти определяется мощностями производства, а основной тренд задается в смартфонах.
Например для процессоров 7 нм:
Kirin 980: ~80 mm2 CPU / 6-8 GB LPDDR4
Apple A12: ~75 mm2 CPU / 4 GB LPDDR4
Vega 20: 360 mm2 CPU / 32 GB HBM2
A64FX: ~330 mm2 CPU / 32 GB HBM2
И нельзя изменить этот тренд по соотношениям площади CPU к объему памяти очень сильно. Хотя отклонения могут быть примерно в два раза из-за дороговизны HBM2. И в среднем на каждый серверный/десктопный/ноутбучный чип будет очень мало памяти - те самые 4-16 GB на каждые 100mm2 площади CPU на техпроцессе 7 нм. А с такими низкими объемами памяти должна справиться HBM3 рядом с чипом.
И эту тенденцию по соотношениям CPU/DRAM нельзя сейчас изменить. Производство чипов CPU/GPU и чипов памяти работает на пределе и всю память раскупают. Если увеличат производство DRAM, тогда в смартфоны будут ставить еще больше памяти и они поглотят все это увеличение производства, что не позволит снизить цены резко.

Поэтому fujitsu правильно угадала направление с отказом от внешней памяти в процессорах.
bess_temporary
Member
1013/1016 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 01 сентября 2018 16:06
lkj

> Например, можно было сделать 48-64 GB быстрой встроенной памяти вместо той комбинации, и всем было бы лучше.

Всем не было бы. Только тем, кому хватает 48-64. А тем, кому нужно 96-192, было бы намного хуже. Кончайте портить людям жизнь

> LRU у кэша L4 не видит LRU статистику у кэша L1, и поэтому LRU-L4 не обладает информацией для умного вытеснения строк в момент чтения строк из DDR4.

Вы бы хоть промоделировали в голове эту ситуацию. И при чем тут L1 ? Есть обращения в память. Часть из них группируется в плотном рабочем множестве в нашем кэше (L4), и к ним обращаются достаточно часто. Другая часть - потоковые одноразовые доступы в большую память по последовательным адресам. Простейший LRU (наверное, даже однобитный) в тэгах L4 увидит, что обращения к данным второго типа реже, чем первого, и вытеснит их в первую очередь. На основе этого принципа реализуют плотные алгоритмы линейной алгебры типа используемых в решалке, основанной на LU-разложении (LINPACK).

> Про 4K я отвечал не вам, а VLev, который и предложил подкачивать по 4 KB.

Он предлагал хранить по 4K. Про подкачивать это вы домыслили. Как и большинство "доводов", с которыми вы спорите

> Пример по латентности для паттерна 80%/20%:
80% - 100 нс HBM2
20% - 100 нс HBM2+ 100 нс DDR4
в среднем - 120нс, что только на 20% хуже чистой латентности DDR4. Никакой катастрофы там нет.


Да, да, у Маши 10 любовников, а у меня ни одного - а в среднем я бл$дь Кончайте теоретизировать.

А рассуждения от трендах памяти бессмысленны. Если людям надо запускать задачи на много гигабайт, для них сделают систему на много гигабайт. Без дурацких рассуждений о сбалансированности. Если Fujitsu ограничился 32 гигами, значит, их целевые задачи не требуют большего. Всего-то. Тем более что тут играет роль экзафлопсная истерия. Правда, с поправкой на здравый смысл, так как сделали универсальный процессор (CPU), а не специализированный (GPU).

Что же касается сбалансированности, то как раз размер кэша определяют для предполагаемого размера памяти, а не наоборот
fobos
Member
29/448 ответов
22 года на iXBT, с октября 2002
Чаще пишет РІ "Игры" (24%)
Инфо
f
fobos Member
6 лет назад / 02 сентября 2018 01:31
Какой ужас...теориетиков хоть ж...жуй.
Тесты, сестра, где тесты?
HMB-HMB3, вам не пофиг????
bess_temporary
Member
1018/1021 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 02 сентября 2018 02:45
Задачи порешайте, потом приходите. Примем вас к обсуждению
matik
Expert
13260/34280 ответов, #7 в рейтинге
23 года на iXBT, с марта 2001
Чаще пишет РІ "Процессоры" (52%)
Инфо
m
matik Expert
6 лет назад / 02 сентября 2018 18:57
lkj
даже эта лучшая direct-mapped схема обладает недостатками, и поэтому проиграет схеме с чистым HBM

Схема с HBM "direct-mapped" кэшем проиграет схеме с HBM.
Ну ладно, ок


единственная реальная реализация в phi использовала медленную MCDRAM
А с чего вдруг MCDRAM - "медленная"?
В каком месте медленная? В чем именно?
lkj
Member
1768/1864 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 02 сентября 2018 20:08
matik
А с чего вдруг MCDRAM - "медленная"?

MCDRAM в PHI не использует interposer. Поэтому они не могут получить "миллион" параллельных контактов. И вместо этого там стоят SerDes на CPU и в чипах памяти, которые преобразовывают потоки данных и запросов для передачи через меньшее количество высокочастотных последовательных линий. И эти преобразования могут добавлять еще издержки протоколов взаимодействия. У Epyc такая же проблеме с высокими задержками межпроцессорных SerDes линков, которые совмещаются еще с PCIe.
bess_temporary
Member
1019/1022 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 02 сентября 2018 20:10
lkj

> И эти преобразования могут добавлять еще издержки протоколов взаимодействия.

И вы можете легко прикинуть величину этих задержек. Остальное могли бы и не говорить, т.к. это все и без вас знают

Добавление от 02.09.2018 20:12:

> У Epyc такая же проблеме с высокими задержками межпроцессорных SerDes линков

Там проблема вовсе не SerDes. Последовательный протокол с заголовками, очереди, кэшевая когерентность. Совсем другой коленкор.
lkj
Member
1769/1865 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 02 сентября 2018 20:35
bess_temporary

И вы можете легко прикинуть величину этих задержек.

Есть цифры в статьях:
130 нс - DDR4
154 нс - MCDRAM
Обе величины слишком большие.
Можно списать на дополнительную сложность гибридной схемы.
Поэтому я выступаю за чистую HBM без SerDes и без DDR4, где задержки должны быть не сильно хуже задержек для DDR4 в SKL-SP.

кэшевая когерентность

кэшевая когерентность есть и во внутрисокетных линках. Но межпроцессорные линки работает значительно медленнее в Epyc.
bess_temporary
Member
1020/1023 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 02 сентября 2018 20:45
lkj

> Есть цифры в статьях:
130 нс - DDR4
154 нс - MCDRAM
Обе величины слишком большие.
Можно списать на дополнительную сложность гибридной схемы.


Их можно списать на методику измерений. Кстати, вы не указали, в каком режиме произведен замер DDR4.

> Поэтому я выступаю за чистую HBM без SerDes и без DDR4

Вы уже много раз говорили, что хотели бы выбросить на помойку все задачи, не умещающиеся в 16 GB (или 32 GB, в зависимости от рассматриваемой системы).

> кэшевая когерентность есть и во внутрисокетных линках. Но межпроцессорные линки работает значительно медленнее в Epyc.

Потому что они межпроцессорные. То есть внешние, длинные и менее защищенные. Что тут непонятного ?
matik
Expert
13262/34282 ответов, #7 в рейтинге
23 года на iXBT, с марта 2001
Чаще пишет РІ "Процессоры" (52%)
Инфо
m
matik Expert
6 лет назад / 02 сентября 2018 20:57
lkj
MCDRAM в PHI не использует interposer
И что? Интерпозер здесь при чем?

Поэтому они не могут получить "миллион" параллельных контактов.
Во-первых, HBM - это прежде всего TSV, если правильно помню. Технология сквозных соединений чипов друг с другом.
Как память, никакого отличия у HBM нет.

Но это совершенно не отвечает на тот вопрос, который я задал: при чем здесь "медленная"? Что там "медленного"?


И вместо этого там стоят SerDes на CPU и в чипах памяти
Что-то есть ощущение, что вы пишете какую-то фигню. Какие "сериализаторы" на запросах в память? Нафейхоа они там?


У Epyc такая же проблеме с высокими задержками межпроцессорных SerDes линков
Межпроцессорные линки здесь вообще не при чем. Никаким боком.
Вы что с чем вообще сравниваете?


130 нс - DDR4
154 нс - MCDRAM

ЧТО это за цифры? Что такое "130нс" у DDR4?
И где данные у HBM, собственно?

Напишите подряд три латентности:
DDR4
MCDRAM
HBM
Поглядим, кто медленнее.


Вообще вы какой-то удивительно странный винегрет устроили, честно говоря: из того простейшего факта, что у HBM высокая ПСП (что неудивительно, сколько именно для этого эти сборки и создавались), вы делаете каких-то космических масштабов выводы, причем на отдельную (и иногда не смежную) тему.
lkj
Member
1770/1866 ответов
22 года на iXBT, с июня 2002
Чаще пишет РІ "Процессоры" (97%)
Инфо
l
lkj Member
6 лет назад / 02 сентября 2018 21:07
bess_temporary
Вы уже много раз говорили, что хотели бы выбросить на помойку все задачи, не умещающиеся в 16 GB (или 32 GB, в зависимости от рассматриваемой системы).

Есть исследования потребления памяти в HPC кластерах на xeon:

80% of use on ARCHER uses less than 24 GiB/node (1 GiB/core)
60% uses less than 12 GiB/node (0.5 GiB/core)


Собственно потребители и строители кластеров уже очень сильно подстраиваются под стоимость DDR4, а не наоборот.
Если серверный процессор интела стоит примерно $1500 после скидки, тогда в серверах и затраты на память хотят уместить в похожую величину.
Для 80-90% новых систем в top500, которые без GPU, ставят примерно по 96 GB (или даже меньше) на один процессор. Такой объем вероятно сможет покрыть и HBM3.
Но если можно снизить стоимость серверного CPU, тогда строители кластеров могут попытаться снизить затраты - поставить два CPU и по 48 GB на CPU вместо одного CPU+96GB. Тут и пригодится высокая плотность 7 нм, когда процессор можно сделать значительно дешевле текущих серверных интелов. Это уже произошло в смартфонах с дешевыми кристаллами CPU/GPU. И соотношения CPU/DRAM на смартфонном рынке будут влиять на цены и соотношения в других сегментах.

А64FX идет по этому пути, когда мы снижаем объем памяти на процессор, но повышаем плотность размещения. Хотя им нужно подтвердить это соответствующими ценами, чтобы на этот путь стали интенсивно переходить от текущих соотношений 96GB/1CPU.

Добавление от 02.09.2018 22:02:

matik

что у HBM высокая ПСП (что неудивительно, сколько именно для этого
эти сборки и создавались),


Кроме высокой ПС у HBM* есть и другие достоинства:
- очень низкое потребление на единицу передаваемой информации.
- высокая плотность - вероятно можно будет разместить 128 GB HBM3 в геометрических пределах нынешнего серверного процессора.
Так одним радиатором с вентилятором можно охлаждать одновременно процессор и память. Высокая плотность HBM сильно экономит место на плате, и поэтому можно повысить вычислительную плотность в серверах, что уже делают, когда размещают большое количество модулей Volta+HBM2 на одной плате. A64FX тоже идут этой дорогой. Vega 20 тоже потенциально на этом пути к высокой плотности размещения.

Недостатки HBM тоже известны:
- сложнее производить и поэтому высокая стоимость
- вроде бы пока не очень хорошо передают тепло между слоями. И поэтому нижние слои памяти HBM могут перегреваться. В HBM3 количество слоев еще увеличивают, и поэтому что-то будут делать с дальнейшим уменьшением потребления или повышать проводимость тепла.
Если успешно устранят или ослабят эти два недостатка, тогда HBM* может попасть в десктопы, серверы, приставки и видеокарты, заменяя основную DDR4 и GDDR.
Например, сильно лучше было бы для мощных APU, которые получили бы увеличение ПС в 10 раз от нынешнего значения, чтобы любой встроенный GPU больше не зависел от низкой ПС у DDR4.

Исправлено: lkj, 02.09.2018 22:16

bess_temporary
Member
1021/1024 ответов, #1 в рейтинге
7 лет на iXBT, с января 2018
1 фото на iXBT.photo
Чаще пишет РІ "Процессоры" (98%)
Россия, iXBT.com c 1997 г.
Инфо
b
bess_temporary Member
6 лет назад / 02 сентября 2018 22:09
lkj

> Есть исследования потребления памяти в HPC кластерах на xeon:

Есть исследования роста мужчин. 80% имеют рост менее 180 см. Давайте все кровати в отелях укоротим, скажем, до 182 см (цифры условные)

> Собственно потребители и строители кластеров уже очень сильно подстраиваются под стоимость DDR4, а не наоборот.

Наоборот. Подстраиваются под наиболее крупные из достаточно часто решаемых задач. А для редко решаемых покупают толстые узлы. Например, на кластере, где я работаю, 5 лет назад было закуплено несколько узлов на полтерабайта (2х10 ядер). Это 2013-й год. А у нас уже 20-е годы на носу (мы ведь говорим о ближайшей перспективе).

И не надо упираться в Top500. Там многие системы - это даже не процессоры, а GPU. И акцент делается на мультипетафлопсы. По достаточно понятным причинам.

Остальные ваши рассуждения никак не связаны с вопросами организации памяти. И являются в основном благими пожеланиями.
Если Вы считаете это сообщение ценным для дискуссии (не обязательно с ним соглашаться), Вы можете поблагодарить его автора, а также перечислить ему на счет некоторую сумму со своего баланса (при отзыве благодарности перечисленная сумма не будет вам возвращена).
Также вы можете оценить сообщение как неудачное.
В течение суток можно 20 раз оценить сообщения разных участников (купите Premium-аккаунт, либо оплачивайте оценки сверх лимита).
Страницы:Кликните, чтобы указать произвольную страницуназад123139140141142143144145146147148149198199200далее
Продолжение темы здесь