Предсказатель переходов появился в версии 7, причем не какой то гибридный а просто вхреначели предсказатель для непосредственных (неподготовленных) переходов, теперь там в системе команд добавились инструкции icall и ret и специальные регистры %cmp. Честно говоря не совсем понимаю как предполагается компилятору решать непосредственный вызов подставлять или подготовленный, наверное когда есть возможность подготовить будет подготавливать, а когда будут макароны из вызовов, будут подставляться непосредственные.
Возврат же всегда теперь будет предсказанным, хотя насколько я понимаю старая возможность выхода из процедуры осталась, что правильно потому что ret в стиле интел не позволяет вернутся по условию например из середины, нужно прыгать сперва в конец процедуры, после чего выходить, что было бы скорее даунгрейдом.
В 16с добавляли что то связанное со сбором информации для профилирования на лету, для ускорения языков с JIT. Сами по себе компилируемые на лету языки казалось бы должны идеально подходить для VLIW, ведь у них есть вся рантайм информация которая собирается в процессе исполнения, но вся малина портится тем что у JIT нет времени на анализ всего кода и долгую компиляцию, а без этого широкие команды плотно не набить.
Сбор некоторой информации в рантайме, как я понимаю, позволяет дать больше возможностей оптимизирующему jit компилятору. Либо возможно речь вообще о том что бы вызывать родной оптимизатор штатного компилятора и что бы он по скорости укладывался в рамки jit.
ARM в свое время и вытеснил MIPS тем что предложил производителям Thumb, VF4, NEON и все расширения отдельно. Сейчас реинкарнация MIPS (RISC-V) пытается создать аналогичное предложение. Так что лучше векторизуйте код под ускорители видео (если это конечно возможно) они то точно везде будут.
Заказывать инженерные образцы и штучные чипы для каких нибудь экспериментальных изделий на серийных зарубежных фабриках очень неудобно, во вторых накладно и небезопасно с точки зрения банальной тайны коммерческой и государственной.
Своя фабрика с современными техпроцессом так и так нужна. Так же такая фабрика нужна как резерв на случай перегруженности мировой фабрики, когда цена на чипы настолько поднимается что даже у своей заказывать становится рентабельно. Хуже дифицита ничего нет, из за него все развитие встает.
Менее известно (я только сегодня прочитал), что в конце 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 ) в Си или плюсах каждый такой объект надо руками удалять, тогда как в джаве их сборщик мусора сам удаляет если они больше ниоткуда не видны. А обычные стековые объекты самоуничтожаются при выходе вместе с куском стека в котором бы.
Не знаю чем вы слушали но Трушкин как раз это и сказал что сделали публичный репозиторий куда можно слать патчи git.openelbrus.ru
У интела и асуса тоже нельзя купить напрямую их изделия. никакие военные тут разумеется непричем. Нужен розничный посредник типа DNS.
для этого придется писать на си.
Нориман Осуждаев, очень приятно.
"Нормальных" это каких? Чем эльбрус ненормален и какое конкретное место надо исправить.
Предсказатель переходов появился в версии 7, причем не какой то гибридный а просто вхреначели предсказатель для непосредственных (неподготовленных) переходов, теперь там в системе команд добавились инструкции icall и ret и специальные регистры %cmp. Честно говоря не совсем понимаю как предполагается компилятору решать непосредственный вызов подставлять или подготовленный, наверное когда есть возможность подготовить будет подготавливать, а когда будут макароны из вызовов, будут подставляться непосредственные.
Возврат же всегда теперь будет предсказанным, хотя насколько я понимаю старая возможность выхода из процедуры осталась, что правильно потому что ret в стиле интел не позволяет вернутся по условию например из середины, нужно прыгать сперва в конец процедуры, после чего выходить, что было бы скорее даунгрейдом.
В 16с добавляли что то связанное со сбором информации для профилирования на лету, для ускорения языков с JIT. Сами по себе компилируемые на лету языки казалось бы должны идеально подходить для VLIW, ведь у них есть вся рантайм информация которая собирается в процессе исполнения, но вся малина портится тем что у JIT нет времени на анализ всего кода и долгую компиляцию, а без этого широкие команды плотно не набить.
Сбор некоторой информации в рантайме, как я понимаю, позволяет дать больше возможностей оптимизирующему jit компилятору. Либо возможно речь вообще о том что бы вызывать родной оптимизатор штатного компилятора и что бы он по скорости укладывался в рамки jit.
ARM в свое время и вытеснил MIPS тем что предложил производителям Thumb, VF4, NEON и все расширения отдельно. Сейчас реинкарнация MIPS (RISC-V) пытается создать аналогичное предложение. Так что лучше векторизуйте код под ускорители видео (если это конечно возможно) они то точно везде будут.
Заказывать инженерные образцы и штучные чипы для каких нибудь экспериментальных изделий на серийных зарубежных фабриках очень неудобно, во вторых накладно и небезопасно с точки зрения банальной тайны коммерческой и государственной.
Своя фабрика с современными техпроцессом так и так нужна. Так же такая фабрика нужна как резерв на случай перегруженности мировой фабрики, когда цена на чипы настолько поднимается что даже у своей заказывать становится рентабельно. Хуже дифицита ничего нет, из за него все развитие встает.
Ну во первых проект "Прорыв" действительно прорывной если у него все получится, то все проблемы атомной энергетики можно считать что будут решены, ирония тут неуместна.
Во вторых надо было два сервера купили два сервера, в чем проблема? Атомная станция это не интернет провайдер или онлайн сервис, они берут для каких то своих нужд, банально запись с камер видеонаблюдений хранить например. Про производительность "чуть лучше" атома даже комментировать не буду это чистое вранье.
Глобальное изменение климата.
Ну и думаю климат тут совершенно не причем, просто у кого-то обычное весеннее обострение.
Все так. Вот бы кто то написал статью как все таки готовить правильно подкачку данных в эльбрусе, можно ли данные из файла загрузить с выравниванием. Что делать когда структура не влазит в битность а немножко больше или немножко меньше. В общем вопросов по работе с данными масса там.
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 билтинами