Объединять базы в единую централизованную систему это опасно и неправильно, любой безопасник скажет что безопаснее всего держать 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 и обрабатывает файлы только определенного размера и форматов. В таких вполне предсказуемых и прогнозируемых применениях бредом уже кажется динамический подход в котором процессор будет анализировать одно и то же месяцами и жечь электричество делая работу о которой никто не просил.
Хотелось бы конечно что бы в будущем эльбрусе было что то средненькое чтоб и так и немножко эдак тоже умело, например что бы команды подготовок не готовили переход как таковой а создавали стек вызовов/переходов, в котором простой как веник бранчпридиктор пометит переходы которые скорее всего не произойдут сверив с историей и начнет толкать в конвеер код который точно или почти точно произойдет. По умолчанию пусть будет считать что точно все произойдет.
Не нашел там сравнения с эльбрусами, как и адекватных тестов в целом.
https://www.7-cpu.com/ - вот здесь например 8 ядер 2Ггц МЦСТ-R проигрывают в два раза 8С. Но это в целом не важно, любой процессор мцст может максимум выдавать то что максимум может выдать инженеры мцст на данный момент, никакой рязани или интел-ксеон-платинум не будет просто от того что in-order vliw поменяют на out-of-order risc.
Но, что важно, прекрасно знают устройство и того и другого и делают осознанную ставку именно на e2k, полагаю потому что он банально интереснее. И пользователям и разработчикам, и с программной и с аппаратной части, там есть куда рости и огромное поле для фантазий и экспериментов. А спарк кроме военных не интересен никому, для него даже в современных браузерах поддержки нет.
Похоже то похоже, вот только KDE3 и её форк Trident написаны на Qt3 а в астре нет никаких библиотек Qt3, зато есть четвертые пятые.
Однако еще там был kPatience открученый от кде зависимостей, то есть у разработчиков как минимум есть опыт выдирания приложений из родных окружений, вполне возможно что и из третих кед приложения выдрали и переписали часть кода на Qt4/5
Мандатное разграничение прав доступа это не альтернативная система и не относящаяся к безопасности операционной системы вообще. Это особая ведомственная система в которой пользователь с правами ниже может писать в документ с правами выше, но не может его читать. И наоборот пользователь с повышенными правами не может читать и переписывать файлы доступные для менее привилегированных пользователей. В общем эта система придумана для документов (и не нами если вдруг кто-то захочет над ней посмеяться).
Что касается KDE3, то там своя проприетарная оболочка на Qt4 (сейчас наверное уже на Qt5). Как я понял уши у этой оболочки растут из МСВС (как и у самой астры в целом), там была тоже своя оболочка на Qt которая всеми ошибочно принималась за IceWM.
Разумеется там (в оболочке) наверняка сплошь ворованный код и написан студентами, но справедливости ради МСВС вообще от начала до конца была закрытая и получала обновления только на дисках, тут хоть закрытая только оболочка с приложениями. Будем надеяться что следующий заход этой организации, либо тех кто от них отпочкуется, будет уже полностью свободным.
Объединять базы в единую централизованную систему это опасно и неправильно, любой безопасник скажет что безопаснее всего держать 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 и обрабатывает файлы только определенного размера и форматов. В таких вполне предсказуемых и прогнозируемых применениях бредом уже кажется динамический подход в котором процессор будет анализировать одно и то же месяцами и жечь электричество делая работу о которой никто не просил.
Хотелось бы конечно что бы в будущем эльбрусе было что то средненькое чтоб и так и немножко эдак тоже умело, например что бы команды подготовок не готовили переход как таковой а создавали стек вызовов/переходов, в котором простой как веник бранчпридиктор пометит переходы которые скорее всего не произойдут сверив с историей и начнет толкать в конвеер код который точно или почти точно произойдет. По умолчанию пусть будет считать что точно все произойдет.
Ответ ниже (промахнулся)
Не нашел там сравнения с эльбрусами, как и адекватных тестов в целом.
https://www.7-cpu.com/ - вот здесь например 8 ядер 2Ггц МЦСТ-R проигрывают в два раза 8С. Но это в целом не важно, любой процессор мцст может максимум выдавать то что максимум может выдать инженеры мцст на данный момент, никакой рязани или интел-ксеон-платинум не будет просто от того что in-order vliw поменяют на out-of-order risc.
Но, что важно, прекрасно знают устройство и того и другого и делают осознанную ставку именно на e2k, полагаю потому что он банально интереснее. И пользователям и разработчикам, и с программной и с аппаратной части, там есть куда рости и огромное поле для фантазий и экспериментов. А спарк кроме военных не интересен никому, для него даже в современных браузерах поддержки нет.
Похоже то похоже, вот только KDE3 и её форк Trident написаны на Qt3 а в астре нет никаких библиотек Qt3, зато есть
четвертыепятые.Однако еще там был kPatience открученый от кде зависимостей, то есть у разработчиков как минимум есть опыт выдирания приложений из родных окружений, вполне возможно что и из третих кед приложения выдрали и переписали часть кода на Qt4/5
Мандатное разграничение прав доступа это не альтернативная система и не относящаяся к безопасности операционной системы вообще. Это особая ведомственная система в которой пользователь с правами ниже может писать в документ с правами выше, но не может его читать. И наоборот пользователь с повышенными правами не может читать и переписывать файлы доступные для менее привилегированных пользователей. В общем эта система придумана для документов (и не нами если вдруг кто-то захочет над ней посмеяться).
Что касается KDE3, то там своя проприетарная оболочка на Qt4 (сейчас наверное уже на Qt5). Как я понял уши у этой оболочки растут из МСВС (как и у самой астры в целом), там была тоже своя оболочка на Qt которая всеми ошибочно принималась за IceWM.
Разумеется там (в оболочке) наверняка сплошь ворованный код и написан студентами, но справедливости ради МСВС вообще от начала до конца была закрытая и получала обновления только на дисках, тут хоть закрытая только оболочка с приложениями. Будем надеяться что следующий заход этой организации, либо тех кто от них отпочкуется, будет уже полностью свободным.