Если коротко подытожить, то ответ на вопрос почему плюсы не устаревают примерно таков:
Потому что на них тоже вполне можно говнокодить!
Особенно ужаснул пример с вектором который куда то мувается при создании класса.
Что это почему это... я ничего не понимаю.
Есть же с 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.
Разумеется там (в оболочке) наверняка сплошь ворованный код и написан студентами, но справедливости ради МСВС вообще от начала до конца была закрытая и получала обновления только на дисках, тут хоть закрытая только оболочка с приложениями. Будем надеяться что следующий заход этой организации, либо тех кто от них отпочкуется, будет уже полностью свободным.
Оказывается, совсем недавно, - в декабре 22-го года.
Комиссия РАН по борьбе с лженаукой продолжает свою работу. Слухи о ее ликвидации не соответствуют действительности. Об этом сообщает портал NEWS.ru со ссылкой на председателя комиссии, академика Евгения Александрова.
"Ее переподчинили — она была подчинена первоначально президиуму РАН, а сейчас подчиняется экспертному совету РАН", — поделился Евгений Александров.
Проблема не в цитате, а в статье в целом. Она напоминает сочинение про Ленина от ученика средней школы.
Если бы ты учился в вузе то имел бы уже какое никакое понимание, что просто так что-то написать от балды и выдать не прокатит, надо идти изучать вникать в материал и потом уже на основе собранного в голове попытаться накорябать что-нибудь на троечку.
Историческая справка В 1994 году был выпущен первый компьютер на базе микропроцессора «Эльбрус-1», который был разработан в институте. В 2000 году был выпущен компьютер «Эльбрус-2»,
Вам, уважаемый Никита, неплохо бы сначала школу закончить и поступить в вуз (например в тот же мфти), а потом тут статьи писать. Без обид.
не напыщенную красоту, которой можно только кичиться, а их интересует функциональность прежде всего
Ключевое отличие западного бизнеса от вездесущих отечественных "продаванов" в том, что они не проецируют сугубо личные приоритеты своего топ-манагмента на пользователей, и уж тем более им никогда в голову не придет поплевывать в них и сравнивать с клиентурой в других странах.
Просто использовать его надо не для работы с DOM, а для CPU-bound задач.
Я тоже об этом, и wasm никак не поможет сделать производительные FLIFBPGили аудиоформаты с архиваторами на стороне клиента, ведь это не библиотека на си а просто байткод js прекомпилированный.
Что касается цифр то к ним не хватает пояснения это холодный старт, горячий прогон какого то кода или что это. В запуске то не сомневаюсь что оно быстрее, вопрос про все остальное.
они рисуют гуй в окошечках системы. При сборке в wasm - в webgl. И это все работать прям шустро.
Это все рисуется в Canvas2D (webgl это уже Canvas3D ) естественно оно быстрое потому что функции написаны на нативном языке и оптимизованы/векторизованы как положено. Но вообще ты прав, перенос из Unity становится лучше с WebAsm, ведь с-sharp типизированный язык и компилировать его в скрипты это просто было бы уродством. Но вот другие скриптовыя языки (питон, руби, пхп, луа) я бы предпочел пересобирать в js по примеру typescript -а, что бы программа оставалась динамичной и не была привязана к типам.
Ну скорости с ним точно не будет поскольку там байткод виртуальной машины, а не нативный код процессора. Может быть даже будет замедление поскольку у JS в отличии от джавы типы не определены, и их подставляют на этапе компиляции из абстрактного синтаксического дерева, в том числе их можно заменить на основе данных о реальном исполнении. В байткоде же (если википедия не врет) уже стек-машина с операциями на конкретный размер и тип данных (64 бита знаковое) тут уже у vm связаны руки.
порт какой-нибудь очень нужной и незаменимой (либо лень) библиотеки в веб
Еще было бы здорово использовать единый джаваскриптовый VM / JIT / GC для всех скриптовых языков в одном проекте например.
Но к сожалению vm языков привязаны к функционалу, который гарантирован стандартом из коробки. Поэтому и библиотеку можно будет собирать не любую а только ту которая может работать в окружении js варианта web.
Вот так при помощи нехитрого кода на жс, строки на руби компилируются в байткод vm и запускаются. Но зачем?
Руби язык поддерживающий ввод/вывод в терминал, работу с фс и другими системными вещами из коробки.
JS язык поддерживающий WebAPI и другие средства браузера из коробки
в таком виде ни руби свои возможности использовать не может, ни джавоскриптовыми пользоваться в полной мере, практическая применимость вебассемблера все еще остается под вопросом.
Если коротко подытожить, то ответ на вопрос почему плюсы не устаревают примерно таков:
Особенно ужаснул пример с вектором который куда то мувается при создании класса.
Что это почему это... я ничего не понимаю.
Есть же с 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.
Разумеется там (в оболочке) наверняка сплошь ворованный код и написан студентами, но справедливости ради МСВС вообще от начала до конца была закрытая и получала обновления только на дисках, тут хоть закрытая только оболочка с приложениями. Будем надеяться что следующий заход этой организации, либо тех кто от них отпочкуется, будет уже полностью свободным.
Комиссия РАН по борьбе с лженаукой продолжает свою работу. Слухи о ее ликвидации не соответствуют действительности. Об этом сообщает портал NEWS.ru со ссылкой на председателя комиссии, академика Евгения Александрова.
"Ее переподчинили — она была подчинена первоначально президиуму РАН, а сейчас подчиняется экспертному совету РАН", — поделился Евгений Александров.
Короче новость о ликвидации это вброс гомеопатов.
Школа это не оскорбление, а среднее образование.
Проблема не в цитате, а в статье в целом. Она напоминает сочинение про Ленина от ученика средней школы.
Если бы ты учился в вузе то имел бы уже какое никакое понимание, что просто так что-то написать от балды и выдать не прокатит, надо идти изучать вникать в материал и потом уже на основе собранного в голове попытаться накорябать что-нибудь на троечку.
Вам, уважаемый Никита, неплохо бы сначала школу закончить и поступить в вуз (например в тот же мфти), а потом тут статьи писать. Без обид.
Ключевое отличие западного бизнеса от вездесущих отечественных "продаванов" в том, что они не проецируют сугубо личные приоритеты своего топ-манагмента на пользователей, и уж тем более им никогда в голову не придет поплевывать в них и сравнивать с клиентурой в других странах.
Я тоже об этом, и wasm никак не поможет сделать производительные FLIF BPG или аудиоформаты с архиваторами на стороне клиента, ведь это не библиотека на си а просто байткод js прекомпилированный.
Что касается цифр то к ним не хватает пояснения это холодный старт, горячий прогон какого то кода или что это. В запуске то не сомневаюсь что оно быстрее, вопрос про все остальное.
Это все рисуется в Canvas2D (webgl это уже Canvas3D ) естественно оно быстрое потому что функции написаны на нативном языке и оптимизованы/векторизованы как положено. Но вообще ты прав, перенос из Unity становится лучше с WebAsm, ведь с-sharp типизированный язык и компилировать его в скрипты это просто было бы уродством. Но вот другие скриптовыя языки (питон, руби, пхп, луа) я бы предпочел пересобирать в js по примеру typescript -а, что бы программа оставалась динамичной и не была привязана к типам.
Ну скорости с ним точно не будет поскольку там байткод виртуальной машины, а не нативный код процессора. Может быть даже будет замедление поскольку у JS в отличии от джавы типы не определены, и их подставляют на этапе компиляции из абстрактного синтаксического дерева, в том числе их можно заменить на основе данных о реальном исполнении. В байткоде же (если википедия не врет) уже стек-машина с операциями на конкретный размер и тип данных (64 бита знаковое) тут уже у vm связаны руки.
Еще было бы здорово использовать единый джаваскриптовый VM / JIT / GC для всех скриптовых языков в одном проекте например.
Но к сожалению vm языков привязаны к функционалу, который гарантирован стандартом из коробки. Поэтому и библиотеку можно будет собирать не любую а только ту которая может работать в окружении js варианта web.
Вот так при помощи нехитрого кода на жс, строки на руби компилируются в байткод vm и запускаются. Но зачем?
Руби язык поддерживающий ввод/вывод в терминал, работу с фс и другими системными вещами из коробки.
JS язык поддерживающий WebAPI и другие средства браузера из коробки
в таком виде ни руби свои возможности использовать не может, ни джавоскриптовыми пользоваться в полной мере, практическая применимость вебассемблера все еще остается под вопросом.