https://opennet.dev/openforum/vsluhforumID3/119974.html Исследователи из компании Positive Technologies выявили уязвимость (CVE-2019-0090), позволяющую при наличии физического доступа к оборудованию извлечь корневой ключ платформы (chipset key), используемый в качестве корня доверия при проверке подлинности различных компонентов платформы, включая прошивки TPM (Trusted Platform Module) и UEFI...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52487<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#181 Thu, 12 Mar 2020 06:45:03 GMT &gt;&gt; Даже мой дремучий ppc64 всё ещё есть.<br>&gt; Какой же он дремучий? Вон, power9 вышел, очень даже мощная система.<br><br>Батенька... ну вот при всём моём уважении... ну не путайте вы уже ppc64 & ppc64le, ну разные они. А за пояснения спасибо - буду гаситься от Эльбрусов аки чёрт от ладана.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#180 Tue, 10 Mar 2020 23:55:24 GMT &gt; С точки зрения оптимизации C++ хуже памятью. Говоря про скорость многие в первую очередь думают про распараллеливание для максимальной загрузки VLIW и забывают при этом про доступ к памяти, а он медленный.<br><br>ААААаАААА!!!! Спасибо огромное. Да, у C++ из-за виртуальных функций уже простой вызов идёт через доступ к совершенно левой VTABLE. Конечно, тогда Эльбрус не любит и классическую LISP-подобную организацию памяти, которая по-умолчанию во всякой функциональщине. Есть чудесная статья "The memory models that underlie programming languages" про разные типы организации памяти. И, конечно, структуры C или параллельные массивы Fortran'а тогда для него "the best".<br><br>Но сейчас идёт серьёзная работа в том же Хаскеле и Камле по оптимизациям типа unboxing - когда переменные кладутся на стек. См "Levity Polymorphism".<br><br>Но из того, что есть сейчас, Rust должен зайти - тут вам и стек, и pattern-matching. Но зато llvm.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#179 Tue, 10 Mar 2020 12:42:30 GMT Не, тут больше дело в разном понимании стандартов C++ со стороны GCC и EDG (фронтенд lcc), не говоря уже о том, что lcc немного отстаёт (C++17 только появился). Поэтому портировать C намного проще и приятнее, чем C++<br><br>С точки зрения оптимизации C++ хуже памятью. Говоря про скорость многие в первую очередь думают про распараллеливание для максимальной загрузки VLIW и забывают при этом про доступ к памяти, а он медленный. И сколько ни параллель, а если проц будет ждать данных из памяти, то всё, приплыли. У Эльбрусов есть совершенно уникальный механизм асинхронной подкачки данных напрямую из L2 в регистры, но он работает только для выровненных данных, в C это обеспечить проще.<br><br>И ещё технические детали: на 4-м поколении e2k (e8c, e1c+) DDR3 &#8212; а это наше боевое железо. DDR4 есть на 5-м поколении (e8cв), но пока в рукам не держал. C++ своими виртуальными методами, перегруженными операторами и прочей ерундой знатно увеличивает нагрузку по доступу к памяти и кеша далеко не всегда хватает.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#178 Tue, 10 Mar 2020 03:34:16 GMT &gt; По опыту портирования и (меньшему) опыту оптимизации с C на e2k как раз всё хорошо, а вот с C++ начинаются пляски.<br><br>Спасибо, занятно. А почему с С++ так плохо? Он в достаточно большой степени ложится на чистый С, то есть, можно написать транспайлер.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#177 Mon, 09 Mar 2020 20:37:07 GMT &gt; Вообще, судя по разным дискуссиям вокруг того же Мультиклета, язык С очень <br>&gt; далёк от системного языка таких "необычных" процессоров.<br><br>По опыту портирования и (меньшему) опыту оптимизации с C на e2k как раз всё хорошо, а вот с C++ начинаются пляски. А что-нибудь функциональное, вроде guile или haskell &#8212; вообще адова боль.<br><br>&gt; Кроме того, явный параллелизм <br>&gt; очень хорошо подходит для pattern-matching'а, позволяя протестировать сразу несколько <br>&gt; разных веток исполнения (то есть, ускорение всякой хардкорно-энтерпрайзной бизнес-логики). <br><br>Ну вот оказалось, что нет. Не могу вдаваться во все детали, но коллеги прорабатывали этот вопрос для Haskell и пришли к выводу, что таки нет. Слишком высокоуровневый параллелизм в таких языках.<br><br>&gt; Причём у Камла был кодогенератор для Итаниума. То есть, если с ними <br>&gt; связаться, может быть можно сделать какое-то прикладное computer-science исследование. <br><br>Между Итаниумом и Эльбрусом общего только то, что *формально* Итаниум &#8212; тоже VLIW.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#176 Mon, 09 Mar 2020 20:31:38 GMT &gt; А чего ж в генте про ваш замечательный е2к ваще ни звука <br>&gt; и даже архитектуры такой не числится? :)<br><br>И не будет. Здесь нашла коса на камень. В Gentoo фундаментальным принципом сообщества является социальный контракт, где сказано:<br><br>Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative (OSI).<br><br>https://gentoo.org/get-started/philosophy/social-contract.html<br><br>А единственный компилятор под Эльбрус &#8212; lcc &#8212; проприетарный и в обозримом будущем его никто открывать не будет. Это плохо, но разработчиков компилятора и процессора тоже можно понять, т.к. там слишком низкоуровневые вещи зашиты, что-то вроде микрокода intel/amd, который тоже никто открывать не собирается.<br><br>Может быть вопрос: но ведь в Gentoo есть интеловский проприетарный icc и иные закрытые компиляторы? Да, это правда, но они ес https://opennet.dev/openforum/vsluhforumID3/119974.html#175 Mon, 09 Mar 2020 20:20:36 GMT &gt; А что, ИП-шникам уже продают?<br><br>Насколько я знаю, такие случаи были.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#174 Mon, 09 Mar 2020 19:13:49 GMT &gt; Простите, а давно UEFI является фичей проца?<br><br>А как пропишет OEM активацию бутгада - так и является. Ибо ничего другого железка с прописаным бутгадом тебе вгрузить не даст.<br> https://opennet.dev/openforum/vsluhforumID3/119974.html#173 Mon, 09 Mar 2020 19:10:42 GMT Особенно круто накопитель в pci-e и тундерболт наружу: если первый не сможет вдруг почему-то запатчить тебе кернель через DMA, так и быть, ближайшая флеха или какой там еще монитор тоже с этим справятся. Удобно.<br>