Здравствуйте, koandrew, Вы писали:
K>DDR4 типовая латентность интерфейса — 20 тактов если обращение выполняется в уже открытую строку, где-то вдвое больше, если в какую-то другую, но банк не занят, или втрое больше (>60 тактов), если нужно будет закрыть какую-то другую строку. Если ещё сверху добавить латентность контроллера памяти, плюс арбитража — то сотня наберётся очень легко. А если уж попадёшь на период рефреша — всё, тушите свет, сливайте воду
А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов? Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.
K>Так что алгоритм с "много случайных обращений" — херовый, придумывай поточный, где не было бы такой дури. Кстати, это тебе здорово поможет и для компа, и для GPGPU, ибо они тоже страдают от латентности памяти.
Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
K>Если для USB 3 использовать чипы FT600 или FT601 — то дрова предоставляются FTDI (производителем чипа) уже готовые и забесплатно, то есть даром. И они обеспечивают реальную полосу пропускания, которой почти хватает для стриминга RGB 1080p@60 в реальном времени (я тут как-то постил результаты своих тестов скорости этого решения). Ещё со стороны FPGA он предоставляет очень удобный FIFO-style интерфейс, так что интегрировать его в свой проект элементарно.
K>Всё другие варианты требуют существенно бОльшего объёма усилий, чтобы интегрировать. В некоторых типовых случаях для PCI Express можно обойтись предоставляемыми забесплатно IP (но не стоит забывать, что они скушают немало ресурсов FPGA)
Здравствуйте, Codealot, Вы писали:
C>А если сравнить это с латентностью получения данных даже (в лучшем случае) через PCIe, то сколько там будет тактов? Я думаю, там счет пойдет уже на сотни тысяч, если еще не хуже.
Какая разница-то? Затыки всё равно будут такие, что никакого профита от параллельности не получится.
C>Реальность — она вообще довольно херовая штука, и в удобные алгоритмы укладывается далеко не всегда
Чаще всего таки просто фантазии автора оказывается недостаточно. Достаточно посмотреть на тысячи и тысячи алгоритмов, которые считались не параллелизуемыми, пока разработчиков конкретно не прижали к стенке и не заставили переделать так, чтобы можно было параллельно считать на GPGPU.
C>Интересно, на что оно их жрет?
На реализацию логики протокола конечно. Там, FSMы всякие, и вычислительные блоки, и т.п. Ты, видимо, плохо представляешь себе, с чем приходится иметь дело при работе с FPGA
Здравствуйте, koandrew, Вы писали:
K>Какая разница-то? Затыки всё равно будут такие, что никакого профита от параллельности не получится.
Если данные умещаются в памяти — все равно будет намного быстрее, чем когда за ними надо бегать очень далеко.
K>Чаще всего таки просто фантазии автора оказывается недостаточно. Достаточно посмотреть на тысячи и тысячи алгоритмов, которые считались не параллелизуемыми, пока разработчиков конкретно не прижали к стенке и не заставили переделать так, чтобы можно было параллельно считать на GPGPU.
Ну и в результате на GPGPU все равно ставят самую быструю оперативку по 16 гб
K>На реализацию логики протокола конечно. Там, FSMы всякие, и вычислительные блоки, и т.п. Ты, видимо, плохо представляешь себе, с чем приходится иметь дело при работе с FPGA
Примерно представляю. Просто плохо представляю, как устроен PCIe на низком уровне. Сильно сложнее чем Ethernet, например?
Здравствуйте, Codealot, Вы писали:
C>Если данные умещаются в памяти — все равно будет намного быстрее, чем когда за ними надо бегать очень далеко.
Чаще всего алгоритм можно перестроить таким образом, чтобы этого делать не пришлось.
C>Ну и в результате на GPGPU все равно ставят самую быструю оперативку по 16 гб
Однако заметь, что объём видеопамяти растёт очень медленно, а вот полоса пропускания — очень быстро. Подумай на досуге, почему По твоей логике должно было быть наоборот.
C>Примерно представляю. Просто плохо представляю, как устроен PCIe на низком уровне. Сильно сложнее чем Ethernet, например?
На канальном уровне несколько проще, т.к. он by design точка-точка. Но логически протокол PCIE — это DMA, то есть доступ к памяти, плюс поддержка out-of-band сигналов и всяких сервисных штук типа прерываний или power management прямо на уровне протокола. Там другая сложность — бешеная скорость и потому очень жёсткие требования по таймингам всей обрабатывающей логики. Если совсем на пальцам — на выходе трансивера у тебя есть поток байтов (или полуслов, или слов, в зависимости от скорости и количества линий), и признак, является ли символ "запятой" (специальным управляющим символом, который позволяет понять, где в сплошном потоке бит находятся границы байт), и твоя задача как-то переварить этот поток на полной скорости дабы определить, есть ли там собственно полезные данные или нет, и, если есть, то что это за данные.
Поищи в гугле по фразе "pci express 3.0 specification pdf" — там найдёшь спеку, почитай, если интересно. По крайней мере мне было любопытно почитать.
Здравствуйте, koandrew, Вы писали:
K>Чаще всего алгоритм можно перестроить таким образом, чтобы этого делать не пришлось.
Но далеко не всегда.
K>Однако заметь, что объём видеопамяти растёт очень медленно, а вот полоса пропускания — очень быстро. Подумай на досуге, почему По твоей логике должно было быть наоборот.
Почему это? Во первых, объемы видеопамяти растут не медленнее, чем объемы оперативки у компов. Во вторых, именно по твоей логике, полоса пропускания видеопамяти должна быть практически неважна — это ведь только буфер для сглаживания колебаний потока данных, который передается по PCIe
K>Там другая сложность — бешеная скорость и потому очень жёсткие требования по таймингам всей обрабатывающей логики. Если совсем на пальцам — на выходе трансивера у тебя есть поток байтов (или полуслов, или слов, в зависимости от скорости и количества линий), и признак, является ли символ "запятой" (специальным управляющим символом, который позволяет понять, где в сплошном потоке бит находятся границы байт), и твоя задача как-то переварить этот поток на полной скорости дабы определить, есть ли там собственно полезные данные или нет, и, если есть, то что это за данные.
Понятно. А аппаратные блоки разве эту проблему не решают?
Здравствуйте, Codealot, Вы писали:
C>Но далеко не всегда.
Гораздо чаще, чем кажется на первый взгляд Особенно когда есть широкая шина памяти.
C>Почему это? Во первых, объемы видеопамяти растут не медленнее, чем объемы оперативки у компов. Во вторых, именно по твоей логике, полоса пропускания видеопамяти должна быть практически неважна — это ведь только буфер для сглаживания колебаний потока данных, который передается по PCIe
Нет, по моей логике как раз нужна полоса пропускания — чтобы можно было кормить всю ту кучу параллельных исполнительных блоков в конвейере. В параллельных вычислениях страшны не сами по себе обращения к памяти, а их неупорядоченность. То есть, если ты знаешь, что на шаге 42 твоего конвейера тебе понадобятся данные X, то ты сможешь заранее запросить их таким образом, чтобы они "пришли" как раз к этому шагу. В видеоконвейере проблема решается несколько другим способом — когда исполнительные ядра доходят до обращения к памяти, это обращение производится, а ядра переключаются на другие задачи до тех пор, пока данные не придут.
Я недавно тут накопал вот такой цикл статей о том, как устроены видеоконвейеры, так сказать, из первых рук: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ Почитай, очень-очень любопытное чтиво!
C>Понятно. А аппаратные блоки разве эту проблему не решают?
По-разному бывает. Например в FPGA семейства Kintex-7 трансиверы физически поддерживают скорости PCI Express 3.0 (8Gbps на линию), однако аппаратный блок поддерживает только PCI Express 2.0 (5Gbps). Так что если хочется максимальной скорости — то придётся педалить код протокола самостоятельно. Да и аппаратный блок — тоже далеко не панацея, он всего лишь сам выцепляет пакеты из потока — обрабатывать их опять же придётся твоему коду.
Здравствуйте, koandrew, Вы писали:
K>Нет, по моей логике как раз нужна полоса пропускания — чтобы можно было кормить всю ту кучу параллельных исполнительных блоков в конвейере. В параллельных вычислениях страшны не сами по себе обращения к памяти, а их неупорядоченность. То есть, если ты знаешь, что на шаге 42 твоего конвейера тебе понадобятся данные X, то ты сможешь заранее запросить их таким образом, чтобы они "пришли" как раз к этому шагу. В видеоконвейере проблема решается несколько другим способом — когда исполнительные ядра доходят до обращения к памяти, это обращение производится, а ядра переключаются на другие задачи до тех пор, пока данные не придут. K>Я недавно тут накопал вот такой цикл статей о том, как устроены видеоконвейеры, так сказать, из первых рук: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ Почитай, очень-очень любопытное чтиво!
Но для этого не нужны такие объемы видеопамяти, как ставят сейчас. На средней игровой видеокарте уже столько же памяти, как на среднем ноуте
K>По-разному бывает. Например в FPGA семейства Kintex-7 трансиверы физически поддерживают скорости PCI Express 3.0 (8Gbps на линию), однако аппаратный блок поддерживает только PCI Express 2.0 (5Gbps). Так что если хочется максимальной скорости — то придётся педалить код протокола самостоятельно. Да и аппаратный блок — тоже далеко не панацея, он всего лишь сам выцепляет пакеты из потока — обрабатывать их опять же придётся твоему коду.
А если ограничиться PCIe 2.0 x4 — как у Artix-7, это сильно геморно?
Здравствуйте, Codealot, Вы писали:
C>Но для этого не нужны такие объемы видеопамяти, как ставят сейчас. На средней игровой видеокарте уже столько же памяти, как на среднем ноуте
Ну как сказать. Нынче модны всякие 4к — а для них текстуры должны иметь бешеное разрешение. Плюс видеоконвейер — это всё же не алгоритм, а скорее сопроцессор (т.к. шейдерные блоки turing-complete). Мы же ведём речь о более или менее статичном алгоритме, под который как раз и затачивают железо (и при необходимости его меняют на ходу). Видеокарты не обладают такой гибкостью, т.к. аппаратная часть там фиксирована. Хотя Интел уже давно грозится выпустить зеоны с фабрикой FPGA на одном кристалле, на настоящий момент есть только комбинация ARM + FPGA. Впрочем, вроде как уже есть специализированные облака, где стоят FPGAшки. Я с этим особо не знаком, ибо мне оно как-то не нужно.
C>А если ограничиться PCIe 2.0 x4 — как у Artix-7, это сильно геморно?
В теории — не должно быть, а как оно на практике — я ещё не знаю, ибо не пробовал. Но надеюсь в ближайшее время попробовать.
Здравствуйте, koandrew, Вы писали:
K>Ну как сказать. Нынче модны всякие 4к — а для них текстуры должны иметь бешеное разрешение.
Не... для 4к нужны уже совсем не средние видеокарты, а там оперативки куда больше, чем 8 гб. А 8 гб — это именно столько, сколько сейчас ставят на средние ноуты.
K>Плюс видеоконвейер — это всё же не алгоритм, а скорее сопроцессор (т.к. шейдерные блоки turing-complete). Мы же ведём речь о более или менее статичном алгоритме, под который как раз и затачивают железо (и при необходимости его меняют на ходу).
Ну хорошо. Допустим, нужно отсортировать массив строк разной длины. Как тут избавиться от случайного доступа к памяти?
K>Хотя Интел уже давно грозится выпустить зеоны с фабрикой FPGA на одном кристалле, на настоящий момент есть только комбинация ARM + FPGA.
Похоже, что у Интел сейчас хватает куда более насущных проблем.
Здравствуйте, Codealot, Вы писали:
C>Не... для 4к нужны уже совсем не средние видеокарты, а там оперативки куда больше, чем 8 гб. А 8 гб — это именно столько, сколько сейчас ставят на средние ноуты.
Ну почему же? На той же 2070 super/2080/5700xt вполне можно играть в 4к, если поумерить свои аппетиты в плане настроек, а на них стоит по 8 Гб. Да и ноуты с 8 Гб у меня язык не поворачивается назвать средними — в моём таблете стоит 8 Гб, а ему летом уже будет 6 лет.
C>Ну хорошо. Допустим, нужно отсортировать массив строк разной длины. Как тут избавиться от случайного доступа к памяти?
в 12 ночи как-то не думается Но вроде как есть параллельные версии алгоритмов сортировки.
C>Похоже, что у Интел сейчас хватает куда более насущных проблем.
Ты видимо никогда не работал в больших конторах Там много всяких департаментов, и они занимаются разными проектами параллельно. Например, не так давно Интел вывел на рынок новую линейку FPGAшек Cyclone 10. Сейчас вот Agilex'ы вроде как начинают появляться, кстати, они производятся на 10 нм процессе
Здравствуйте, koandrew, Вы писали:
K>Да и ноуты с 8 Гб у меня язык не поворачивается назвать средними — в моём таблете стоит 8 Гб, а ему летом уже будет 6 лет.
Вполне средние, посмотри в любом магазине.
K>в 12 ночи как-то не думается Но вроде как есть параллельные версии алгоритмов сортировки.
Параллельные — да, но все равно используют разделяемую память.
K>Ты видимо никогда не работал в больших конторах Там много всяких департаментов, и они занимаются разными проектами параллельно. Например, не так давно Интел вывел на рынок новую линейку FPGAшек Cyclone 10. Сейчас вот Agilex'ы вроде как начинают появляться, кстати, они производятся на 10 нм процессе
Здравствуйте, Codealot, Вы писали:
C>Вполне средние, посмотри в любом магазине.
Смотрел. Типовой размер — 16 Гб, 8 только в девайсах начального уровня, ну или девайсах предыдущих поколений.
C>Параллельные — да, но все равно используют разделяемую память.
Ну дык на чипе FPGA есть некоторое количество очень быстрой SRAM, которую можно использовать как кэш. Тока вот её обычно не так уж и много
C>В настолько больших — точно нет.
Все эти разговоры про "Интел всё" — бред сивой кобылы. У них столько бабла, что они могут купить сто контор калибра АМД.
Здравствуйте, koandrew, Вы писали:
K>Смотрел. Типовой размер — 16 Гб, 8 только в девайсах начального уровня, ну или девайсах предыдущих поколений.
Наверно, те магазины в какой-то совсем другой реальности. Потому что в моей реальности, на девайсах начального уровня — 4 гб
K>Ну дык на чипе FPGA есть некоторое количество очень быстрой SRAM, которую можно использовать как кэш. Тока вот её обычно не так уж и много
Отож. В общем, к чему я это всё. 8 гб памяти — это совсем не так и много.
Здравствуйте, Codealot, Вы писали:
C>Наверно, те магазины в какой-то совсем другой реальности. Потому что в моей реальности, на девайсах начального уровня — 4 гб
Может наоборот — твоя реальность где-то в районе барахолки б/у?
C>Отож. В общем, к чему я это всё. 8 гб памяти — это совсем не так и много.
Я это к тому, что девплат, где стоит стока (или больше) памяти, почти нет, несмотря на то, что некоторые из этих плат стоят многие тысячи баксов, то есть не поставили её явно не ради того, чтобы сэъкономить 40-50$ на чипах памяти.
Здравствуйте, koandrew, Вы писали:
K>Может наоборот — твоя реальность где-то в районе барахолки б/у?
Типа вот этой барахолки? https://www.amazon.com/Newest-Flagship-HP-Pentium-Keyboard/dp/B07XF1JWBM/
K>Я это к тому, что девплат, где стоит стока (или больше) памяти, почти нет, несмотря на то, что некоторые из этих плат стоят многие тысячи баксов, то есть не поставили её явно не ради того, чтобы сэъкономить 40-50$ на чипах памяти.
Здравствуйте, Codealot, Вы писали:
C>Типа вот этой барахолки? https://www.amazon.com/Newest-Flagship-HP-Pentium-Keyboard/dp/B07XF1JWBM/
Ага. По ссылке — редкостное Г, самый лоу-энд.
C>Знаешь, что такое порочный круг в доказательстве?
Ага. А ещё у меня есть кое-какой опыт реализации алгоритмов на FPGA, и я вот что-то не припомню случая, когда мне бы не хватило памяти, а вот полосы пропускания в/из памяти мне не хватает регулярно. Потому я и раздумываю сделать платку с кучкой дешёвых чипов памяти, которые не дадут большой объём, но обеспечат широкую полосу пропускания. Что-нить типа четырёх гигабитных чипов DDR3 (64Мх16), которые в сумме дадут всего 512 МБайт объёма, но зато 8*2*400М ~ 6 ГБайт/с полосы. А поскольку всё это будет работать всего на 400 МГц, можно особо не заморачиваться по поводу разводки. При этом плату можно будет развести под восьмигигабитные модули, и, если вдруг когда-то понадобится большой объём, то поставив их, получится аж 4 ГБайт Правда, каждый такой чип стоит $26 (сейчас глянул на DK), в то время как гигабитный чип — всего $3.9. Считайте сами, как грится
Здравствуйте, koandrew, Вы писали:
K>Ага. По ссылке — редкостное Г, самый лоу-энд.
Дык я и написал — начальный уровень
K>Ага. А ещё у меня есть кое-какой опыт реализации алгоритмов на FPGA, и я вот что-то не припомню случая, когда мне бы не хватило памяти, а вот полосы пропускания в/из памяти мне не хватает регулярно.
Всё зависит от задачи. Есть и такие FPGA-платы, на которые ставят по 32 гига.
K>Правда, каждый такой чип стоит $26 (сейчас глянул на DK), в то время как гигабитный чип — всего $3.9. Считайте сами, как грится
Дурят нашего брата. 4 x $26 — за такие деньги или самую малость дороже можно купить DDR3 DIMM-ок уже на 32Gb.
Здравствуйте, Codealot, Вы писали:
C>Дык я и написал — начальный уровень
ХЗ, мне кажется там даже сама ОС будет работать через пень колоду.
C>Всё зависит от задачи. Есть и такие FPGA-платы, на которые ставят по 32 гига.
Не сомневаюсь, но я таких пока не встречал.
C>Дурят нашего брата. 4 x $26 — за такие деньги или самую малость дороже можно купить DDR3 DIMM-ок уже на 32Gb.
Ну дык купи катушку с 2000 чипами — тебе их тоже продадут в несколько раз дешевле Тока мне-то какой с этого толк, мне стока чипов не нужно, да и денег стока тратить жалко.
Никто тут никого не дурит — просто оптом всегда дешевле.
Здравствуйте, koandrew, Вы писали:
K>ХЗ, мне кажется там даже сама ОС будет работать через пень колоду.
На самообслуживание винды и не слишком тяжеловесные проги хватит. VPS-кам начального уровня так и вообще всего 512 мб дают
K>Не сомневаюсь, но я таких пока не встречал.
https://www.alpha-data.com/dcp/products.php?product=adm-pcie-8k5
K>Ну дык купи катушку с 2000 чипами — тебе их тоже продадут в несколько раз дешевле Тока мне-то какой с этого толк, мне стока чипов не нужно, да и денег стока тратить жалко. K>Никто тут никого не дурит — просто оптом всегда дешевле.
По твоей логике должно было быть наоборот.
Тока мне-то какой с этого толк, мне стока чипов не нужно, да и денег стока тратить жалко.