Кстати, только меня название смущает? У меня первая ассоциация на слова "сервер" и "Гравитон" - семейство серверных ARM процессоров от Amazon. То ли ребята не в курсе, то ли сознательно путаницу наводят.
Кстати, возможен и промежуточный вариант для NUMA. Скажем, процессор (многоядерный, есно) плюс непосредственно окружающая его память обеспечивают аппаратное согласование кэшей, а между узлами NUMA такого согласования уже нет.
В общепринятой программной модели NUMA влияет только на производительность - обращение к "чужой" памяти дороже - но не на корректность, за когерентностью кешей следит железо и дополнительно в коде для корректности работы ничего писать не надо (для того, чтобы не проседала производительность - надо следить, к какой памяти идём).
Но проблемы когерентности вылезают и без NUMA, когда у нас просто на одном чипе несколько ядер со своими кешами первого/второго уровня.
наверняка связь ядро-контроллер памяти -- через AXI
Не уверен, там же отношение многие ко многим (скажем, 8 контроллеров памяти на 64 ядра без явной привязки) - в любом случае такие вещи не особо документируются.
Почему ж не помогут, если они вставляются там, где нужно?
Потому что они не об этом. Барьеры указывают о том, в каком порядке видны изменения разных ячеек памяти; то, что изменения разных значений в одной кеш линейке от разных агентов корректно накладываются, обеспечивается механизмом когерентности, который к модели памяти и необходимости использования барьеров ортогонален.
Вопрос для чего именно. Я то больше с "большими" процессорами работаю - там есть AMBA для связи с периферией (и вроде как AXI входит в AMBA), но работа с памятью идёт через интегрированные контроллеры, для связи между сокетами - отдельные каналы со своим протоколом.
И дело же не только в том, что торчит наружу - на телефонах, скажем, обычно процессорный чип один, но внутри него кучка разнородных ядер со своми кешами, и надо чтобы многопоточный софт корректно работал.
и есть предположение, что это для облегчения работы Линуха
Дело не только в операционке, без когерентности кешей обычный код написанный на C или Фортране (скажем, с распараллеливанием через OpenMP) не будет работать корректно, и барьеры не помогут.
Малейшие отличия по железу и это уже может привести к тому, что нужно ковырять прошивку или изучать, что там за потроха напихали.
Да, с этим согласен - сделать одну прошивку, которая при загрузке определит, какое железо есть на чипе и рядом и загрузит нужные драйвера, нельзя - нужно иметь спецификацию или вручную добытые знания при создании прошивки. И насколько понял, с ноутбуками на ARM (скажем, на модном Snapdragon X Elite) похожая ситуация, как то Linux туда с трудом залезает (хотя на армовых серверах всё нормально детектится с помощью UEFI/ACPI).
Но тем не менее взгромоздить свою операционку на мобильный девайс с ARM хоть и сложно, но реально.
Да, на про этом какого то серьёзного изменения при маркетинговом переименовании Атомов в Pentium N не было - постепенно разивалась от Bonnell до нынешнего Skymont. При этом на мой взгляд самым серьёзным был переход к Silvermont на самой заре развития Атомов (добавили OoO и выкинули SMT).
Так что с точки зрения ядер всё это эволюция одной линейки, которую обычно называют Атомами (скажем, здесь это всё в табличке "Intel Atom Roadmap"), на какой SoC потом идёт ядро и как это называет маркетинг - дело десятое.
GPRS WAP - по трафику (он занимал слоты только при передаче пакетов, не передаёшь данные - не занимаешь слот). А CSD, как и голос, при установке соединения выбирал конкретный частотный канал и слот и занимал его всё время.
Потому что работал с этими вещами не один десяток лет. Даже если ввести в теги по биту на каждый байт в кеш линии - получается, что при вытеснении грязной линии в память или следующий уровень надо записывать только отдельные байты, что сильно усложнит аппаратуру - и так сейчас не делают. Самое близкое, что видел - отдельные dirty bits на каждые 16 байт в кеш линии на одной GPUшке; на CPU только общий dirty bit на кеш линию.
один процессор работает только с одними байтами, а другой -- с другими байтами, т.е. имеющими разные адреса
Именно так. Но в кешах гранулярность хранения - кеш линия (обычно 64 байта) и просто так менять отдельные части нельзя (иначе у разных процессоров будут разные версии, при этом кеш линейка не отслеживает, какие байты в ней изменены). Если, скажем, разные процессоры меняют разные целые числа в одной линейке, в каждый момент должна быть одна валидная версия, содержащая изменения от всех процессоров. Для синхронизации есть протоколы когерентности, причём их использование необходимо независимо от модели памяти.
Так вопрос не в сериализации, а в постоянных обращениях разных процессоров к разным частям кеш линейки (с обновлениями) без прерываний и системных вызовов.
необходимостью иметь, фактически, связь процессоров (их кэшей, причём всех уровней) "все со всеми".
Это в любом случае нужно для когерентности кешей в любой модели памяти (записи в разные части кеш линеек должны корректно мёрджиться).
Так что, думаю, обработкой срочных запросов занимаются машины других архитектур, а на мэйнфреймах лежит, так сказать, бэкенд -- гигантские базы данных и всё такое, где важней общая производительность, а не время ответа.
Да, возможно так - основная база на мэйнфрейме, а какие-нибудь кеши в памяти и т.п. на машинках попроще.
у мэйнфреймов любое прерывание вызывает т.н. сериализацию ("временную отмену совмещений", как её переводили в советской литературе), в результате чего, по сути, кэш очищается
А как при этом с производительностью в клиент серверных приложениях, когда каждая микросекунда отклика на счету (например HFT), при этом данные для следующего запроса могут быть в кеше процессора? Или там есть технологии типа DPDK с возможностью обработать запрос из сети без прерываний и переключения в контекст ядра?
На Siemens C55 первое, что делалось после покупки - разлочивалась заливка мелодий и джавы с компа, после этого всё записывалось по кабелю. Не помню, чтобы с WAP страниц что-то скачивал, хотя по сайтам лазил.
Меня в КПДВ несколько смущает let primes... с последующим primes.append() Вроде let объявляет immutable переменную.
Амазоновский Гравитон доступен в их облаке с 2018го.
Кстати, только меня название смущает? У меня первая ассоциация на слова "сервер" и "Гравитон" - семейство серверных ARM процессоров от Amazon. То ли ребята не в курсе, то ли сознательно путаницу наводят.
В общепринятой программной модели NUMA влияет только на производительность - обращение к "чужой" памяти дороже - но не на корректность, за когерентностью кешей следит железо и дополнительно в коде для корректности работы ничего писать не надо (для того, чтобы не проседала производительность - надо следить, к какой памяти идём).
Но проблемы когерентности вылезают и без NUMA, когда у нас просто на одном чипе несколько ядер со своими кешами первого/второго уровня.
Странное округление с отбрасыванием трёх порядков.
Не уверен, там же отношение многие ко многим (скажем, 8 контроллеров памяти на 64 ядра без явной привязки) - в любом случае такие вещи не особо документируются.
Потому что они не об этом. Барьеры указывают о том, в каком порядке видны изменения разных ячеек памяти; то, что изменения разных значений в одной кеш линейке от разных агентов корректно накладываются, обеспечивается механизмом когерентности, который к модели памяти и необходимости использования барьеров ортогонален.
Вопрос для чего именно. Я то больше с "большими" процессорами работаю - там есть AMBA для связи с периферией (и вроде как AXI входит в AMBA), но работа с памятью идёт через интегрированные контроллеры, для связи между сокетами - отдельные каналы со своим протоколом.
И дело же не только в том, что торчит наружу - на телефонах, скажем, обычно процессорный чип один, но внутри него кучка разнородных ядер со своми кешами, и надо чтобы многопоточный софт корректно работал.
Дело не только в операционке, без когерентности кешей обычный код написанный на C или Фортране (скажем, с распараллеливанием через OpenMP) не будет работать корректно, и барьеры не помогут.
Возможно на микроконтроллерах делают по своему. На серверных ARM процессорах кеш линейки пишутся целиком.
С AXI шиной не работал. Она реально используется в многосокетных системах для обмена данными между сокетами или для работы с памятью?
Я здесь линейкой называю не внешний продукт, а дизайн микроархитектуры.
Да, с этим согласен - сделать одну прошивку, которая при загрузке определит, какое железо есть на чипе и рядом и загрузит нужные драйвера, нельзя - нужно иметь спецификацию или вручную добытые знания при создании прошивки. И насколько понял, с ноутбуками на ARM (скажем, на модном Snapdragon X Elite) похожая ситуация, как то Linux туда с трудом залезает (хотя на армовых серверах всё нормально детектится с помощью UEFI/ACPI).
Но тем не менее взгромоздить свою операционку на мобильный девайс с ARM хоть и сложно, но реально.
Да, на про этом какого то серьёзного изменения при маркетинговом переименовании Атомов в Pentium N не было - постепенно разивалась от Bonnell до нынешнего Skymont. При этом на мой взгляд самым серьёзным был переход к Silvermont на самой заре развития Атомов (добавили OoO и выкинули SMT).
Так что с точки зрения ядер всё это эволюция одной линейки, которую обычно называют Атомами (скажем, здесь это всё в табличке "Intel Atom Roadmap"), на какой SoC потом идёт ядро и как это называет маркетинг - дело десятое.
GPRS WAP - по трафику (он занимал слоты только при передаче пакетов, не передаёшь данные - не занимаешь слот). А CSD, как и голос, при установке соединения выбирал конкретный частотный канал и слот и занимал его всё время.
Если хочется, чтобы вывод был не на экран, а в стандартный вывод (с возможностью перенаправить в файл), нужен таки 21h
Потому что работал с этими вещами не один десяток лет. Даже если ввести в теги по биту на каждый байт в кеш линии - получается, что при вытеснении грязной линии в память или следующий уровень надо записывать только отдельные байты, что сильно усложнит аппаратуру - и так сейчас не делают. Самое близкое, что видел - отдельные dirty bits на каждые 16 байт в кеш линии на одной GPUшке; на CPU только общий dirty bit на кеш линию.
Именно так. Но в кешах гранулярность хранения - кеш линия (обычно 64 байта) и просто так менять отдельные части нельзя (иначе у разных процессоров будут разные версии, при этом кеш линейка не отслеживает, какие байты в ней изменены). Если, скажем, разные процессоры меняют разные целые числа в одной линейке, в каждый момент должна быть одна валидная версия, содержащая изменения от всех процессоров. Для синхронизации есть протоколы когерентности, причём их использование необходимо независимо от модели памяти.
Так вопрос не в сериализации, а в постоянных обращениях разных процессоров к разным частям кеш линейки (с обновлениями) без прерываний и системных вызовов.
Это в любом случае нужно для когерентности кешей в любой модели памяти (записи в разные части кеш линеек должны корректно мёрджиться).
Да, возможно так - основная база на мэйнфрейме, а какие-нибудь кеши в памяти и т.п. на машинках попроще.
А как при этом с производительностью в клиент серверных приложениях, когда каждая микросекунда отклика на счету (например HFT), при этом данные для следующего запроса могут быть в кеше процессора? Или там есть технологии типа DPDK с возможностью обработать запрос из сети без прерываний и переключения в контекст ядра?
На Siemens C55 первое, что делалось после покупки - разлочивалась заливка мелодий и джавы с компа, после этого всё записывалось по кабелю. Не помню, чтобы с WAP страниц что-то скачивал, хотя по сайтам лазил.
Раз уж выводите все символы через ah=02h, смысл в отдельной обработке доллара вроде как пропадает.