Хомячки опять негодуют в карму! Ножкой топ - не пущать, такскаать, нельзя такие комбинации букв слагать, наверное. А как там было?... саморегуляция, но от хомячков ничего не устоит! Короче, спать не могу ;)
Тем не менее, занимательно что аффтар сумел убедить аудиторию что он (внезапно) прям-таки в теме проблематики, светоч в перспективах развития "микроархитектур", а его мнение авторитетно и достойно внимания ;) Не доронин, но явно с задатками для "хабра-пипл хавает". Хорошо что ничего, по большому счету, от этого НЕ зависит = бальзам.
Сам-то кто? Ой, бросьте - уже 20 лет как читать разучился и мимо-крокодил.
качественно и конструктивно разобрать недостатки, как не люди, хорошо и глубоко знакомые с предметом обсуждения
Это сарказм такой про автора статьи?
Ходить на работу 10 в организацию, заниматься бинарной трансляцией, не хватать звезд с неба, выгореть и разочароваться - это примерно совсем не то, что вы подразумеваете.
Каждый волен заблуждаться, в том числе и автор. Тем не менее, автору хотелось-бы посоветовать: 1. Как можно меньше уподобляться эмигрантам/ренегатам ругая "Alma Mater". 2. Тщательнее и глубже изучить состояние дел (в том числе проблемы и недостатки) других "правильных" (микро)архитектур, чтобы избежать использования ошибочных доводов.
Как именно у "куратора" не знаю, но на всякий для полноты картины:
В подобных случаях/задачах важно экономить memory bandwidth.
Например, если вы читаете/пишете одну кэш-линию для одного счетчика-на-пакет, то примерно успеваете, а если две то уже никак.
Поэтому, какие-либо варианты хеш-таблиц часто не подходят.
С другой стороны, "моррисоны", "скетчи" и т.п. можно реализовать через примитивную арифметику и табличные функции. А сами счетчики держать в не-кэшируемой памяти, заранее посчитав достаточность полосы для худшего случая.
Короче, в результате можно посчитать/доказать, что ваш софт полностью обработает корректно весь/любой трафик через входящие N×10G (но отдельная тема чтобы эти N×10G рационально приземлить на другие numa-ноды и т.д.).
Задачи всё-таки немного разные, но главное что "пакеты" считать им нужно на нагруженных 10G интерфейсаx.
Соответственно, дерево не подходит, ибо уловные переходы при поиске и перебалансировка.
Возможно вы и правы насчет причин закрытия технических особенностей Эльбруса, так как сложно судить о том, чего не знаешь ;-)
В открытом доступе нет детальных спецификаций/описаний, включая полную систему команд, кодирования слогов VLIW и т.п. Но есть информация, которой более чем достаточно для подобных суждений.
Вот только OpenSource взаимодействие с community касается исключительно версия ОС Эльбрус для x86-64 платформы, которая размещена для свободного скачивания, а никак не версии для процессоров Эльбрус.
imho тут какая-то нездоровая накрутка происходит, если не передергивание.
ОС Эльбрус для x86 — это оксюморон, пригодный только для ознакомления с ограничениями основной версии. Проще говоря, из всего существующего OpenSource-софта только некоторое подмножество собирается (нет многих пакетов, тормозят и/или глючат, только старые версии, с плохими патчами и т.п.) для E2K, включая ядра Linux, и вот чтобы это прочувствовать/примерить без приобретения нативного железа эта сборка и нужна.
Поэтому на месте МЦСТ я бы просто вырезал условным sed-ом всё под #ifdef __e2k__ и отдавал этот tarball "как есть" всем желающим, тем самым закрыв все вопросы с GPL и т.п.
Т.е. с одной стороны, мне кажется что нет никакого смысла просить исходники "ОС Эльбрус для x86", кроме как "из принципа".
С другой стороны, мне не понятно почему МЦСТ также "из принципа" не выдаст все необходимые (очищенные) исходники и скрипты сборки именно этой редакции/версии, тем самым закрыв все вопросы с упреками в нарушении GPL.
Не чистый, но всё-таки MIPS. Ситуация принципиально разная, если разобраться.
Loongson вырос из MIPS, с покупкой соответствующих лицензий и консультаций у MIPS/Imagination.
Соответственно, там исходно был открытый набор инструкций и были доступны открытые компиляторы.
А добавили новые инструкции и удалили устаревшие относительно недавно, и как-либо их "секретить" не было никакого смысла.
С Эльбрусами ситуация другая, точнее принципиально иная если учесть особенности архитектуры. Не возьмусь судить насколько оправдано (не)офишировать детальный формат кодирования инструкций, но фишка VLIW в том, что формат команд и слогов во-многом определяет возможности и внутреннюю архитектуру процессора. На это накладываются исторические требования заказчика/регулятора и необходимость ресурсов на документирование (до уровня публичного использования) и дальнейшую поддержку всего этого хозяйства (включая OpenSource и взаимодействие с community).
++ Ну и в целом, система команд Эльбруса намного сложнее в сравнении с Loongson. По MIPS уже есть масса информации, книг и других ресурсов — ознакомившись или имея опыт можно понять отличия Loongson за один рабочий день. А с Эльбрусами всё ровно наоборот.
Хомячки опять негодуют в карму!
Ножкой топ - не пущать, такскаать, нельзя такие комбинации букв слагать, наверное.
А как там было?... саморегуляция, но от хомячков ничего не устоит!
Короче, спать не могу ;)
Тем не менее, занимательно что аффтар сумел убедить аудиторию что он (внезапно) прям-таки в теме проблематики, светоч в перспективах развития "микроархитектур", а его мнение авторитетно и достойно внимания ;)
Не доронин, но явно с задатками для "хабра-пипл хавает".
Хорошо что ничего, по большому счету, от этого НЕ зависит = бальзам.
Сам-то кто? Ой, бросьте - уже 20 лет как читать разучился и мимо-крокодил.
Вы остыньте, а уж потом переходите на измерение корон.
"Уважаемый", с такими "позывами к дискуссии" вам - к малахову.
Но таки в чем-то соглашусь - и первого (моего) комментария было слишком много как для самой статьи, так и для комментариев/ответов.
Рекомендую не-предвзято перечитать мой первый комментарий.
Это сарказм такой про автора статьи?
Ходить на работу 10 в организацию, заниматься бинарной трансляцией, не хватать звезд с неба, выгореть и разочароваться - это примерно совсем не то, что вы подразумеваете.
Каждый волен заблуждаться, в том числе и автор. Тем не менее, автору хотелось-бы посоветовать:
1. Как можно меньше уподобляться эмигрантам/ренегатам ругая "Alma Mater".
2. Тщательнее и глубже изучить состояние дел (в том числе проблемы и недостатки) других "правильных" (микро)архитектур, чтобы избежать использования ошибочных доводов.
Постараюсь помочь/сделать, если к концу лета сами не справитесь.
А что если вынести журналы вашего "тестового и не самого быстрого кластера ceph" на NVRAM NVMe или PMEM/NVDIMMы ?
Хмм, наоборот — чем хуже "cache frendly", тем больше обмен с памятью и ожидание данных, тем сильнее заметен выигрыш от быстрой памяти.
А в РФ где и когда можно будет купить?
Хотя-бы парочку по 128 Гб.
+1
Как именно у "куратора" не знаю, но на всякий для полноты картины:
В подобных случаях/задачах важно экономить memory bandwidth.
Например, если вы читаете/пишете одну кэш-линию для одного счетчика-на-пакет, то примерно успеваете, а если две то уже никак.
Поэтому, какие-либо варианты хеш-таблиц часто не подходят.
С другой стороны, "моррисоны", "скетчи" и т.п. можно реализовать через примитивную арифметику и табличные функции. А сами счетчики держать в не-кэшируемой памяти, заранее посчитав достаточность полосы для худшего случая.
Короче, в результате можно посчитать/доказать, что ваш софт полностью обработает корректно весь/любой трафик через входящие N×10G (но отдельная тема чтобы эти N×10G рационально приземлить на другие numa-ноды и т.д.).
Задачи всё-таки немного разные, но главное что "пакеты" считать им нужно на нагруженных 10G интерфейсаx.
Соответственно, дерево не подходит, ибо уловные переходы при поиске и перебалансировка.
от
rand()и%тоже несложно избавиться ;)ниачом
Чудо маркетинга "как сделать что-то из ничего".
Причем чудо двойное, как в исполнении штеуда, так и селектела ;)
В открытом доступе нет детальных спецификаций/описаний, включая полную систему команд, кодирования слогов VLIW и т.п. Но есть информация, которой более чем достаточно для подобных суждений.
imho тут какая-то нездоровая накрутка происходит, если не передергивание.
ОС Эльбрус для x86 — это оксюморон, пригодный только для ознакомления с ограничениями основной версии. Проще говоря, из всего существующего OpenSource-софта только некоторое подмножество собирается (нет многих пакетов, тормозят и/или глючат, только старые версии, с плохими патчами и т.п.) для E2K, включая ядра Linux, и вот чтобы это прочувствовать/примерить без приобретения нативного железа эта сборка и нужна.
Поэтому на месте МЦСТ я бы просто вырезал условным
sed-ом всё под#ifdef __e2k__и отдавал этот tarball "как есть" всем желающим, тем самым закрыв все вопросы с GPL и т.п.Т.е. с одной стороны, мне кажется что нет никакого смысла просить исходники "ОС Эльбрус для x86", кроме как "из принципа".
С другой стороны, мне не понятно почему МЦСТ также "из принципа" не выдаст все необходимые (очищенные) исходники и скрипты сборки именно этой редакции/версии, тем самым закрыв все вопросы с упреками в нарушении GPL.
Не чистый, но всё-таки MIPS. Ситуация принципиально разная, если разобраться.
Loongson вырос из MIPS, с покупкой соответствующих лицензий и консультаций у MIPS/Imagination.
Соответственно, там исходно был открытый набор инструкций и были доступны открытые компиляторы.
А добавили новые инструкции и удалили устаревшие относительно недавно, и как-либо их "секретить" не было никакого смысла.
С Эльбрусами ситуация другая, точнее принципиально иная если учесть особенности архитектуры. Не возьмусь судить насколько оправдано (не)офишировать детальный формат кодирования инструкций, но фишка VLIW в том, что формат команд и слогов во-многом определяет возможности и внутреннюю архитектуру процессора. На это накладываются исторические требования заказчика/регулятора и необходимость ресурсов на документирование (до уровня публичного использования) и дальнейшую поддержку всего этого хозяйства (включая OpenSource и взаимодействие с community).
++ Ну и в целом, система команд Эльбруса намного сложнее в сравнении с Loongson. По MIPS уже есть масса информации, книг и других ресурсов — ознакомившись или имея опыт можно понять отличия Loongson за один рабочий день. А с Эльбрусами всё ровно наоборот.
https://habr.com/ru/company/pt/blog/552824/
Плюс сугубо моё частное мнение.