Заказывать инженерные образцы и штучные чипы для каких нибудь экспериментальных изделий на серийных зарубежных фабриках очень неудобно, во вторых накладно и небезопасно с точки зрения банальной тайны коммерческой и государственной.
Своя фабрика с современными техпроцессом так и так нужна. Так же такая фабрика нужна как резерв на случай перегруженности мировой фабрики, когда цена на чипы настолько поднимается что даже у своей заказывать становится рентабельно. Хуже дифицита ничего нет, из за него все развитие встает.
Менее известно (я только сегодня прочитал), что в конце 2022 года случился полный прорыв – откуда то доставили и даже поставили ЦЕЛЫХ 2 (ДЖВА) сервера на «Эльбрус-16С» (1891ВМ038)
Интересно, что предполагается прорвать двумя серверами с производительностью чуть лучше Intel Atom с процессорами с TSMC? Даже бюджет проекта не прорвать.
Ну во первых проект "Прорыв" действительно прорывной если у него все получится, то все проблемы атомной энергетики можно считать что будут решены, ирония тут неуместна.
Во вторых надо было два сервера купили два сервера, в чем проблема? Атомная станция это не интернет провайдер или онлайн сервис, они берут для каких то своих нужд, банально запись с камер видеонаблюдений хранить например. Про производительность "чуть лучше" атома даже комментировать не буду это чистое вранье.
Глобальное потепление, ничего не поделать.
Глобальное изменение климата.
Ну и думаю климат тут совершенно не причем, просто у кого-то обычное весеннее обострение.
Все так. Вот бы кто то написал статью как все таки готовить правильно подкачку данных в эльбрусе, можно ли данные из файла загрузить с выравниванием. Что делать когда структура не влазит в битность а немножко больше или немножко меньше. В общем вопросов по работе с данными масса там.
Объединять базы в единую централизованную систему это опасно и неправильно, любой безопасник скажет что безопаснее всего держать 100500 рассредоточенных баз различной степени дырявости под контролем разных региональных чиновников различной степени корыстности и коррупционности..
Не важно какой у вас там процессор и какие в нем аппаратные дыры либо дыры в микрокоде и не важно какие дыры есть в гипервизоре чипсета.
Важно позолотить ручку, получить ключик и тогда безопасность в доме будет.
Если "мувает" тот кто вызывает https://godbolt.org/z/Pj3aGn1f6 тогда мув внутри конструктора просто не нужен, о чем вообщем то и начался разговор. А если предполагается реализация поведения как у раста, когда при передаче массива куда либо, он исчезает из текущего контекста, то тогда надо проставлять ссылку.
Здесь же мы имеем "пример использования мува" который полагается на то, что ему мувнут данные где то там на стеке выше, а у него мув просто так для галочки. Причем этот мув для галочки еще и вызывает дополнительные накладные расходы без пользы и смысла.
Program returned: 0
Program stdout
class ctx students: 3
main ctx students: 3
А вызывается копирование вектора при передаче в конструктор, что логично. И только когда мы в конструкторе указываем что вектор принимаем ссылкой: https://godbolt.org/z/d4T8b1W45
Program returned: 0
Program stdout
class ctx students: 3
main ctx students: 0
Происходит перемещение данных вместо копии для чего и был придуман std::move.
Ваши примеры с пустыми классами да еще с -O3 непонятно вообще о чем и про что.
Я и написал что минимум, ранние плюсы просто не застал.
не надо, прочитайте статью
В статье не дано никаких разъяснений. Открыл документацию по плюсам:
std::string str = "Salut";
std::vector<std::string> v;
v.push_back(str);
std::cout << "After copy, str is " << std::quoted(str) << '\n';
v.push_back(std::move(str));
std::cout << "After move, str is " << std::quoted(str) << '\n';
std::cout << "The contents of the vector are { " << std::quoted(v[0])
<< ", " << std::quoted(v[1]) << " }\n";
/* After copy, str is "Salut"
After move, str is ""
The contents of the vector are { "Salut", "Salut" }*/
То есть оно просто вместо копирования меняет данные на стеке, полезно если структуру или вектор заполняли только для того что бы передать объекту и забыть про них, но это точно никакого отношения к долгоживущим объектам и их очищению не имеет. Кроме того в примере из статьи при вызове конструктора данные сначала копируются в его контекст (так как как я и написал не проставлена ссылка), а потом героически переносятся в объект.
Если коротко подытожить, то ответ на вопрос почему плюсы не устаревают примерно таков:
Потому что на них тоже вполне можно говнокодить!
Особенно ужаснул пример с вектором который куда то мувается при создании класса.
Что это почему это... я ничего не понимаю.
Есть же с 11х плюсов как минимум синтаксис для приема аргументов в виде ссылок:
Schoolmates(std::vector<Students> &students) {}
То что в языках типа джаваскрипта все объекты по дефолту передаются в виде ссылок то это не потому что там сборщик мусора есть, а в плюсах нет. А потому что в плюсах есть ссылки и поинтеры, а в джаваскриптах их нет. В php например ссылки есть и функции/методу можно передать в виде ссылки не только массив / объект, но и простую переменную по которой функция будет записывать/читать значения на стеке выше. Не смотря на то что это скриптовый язык со сборщиком мусора. Вообще сборщик мусора это только про долгоживущие объекты т.е. созданные через new (или malloc ) в Си или плюсах каждый такой объект надо руками удалять, тогда как в джаве их сборщик мусора сам удаляет если они больше ниоткуда не видны. А обычные стековые объекты самоуничтожаются при выходе вместе с куском стека в котором бы.
Тут вообще наверное ускорения ждать не стоит так как у эльбруса только два целочисленных устройства умеют в вектора 80-128 бит, ему надо наоборот все в вещественное переводить и в них считать так как все 6 вещественных юнитов их поддерживают. Серьезно, лучше уж просто грамотно на плюсах написать и довериться компилятору, чем делать вот такие ручные оптимизации.
Рязань производится на том же самом TSMC. А в ближайшем десятилетии возможно сможет производится в одном из штатов, так как у "цивилизации" если чего-то нет, то они не жалеют времени и денег на то чтоб у них это появилось чтоб они ни от кого не зависели. Пример - та же космонавтика где у них практически все свое появилось уже и мы им будем скоро не нужны.
Я это все к тому что быть с "цивилизацией" можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой - кофе приносить, туалеты на их станции чинить, соперничать с другим обслуживающим персооналом за право быть к господину ближе чем другие.
Причем большая часть элиты нашей страны строго ориентировалась на второе все время своей власти, но барину нравятся только маленькие и слабенькие, большие могучие коровы ему не нужны.
Для эльбруса недостаточно просто упаковать операции в одну avx/sse инструкцию. Ему надо полностью оптимизировать функции/процедуры на которые приходится большая часть времени работы. Оптимизации заключаются в том что надо подсказать компилятору вещи, которые не очевидны из кода - типичное количество итераций в том или ином цикле, могут ли пересекаться указатели, выравнены ли данные итп.
В общем надо уметь читать ассемблер е2к, смотреть что генерирует компилятор и все ли возможности он в том или ином случае использовал.
Причем здесь отдельные алгоритмы. Я говорил о задачах.
Когда собирают программы под десктоп, никто точно не знает с чем и как будет работать условный пользователь. Поэтому программы собираются с максимальным функционалом, а это ветвления и куча подключаемых библиотек, которые возможно не нужны вообще, но из которых эльбрус будет дергать функции в кэш и подготавливать в конвеер постоянно, просто потому что эльбрус так работает и на данный момент не умеет подстраивать поток исполнения.
Сервер - это совсем другое дело. Там нет пользователя запускающего разные программы под свои сегодняшние задачи, там настраивается и поднимается (условно) одно приложение работающее с заранее предорприделенным типом данных - картинками jpg и png размером от 10x10 до 5000x5000 пикселей, простые текстовые данные до 100000 символов или json сообщения. И запускается оно не пару раз в день а один раз и надолго. Здесь можно и нужно заморочится с более тонкой конфигурацией софта перед запуском в продакшн.
Что до СУБД, то запросы как правило тоже делаются из приложения, а пользователю если и предоставляется какой то доступ к ней, то только через API, напрямую какие попало запросы ей не посылаются.
Это так, но это ситуация из мира десктопов к которым эльбрус и правда не готов, но например на сервере где одно и то же нагруженное приложение крутится 24/7 и обрабатывает файлы только определенного размера и форматов. В таких вполне предсказуемых и прогнозируемых применениях бредом уже кажется динамический подход в котором процессор будет анализировать одно и то же месяцами и жечь электричество делая работу о которой никто не просил.
Хотелось бы конечно что бы в будущем эльбрусе было что то средненькое чтоб и так и немножко эдак тоже умело, например что бы команды подготовок не готовили переход как таковой а создавали стек вызовов/переходов, в котором простой как веник бранчпридиктор пометит переходы которые скорее всего не произойдут сверив с историей и начнет толкать в конвеер код который точно или почти точно произойдет. По умолчанию пусть будет считать что точно все произойдет.
Заказывать инженерные образцы и штучные чипы для каких нибудь экспериментальных изделий на серийных зарубежных фабриках очень неудобно, во вторых накладно и небезопасно с точки зрения банальной тайны коммерческой и государственной.
Своя фабрика с современными техпроцессом так и так нужна. Так же такая фабрика нужна как резерв на случай перегруженности мировой фабрики, когда цена на чипы настолько поднимается что даже у своей заказывать становится рентабельно. Хуже дифицита ничего нет, из за него все развитие встает.
Ну во первых проект "Прорыв" действительно прорывной если у него все получится, то все проблемы атомной энергетики можно считать что будут решены, ирония тут неуместна.
Во вторых надо было два сервера купили два сервера, в чем проблема? Атомная станция это не интернет провайдер или онлайн сервис, они берут для каких то своих нужд, банально запись с камер видеонаблюдений хранить например. Про производительность "чуть лучше" атома даже комментировать не буду это чистое вранье.
Глобальное изменение климата.
Ну и думаю климат тут совершенно не причем, просто у кого-то обычное весеннее обострение.
Все так. Вот бы кто то написал статью как все таки готовить правильно подкачку данных в эльбрусе, можно ли данные из файла загрузить с выравниванием. Что делать когда структура не влазит в битность а немножко больше или немножко меньше. В общем вопросов по работе с данными масса там.
meson+ninja, не? mpv их использует например.
Объединять базы в единую централизованную систему это опасно и неправильно, любой безопасник скажет что безопаснее всего держать 100500 рассредоточенных баз различной степени дырявости под контролем разных региональных чиновников различной степени корыстности и коррупционности..
Не важно какой у вас там процессор и какие в нем аппаратные дыры либо дыры в микрокоде и не важно какие дыры есть в гипервизоре чипсета.
Важно позолотить ручку, получить ключик и тогда безопасность в доме будет.
Продались росатому, а росатом не под санкциями.
Вечерние новости: грабитель вскрыл банкомат что бы завладеть материнской платой на Эльбрусе
Если "мувает" тот кто вызывает https://godbolt.org/z/Pj3aGn1f6
тогда мув внутри конструктора просто не нужен, о чем вообщем то и начался разговор. А если предполагается реализация поведения как у раста, когда при передаче массива куда либо, он исчезает из текущего контекста, то тогда надо проставлять ссылку.
Здесь же мы имеем "пример использования мува" который полагается на то, что ему мувнут данные где то там на стеке выше, а у него мув просто так для галочки. Причем этот мув для галочки еще и вызывает дополнительные накладные расходы без пользы и смысла.
В статье std::move() вызывается в контексте конструктора, а не в контексте того, где его (конструктор) вызывают.
Манипуляция не пройдет.
Где предполагает? Классы из библиотеки libstdc++ это база языка? Не знал.
В "исходном примере" ничего никуда не перемещается:
https://godbolt.org/z/jd5vjWv9f
А вызывается копирование вектора при передаче в конструктор, что логично. И только когда мы в конструкторе указываем что вектор принимаем ссылкой:
https://godbolt.org/z/d4T8b1W45
Происходит перемещение данных вместо копии для чего и был придуман std::move.
Ваши примеры с пустыми классами да еще с -O3 непонятно вообще о чем и про что.
Я и написал что минимум, ранние плюсы просто не застал.
В статье не дано никаких разъяснений. Открыл документацию по плюсам:
То есть оно просто вместо копирования меняет данные на стеке, полезно если структуру или вектор заполняли только для того что бы передать объекту и забыть про них, но это точно никакого отношения к долгоживущим объектам и их очищению не имеет.
Кроме того в примере из статьи при вызове конструктора данные сначала копируются в его контекст (так как как я и написал не проставлена ссылка), а потом героически переносятся в объект.
Если коротко подытожить, то ответ на вопрос почему плюсы не устаревают примерно таков:
Особенно ужаснул пример с вектором который куда то мувается при создании класса.
Что это почему это... я ничего не понимаю.
Есть же с 11х плюсов как минимум синтаксис для приема аргументов в виде ссылок:
Schoolmates(std::vector<Students> &students) {}То что в языках типа джаваскрипта все объекты по дефолту передаются в виде ссылок то это не потому что там сборщик мусора есть, а в плюсах нет. А потому что в плюсах есть ссылки и поинтеры, а в джаваскриптах их нет. В php например ссылки есть и функции/методу можно передать в виде ссылки не только массив / объект, но и простую переменную по которой функция будет записывать/читать значения на стеке выше. Не смотря на то что это скриптовый язык со сборщиком мусора. Вообще сборщик мусора это только про долгоживущие объекты т.е. созданные через new (или malloc ) в Си или плюсах каждый такой объект надо руками удалять, тогда как в джаве их сборщик мусора сам удаляет если они больше ниоткуда не видны. А обычные стековые объекты самоуничтожаются при выходе вместе с куском стека в котором бы.
Под x86 там все уже оптимизировано, там такие же вставки c AVX/AVX2 билтинами
Там довольно заурядный цикл я думал компилятор его без труда автовекторизует и он его таки векторизовал, но уже без буфера подкачки.
Тут вообще наверное ускорения ждать не стоит так как у эльбруса только два целочисленных устройства умеют в вектора 80-128 бит, ему надо наоборот все в вещественное переводить и в них считать так как все 6 вещественных юнитов их поддерживают.
Серьезно, лучше уж просто грамотно на плюсах написать и довериться компилятору, чем делать вот такие ручные оптимизации.
Классная статья в стиле пояснения разработчика к релизу, вот только жаль что самого релиза нигде скачать нельзя чтоб ознакомится что это такое.
Рязань производится на том же самом TSMC.
А в ближайшем десятилетии возможно сможет производится в одном из штатов, так как у "цивилизации" если чего-то нет, то они не жалеют времени и денег на то чтоб у них это появилось чтоб они ни от кого не зависели. Пример - та же космонавтика где у них практически все свое появилось уже и мы им будем скоро не нужны.
Я это все к тому что быть с "цивилизацией" можно по разному, можно учится у них и делать как они (то есть стараться быть как бы ментально на одном уровне с ними), а можно быть при них служанкой - кофе приносить, туалеты на их станции чинить, соперничать с другим обслуживающим персооналом за право быть к господину ближе чем другие.
Причем большая часть элиты нашей страны строго ориентировалась на второе все время своей власти, но барину нравятся только маленькие и слабенькие, большие могучие коровы ему не нужны.
Для эльбруса недостаточно просто упаковать операции в одну avx/sse инструкцию.
Ему надо полностью оптимизировать функции/процедуры на которые приходится большая часть времени работы. Оптимизации заключаются в том что надо подсказать компилятору вещи, которые не очевидны из кода - типичное количество итераций в том или ином цикле, могут ли пересекаться указатели, выравнены ли данные итп.
В общем надо уметь читать ассемблер е2к, смотреть что генерирует компилятор и все ли возможности он в том или ином случае использовал.
Причем здесь отдельные алгоритмы. Я говорил о задачах.
Когда собирают программы под десктоп, никто точно не знает с чем и как будет работать условный пользователь. Поэтому программы собираются с максимальным функционалом, а это ветвления и куча подключаемых библиотек, которые возможно не нужны вообще, но из которых эльбрус будет дергать функции в кэш и подготавливать в конвеер постоянно, просто потому что эльбрус так работает и на данный момент не умеет подстраивать поток исполнения.
Сервер - это совсем другое дело. Там нет пользователя запускающего разные программы под свои сегодняшние задачи, там настраивается и поднимается (условно) одно приложение работающее с заранее предорприделенным типом данных - картинками jpg и png размером от 10x10 до 5000x5000 пикселей, простые текстовые данные до 100000 символов или json сообщения. И запускается оно не пару раз в день а один раз и надолго. Здесь можно и нужно заморочится с более тонкой конфигурацией софта перед запуском в продакшн.
Что до СУБД, то запросы как правило тоже делаются из приложения, а пользователю если и предоставляется какой то доступ к ней, то только через API, напрямую какие попало запросы ей не посылаются.
Это так, но это ситуация из мира десктопов к которым эльбрус и правда не готов, но например на сервере где одно и то же нагруженное приложение крутится 24/7 и обрабатывает файлы только определенного размера и форматов. В таких вполне предсказуемых и прогнозируемых применениях бредом уже кажется динамический подход в котором процессор будет анализировать одно и то же месяцами и жечь электричество делая работу о которой никто не просил.
Хотелось бы конечно что бы в будущем эльбрусе было что то средненькое чтоб и так и немножко эдак тоже умело, например что бы команды подготовок не готовили переход как таковой а создавали стек вызовов/переходов, в котором простой как веник бранчпридиктор пометит переходы которые скорее всего не произойдут сверив с историей и начнет толкать в конвеер код который точно или почти точно произойдет. По умолчанию пусть будет считать что точно все произойдет.