Pull to refresh
2
0

Пользователь

Send message

ЖЖ Артемия Лебедева не обнаружили еще?

"Импортозамещение" это тема из 2014-2019. На дворе уже без пяти минут 2025й и модное слово в этом сезоне - Технологический сувернитет. Нужно хотя бы иногда от бутылки отрываться и заглядывать в календарь, в окно браузера, чтоб получать актуальную информацию..

Последние лет 15-20 по всем каналам, даже на рулонах туалетной бумаги, рассказывали – импортозамещение уже здесь. Год назад один майнер даже звал в проект -

продукт улучшается каждый день и можно приложить к этому голову, руку или даже ногу

Что именно в итоге приложили, было видно прямо на презентации - которая там же и упала. Злые, нехорошие майнеры в ответ еще и издевались:

Так надо было согласится, потыкать палкой и написать "неприятную" статью про то что это из себя представляет на деле.

В противном случае о чем эта стена нытья? О том что в надцатом году, на мероприятии у друзей к тебе клеилась мадам, но ты не поддался на провокации и вот уже 6лет не жалеешь об этом по целому ряду причин?

Ну молодец, держи в курсе.

В моем понимании профилактическая медицина это когда лечащий врачь выписывает пациенту пить не меньше 2,5л воды в сутки и раз в полгода-год ходить в поликлиннику на узи проверять почки на наличие камней.

А возить например простудившееся животное на капельницы, сдачу крови и прочие на чем настаивают в частных ветклиникахэто не профилактика заболеваний, а способ частной клиники хоть как то существовать навязав нафиг не нужные услуги, т.к. зарплаты аренду и прочее надо платить каждый месяц а клиенты не прирастают.
Чисто по человечески я это все конечно понимаю, но всегда подозревал что весь это атракцион "важных медицинских услуг" закончится прямым лоббированием интересов через минздрав росветнадзор и что там у нас еще. А то что вы предлагаете еще и приведет к появлению 100500 мошеннических организаций, мало нам фальшивых газовиков-мчсников-проверяльщиков счетчиков вентиляций, будут еще сборщики анализов с тетрадкой и пробирками по квартирам ходить и тыкая в какое то там постонавление баночки для анализов продавать, кровь грязной иглой брать.

Все лидеры рынка так или иначе активно участвуют в поддержке своего железа, в ядрах, в библиотеках, в компиляторах. Если не сами то по крайней мере помогают разработчикам затачивать ПО под свои продукты. На сообщество очень много возлагала такая компания как AMD и в итоге всегда плелась сзади за intel и nvidia. Но даже AMD не подразумевала под сообществом что какой то вася пупкин тебе все портирует/оптимизирует нахаляву, так не будет. Сообщество это когда основной код пилят тестируют сопровождают одни люди, а тебе как вендору можно сосредоточится только на поддержке своей железяки. В сообществе рискфайв вообще ситуация прекрасная все ждут сказочного вендора который за свой счет проведет оптимизацию ПО заложив это все в стоимость своих продуктов, а другой вендор из так называемой дружественной страны не вложив в софт ни копья будет заваливать рынок своими дешевыми чипами.

Далеко от правды. Потому что в стандартной библиотеке до сих пор нет сетевого взаимодействия. Нет графической подсистемы. А многим, по вашей же логике, это нужно

Ну так еще не вечер. Насчет 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 без понимания зачем и для чего конкретно оно тебе нужно, приводит к тому что мы видим выше.

ARM, протаптывая дорогу к портабельному софту, делает это в том числе и для RISC-V

Нет, арм продирается сквозь кусты вслед за интел, и все больше подражает последнему что бы было легче.

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:

В рамках данного проекта штатное решение по портированию состоит в использовании проприетарного оптимизирующего e2k-бэкенда (из компилятора lcc). Использование e2k-бэкенда реализовано посредством транслятора промежуточных представлений llvm-IR -> EIR (lcc). В процессе трансляции используется транзитное представление lccrt-IR.

Решение ожидаемое, так как архитектура LLVM плохо напяливается на VLIW, но итоговый код оно генерирует все равно отличный от оригинального lcc, причем очень сильно в худшую сторону. Нужна ли такая разработка которая генерирует заведомо паршивый код, может проще фронтенды для llvm пропатчить что бы они выдавали AST языка, или что им там надо для полноценного компиляния.

Или вообще поддержать GIMPLE он вроде похож на этот их EIR.

Information

Rating
6,615-th
Registered
Activity