Далеко от правды. Потому что в стандартной библиотеке до сих пор нет сетевого взаимодействия. Нет графической подсистемы. А многим, по вашей же логике, это нужно
Ну так еще не вечер. Насчет 2d графики конечно врядли, все таки этому место в графических тулкитах а не в библиотеке, а вот сеть влепят 99%. Есть (как минимум) три реализации сети - fetch и сокеты в вебе, http сервер в ноде и реализация из Qt. Все три написаны на плюсах и требуют поддержки на системном уровне, логично реализовать тот же
auto std::fetch(std::string url) -> std::promise<std::response>
auto std::fetch(std::request &&r) -> std::promise<std::response>
чтоб не таскать свою реализацию в каждом движке. Для клиентских запросов естественно, для серверных приложений что-то аля около Qt но это не точно.
Программист языка C++ должен знать стандартную библиотеку. Почему? Вот какой вопрос должен был быть у вас.
Кому должен и почему должен? Вам известно что на винде например нет никакой "стандартной библиотеки"?
И более того:
std::move, который уже упомянули, это часть стандартной библиотеки. Семантика перемещения зависит от этой функции. Например, некоторые программисты реализуют свои std::string и std::vector. Они знают особенности реализации стандартной библиотеки,
вы уверены что правильно понимаете что такое "стандартная библиотека" и для чего она нужна? в ассемблер когда нибудь смотрели? Если не смотрели то я вам докладываю что все что вы перечислили находится в заголовочных файлах, в libstdc++ находятся системо-зависимые функции вроде мемори-алокатора, копи-алокатора, io и тому подобного. Это не джава библиотеки где классы в бинарном виде.
К примеру, как вы узнаете нужен ли тот или иной контейнер в вашей задаче?
В плюсовом стандарте и в библиотеке это все не с потолка берется, консорциум закрепляет то что уже и так давно было в других библиотеках фреймворках и даже языках. Они там давно уже не занимаются генерированием рационализаторских идей (если вообще когда то этим занимались), а затаскивают все то что прижилось в той или иной области и очень бы хотелось видеть в плюсах конкретным пользователям.
Программист на С++ фактически обязан знать стандартную библиотеку языка. В текущее время вообще считается, что программист на любом языке
Простите, а когда в main входишь надо через argc argv переступать? Что правильные программисты на крестах должны использовать - табы или пробелы? Вы случайно не в курсе что там уважаемые люди считают по этому поводу?
Ну а если серьезно то программист должен знать(=понимать) сколько ему нужно для решения задачи. Формальность знаний и зазубривание всяких unordered_map/list без понимания зачем и для чего конкретно оно тебе нужно, приводит к тому что мы видим выше.
JIT и "языки высокого уровня" работают плохо потому что там ограниченное время на компиляцию, тогда как сама концепция VLIW подразумевает затратить побольше времени/энергии во время компиляции что бы потом экономить на том что суперскаляр вынужден делать каждый раз снова и снова.
С динамическим предсказанием ветвлений как раз эльбрусовский метод с подготовкой прыжков справляется лучше чем любой предсказать, так как он не ошибается, однако он бессилен перед подряд идущими переходами и множественными кейсами.
Разумеется это не значит что с этим ничего нельзя сделать, в 16С они добавили аппаратные счетчики для построения профиля программы и соответственно облегчения труда компилятора, а в последней версии бранч-юнит расширен командами iretи icall и своими флагами условий типа icall foo? %cmp0 Если короче то бранчпредиктором для неподготовленных переходов, насколько я могу судить.
Однако сколько решений в процессор не пихай все упирается в софт который должен все это поддерживать.
Я вообще к тому что прежде чем устраивать забег по граблям на новое решение пусть оно вначале предъявит результат не на словах а на деле. Пока что решения на риск-5 которое рвет эльбрус на тех же тестах, на которых он сливает современному интелу, как то не видно. Причем хотелось бы видеть результат именно от российских разработчиков, результат от китайцев и квалкомов нам не особо подходит.
Путь России, Китая и другой зарождающейся мировой альтернативы - это линуксные компьютеры на RISC-V.
Путь китая это LoongArch, а наш - Эльбрус. На них уже есть серверы и внедрение, есть портированное ПО и программисты знакомые с их архитектурными особенностями.
"Путь RISC-V" это тот же путь которым в 90е у нас проталкивали и агитировали за MIPS - некстген архитектура, скоро заменит устаревший x86, майкрософт уже виндовс под нее делает итд итп. Нет в мире никаких мировых путей, есть рынок и грамотное продвижение продукта.
"Америка" рассчитывает импортозаместить свой ВПК произведенными в америке чипами. "Мировой рынок" даже многие американские компании не особо интересует, а уж американское государство, которое ни прямо ни косвенно никакой торговлей не занимается, тем более плевать на него хотело.
Но устройства вроде как продаются и обзоры есть. Аврора (она же Sailfish OS) из себя представляет по сути современную итерацию нокиевской MeeGo - т.е. нормальный не обкусаный линукс с полноценным чрутом который можно даже посмотреть но нельзя менять, он защищен примерно как в макоси сигнатурной подписью которую имеют только пакеты от маинтейнера (пакеты кстати RPM), а сверху просто тач оболочка на Qt и вайланде, как водится проприетарная.
Я не утверждал что нельзя сделать. Можно, преодолев при этом кучу ограничений и накидав в бакенд кучу специфичных анализов https://youtu.be/LgxD-Kcasy8?t=2543
Но если итог будет заведомо хуже кода который генерирует родной компилятор, то заниматься этим нет никакого смысла.
А не будет он потому что LLVM уже на верхнем уровне делает какие то общие оптимизации, которые в основном заточены на risc и совершенно не учитывают vliw архитектуры. Бакенду попадет в руки уже пережеванный код без прагм и рестриктов что уже даже пример компиляции через lccrt-IR демонстрирует - обычный lcc если ему хорошенько подсказок накидать он даже сложные вложенные циклы начинает по своему раскручивать/наматывать, подрубать apb, если чтения из кучи линейные, а вот с LLVM-IR раскрутки и apb врубаются только для элементарных циклов где и без подсказок понятно что можно применить.
Есть вот такое обсуждение https://youtu.be/LgxD-Kcasy8?t=1206 Тут даже не про эльбрус, а про специализированные vliw cpu, коих много, и у всех свои проприетарные патчи для планировщика инструкций, там дальше где то разговор про предикаты, что он почему то предполагается только один.
(Отсебятина) LLVM и его IR это, как я понимаю стековая машина и байткод, выбрана такая архитектура либо просто для естественной безопасности, либо предполагалось что это будет универсальный компилятор для vm+jit в том числе. Поддержка vliw хоть и изначально заявлялась, но еще опыт AMD показал что у разработчиков представление о vliw ограничивалось укладыванием инструкций в бандл.
Решение ожидаемое, так как архитектура LLVM плохо напяливается на VLIW, но итоговый код оно генерирует все равно отличный от оригинального lcc, причем очень сильно в худшую сторону. Нужна ли такая разработка которая генерирует заведомо паршивый код, может проще фронтенды для llvm пропатчить что бы они выдавали AST языка, или что им там надо для полноценного компиляния.
Или вообще поддержать GIMPLE он вроде похож на этот их EIR.
Предсказатель переходов появился в версии 7, причем не какой то гибридный а просто вхреначели предсказатель для непосредственных (неподготовленных) переходов, теперь там в системе команд добавились инструкции icall и ret и специальные регистры %cmp. Честно говоря не совсем понимаю как предполагается компилятору решать непосредственный вызов подставлять или подготовленный, наверное когда есть возможность подготовить будет подготавливать, а когда будут макароны из вызовов, будут подставляться непосредственные.
Возврат же всегда теперь будет предсказанным, хотя насколько я понимаю старая возможность выхода из процедуры осталась, что правильно потому что ret в стиле интел не позволяет вернутся по условию например из середины, нужно прыгать сперва в конец процедуры, после чего выходить, что было бы скорее даунгрейдом.
В 16с добавляли что то связанное со сбором информации для профилирования на лету, для ускорения языков с JIT. Сами по себе компилируемые на лету языки казалось бы должны идеально подходить для VLIW, ведь у них есть вся рантайм информация которая собирается в процессе исполнения, но вся малина портится тем что у JIT нет времени на анализ всего кода и долгую компиляцию, а без этого широкие команды плотно не набить.
Сбор некоторой информации в рантайме, как я понимаю, позволяет дать больше возможностей оптимизирующему jit компилятору. Либо возможно речь вообще о том что бы вызывать родной оптимизатор штатного компилятора и что бы он по скорости укладывался в рамки jit.
Ну так еще не вечер. Насчет 2d графики конечно врядли, все таки этому место в графических тулкитах а не в библиотеке, а вот сеть влепят 99%. Есть (как минимум) три реализации сети - fetch и сокеты в вебе, http сервер в ноде и реализация из Qt. Все три написаны на плюсах и требуют поддержки на системном уровне, логично реализовать тот же
auto std::fetch(std::string url) -> std::promise<std::response>auto std::fetch(std::request &&r) -> std::promise<std::response>чтоб не таскать свою реализацию в каждом движке. Для клиентских запросов естественно, для серверных приложений что-то аля около Qt но это не точно.
Кому должен и почему должен? Вам известно что на винде например нет никакой "стандартной библиотеки"?
И более того:
вы уверены что правильно понимаете что такое "стандартная библиотека" и для чего она нужна? в ассемблер когда нибудь смотрели? Если не смотрели то я вам докладываю что все что вы перечислили находится в заголовочных файлах, в libstdc++ находятся системо-зависимые функции вроде мемори-алокатора, копи-алокатора, io и тому подобного. Это не джава библиотеки где классы в бинарном виде.
В плюсовом стандарте и в библиотеке это все не с потолка берется, консорциум закрепляет то что уже и так давно было в других библиотеках фреймворках и даже языках. Они там давно уже не занимаются генерированием рационализаторских идей (если вообще когда то этим занимались), а затаскивают все то что прижилось в той или иной области и очень бы хотелось видеть в плюсах конкретным пользователям.
Простите, а когда в main входишь надо через argc argv переступать?
Что правильные программисты на крестах должны использовать - табы или пробелы? Вы случайно не в курсе что там уважаемые люди считают по этому поводу?
Ну а если серьезно то программист должен знать(=понимать) сколько ему нужно для решения задачи. Формальность знаний и зазубривание всяких unordered_map/list без понимания зачем и для чего конкретно оно тебе нужно, приводит к тому что мы видим выше.
Нет, арм продирается сквозь кусты вслед за интел, и все больше подражает последнему что бы было легче.
Эльбрусы у нас не производятся.
JIT и "языки высокого уровня" работают плохо потому что там ограниченное время на компиляцию, тогда как сама концепция VLIW подразумевает затратить побольше времени/энергии во время компиляции что бы потом экономить на том что суперскаляр вынужден делать каждый раз снова и снова.
С динамическим предсказанием ветвлений как раз эльбрусовский метод с подготовкой прыжков справляется лучше чем любой предсказать, так как он не ошибается, однако он бессилен перед подряд идущими переходами и множественными кейсами.
Разумеется это не значит что с этим ничего нельзя сделать, в 16С они добавили аппаратные счетчики для построения профиля программы и соответственно облегчения труда компилятора, а в последней версии бранч-юнит расширен командами
iretиicallи своими флагами условий типа icall foo? %cmp0Если короче то бранчпредиктором для неподготовленных переходов, насколько я могу судить.
Однако сколько решений в процессор не пихай все упирается в софт который должен все это поддерживать.
Я вообще к тому что прежде чем устраивать забег по граблям на новое решение пусть оно вначале предъявит результат не на словах а на деле. Пока что решения на риск-5 которое рвет эльбрус на тех же тестах, на которых он сливает современному интелу, как то не видно. Причем хотелось бы видеть результат именно от российских разработчиков, результат от китайцев и квалкомов нам не особо подходит.
Путь китая это LoongArch, а наш - Эльбрус. На них уже есть серверы и внедрение, есть портированное ПО и программисты знакомые с их архитектурными особенностями.
"Путь RISC-V" это тот же путь которым в 90е у нас проталкивали и агитировали за MIPS - некстген архитектура, скоро заменит устаревший x86, майкрософт уже виндовс под нее делает итд итп. Нет в мире никаких мировых путей, есть рынок и грамотное продвижение продукта.
"Америка" рассчитывает импортозаместить свой ВПК произведенными в америке чипами. "Мировой рынок" даже многие американские компании не особо интересует, а уж американское государство, которое ни прямо ни косвенно никакой торговлей не занимается, тем более плевать на него хотело.
Но устройства вроде как продаются и обзоры есть.
Аврора (она же Sailfish OS) из себя представляет по сути современную итерацию нокиевской MeeGo - т.е. нормальный не обкусаный линукс с полноценным чрутом который можно даже посмотреть но нельзя менять, он защищен примерно как в макоси сигнатурной подписью которую имеют только пакеты от маинтейнера (пакеты кстати RPM), а сверху просто тач оболочка на Qt и вайланде, как водится проприетарная.
Да, вы правы, совсем не стековая, но все таки сорт оф dataflow
Я не утверждал что нельзя сделать. Можно, преодолев при этом кучу ограничений и накидав в бакенд кучу специфичных анализов https://youtu.be/LgxD-Kcasy8?t=2543
Но если итог будет заведомо хуже кода который генерирует родной компилятор, то заниматься этим нет никакого смысла.
А не будет он потому что LLVM уже на верхнем уровне делает какие то общие оптимизации, которые в основном заточены на risc и совершенно не учитывают vliw архитектуры. Бакенду попадет в руки уже пережеванный код без прагм и рестриктов что уже даже пример компиляции через lccrt-IR демонстрирует - обычный lcc если ему хорошенько подсказок накидать он даже сложные вложенные циклы начинает по своему раскручивать/наматывать, подрубать apb, если чтения из кучи линейные, а вот с LLVM-IR раскрутки и apb врубаются только для элементарных циклов где и без подсказок понятно что можно применить.
Есть вот такое обсуждение https://youtu.be/LgxD-Kcasy8?t=1206
Тут даже не про эльбрус, а про специализированные vliw cpu, коих много, и у всех свои проприетарные патчи для планировщика инструкций, там дальше где то разговор про предикаты, что он почему то предполагается только один.
(Отсебятина) LLVM и его IR это, как я понимаю стековая машина и байткод, выбрана такая архитектура либо просто для естественной безопасности, либо предполагалось что это будет универсальный компилятор для vm+jit в том числе.
Поддержка vliw хоть и изначально заявлялась, но еще опыт AMD показал что у разработчиков представление о vliw ограничивалось укладыванием инструкций в бандл.
Так потому что нет там никакого LLVM:
В рамках данного проекта штатное решение по портированию состоит в использовании проприетарного оптимизирующего e2k-бэкенда (из компилятора lcc). Использование e2k-бэкенда реализовано посредством транслятора промежуточных представлений llvm-IR -> EIR (lcc). В процессе трансляции используется транзитное представление lccrt-IR.
Решение ожидаемое, так как архитектура LLVM плохо напяливается на VLIW, но итоговый код оно генерирует все равно отличный от оригинального lcc, причем очень сильно в худшую сторону. Нужна ли такая разработка которая генерирует заведомо паршивый код, может проще фронтенды для llvm пропатчить что бы они выдавали AST языка, или что им там надо для полноценного компиляния.
Или вообще поддержать GIMPLE он вроде похож на этот их EIR.
Не знаю чем вы слушали но Трушкин как раз это и сказал что сделали публичный репозиторий куда можно слать патчи git.openelbrus.ru
У интела и асуса тоже нельзя купить напрямую их изделия. никакие военные тут разумеется непричем. Нужен розничный посредник типа DNS.
для этого придется писать на си.
Нориман Осуждаев, очень приятно.
"Нормальных" это каких? Чем эльбрус ненормален и какое конкретное место надо исправить.
Предсказатель переходов появился в версии 7, причем не какой то гибридный а просто вхреначели предсказатель для непосредственных (неподготовленных) переходов, теперь там в системе команд добавились инструкции icall и ret и специальные регистры %cmp. Честно говоря не совсем понимаю как предполагается компилятору решать непосредственный вызов подставлять или подготовленный, наверное когда есть возможность подготовить будет подготавливать, а когда будут макароны из вызовов, будут подставляться непосредственные.
Возврат же всегда теперь будет предсказанным, хотя насколько я понимаю старая возможность выхода из процедуры осталась, что правильно потому что ret в стиле интел не позволяет вернутся по условию например из середины, нужно прыгать сперва в конец процедуры, после чего выходить, что было бы скорее даунгрейдом.
В 16с добавляли что то связанное со сбором информации для профилирования на лету, для ускорения языков с JIT. Сами по себе компилируемые на лету языки казалось бы должны идеально подходить для VLIW, ведь у них есть вся рантайм информация которая собирается в процессе исполнения, но вся малина портится тем что у JIT нет времени на анализ всего кода и долгую компиляцию, а без этого широкие команды плотно не набить.
Сбор некоторой информации в рантайме, как я понимаю, позволяет дать больше возможностей оптимизирующему jit компилятору. Либо возможно речь вообще о том что бы вызывать родной оптимизатор штатного компилятора и что бы он по скорости укладывался в рамки jit.