The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Серьёзное снижение производительности ядра 5.19, вызванное защитой от атаки Retbleed, opennews (??), 12-Сен-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


3. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +38 +/–
Сообщение от Аноним (3), 12-Сен-22, 14:07 
Судя по скорости Эльбрусы - это как-бы интелы с закрытием спекулятивных уязвимостей
Ответить | Правка | Наверх | Cообщить модератору

7. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –16 +/–
Сообщение от Аноним (7), 12-Сен-22, 14:39 
Эльбрус по интелу это Core 2 Duo. Можешь вместо дорогостоящего брусочка прикупить себе систему на intel celeron типа n5105 или что-то из этой оперы, получишь идентичную производительность в меньшем форм факторе minipc, в разы меньшем электропотреблении и нормальном аппаратном декодировании видео в браузере.
Ответить | Правка | Наверх | Cообщить модератору

8. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –9 +/–
Сообщение от Аноним (7), 12-Сен-22, 14:42 
Да и ценник будет в раз 10 меньше. Покупая отечественное (я имею в виду импортозамещенное аналоговнетное) покупатель должен иметь в виду что он спонсирует разработку, попилы, проценты отката от начальника предприятия до крышующего силовика и чинуши).
Ответить | Правка | Наверх | Cообщить модератору

14. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +9 +/–
Сообщение от жявамэн (ok), 12-Сен-22, 14:58 
Загляни под кровать
Там сидят попильшики и пилят ножки
Ответить | Правка | Наверх | Cообщить модератору

26. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –3 +/–
Сообщение от a_kusb (ok), 12-Сен-22, 15:23 
Так то по факту он довольно правильно сказал. Существует ловушка импортозамещения и налоги, которые уходят правительству, существуют связи и вот это всё. Это только часть медали, но вот.
Ответить | Правка | Наверх | Cообщить модератору

30. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +13 +/–
Сообщение от Аноним (30), 12-Сен-22, 15:33 
Больше всего сейчас попилит и откатывает майкакаасофт со своими виндами, а так же ай би мэ и циска, но принято почему то обсуждать Эльбрус и его цену (как раз за то, что попилить нельзя, каждая копеечка на счету).
Ответить | Правка | Наверх | Cообщить модератору

40. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +4 +/–
Сообщение от erthink (ok), 12-Сен-22, 15:44 
> Больше всего сейчас попилит и откатывает майкакаасофт со своими виндами, а так
> же ай би мэ и циска, но принято почему то обсуждать
> Эльбрус и его цену (как раз за то, что попилить нельзя,
> каждая копеечка на счету).

А было несколько заходов "получить финансирование" на мега-перспективный RISC-V и покупной ARM, под что формировали общественное мнение, в том числе среди разработчиков.

Поэтому большинство хомячков до сих пор уверены в попилах, типуковости e2k и перспективности risc-v.

Ответить | Правка | Наверх | Cообщить модератору

56. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 12-Сен-22, 16:19 
RISCV поддерживается опенсорсными тулчейнами и уже есть поддержка нескольких SoC в майнлайне. Очень способствует уверенности в светлом будущем архитектуры.
Ответить | Правка | Наверх | Cообщить модератору

66. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +6 +/–
Сообщение от erthink (ok), 12-Сен-22, 16:41 
> RISCV поддерживается опенсорсными тулчейнами и уже есть поддержка нескольких SoC в майнлайне.
> Очень способствует уверенности в светлом будущем архитектуры.

Как уже много раз писал, RISC-V прекрасен для своего первоначального предназначения (простых встраиваемых применений типа стиралок и кофеварок, но не путать с IoT).

А дальше начинает фигня, напомню: Как у "чистого риска" нет явного указателя стека и какой-либо защиты стека.
При этом ABI вроде-бы входит в спеку архитектуры и предусматривает распределение регистров.
Поэтому де-факто имеет один стек, где данные смешаны с адресами возврата, плюс "опенсорсные тулчены" которые иначе не умеют, плюс весь системный софт где это захардкожено.
В результате "новая перспективная архитектура" принципиально уязвима для ROP как относительно дремучие x86, ARM и т.п.

Ниже копипаста по этой теме.

---

Основная моя претензия к RISC-V в том, что в новой "допеределенной" архитектуре сохранено всё необходимое для эксплуатации ошибок "выход за пределы буфера на стеке" и ROP.

Отдельная тонкость в том, что в RISC-V (и традиционно во всех "берклиевских рисках") нет аппаратного стека в явном виде "как в x86", а стек фактически определяется в ABI - можно поменять соглашение об использовании регистров (занять ещё один под указатель второго стека), и проблемы не будет.

Поэтому получается, что непосредственно у самих ЦПУ на базе RISC-V на уровне аппаратуры более-менее хорошо, как минимум по этому вопросу. А все проблемы на стороне ПО. Однако, если посмотреть на RISC-V как на "экосистему", то она "одностековая", причем соглашение об использовании регистров прописано в спецификации ISA.

Решить проблему действительно можно сменой ABI, но если это не начать делать «вчера», то будет как с x86 (конечно, не совсем так, но снежный ком будет расти). Но кто и как это будет делать не понятно. Точнее говоря, уже понятно что разработчики ПО уже поставлены перед выбором:

- либо отказаться от готовой инфраструктуры и самим "пилить" все задачи связанные с изменением ABI (от доработки компиляторов до перепортирования софта);

- либо всеми силами не замечать проблему, и убеждать себя и всех и что её нет.

Очевидно что RISC-V тут не более дырявый чем остальные архитектуры с одним стеком. Однако:

1) разделение стеков существенно уменьшает вероятность/риски эксплуатации ошибок переполнения буферов размещенных на стеке.

2) своевременное лечение проблемы даже "в лоб" было-бы почти бесплатным, как по затратам, так и по быстродействию (занимаем еще один регистр из 31).

3) в RISC-V ISA для инструкций JAL и JALR явно специфицированы автоматическое выполнение push/pop в RAS (return-address stack), т.е. «уши» аппаратного стека всё-таки торчат, но и нет проблем отделить RAS от SP с данными.

4) ничего не сделано, а напротив сформировано сугубо одностековое ABI и инфраструктура.

Суммарно получается: что есть дыра, которую точно следовало-бы заткнуть, была возможность сделать это бесплатно, но дыра бережно сохранена и сделано всё, чтобы затруднить её устранение = это у меня вызывает озабоченность, особенно когда предлагают заменять "неперспективные Эльбрусы" на "прогрессивные RISC-V".

Ответить | Правка | Наверх | Cообщить модератору

79. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 12-Сен-22, 17:24 
В IA32, а тем более в AMD64, где меняли ABI (и в то время было известно о ROP-техниках), возможно было разделить стеки. Entel+leave не используются из-за скорости, никто не заставлял копировать указатель стека в регистр базы.
Ответить | Правка | Наверх | Cообщить модератору

118. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от a_kusb (ok), 12-Сен-22, 19:15 
Интересно, а если изменить ABI и протащить это в опенсорсные тулчейны? (Или даже в спеку RISC-V, но вообще не знаю насколько реально, разве что она молодая и мало используется там, где нужна совместимость.)
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

135. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от аНОНИМ (?), 12-Сен-22, 21:52 
Добавлю:

1. У 32битного арма, покрмере в юзерспейсе, точно так же нет аппаратного стека. Ну в тумбе конечно есть уши и что там в аарч64 -- не знаю.

2. в JAL и JALR никаких пушей-попов нет -- а есть сохранение/загрузка PC в/из link register. Если нужен стек, то его потом надо руками сложить в, собственно, софтверный стек.

3. идея сменить ABI на 2стековое конечно интересная, и более того она тоже решается в amd64 архитектуре, ну регистров-то там хватит. И на первый взгляд ВООБЩЕ ничего поломаться не должно -- ессно после перекомпиляции этого всего 'ничего'.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

136. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от erthink (ok), 12-Сен-22, 22:10 
> 3. идея сменить ABI на 2стековое конечно интересная, и более того она
> тоже решается в amd64 архитектуре, ну регистров-то там хватит. И на
> первый взгляд ВООБЩЕ ничего поломаться не должно -- ессно после перекомпиляции
> этого всего 'ничего'.

Ломаются всякие контексты, короутины, парсеры кадров стека, JIT-ы, FFI и т.п.
Упрощенно, ломается 50% где есть "#include <asm/xxx>" и __asm(xyz).
Короче, его величество ABI...

Кстати, так вот подумаешь - отчего люди жалуются что "софта на Эльбрусы мало", всего-то перекомпилировать.

Ответить | Правка | Наверх | Cообщить модератору

215. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 11:40 
> Ломаются всякие контексты, короутины, парсеры кадров стека, JIT-ы, FFI и т.п.

Подтверждаю.  Прорабатывать такое долго, трудно и больно (я даже близко не подхожу, вывод судя по коллегам).

> Кстати, так вот подумаешь - отчего люди жалуются что "софта на Эльбрусы мало",
> всего-то перекомпилировать.

Ну как... когда в жёсткое archdep не упираешься -- то в случае альта более 90% в принципе собравшихся пакетов или просто собрались в лоб (когда всё нужное уже было на месте), или потребовали тривиальных пинков вроде "убрать конкретно -Wimplicit-fallthrough=0, пока не сделали в lcc".  Тяжёлых патчей требуют процента три, очень тяжёлых -- единицы-десятки.

Ответить | Правка | Наверх | Cообщить модератору

137. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от erthink (ok), 12-Сен-22, 22:33 
> 2. в JAL и JALR никаких пушей-попов нет -- а есть сохранение/загрузка
> PC в/из link register. Если нужен стек, то его потом надо
> руками сложить в, собственно, софтверный стек.

Пардон, забыл сразу ответить.

RAS там примерно вот этот = http://www-classes.usc.edu/engr/ee-s/457/EE457_Classnotes/ee...

Т.е. это те самые "уши стека, которого как-бы нет" ;)

// P.S. pdf этот просто какой-то первый попавшийся и (вроде-бы) релевантный.

Ответить | Правка | К родителю #135 | Наверх | Cообщить модератору

150. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –2 +/–
Сообщение от Аноним (-), 13-Сен-22, 01:11 
> 4) ничего не сделано, а напротив сформировано сугубо одностековое ABI и инфраструктура.

Да, конечно. Если бы они написали рекомендацию использовать два стека, то Торвальдс, а вместе с ними гуглы, амазоны, редхаты и пр., сочли бы для себя ниже чести положить на неё болт, и делать по-своему.

Перед RISC-V не стоит задачи учить всех программировать. Они скромнее, они создают процессор под популярные юзкейсы. И рекомендации пишут исходя из того, как они ждут их процессор будет использоваться. Если бы они порекомендовали бы использовать два стека, то получилось бы так, что те тупые люди, кто повёлся бы на рекомендацию, оказались бы в ситуации белых ворон. А те кто не повёлся бы, были бы вынуждены сами между собой договариваться о том, какой регистр использовать для стека, с риском оказаться в ситуации нескольких по-сути одинаковых но в технических деталях различающихся стандартов.

Переход на два стека для ядра или для допустим linux'ового юзерспейса -- это огромный геморрой для разработчиков. В первом случае для ядерных, во втором для "широких слоёв", но в первую очередь для мейнтейнеров дистров. Кто такой этот RISC-V International, чтобы подобные геморрои _рекомендовать_? Он и не рекомендует, потому что знает своё место в пищевой цепочке.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

216. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 11:44 
> Перед RISC-V не стоит задачи учить всех программировать. Они скромнее, они создают
> процессор под популярные юзкейсы.

...один из которых -- чушь, которую дипломированные дураки назвали "контролируемым хаосом" в слепой уверенности, что хаос контролируют они, а не наоборот.

Ну, когда вдруг оказывается, что "твоя" система -- уже не твоя.

> Если бы они порекомендовали бы использовать два стека, то получилось бы так,
> что те тупые люди, кто повёлся бы на рекомендацию, оказались бы в ситуации белых ворон.

Пусть жизнь покажет, кто был тупой.

> Переход на два стека для ядра или для допустим linux'ового юзерспейса --
> это огромный геморрой для разработчиков. В первом случае для ядерных, во
> втором для "широких слоёв", но в первую очередь для мейнтейнеров дистров.

Вполне подъёмный даже для маленького (правда, ни разу не тупого) коллектива.  А про "первую очередь" так и вовсе мимо кассы, это я Вам могу авторитетно сказать.

> Кто такой этот RISC-V International, чтобы подобные геморрои _рекомендовать_?

Судя по "бывшей" айбиэмерше во главе Foundation -- как раз поставщик "цифровых ножек буша".

Ответить | Правка | Наверх | Cообщить модератору

285. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Аноним (285), 13-Сен-22, 17:43 
> Пусть жизнь покажет, кто был тупой.

Она показала уже. Рекомендация RISC-V International совпала с тем, как RISC-V применяют. Они угадали. То есть те тупые, кто угадать не мог и поэтому последовал рекомендации, ничего не потеряли.

> Вполне подъёмный даже для маленького (правда, ни разу не тупого) коллектива

RISC-V International не собирается такой коллектив никому предоставлять в качестве входного подарка. И не их дело указывать другим, что они должны оплачивать ещё и работу этого маленького и ни разу не тупого коллектива.

> я Вам могу авторитетно сказать.

Шегорин, мы знаем "глубину" твоего авторитета. Мог бы и не говорить про "авторитетно". А те кто не знает, только по этому комменту могут видеть, что ты русских слов понять не в состоянии, потому что в твоей голове маркетинг, пропаганда и технические соображения спутаны в такой клубок, что ты сам не можешь отличить одно от другого. "Глубина" авторитета такая, что его видно до дна с первого взгляда.

Ответить | Правка | Наверх | Cообщить модератору

196. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Аноним (196), 13-Сен-22, 09:51 
> Как уже много раз писал, RISC-V прекрасен для своего первоначального предназначения (простых
> встраиваемых применений типа стиралок и кофеварок, но не путать с IoT).

Он прекрасен тем что
1) Это экосистема. Открытая. Чипмейкерская.
2) Уже есть легион ядер, самых разных масштабов. От low power MCU до серверных чипов. Открытых.
3) Есть нехило обвеса и SoC на это все. В чем можно убедиться зайдя на гитхаб.
4) Есть легион тулзов, самых разных. Вплоть до симуляторов которые могут анализировать с точностью вплоть до вентилей. Не говоря уж про компиляторы, системный обвес и все такое. И все это открытое, конечно.
5) Ах да, эта экосистема вертикально масштабируема. Как ARM. Одно ядро на одну оказию хорошо. Универсальная масштабируемая экосистема лучше.
6) Это эволюционирует. Шустро, динамично, под насущные задачи, толпой народа. В эту экосистему вписались легионы. От самоделкиных до корпораций размером с WD и чуть ли не интел.

> А дальше начинает фигня, напомню: Как у "чистого риска" нет явного указателя стека

А что же у него есть по вашему?

> и какой-либо защиты стека.

1) Реализуемо допустим MMU.
2) Если этого всего мало, вон там Rust на горизонте появился, он с другого бока зашел.

И между нами, компил тайм верификация лучше рантайм факапов. Особенно для безопасного, надежного и беспроблемного софта.

> При этом ABI вроде-бы входит в спеку архитектуры и предусматривает распределение регистров.

И это хорошо. Ибо дает определенные

> Поэтому де-факто имеет один стек, где данные смешаны с адресами возврата,

Не обязано вести к каким-то фундаментальным проблемам само по себе. То что в случае конкретно си это может отливаться в те или иные грабли, это вообще-то трабла именно сей, в дизайне ЯП.

> плюс "опенсорсные тулчены" которые иначе не умеют, плюс весь системный софт где
> это захардкожено.

Да и хрен с ним. Говоря за себя если выбирать между допустим разучиванием раста и проприетарного сишного тулчейна - ну, вы поняли. Rust и его либы мой дистро культурно втянет, технично обув MS/amazon/google на контроль, я уже вижу как они это делают. А проприетарный тулчейн это проприетарный тулчейн. Факап в самом core экосистемы.

Видите ли, системщики не настолько раки чтобы спрашивать ослиное позволение wannabe-божков с тулчейном. Это даже майкрософту популярно объяснили уже, на память о чем у них "драйверов нет" вон там под ARM/RISCV/... и полный пролет в экосистеме. Удачи :)

> В результате "новая перспективная архитектура" принципиально уязвима для
> ROP как относительно дремучие x86, ARM и т.п.

Ну, значит, Rust будут применять более активно и так тому и быть. Есть более 1 способа решить ту или иную инженерную проблему. В том числе и эту.

> сохранено всё необходимое для эксплуатации ошибок "выход за пределы буфера на
> стеке" и ROP.

Этот класс ошибок можно просто загасить с другого бока. На уровне тулчейнов и ЯП.

> то она "одностековая", причем соглашение об использовании регистров прописано в спецификации
> ISA.

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

> - либо отказаться от готовой инфраструктуры и самим "пилить" все задачи связанные
> с изменением ABI (от доработки компиляторов до перепортирования софта);

ИЧСХ в случае с RISCV и его тулчейнами это даже какие-нибудь мелкие исследователи могут попробовать. А если получится что-то годное, почему бы остальным на это не свалить, не понятно. Ну вон у арма был EABI а потом стал ARMHF. И ничего, живые все.

> - либо всеми силами не замечать проблему, и убеждать себя и всех
> и что её нет.

А в каком-нибудь Rust и т.п. яп ее может и не быть в именно вон той формулировке. А в си, видите ли, реальная проблема в том что в сорце нет достаточной аннотации намерений кодера в ряде случаев, что нагибает статический анализ. Это я как сишник повернутый на надежности, стабильности и безопасности говорю. Ну вот реально есть дурные моменты дизайна. И это наследие си, а не чего-то еще. Особенно то что там касается UB где комитет свалил все и вся на кодеров и тулчейны, и указатели где ну вот вообще никакой декларации намерений кодера тулчейну а потому сие не предмет для какой либо верификации во время компила. Это само по себе грабли, гораздо более крупные чем одно только переполнение буферов.

> 1) разделение стеков существенно уменьшает вероятность/риски эксплуатации ошибок
> переполнения буферов размещенных на стеке.

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

> 3) в RISC-V ISA для инструкций JAL и JALR явно специфицированы автоматическое
> выполнение push/pop в RAS (return-address stack), т.е. «уши» аппаратного стека
> всё-таки торчат, но и нет проблем отделить RAS от SP с данными.

Обычное поведение обычного проца и упрощает некоторые системные вещи типа handler'ов если хочется их делать все же не на ассемблере, бжад. А кому сейчас хочется с ассемблером возякаться, даже там?!

> предлагают заменять "неперспективные Эльбрусы" на "прогрессивные RISC-V".

Я не думаю что это корректная постановка вопроса. Этих эльбрусов существует полторы штуки, с кучей дурных проблем, экосистемы толком нет, полтора инвалида с проприетарным тулчейном и внемайнлайновым викидышем это не вообще экосистема. А заодно вон та чудная фирма за 20, чтоли, лет не смогла то что вон те мелкие стартапы осилили за 4-5 лет.

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

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

234. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от erthink (ok), 13-Сен-22, 13:02 
> Он прекрасен тем что

Удивительно, конечно, что в качестве аргументов вы пересказываете растиражированное содержание рекламных буклетов. Тем не менее, попытаюсь прояснить свою позицию.

Никто не запрещает вам верить в маркетинг о "бело-пушистости" RISC-V и прочее великодушие капиталистов.
Стартаперам действительно удобно разводить инвесторов, в том числе дизайнить и раздавать свои велосипедные ядра.
А студенты уже сдают зачеты, курсовые и даже дипломы, списывая публично доступны блоки ;)

Да, экосистема RISC-V действительно уже позволяет получить несколько дополнительных вариантов ядер для всяческих микроконтроллеров и т.п., в том числе выбирать на фабрике на уровне шаблонов.

Но в RISC-V нет ничего, что как-то принципиально способствовало и/или облегчало создание тиражного high-end процессора общего назначения. Выводить на рынок будет легче, но не создавать.
Скорее наоборот, придется либо оставаться в общей колее, либо убеждать конкурентов и сообщество идти за вами, либо форкать экосистему.

Ядра SiFive очень не плохи, но между ними и топовыми тиражными ЦПУ пропасть: патенты, физдизайн, тираж. Поэтому никакой SiFive ничего не родит на смену x86 или ARM, пока их не купит кто-то из топовых игроков.

Монстры типа штеуда и ибм конечно будут развивать RISC-V, но только в нужном/выгодном им направлении, одновременно черри-пикая все интересное (постоянно скупают стартапы, компании, людей, проекты). В этом суть этой затеи и механизма - одни хотят засветиться и удачно продаться, другие постоянно "стригут газон" чтобы не выросли сорняки-конкуренты.

>> А дальше начинает фигня, напомню: Как у "чистого риска" нет явного указателя стека
> А что же у него есть по вашему?

RTFM

> Я не думаю

Есть подозрение что это кое-то объясняет ;)

> Этих эльбрусов существует полторы штуки, с кучей дурных проблем, экосистемы толком нет, полтора инвалида с проприетарным тулчейном и внемайнлайновым викидышем это не вообще экосистема. А заодно вон та чудная фирма за 20, чтоли, лет не смогла то что вон те мелкие стартапы осилили за 4-5 лет.

Какие стартапы, чего осилили?
Научились VHDL комбинировать, делать прототипы на FPGA и кукарекать на паре конференций...
И это на готовой экосистеме, с готовыми спеками, готовыми блоками, симуляторами, готовым тулченом и сообществом - это примерно "плинтус" в сравнении с результатом МЦСТ.
Байкаловцы хоть и на покупных ядрах и IP-блоках, но довели до продуктовой серии.

> Все же в проце главное не какой там стек, и регистры, а вменяемость общего сочетания парметров. С чем у эльбрусов жесточайше не задалось. Все думали что итаник это фэйл и ниже падать некуда, но оказалось что это не предел.

Ну вот опять колунада в духе маслова, ну сколько можно.

Никто не говорит что e2k идеальная архитектура, что в ней нечего улучшать и/или переделывать и т.п.
Но это (как минимум) несколько принципиально важных решений, собственная разработка, собственные компетенции по всему спектру (от VHDL до компилятора и ОС).

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

Ответить | Правка | Наверх | Cообщить модератору

292. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 17:58 
> Удивительно, конечно, что в качестве аргументов вы пересказываете
> растиражированное содержание рекламных буклетов.

Ну так они ж в целом не врут. Просто хайлайтят пойнт. ИМХО пойнт валидный.

> Никто не запрещает вам верить в маркетинг о "бело-пушистости" RISC-V и прочее
> великодушие капиталистов.

Во первых никакой белизны и пушистости. Свой набор проблем, WIP и все такое. Во вторых, к великодушию отношения не имеет, чистый прагматизм. Остро возбухший после попыток продать ARM нвидии, очень помогло бутстрапу экосистемы :)

> Стартаперам действительно удобно разводить инвесторов, в том числе дизайнить и раздавать
> свои велосипедные ядра.

Так потом это пускают в масспродакшн и получают недурные параметры недорого. И толпа народа УЖЕ этим пользуется. Китайцы выкатили недорогие MCU и апликушники например. Это уже применяется. И приносит прибыль их чипмейкерам. Развод то в чем? Процу не обязательно быть самым самым, влияет общее соотношение.

> А студенты уже сдают зачеты, курсовые и даже дипломы, списывая публично доступны блоки ;)

Как по мне, если у них что-то работающее в результате получается, ну отлично. Е...чие концепции ради концепций без результата всех утомили.

> Да, экосистема RISC-V действительно уже позволяет получить несколько
> дополнительных вариантов ядер для всяческих микроконтроллеров и т.п.,

Она позволяет нехилую вертикальную масштабируемость + реюз знаний, очень эффективно. Когда один тулчейн покрывает все от mcu до серверных апликушников это удобно и я этот тулчейн буду знать сильно лучше чем 3-4 отдельных тулчейна. Это так сложно понять?

> в том числе выбирать на фабрике на уровне шаблонов.

А также встраивать небольшие cpu core в штуки с FPGA, например, комбинируя быструю ASIC-like логику с одной стороны и чуть ли не всю мощь линуха с другой. Попробуйте так с вашими парадигмами вообще. А, ну да, кому всякая измериловка на грани scifi нужна и т.п., не ваш уровень технологий же.

> Но в RISC-V нет ничего, что как-то принципиально способствовало и/или облегчало создание
> тиражного high-end процессора общего назначения.

Тем не менее, насколько я помню алибаба не только себе запилили, но и сорц выложили. Ахренли, китайцы умеют работать на результат, а не страдать высококонцептуальной хней.

> Выводить на рынок будет легче, но не создавать.

А тут надо определиться какая цель. Пропилить из принципа метровый бетонный блок или попасть в пункт назначения обойдя его.

> Скорее наоборот, придется либо оставаться в общей колее, либо убеждать конкурентов и
> сообщество идти за вами, либо форкать экосистему.

Как минимум, большая часть тулсов и софта будет работать и с этим тоже, а от патчей с tune под вооооон тот чип врядли кто откажется. Если производитель готов майнтайнить, конечно, чужую работу делать никто не будет нашару.

> Ядра SiFive очень не плохи, но между ними и топовыми тиражными ЦПУ
> пропасть: патенты, физдизайн, тираж.

Кроме SiFive есть куча других ядер. Конечно же не все они открытые и проч. Их все я уже не знаю, их легион. Ну вон у GigaDevice есть мк на этом, а у Allwinner - апликушники для одноплатников и околовстройки. Китайцы уже за дело взялись по полной. Им как раз удобно что самим не надо тулчейны делать, не их оно.

> Поэтому никакой SiFive ничего не родит на смену x86 или ARM,

RISCV уже основательно двигает ARM в ряде областей. Ну вот как-то фокус новых разработок резко ушел с ARM в RISCV. Извините, даже WD и нвидия в своих чипах на это переходят. Одни вероятно в контроллерах винчей и ssd, вторые в aux ядрах GPU.

> пока их не купит кто-то из топовых игроков.

Интел так то уже пытался. Но совсем не факт что они хотят продаться этом динозавру. И есть эн всяких фаблесов которые RISCV ядра на заказ разрабатывают и продают другим по сходной цене и проч. Экосистема взлетает.

> Монстры типа штеуда и ибм конечно будут развивать RISC-V, но только в
> нужном/выгодном им направлении, одновременно черри-пикая все интересное

Все будут развивать в интересном именно их направлении. Но когда их много, можно будет чипы под задачи выбирать из кучи опций, а если вдруг нужного нет, легко создавать новые, из кубиков. Как с ARM. В этом весь их пойнт.

> (постоянно скупают стартапы, компании, людей, проекты).

За это время появляется толпа новых, а людям часто не нравится работать в замшелых мастодонтах, все же стартапы это совсем другой климат. Круговорот продолжается.

> В этом суть этой затеи и механизма - одни хотят засветиться и удачно продаться,
> другие постоянно "стригут газон" чтобы не выросли сорняки-конкуренты.

RISCV напрямую конкурентом топовых x86 пока еще не является, даже ARM стал всерьез наседать на пятки только недавно. Но вообще вот именно топовый проц зачастую и не надо, только паршиво спроектированому софту. Остальным хватит заурядного проца с хорошим цена/качество и потребление/производительность. У интела с этим "не очень", по обоим пунктам.

> Есть подозрение что это кое-то объясняет ;)

Может быть.

> Какие стартапы, чего осилили?
> Научились VHDL комбинировать, делать прототипы на FPGA и кукарекать на паре конференций...

Ну да. И в результате заваливают рынок дешевыми массовыми чипами. Экосистема взлетает.

> И это на готовой экосистеме, с готовыми спеками, готовыми блоками, симуляторами, готовым
> тулченом и сообществом - это примерно "плинтус" в сравнении с результатом МЦСТ.

МЦСТ: посылают искать в яндекс музее. А если не в музее - то по цене крыла самолета и без перспектив. Ну, а смысл покупать и осваивать чип, который больше производить не могут? Чтобы поиметь сотни бесполезных знаний?

RISCV: посылают на алиэкспресс, можно купить за ...цать баксов одноплатник на этом, без траху с NDA, с доставкой хотькуда, уже майнлайновый линух реально запустить, хоть и с особенностями. А само сочетание позволяет вкатить это в довольно широкий спектр весьма прагматичных задач и делавшее это фирмы в минусе точно не будут. И живут рынком. Почувствуйте разницу.

> Байкаловцы хоть и на покупных ядрах и IP-блоках, но довели до продуктовой серии.

Это которые обанкротились? Видимо они тоже делали что-то не так, но, видимо, крышей не вышли, в отличие от.

> Ну вот опять колунада в духе маслова, ну сколько можно.

Извините, но оно ни ощутимого процента рынка не заняло, даже в РФ, а проприетарные тулчейны, nda и внемайнлайновые ядра это вообще атас. На такую хрень уже даже тормоза типа квалкомов с броадкомами забили.

> Никто не говорит что e2k идеальная архитектура, что в ней нечего улучшать
> и/или переделывать и т.п.

На вид с галерки это все выглядит как "кусок грабель" и "гора родила мышь".

> Но это (как минимум) несколько принципиально важных решений, собственная
> разработка, собственные компетенции по всему спектру (от VHDL до компилятора и ОС).

И кто, пардон, собственник этого, и что это всем остальным кроме этого собственника дает? А, опция вендорлокнуть госов на себя? Я бы на месте госов за ЭТО укатал, ибо подстава. Им так то выгоднее чтобы эн фирмачей рубались и делали дешево и круто, а лучшим из них контракт отдать. Ну, если коррупцию как фактор исключить.

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

Ваши результаты выглядят как издевательство над здравым смыслом. Ну да, пропилили всем назло метр бетона. Хотя целью было совсем не это. И это круто а вы не бакланы, потому что ... что?

Ответить | Правка | Наверх | Cообщить модератору

208. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (203), 13-Сен-22, 10:23 
Достаточно какой-либо распространённой ОС типа Windows авторитарно решить "мы не будем следовать спеке на ISA". Тогда всем компиляторам придётся реализовать то, что нужно реализовать, после чего другие ОС перекатятятся в виду преимуществ указанной конвенции и наличия инструментов.
Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

224. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 12:15 
> Достаточно какой-либо распространённой ОС типа Windows авторитарно решить "мы не будем
> следовать спеке на ISA". Тогда всем компиляторам придётся реализовать то, что
> нужно реализовать, после чего другие ОС перекатятятся в виду преимуществ указанной
> конвенции и наличия инструментов.

Внезапно, в линухе - и тулчейнах *-linux-* все клали большой болт на то что там творится в винде. Представляете себе, в разных ОС может быть разный ABI программ, если вон то почему-то неудобно?! Учитывая что они вот прям на уровне формата бинарей не совместимы, это никого не колышет особо. А тулчейны один фиг довольно разные и еще и вот это там подкрутить - не особая проблема, и ничем не икнется даже.

Ответить | Правка | Наверх | Cообщить модератору

57. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (51), 12-Сен-22, 16:20 
У нас с таким же успехом и покупной ARM попиливали бы, и RISC-V. Думаете, при разрарботке Байкал-М не попиливали?
Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

44. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от я из фейсбука (?), 12-Сен-22, 15:50 
Госдеп уже закалибался донатить гейтсу и айбиэмам с цисками
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

78. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 12-Сен-22, 17:17 
Никто не обсуждает цену на Эльбрус. Поинтересовался, почему розничная цена на давно закупленные платы поднялась вдвое, заминусовали.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

94. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от erthink (ok), 12-Сен-22, 17:52 
> Никто не обсуждает цену на Эльбрус. Поинтересовался, почему розничная цена на давно
> закупленные платы поднялась вдвое, заминусовали.

Не скажу что постоянно следил за ценниками, но за 1.5 года не вижу разницы за целиком собранный e2k (500-1000 рублей в зависимости от конфигурации).

Может в долларах/евро цена поплыла из-за падения их курса?

Ответить | Правка | Наверх | Cообщить модератору

97. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 12-Сен-22, 18:00 
«Материнская плата E8C-mITX на базе Эльбрус-8С и 2D-видео» стоила чуть больше 120 и подорожала у того же продавца вдвое одновременно с ажиотажем на обычную комплектуху. Та плата, что получше за 180, тогда же и исчезла. Если в сборе - может быть не так заметно, компенсировано снижением цены на остальное, либо продавец другой и ничего не менял. Но в последнем случае не понятно, зачем тут рекламируют поднявшего цену.
Ответить | Правка | Наверх | Cообщить модератору

103. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от erthink (ok), 12-Сен-22, 18:09 
Не следил, поэтому спорить не буду.

От себя могу сказать, что купленный 1.5 года назад 8СВ сейчас стоит примерно столько-же.

Ответить | Правка | Наверх | Cообщить модератору

173. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Аноним (173), 13-Сен-22, 04:36 

> Материнская плата E8C-mITX на базе Эльбрус-8С и 2D-видео» стоила чуть больше 120
> Та плата, что получше за 180, тогда же и исчезла.

О чем я выше и говорил. Вот например https://aliexpress.ru/wholesale?catId=&SearchText=minipc здесь есть и модели на селеронах по цене примерно в 10-15 тысяч, и на рязанях более новых моделях 30-40 тысяч. Импортозаместили? Проозводительность никакая? Цена огромная? В начличие нет? Ничего не напоминает? Там всеми вами любимый ССССР например?

Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

189. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 13-Сен-22, 08:46 
Мне не интересна тема «Эльбрус стоит дороже ширпотреба». Если посмотреть приличные серверные доски, сравнить тираж - всё становится понятно. Меня удивляет, что спекулянты взвинтили цену на уже купленное оборудование и это преподносится как что-то хорошее, тогда как при не столь высоком повышении цен на ширпотреб стоял ор о предательстве национальных интересов и вписывалась ФАС.

И обратите внимание: erthink владеет Эльбрусом и не спорит, лишь рассказывает о своём опыте. А какие-то фатаники опять минусуют, и я на 146% уверен, что они сами для себя никогда и не думали приобрести этот Эльбрус, иначе бы знали цену.

Ответить | Правка | Наверх | Cообщить модератору

197. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (196), 13-Сен-22, 09:57 
> Мне не интересна тема «Эльбрус стоит дороже ширпотреба».

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

Вот сейчас все будут пля почки продавать или в музеях куандекса шеллы выпрашивать. Или, скорее, купят на алике борды за копье, в том числе и RISCV, и приобщатся к более другой экосистеме. Показать где за цать баксов 64-битный RISCV уже можно купить или сами найдете? А, да, если вы думали что страшнее госдепа зверя нет, обломитесь :). Китай видите ли не даст вам дыхнуть и в low end, где вы теоретически могли бы иметь какие-то шансы если забыть про идиотов в управлении процессами.

Ответить | Правка | Наверх | Cообщить модератору

217. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 11:50 
>> Мне не интересна тема «Эльбрус стоит дороже ширпотреба».
> Это однако смогло угробить даже итаника

А точно "это"?

Тут человек из интела рассказывает совсем другую картину:

---
Но все же Itanium, как и Титаник, видимо, был проклят с самого начала. Дело в том, что против него играли как религия (not invented here!) так и политка. А в средневековом государстве – это необоримая сила. “Крестным отцом” Itanium был Mike Fister тогдашний глава серверного подразделения Intel. И в начале 2000х между ним и Полом Отеллини развернулась борьба за то, кто станет следующим  CEO Intel после Kрейга Баррета.  Борьбу эту Captain Itanic проиграл и ушел в CEO в Cadence (который, безусловно уважаемая компания, но все же не Intel). Также ко дну пошло его детище. А спасать было некому  - Отеллини Itanium не жаловал. Уж не знаю вследствие “разборок” начала 2000х или по каким то другим причинам... К тому же обнаружилась масса других проблем.

* Индустрия как то сразу не поверила в Itanium. Портирование софта шло без особого энтузиазма. А Intel не решился на большую ставку – Itanium enabling strategy всегда оставляла у меня ощущение какой то недосказанности...

* Возможно расчет был на  x86 compatibility block, но именно он стал больным местом Itanium – энергии потреблял больше чем весь остальной процессор и грелся как сволочь. Бинарный транслятор также не выглядел панацеей: пробразование из CISCа во VLIW является одним из самых сложных (хотя на Эльбрусе как то работает)...

* Насколько увлекательным являлось написание микрокернелов для Itanium на ассемблере – настолько кошмарным было портирование приложений. Компилятор является основным камнем преткновения для архитектуры VLIW/EPIC. Одно из немногих исключений, которое я знаю – опять же Эльбрус. Но для того чтобы довести его компилятор до ума потребовалось порядка 20 лет. Интел столько ждать не захотел...

* Ну и последнее – Itanium всегда выпускался с отставанием на шаг по техпроцессу от x86. И в этом трудно не усмотреть наличие “доброй” политической воли.
--- http://habr.com/ru/post/664682/

Вы там завязывайте, может, с домыслами-то и масловскими сказочками?

Ответить | Правка | Наверх | Cообщить модератору

225. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 13-Сен-22, 12:17 
>> Мне не интересна тема «Эльбрус стоит дороже ширпотреба».
> Это однако смогло угробить даже итаника, его экосистема просто не взлетела. А
> все потому что какой-то тупак в интеле видимо вякал то же
> что и ты, случайно убив свое же направление всего одним тупым
> решением.

А если бы был опыт использования компиляторов в то время, тогда были бы знания, что компиляторы и под IA32 не очень умели. Потому что не хватало памяти, в частности.

> Вот сейчас все будут пля почки продавать или в музеях куандекса шеллы
> выпрашивать. Или, скорее, купят на алике борды за копье, в том
> числе и RISCV, и приобщатся к более другой экосистеме.

Мне не интересно, что будут делать все. Эльбрус по шеллу мне не нужен, только живой. Потому и странные взвинчивания цен воспринимаю с удивлением. А RISC-V с сектой поддержки и чрезмерно активными фанатиками не интересен ни в каком виде.

Ответить | Правка | Наверх | Cообщить модератору

233. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 12:58 
> А если бы был опыт использования компиляторов в то время, тогда были
> бы знания, что компиляторы и под IA32 не очень умели. Потому
> что не хватало памяти, в частности.

У IA32 видите ли были забойные преимущества.
1) Дешевый.
2) Делается несколькими вендорами.
3) Софт уже все же есть и кой-как оптимизировали. А даже и асмовыми вставками, там где компилер подводил.

Но вот какой псих будет разучивать асм проца которого у него даже нет? А чтобы он был... эээ... платить несколько килобаксов за тормозной чип, 100% вендорлок, отсутствие софта и проч очень так себе с "пользовательской" сотороны вопроса. А кодеры и энтузиасты может и не бедные, но и не рокфеллеры, чтобы столько денег "на всякий" выкинуть в какой-то, извините, хлам.

Если бы они сделали суперлайт, в разы тормознее, зато за 20 баксов - имхо экосистема пошла бы на взлет как ракета. За цать баксов - многое прощают. Даже это. И купят и чисто из любопытства, посмотреть "не получится ли что-то дельное". У многих получится фигня. Но некоторые постепенно допилят и нормальный софт.

> Мне не интересно, что будут делать все. Эльбрус по шеллу мне не нужен, только живой.

И кмк точно так же посчитает и 99.9(9)% кодеров.

> Потому и странные взвинчивания цен воспринимаю с удивлением.

Что самое интересное, это даже частично-рыночный маневр. У них образовалось полкило unobtainium'а. При том нового, кажется, не будет. А откуда?

> А RISC-V с сектой поддержки и чрезмерно активными фанатиками не интересен
> ни в каком виде.

А вот это уже ни на что не влияет. Один какой-то n00by ничего не решает против большой экосистемы. Значит это случится без вас. У вас не будет опции ворочать мелкими дешевыми проциками и влезть в определенные ниши. С чисто меркантильной точки зрения "-1 неглупый конкурент" для вот лично меня - вообще фича, а не баг.

Ответить | Правка | К родителю #225 | Наверх | Cообщить модератору

116. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от a_kusb (ok), 12-Сен-22, 19:11 
// Интересно, довольно палевная накрутка плюсиков.
Я не прикапываюсь кстати, я довольно абстрактно.
Сильно сомневаюсь что Майкрософт с прочими пилят бюджет настолько безнадёжно. Но думаю они с удовольствием участвуют в распилах с "другой" стороны финансовых потоков.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

55. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –2 +/–
Сообщение от Аноним (-), 12-Сен-22, 16:18 
> Да и ценник будет в раз 10 меньше. Покупая отечественное (я имею
> в виду импортозамещенное аналоговнетное) покупатель должен иметь в виду

Что это хрен купишь, а что где его теперь производить? В зеленограде? Оттуда повезет если это с PIII зарубится, какой кор2, о чем вы?!

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

71. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 16:58 
> Что это хрен купишь

http://imaxai.ru
http://bitblaze.ru

> Оттуда повезет если это с PIII зарубится, какой кор2, о чем вы?!

Вы там это, поправляйтесь уже и больше с лопаты не жрите :)

Ответить | Правка | Наверх | Cообщить модератору

99. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Аноним (99), 12-Сен-22, 18:04 
>с лопаты не жрите

Пожалуйста, не надо это говорить пациентам, им и так тяжело.

Ответить | Правка | Наверх | Cообщить модератору

198. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 10:03 
> Вы там это, поправляйтесь уже и больше с лопаты не жрите :)

Это какие-то складские остатки? Ну или где это добро производить по нормальным нанометрам планируется вообще? Потому что на зеликовских LP это будет полное ололо, а более приличные фабы не захотят подставляться работой с таким клиентом, имхо.

Прикольно конечно размахивать флагом, но... знаете в чем ваша трабла? Признавать ошибки вы не умеете от слова вообще.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

218. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 11:51 
> Прикольно конечно размахивать флагом, но... знаете в чем ваша трабла?
> Признавать ошибки вы не умеете от слова вообще.

Умеем.  Просто не спешим, роняя тапки, признавать именно своими ошибками на сейчас спорные.

Пусть время покажет.

Ответить | Правка | Наверх | Cообщить модератору

237. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 13:15 
> Умеем.  Просто не спешим, роняя тапки, признавать именно своими ошибками на
> сейчас спорные.

А точно сей-час? Может, сей-год? Или, даже, сея-декада, если не сей-век?

> Пусть время покажет.

С этой точки зрения за 20 лет результат вроде бы довольно маргинальный по влиянию на окружающий мир, не? Более маргинальный чем у вон той кучки копеечных RISCV, которые уже объявили себя покемонами и захватывают мир, никого особо не спращивая. Китайцам, кстати, очень зашло, а бонусом можно не спрашивать мнение американцев и ARM, а просто шлепать чипы, no strings attached. Удобно, так то. И достаточно эффективно.

Ответить | Правка | Наверх | Cообщить модератору

123. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Артём (?), 12-Сен-22, 19:39 
всю мцст приперли минусовать тебя кажись
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

219. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 11:52 
> всю мцст приперли минусовать тебя кажись

Гм, забавная идея -- может, действительно коллегам ссылочку отправить?
Хотя лучше не отвлекать от полезного, думаю.

Ответить | Правка | Наверх | Cообщить модератору

9. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от DeerFriend (?), 12-Сен-22, 14:49 
А кто будет учитывать 70% падение производительности при невыключении защиты на интелях?
Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

43. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от Beta Version (ok), 12-Сен-22, 15:47 
>Эльбрус по интелу это Core 2 Duo.

Как ты их так в лоб сравниваешь? Это же две разные архитектуры.

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

69. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 16:49 
> Эльбрус по интелу это Core 2 Duo

Это касалось 4С на 800 МГц после переезда с lcc 1.19 на 1.20 применительно к Xfce-десктопу по моей личной оценке, если что ("до" -- скорее как старший PIII на ощупь был; разумеется, до того, как маленькие интеловые шалости начали выходить на публику и обкладываться вот такенными затычками).

Сейчас пишу с рабочего 8С, который смотрит на это всё с недоумением.  А дома ждёт 16С, который подороже соплерона будет, но 4K декодирует примерно на одном ядре и в целом машина совсем другого класса.  Ну и надо бы переезжать на lcc 1.26, уже стабилизировали.

PS: таких психов, кстати, уже не получается посчитать на пальцах одной руки -- за лето ещё двое (или трое? путаться начал) прибавились %)

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

100. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Аноним (99), 12-Сен-22, 18:06 
Каких психов?
Ответить | Правка | Наверх | Cообщить модератору

109. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 18:14 
> Каких психов?

Эльбрусоводов в домашних условиях вроде erthink, ge0gr4f, меня... (кстати, да -- минимум трое опеннетчиков среди таковых оказались, ещё одного человека "светить" не буду)

Ср.: http://altlinux.org/эльбрус/faq#Видео -> http://zen.yandex.ru/id/610319187e2db54b295a6aa4

Ответить | Правка | Наверх | Cообщить модератору

142. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от я из фейсбука (?), 13-Сен-22, 00:28 
Если бы даже распильщики не пользовались этими своими эльбрусами, это был бы полный фейл. Хотя и такое случается
Ответить | Правка | Наверх | Cообщить модератору

187. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от onanim (?), 13-Сен-22, 08:34 
я разинул пасть и заорал, когда на презентации новых мобил хуавея их директор или кто там засветил свой айфон
Ответить | Правка | Наверх | Cообщить модератору

174. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от Аноним (173), 13-Сен-22, 04:44 
>> Каких психов?
> Эльбрусоводов в домашних условиях вроде erthink, ge0gr4f, меня... (кстати, да -- минимум
> трое опеннетчиков среди таковых оказались, ещё одного человека "светить" не буду)
> Ср.: http://altlinux.org/эльбрус/faq#Видео -> http://zen.yandex.ru/id/610319187e2db54b295a6aa4
> Эльбрусоводов в домашних условиях
> bitblaze
> В Разработке
> Сделать предзаказ
> БАЙКАЛ-М

Видел я видео обзор на этот ваш "ноутбук" в корпус которого по сути встроили "тв-приставку" и подложили тяжелых болтов заварили сваркой для веса. Графика какая? Mali? Драйвера есть? Конечно нет. На видео что я видел даже курсор мыши при передвижении "моргает", а знаете где еще моргает? На каждой второй тв-приставке на который очумельнцы портировали armbian, slackware-arm64 и т.д тоже "моргает", а почему на них все так плохо? Потому что драйверов нет. А почему драйверов нет? Потому что mali позиционируется как пропреетарный вендор для Android. Сними портрет вождя со стены, а то в его паралельную реальность засосет. Почаще на свежый воздух выходи, пользуйся VPN.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

191. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от n00by (ok), 13-Сен-22, 09:08 
Драйвера открытые есть для Mali. А вот кто их «отреверсил» - это уже очень интересно, чем оно закончится.
Ответить | Правка | Наверх | Cообщить модератору

211. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 10:38 
> Драйвера открытые есть для Mali. А вот кто их «отреверсил» - это
> уже очень интересно, чем оно закончится.

Вроде пока все довольно неплохо выглядит. Драйверы есть. Открытые. Замайнлайнены. И вообще-то эти GPU уже запускается out of the box на майнлайновом линухе. Да и для многих други драверы где реверснули, где сам производитель расщедрился, как с powervr. А вы там можете гадать на кофейной гуще, если вам так удобнее.

Ответить | Правка | Наверх | Cообщить модератору

226. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 13-Сен-22, 12:25 
Здравствуйте, дети. Сегодня мы проводим урок информатики на красивых кампегах с новым ядром Linux. Давайте все дружно похлопаем программистам из Collabora, благодаря кому это стало возможным. Все хотят стать такими же крутыми и научиться кодить драйвера, а не просто упаковывать их в пакетики? Тогда давайте внимательно изучим биографию...
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

364. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 14-Сен-22, 11:41 
>> Здравствуйте, дети. Сегодня мы проводим урок информатики на красивых кампегах с новым
>> ядром Linux. Давайте все дружно похлопаем программистам из Collabora, благодаря кому
>> это стало возможным. Все хотят стать такими же крутыми и научиться
>> кодить драйвера, а не просто упаковывать их в пакетики? Тогда давайте
>> внимательно изучим биографию...
> Кто хочет - может равняться на тугих орков, изучающих содержимое трусов

В том и дело, что я не хочу на вас ровняться. Не хочу, что бы вы своё содержимое вываливали в биографии на всеобщее обозрение для изучения, будто бы это что-то хорошее. При этом других реверсеров GTA гнобили бы в судах.

Ответить | Правка | К родителю #173 | Наверх | Cообщить модератору

220. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 12:00 
> Видел я видео обзор

А я байкалы руками щупал, вот и спокойно дожидаюсь ноутбука на e2c3 (не акация и не ход конём, а двухъядерный эльбрус со встроенной графикой -- инженерка такая уже на стенде есть).  От тех же омичей, которым в качестве одного из образцов компоновки отправил упокоившийся UX31A.

> а то в его паралельную реальность засосет.
> Почаще на свежый воздух выходи, пользуйся VPN.

Про свежий воздух совершенно правы (московская природа тоже хороша), а вот через VPN как раз Вас   по малоумию и засосало в параллельную реальность, где "сияющий град на холме" не бомбил десятки стран и не поставил "свою" же страну на грань гражданки ради той самой власти, в жажде которой обвиняет всех остальных.

Так что да, прогуляйтесь по парку или за городом, пока солнышко блистает.  И возьмите хотя бы недельку отпуска от интернета -- глядишь, инфоугар из головы начнёт выветриваться.

...вспомнилось: "мы не продаём алкоголь тем, кто не достиг ничего, даже 18 лет" (ц)

Ответить | Правка | К родителю #174 | Наверх | Cообщить модератору

255. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (99), 13-Сен-22, 15:35 
>Эльбрусоводов в домашних условиях

А почему психов то? Вы жертвы троллей?

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

15. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +7 +/–
Сообщение от erthink (ok), 12-Сен-22, 14:59 
Если в штеудах закрыть _все_ спекулятивные дыры, но они будут медленнее сопоставимых Эльбрусов (имеется в виду 16C на 16 нм).

Но тут всё-таки есть вопрос, нужно ли (есть ли смысл) закрывать все интеловские дыры в спекулятивном выполнении, если в микрокоде вообще не понятно что, а в ЦПУ интегрирован руткит с отдельным независимым процессорным ядром (aka AMT).

Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

27. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Без аргументов (?), 12-Сен-22, 15:25 
В Эльбрусах тоже есть спекулятивное выполнение)) просто уязвимость невозможно найти в том, чего нет.
Ответить | Правка | Наверх | Cообщить модератору

59. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +5 +/–
Сообщение от Аноним (51), 12-Сен-22, 16:25 
Чёт не распарсил. Как бы, две части предложения противоречат друг другу.
Ответить | Правка | Наверх | Cообщить модератору

72. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 16:59 
Он пытался сострить, но не учёл как минимум http://elbrus.6te.net ;-)
Ответить | Правка | Наверх | Cообщить модератору

120. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от a_kusb (ok), 12-Сен-22, 19:19 
> Он пытался сострить, но не учёл как минимум http://elbrus.6te.net ;-)

В принципе эффект неуловимого Джо. Может и в ARM меньше дыры бросаются в глаза, что до эльбрусов то.

Ответить | Правка | Наверх | Cообщить модератору

152. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 01:34 
Игра в видео не удачный пример. Это игра годов, когда были в ходу Pentium 3. Ещёбы эта игра не заработала как положено. Тест скорее всего видеокарты.

Ах да видео о корпусе для ПК.

Игры меня не интересуют.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

62. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –2 +/–
Сообщение от Аноним (62), 12-Сен-22, 16:30 
> Если в штеудах закрыть _все_ спекулятивные дыры, но они будут медленнее сопоставимых Эльбрусов (имеется в виду 16C на 16 нм).

Ждём нормально оформленного теста.

> Но тут всё-таки есть вопрос, нужно ли (есть ли смысл) закрывать все интеловские дыры в спекулятивном выполнении

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

> если в микрокоде вообще не понятно что, а в ЦПУ интегрирован руткит с отдельным независимым процессорным ядром (aka AMT).

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

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

73. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +3 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 17:01 
> и тут с интелами можно получать производительность на порядки выше эльбрусовской.

Вас же не затруднит циферки-то привести?  Вот прям-таки в сотни, тыщи и прочие #миллионы разов отличающиеся?

> у эльбрусов, например, руткит сидит и в железе, и в микрокоде,
> а вдобавок ещё и в комиляторе.

В Вас сидит балабол.

Впрочем, можете попытаться опровергнуть.

Ответить | Правка | Наверх | Cообщить модератору

67. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (67), 12-Сен-22, 16:47 
а что в 7й сделают эдакое? Когда она выйдет и где можно будет купить?
Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

91. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от n00by (ok), 12-Сен-22, 17:43 
> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).

Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов не очень работает. Но зависит от байткода и ВМ, конечно.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

239. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от erthink (ok), 13-Сен-22, 13:28 
>> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
>> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).
> Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов
> не очень работает. Но зависит от байткода и ВМ, конечно.

ВМ - более абстрактная вещь, но если говорить о байткоде, то предсказание переходов работает не плохо.
Очень хорошо предсказываются все служебные переходы, leaf-циклы и более-менее ветвления в них.

Но основное замедление не из-за отсутствия предсказателя, а из-за отсутствия спекулятивного выполнения и низкой заполняемости ШК (широких команд).

Переименование регистров и спекулятивное выполнение позволяет out-of-order ЦПУ начать выполнять следующий и даже через-один элемент байт-кода. Тогда как на VLIW каждый элемент байт-кода в большинстве случаев требует выполнения нескольких крайне рыхлых ШК.

Ответить | Правка | Наверх | Cообщить модератору

275. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 13-Сен-22, 17:14 
>>> Ну и скорость - смотря как сравнивать, например байткод Эльбрусы выполняют/интерпретируют
>>> медленнее (и будут медленнее как минимум до релиза 7-й версии архитектуры).
>> Мне казалось, что Эльбрус наоборот должен выигрывать, поскольку в ВМ предсказатель переходов
>> не очень работает. Но зависит от байткода и ВМ, конечно.
> ВМ - более абстрактная вещь, но если говорить о байткоде, то предсказание
> переходов работает не плохо.
> Очень хорошо предсказываются все служебные переходы, leaf-циклы и более-менее ветвления
> в них.

Похоже, я что-то недопонимаю. Допустим, у абстрактного процессора есть 256 команд. Их исполняет switch в цикле. Какие-то опкоды можно сгруппировать, в итоге получаем 32 case. При компиляции такой «ВМ» окажется, что switch представляет из себя косвенный переход по таблице адресов в памяти. При таком количестве предсказание на основе истории переходов работает не очень, вот что пишет Интел:

B.8.3.2
Virtual Tables and Indirect Calls
17. Virtual Table Usage: BR_IND_CALL_EXEC / INST_RETIRED.ANY
A high value for the ratio Virtual Table Usage indicates that the code includes many indirect calls. The
destination address of an indirect call is hard to predict.

и вот что рекомендует, что бы упростить предсказание:

Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are
present, try to put the most likely target of an indirect branch immediately following the indirect
branch. Alternatively, if indirect branches are common but they cannot be predicted by branch
prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the
processor from decoding down the fall-through path.

Для тестов реализовал интерпретатор байт-кода OCaml на асме AMD64, при этом вместо косвенного перехода по таблице вычислял адрес обработчика умножением на степень двойки (на старых поколениях архитекруры это было бы быстрее, поскольку исключается чтение адреса из памяти).

Вот такие печальные результаты предсказателя из perf stat


    12 440 035 801      instructions:u            #    0,48  insn per cycle
     1 039 998 618      branch-misses:u           #   33,33% of all branches

Что бы улучшить ситуацию, пришлось добавить условный переход, который никогда не исполняется

 execute_instruction:
     mov    eax, [opcode]
     shl    rax, instruction_size_log2
+;    Переход никогда не происходит. Предотвращает предсказания следующего
+;    косвенного перехода, во многих случаях некорректные.
+    jc    .stop
     lea    rax, [rax + vm_base + vm_base_lbl - execute_instruction]
     next_opcode
     jmp    rax
-    ud2
+.stop:    ud2

Здесь промахов нет, но обратите внимание - всего одна инструкция за такт, что явно меньше возможного.

    11 600 026 289      instructions:u            #    1,21  insn per cycle
        80 002 443      branch-misses:u           #    3,51% of all branches

Последние результаты блики к оригинальному интерпретатору, написанному на Си. В той реализации файл с байткодом считывается в память и каждый опкод заменяется адресом обработчика, в последствии исполняется расширением GCC goto *ptr.

Если же опкодов мало и их обработчики объёмные, тогда предсказатель должен повести себя лучше, но много ли таких ВМ?

> Но основное замедление не из-за отсутствия предсказателя, а из-за отсутствия спекулятивного
> выполнения и низкой заполняемости ШК (широких команд).
> Переименование регистров и спекулятивное выполнение позволяет out-of-order ЦПУ начать
> выполнять следующий и даже через-один элемент байт-кода. Тогда как на VLIW
> каждый элемент байт-кода в большинстве случаев требует выполнения нескольких крайне рыхлых
> ШК.

По-моему, в примере выше процессор не знает, что ему можно исполнить.

Ответить | Правка | Наверх | Cообщить модератору

321. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от erthink (ok), 13-Сен-22, 20:18 
>[оверквотинг удален]
> +; Переход никогда не происходит. Предотвращает предсказания следующего
> +; косвенного перехода, во многих случаях некорректные.
> + jc .stop
>   lea rax, [rax + vm_base + vm_base_lbl - execute_instruction]
>   next_opcode
>   jmp rax
> - ud2
> +.stop: ud2
>
> Здесь промахов нет, но обратите внимание - всего одна инструкция за такт,

Всё примерно верно, но только иначе.

Базовый паттерн goto jump_table[*bytecode_ip++], соответственно out-of-order процессор может "узнать" адрес перехода еще до реального выполнения инструкций перед goto.
Условных переходов тут нет (можно избавиться), поэтому предсказывать нечего.

Если же инструкция байткода соответствует условному переходу, то вот тогда может участвовать предсказатель.
И у всех современных ЦПУ он будет работать и верно предсказывать переходы в случае циклов в байткоде.

Сложно возникают только если в байткоде есть цикл, а внутри него оператор if, которые реализуются через один опкод, но в актуальном коде работают в разных плечах.
Тогда просто предсказатель начинает путаться, но штеудовский во многих случаях умеет подстраиваться (работает по принципу электронной гадалки).

Как-то так.

Ответить | Правка | Наверх | Cообщить модератору

396. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от n00by (ok), 17-Сен-22, 08:14 
>[оверквотинг удален]
> Базовый паттерн goto jump_table[*bytecode_ip++], соответственно out-of-order процессор
> может "узнать" адрес перехода еще до реального выполнения инструкций перед goto.
> Условных переходов тут нет (можно избавиться), поэтому предсказывать нечего.
> Если же инструкция байткода соответствует условному переходу, то вот тогда может участвовать
> предсказатель.
> И у всех современных ЦПУ он будет работать и верно предсказывать переходы
> в случае циклов в байткоде.
> Сложно возникают только если в байткоде есть цикл, а внутри него оператор
> if, которые реализуются через один опкод, но в актуальном коде работают
> в разных плечах.

Да, те замеры проводились на байткоде, полученном вот из такого исходника:


let rec tailcall4 a b c d =
  if a < 0
  then b
  else tailcall4 (a-1) (b+1) (c+2) (d+3)
По-моему, цикл с выходом по условию - достаточно частая конструкция.

> Тогда просто предсказатель начинает путаться, но штеудовский во многих случаях умеет подстраиваться
> (работает по принципу электронной гадалки).

То есть Интел хорошо работает не во всех случаях. Соответственно, когда это критично, интерпретаторы и/или исполняемую программу оптимизируют с учётом особенностей имеющегося процессора. Под Эльбрус собирают уже готовое, а не под него спроектированное. Возможно, это не решающий фактор, но наверняка играет роль. Если так, то получается, что имеющийся «бесплатный» открытый код отчасти представляет собой эдакий чемодан без ручки, реальная цена за него - это негатив к Эльбрусу.

> Как-то так.

Ответить | Правка | Наверх | Cообщить модератору

20. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +3 +/–
Сообщение от Аноним (-), 12-Сен-22, 15:14 
А где сейчас можно пощупать цп эльбрус?
Для этого на свободный тайвань ехать надо? Думаете остались образцы?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

25. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +5 +/–
Сообщение от erthink (ok), 12-Сен-22, 15:23 
> А где сейчас можно пощупать цп эльбрус?
> Для этого на свободный тайвань ехать надо? Думаете остались образцы?

МЦСТ даёт разработчикам доступ к тестовым стендам.

Bitblaze продаёт, в том числе частным лицам.
Пока в наличие что-то точно есть, но вероятно что актуальные процессоры 5-й и 6-й версий архитектуры уже закончились.

Ответить | Правка | Наверх | Cообщить модератору

32. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Аноним (-), 12-Сен-22, 15:34 
Ну то есть распродаются товарные остатки?
А что предполагается делать дальше?
Доводы вида: глобальный мир, все свое не обязательно иметь итд показали ведь свою несостоятельность?!
Ответить | Правка | Наверх | Cообщить модератору

60. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (51), 12-Сен-22, 16:27 
А дальше делать на 90 нм-ах ;)
Ответить | Правка | Наверх | Cообщить модератору

76. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 17:09 
А дальше "весь мир" прикидывает, как быть без неона (китайцам свой самим нужон).  Ну или что пилить под собой сук всё-таки было архиглупо.
Ответить | Правка | Наверх | Cообщить модератору

108. Скрыто модератором  –1 +/–
Сообщение от Аноним (-), 12-Сен-22, 18:11 
Ответить | Правка | Наверх | Cообщить модератору

113. Скрыто модератором  –1 +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 18:24 
Ответить | Правка | Наверх | Cообщить модератору

124. Скрыто модератором  +/–
Сообщение от Аноним (-), 12-Сен-22, 20:09 
Ответить | Правка | Наверх | Cообщить модератору

132. Скрыто модератором  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 21:24 
Ответить | Правка | Наверх | Cообщить модератору

140. Скрыто модератором  +1 +/–
Сообщение от Аноним (-), 12-Сен-22, 23:20 
Ответить | Правка | Наверх | Cообщить модератору

360. Скрыто модератором  +/–
Сообщение от Аноним (-), 14-Сен-22, 09:40 
Ответить | Правка | Наверх | Cообщить модератору

195. Скрыто модератором  +1 +/–
Сообщение от n00by (ok), 13-Сен-22, 09:36 
Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

199. Скрыто модератором  +1 +/–
Сообщение от Аноним (-), 13-Сен-22, 10:12 
Ответить | Правка | Наверх | Cообщить модератору

228. Скрыто модератором  +/–
Сообщение от n00by (ok), 13-Сен-22, 12:38 
Ответить | Правка | Наверх | Cообщить модератору

232. Скрыто модератором  +/–
Сообщение от Аноним (-), 13-Сен-22, 12:58 
Ответить | Правка | Наверх | Cообщить модератору

235. Скрыто модератором  +/–
Сообщение от n00by (ok), 13-Сен-22, 13:05 
Ответить | Правка | К родителю #232 | Наверх | Cообщить модератору

240. Скрыто модератором  +/–
Сообщение от Аноним (240), 13-Сен-22, 13:49 
Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

261. Скрыто модератором  +/–
Сообщение от n00by (ok), 13-Сен-22, 16:07 
Ответить | Правка | К родителю #240 | Наверх | Cообщить модератору

286. Скрыто модератором  +/–
Сообщение от Аноним (-), 13-Сен-22, 17:46 
Ответить | Правка | К родителю #261 | Наверх | Cообщить модератору

366. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 12:05 
Ответить | Правка | К родителю #286 | Наверх | Cообщить модератору

371. Скрыто модератором  +/–
Сообщение от Аноним (-), 14-Сен-22, 14:15 
Ответить | Правка | К родителю #366 | Наверх | Cообщить модератору

380. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 16:31 
Ответить | Правка | К родителю #371 | Наверх | Cообщить модератору

388. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 18:31 
Ответить | Правка | Наверх | Cообщить модератору

390. Скрыто модератором  +/–
Сообщение от Анонн (?), 14-Сен-22, 18:38 
Ответить | Правка | К родителю #388 | Наверх | Cообщить модератору

393. Скрыто модератором  +/–
Сообщение от n00by (ok), 15-Сен-22, 10:42 
Ответить | Правка | К родителю #390 | Наверх | Cообщить модератору

361. Скрыто модератором  +/–
Сообщение от Аноним (-), 14-Сен-22, 09:54 
Ответить | Правка | К родителю #235 | Наверх | Cообщить модератору

230. Скрыто модератором  +/–
Сообщение от Аноним (-), 13-Сен-22, 12:49 
Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

236. Скрыто модератором  +/–
Сообщение от n00by (ok), 13-Сен-22, 13:08 
Ответить | Правка | Наверх | Cообщить модератору

241. Скрыто модератором  +/–
Сообщение от Аноним (240), 13-Сен-22, 13:55 
Ответить | Правка | Наверх | Cообщить модератору

258. Скрыто модератором  +/–
Сообщение от n00by (ok), 13-Сен-22, 15:58 
Ответить | Правка | К родителю #241 | Наверх | Cообщить модератору

288. Скрыто модератором  +/–
Сообщение от Аноним (-), 13-Сен-22, 17:49 
Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

367. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 12:15 
Ответить | Правка | К родителю #288 | Наверх | Cообщить модератору

376. Скрыто модератором  +/–
Сообщение от Аноним (-), 14-Сен-22, 14:54 
Ответить | Правка | К родителю #367 | Наверх | Cообщить модератору

314. Скрыто модератором  +/–
Сообщение от Аноним (314), 13-Сен-22, 19:46 
Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

368. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 12:25 
Ответить | Правка | К родителю #314 | Наверх | Cообщить модератору

370. Скрыто модератором  +/–
Сообщение от Аноним (-), 14-Сен-22, 14:09 
Ответить | Правка | К родителю #368 | Наверх | Cообщить модератору

381. Скрыто модератором  +/–
Сообщение от n00by (ok), 14-Сен-22, 16:36 
Ответить | Правка | К родителю #370 | Наверх | Cообщить модератору

389. Скрыто модератором  +/–
Сообщение от Анонн (?), 14-Сен-22, 18:31 
Ответить | Правка | К родителю #381 | Наверх | Cообщить модератору

392. Скрыто модератором  +/–
Сообщение от Аноним (99), 15-Сен-22, 00:49 
Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

394. Скрыто модератором  +/–
Сообщение от n00by (ok), 15-Сен-22, 11:05 
Ответить | Правка | Наверх | Cообщить модератору

297. Скрыто модератором  +/–
Сообщение от Аноним (-), 13-Сен-22, 18:52 
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

377. Скрыто модератором  +/–
Сообщение от Аноним (99), 14-Сен-22, 15:14 
Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

131. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от edo (ok), 12-Сен-22, 21:13 
не слышал, чтобы какой-нибудь завод по производству процессоров встал из-за дефицита неона. и не думаю, что услышу: не такая это высокотехнологичная вещь, чтобы оказалось, что весь мир не может решить проблему.

а вот эльбрусы (и байкалы тоже) не производятся уже сейчас. с полгода точно. и перспектив возобновления производства не видно.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

133. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 21:25 
Вы много чего не слышали, поинтересуйтесь.
Ответить | Правка | Наверх | Cообщить модератору

143. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от я из фейсбука (?), 13-Сен-22, 00:31 
Вся мировая полупроводниковая отрасль держится на российском неоне. Записали.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

200. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 10:14 
> Вся мировая полупроводниковая отрасль держится на российском неоне. Записали.

Проедет 10 лет, интель и амд положат очередные миллиарды в карманы акционеров, как впрочем и тысячи других фирм. А вон те физиономии продолжат вещать как там бедненьким фигово без их неона, бла-бла-бла. Рассекая на ладе-калине без АКПП.

Это мое предсказание будущего. А что, вернемся годиков через 5-10 и проверим? :)

Ответить | Правка | Наверх | Cообщить модератору

153. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 01:49 
Вроде наш неон это какой-то процент и могут обойтись ужаться и без нашего неона. Не точно. Как-то без нашего газа обходятся в уменшенном варианте потребления газа и примрно так можнно и с неоном из рф поступить. Только предположение на уровне гдето что-то слышал. А как будет или на самом деле точно не знаю.
Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

102. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 12-Сен-22, 18:07 
А 65нм может таки запустят?
Или южнокорейцы даже за оверпрайс отказались линию запускать?
Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

75. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 12-Сен-22, 17:08 
> вероятно что актуальные процессоры 5-й и 6-й версий архитектуры
> уже закончились.

8СВ в товарных количествах успели сделать, пока есть.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

201. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 10:15 
> 8СВ в товарных количествах успели сделать, пока есть.

Прикольный горизонт планирования. Расчет на то что потом станет вообще уже не до всяких эльбрусов чтоли?

Ответить | Правка | Наверх | Cообщить модератору

221. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Michael Shigorinemail (ok), 13-Сен-22, 12:04 
Упор на то, что _сейчас_ есть на чём переносить, пилотить и местами внедрять.  _Уже_ есть.
Ответить | Правка | Наверх | Cообщить модератору

362. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 14-Сен-22, 10:09 
> Упор на то, что _сейчас_ есть на чём переносить, пилотить и местами
> внедрять.  _Уже_ есть.

Пилоты через 20 лет разработки? На этом фоне китайские стартапы с RISCV как элонмаск смотрятся.

Ответить | Правка | Наверх | Cообщить модератору

34. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Аноним (30), 12-Сен-22, 15:35 
Если бесплатно, то щупайте современный Эльбрус в Московском яндекс музее, он там есть)
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

41. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +2 +/–
Сообщение от Аноним (41), 12-Сен-22, 15:46 
тут можно запросить шелл

https://elbrus.6te.net/

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

58. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  –1 +/–
Сообщение от Аноним (-), 12-Сен-22, 16:21 
> https://elbrus.6te.net/

Сколько мегахешей оно могет? :)

Ответить | Правка | Наверх | Cообщить модератору

155. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 01:57 
Тебе же показали запуск игры в Линукс с Эльбрусом чего тебе ещё надо? Этого что не достаточно? https://www.opennet.ru/openforum/vsluhforumID3/128413.html#152
Ответить | Правка | Наверх | Cообщить модератору

202. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 13-Сен-22, 10:16 
> Тебе же показали запуск игры в Линукс с Эльбрусом чего тебе ещё
> надо? Этого что не достаточно? https://www.opennet.ru/openforum/vsluhforumID3/128413.html#152

Да нахрен мне игры? Вот помайнить какой-нибудь монеры на халявно шелле - еще можно подумать :)

Ответить | Правка | Наверх | Cообщить модератору

382. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (-), 14-Сен-22, 17:59 
А мня не интересует майнинг и игры. Чем заниматся грабижом лучше майнить. А так майнинг это забор рисурсов у человечества, а в замен не чего не давая. Дерево рубят тоже ресурчы забирают, но из дерева хотябы, что производятЖ тепло например, мебель и т.д. А майнинг это только птребление и ноль продукта - пустой код. По этому я не раматриваю компьюторы для майнинга и для игр.
Ответить | Правка | Наверх | Cообщить модератору

383. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +/–
Сообщение от Аноним (383), 14-Сен-22, 18:02 
Ж не чего не значит лишнее
Ответить | Правка | Наверх | Cообщить модератору

47. "Серьёзное снижение производительности ядра 5.19, вызванное з..."  +1 +/–
Сообщение от Аноним (47), 12-Сен-22, 15:58 
Там же, где и "развитой социализм" :)
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру