От Рядовой-К
К МУРЛО
Дата 06.11.2022 14:44:35
Рубрики Современность; ВВС;

Прочитал в Телеге

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


Что "эльбрусовским" разработчикам-производителям в этом году три раза отказали о финансировании работ.
От KGI
К Рядовой-К (06.11.2022 14:44:35)
Дата 06.11.2022 15:41:01

Re: Прочитал в...

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

>Что "эльбрусовским" разработчикам-производителям в этом году три раза отказали о финансировании работ.

Очень хорошо сделали. А то получается, что разработчики эльбруса в шоколаде , а трахаться с хитрым компилятором , профайлером, врукопашную распараллеливать , предсказывать переходы будут программисты:)).
От S. Engineer
К KGI (06.11.2022 15:41:01)
Дата 06.11.2022 19:13:08

Re: Прочитал в...


> а трахаться с хитрым компилятором , профайлером, врукопашную распараллеливать , предсказывать переходы будут программисты:)).

Расспараллеливанием, предсказанием как раз и занимается хитрый компилятор.
От KGI
К S. Engineer (06.11.2022 19:13:08)
Дата 06.11.2022 19:44:13

Re: Прочитал в...


>> а трахаться с хитрым компилятором , профайлером, врукопашную распараллеливать , предсказывать переходы будут программисты:)).
>
>Расспараллеливанием, предсказанием как раз и занимается хитрый компилятор.

Компилятор == программист. Вначале хитро настраивает хитрый компилятор, потом то что получилось профилирует хитрым профайлером , выясняет что задача работает как на пентиум 1, потом опять настраивает хитрый компилятор и тд... А разработчики эльбруса всегда могут сказать что сами вы все дураки.
От S. Engineer
К KGI (06.11.2022 19:44:13)
Дата 06.11.2022 20:52:24

Re: Прочитал в...


>>> а трахаться с хитрым компилятором , профайлером, врукопашную распараллеливать , предсказывать переходы будут программисты:)).
>>
>>Расспараллеливанием, предсказанием как раз и занимается хитрый компилятор.
>
>Компилятор == программист.

Нет, конечно. Задача программиста - закодировать алгоритм, обычно на языке высокого уровня (C/C++, Java и т.п.). А компилятор переводит программу в исполняемый процессором код.

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

Как и у любого компилятора, например - https://spec.org/cpu2017/results/res2022q3/cpu2017-20220607-32036.html

Процедура сия проводится один раз, да и по опыту нужные опции обычно уже знают заранее.

> А разработчики эльбруса всегда могут сказать что сами вы все дураки.

И в данном случае правильно бы сделали, но люди они деликатные и в результате в интернетах вот такие вот "специалисты" вроде вас несут махровую чушь.
От tarasv
К S. Engineer (06.11.2022 20:52:24)
Дата 06.11.2022 23:56:40

Re: Прочитал в...

>Нет, конечно. Задача программиста - закодировать алгоритм, обычно на языке высокого уровня (C/C++, Java и т.п.). А компилятор переводит программу в исполняемый процессором код.
>Процедура сия проводится один раз, да и по опыту нужные опции обычно уже знают заранее.

Если бы все было так просто. В Эльбрусе заметно больше способов выстрелить себе в ногу при написании кода на ЯВУ чем когда целевая платформа Интел или АРМ. И ключики компилятора не всегда помогают. Чисто вычислительный код на С прилично работающий на нескольких платформах может понадобиться портировать для того чтобы получить нормальную производительность на Эльбрусе.

Орфографический словарь читал - не помогает :)
От S. Engineer
К tarasv (06.11.2022 23:56:40)
Дата 07.11.2022 00:33:27

Re: Прочитал в...

> В Эльбрусе заметно больше способов выстрелить себе в ногу при написании кода на ЯВУ чем когда целевая платформа Интел или АРМ.

Спорное высказывание, требующее пруфов.

> И ключики компилятора не всегда помогают. Чисто вычислительный код на С прилично работающий на нескольких платформах может понадобиться портировать для того чтобы получить нормальную производительность на Эльбрусе.

Пока не приходилось встречать чисто вычислительного кода, прилично работающего вот сразу на нескольких платформах. Например, для упомянутых выше Интел и АРМ рекомендации по оптимизации кода различаются. И на практике это заметно, скажем, на популярном теста производительности SPEC CPU - состоит он из набора программ с интенсивными вычислениями. Состав определялся комитетом, представляющим разные процессорные платформы; в программах этих есть макропроцессорные вставки с оптимизацией для разных процессорных платформ. И тем не менее, часть этих программ, например, замечательно работают на Intel и ужасно на POWER (и наоборот). При минимальном рефакторинге кода разница нивелируется.

Так что в этом плане Эльбрус новых требований не предъявляет. Код для него не портировать нужно, а подправить вычислительное ядро этого кода.
От tarasv
К S. Engineer (07.11.2022 00:33:27)
Дата 07.11.2022 03:37:41

Re: Прочитал в...

>> В Эльбрусе заметно больше способов выстрелить себе в ногу при написании кода на ЯВУ чем когда целевая платформа Интел или АРМ.
>Спорное высказывание, требующее пруфов.

Безобидный на вид набор вложенных циклов вида for (int i = 0; i < size; ++i) для обращения к элементам массивов может снизить производительность кода откомпилированного для Эльбруса в пару раз. Потому что для обращения к элементам массивов можно использовать только переменные размерности size_t, а еще лучше signed это размерности. Что на Интеле что на Arm это наоборот немного замедляет выполнение. Но если звезды у оптимизатора Эльбрусовского компилятора сложатся по другому то негативный эффект может быть меньше и программист его не заметит.
Много специфики связано с разницей VLIW и RISC/CISC. Способы оптимизации отличаются очень сильно, гораздо больше чем при работе одного кода RISC и CISC. Тем кто работал с Итаниум наверно будет нормально, а тем кто с ним не работал, а это большинство, придется шишки набивать.

>Пока не приходилось встречать чисто вычислительного кода, прилично работающего вот сразу на нескольких платформах. Например, для упомянутых выше Интел и АРМ рекомендации по оптимизации кода различаются.

Интеловская MKL например, код общий, все остальное делает компилятор.

>И тем не менее, часть этих программ, например, замечательно работают на Intel и ужасно на POWER (и наоборот). При минимальном рефакторинге кода разница нивелируется.

Это преувеличение. Посмотрел результаты тех времен когда еще Итаниум и сравнил с близким Ксеоном. Максимум в пользу Итаниума 1.13 минимум 0.63 на одной задаче, остальные 0.86 и выше.


Орфографический словарь читал - не помогает :)
От S. Engineer
К tarasv (07.11.2022 03:37:41)
Дата 07.11.2022 09:26:29

Re: Прочитал в...


> Безобидный на вид набор вложенных циклов вида for (int i = 0; i < size; ++i) для обращения к элементам массивов может снизить производительность кода откомпилированного для Эльбруса в пару раз.

Примерно все циклы выглядят именно так. И примерно во всех циклах замедления в пару, в пару десятков и в пару сотен раз.

Потому что для обращения к элементам массивов можно использовать только переменные размерности size_t, а еще лучше signed это размерности. Что на Интеле что на Arm это наоборот немного замедляет выполнение. Но если звезды у оптимизатора Эльбрусовского компилятора сложатся по другому то негативный эффект может быть меньше и программист его не заметит.

мелочи.

> Много специфики связано с разницей VLIW и RISC/CISC. Способы оптимизации отличаются очень сильно, гораздо больше чем при работе одного кода RISC и CISC. Тем кто работал с Итаниум наверно будет нормально, а тем кто с ним не работал, а это большинство, придется шишки набивать.

как бы RISC он очень разный. Alpha очень была специфична к оптимизации - ну вот очень сильно отличалась она от своих собратьев. SPARC тоже имел и имеет массу нюансов - регистровые окна, вызовы процедур, обработка аргументов = 0 - всё не как у Intel/AMD, всё не как у POWER.


>>Пока не приходилось встречать чисто вычислительного кода, прилично работающего вот сразу на нескольких платформах. Например, для упомянутых выше Интел и АРМ рекомендации по оптимизации кода различаются.
>
> Интеловская MKL например, код общий, все остальное делает компилятор.

Интеловская MKL - это две разные библиотеки, одна для x86, Другая для Itanium. И больше ни для чего.


>>И тем не менее, часть этих программ, например, замечательно работают на Intel и ужасно на POWER (и наоборот). При минимальном рефакторинге кода разница нивелируется.
>
> Это преувеличение. Посмотрел результаты тех времен когда еще Итаниум и сравнил с близким Ксеоном. Максимум в пользу Итаниума 1.13 минимум 0.63 на одной задаче, остальные 0.86 и выше.

Было-было, на порядок. Я поищу.
От Никита Каменский
К S. Engineer (07.11.2022 00:33:27)
Дата 07.11.2022 01:38:33

Re: Прочитал в...


>> В Эльбрусе заметно больше способов выстрелить себе в ногу при написании кода на ЯВУ чем когда целевая платформа Интел или АРМ.
>
>Спорное высказывание, требующее пруфов.

Практически любой компонент с логикой интерпретатора: всякие скриптовые языки, Java та же. Какой-нибудь тривиальный daScript на "Эльбрусе" может капитально тупить на ровном месте, тогда как на всём остальном он летает. Причина совершенно очевидна - нормальное предсказание переходов на "Эльбрусе" возможно только через полноценную компиляцию.

*А исполняемые файлы в 5+ раз большего размера... О-о-о...
От S. Engineer
К Никита Каменский (07.11.2022 01:38:33)
Дата 07.11.2022 01:54:48

Re: Прочитал в...


>Практически любой компонент с логикой интерпретатора

Это типичная urban legend, которая родилась раньше Эльбруса. С реальностью не пересекается.

>: всякие скриптовые языки, Java та же.

Java - не скрипотвый язык. Наверное, путаете с JavaScript, но это совсем разные языки несмотря на сходство в названии.

> Причина совершенно очевидна - нормальное предсказание переходов на "Эльбрусе" возможно только через полноценную компиляцию.

Это тоже urban legend.

>*А исполняемые файлы в 5+ раз большего размера... О-о-о...

Откуда инфа? Но даже если и так, да хоть бы и в 10, это не имеет значения.
От Никита Каменский
К S. Engineer (07.11.2022 01:54:48)
Дата 07.11.2022 02:39:37

Re: Прочитал в...


>>Практически любой компонент с логикой интерпретатора
>>...
>> Причина совершенно очевидна - нормальное предсказание переходов на "Эльбрусе" возможно только через полноценную компиляцию.
>
>Это типичная urban legend, которая родилась раньше Эльбруса. С реальностью не пересекается.

Не выдумывайте. Это факт.

>>: всякие скриптовые языки, Java та же.
>
>Java - не скрипотвый язык. Наверное, путаете с JavaScript, но это совсем разные языки несмотря на сходство в названии.

Я нечётко выразился (надо было точку с запятой поставить). Java перечислялась в качестве платформы с интерпретирующим компонентом.

*А ещё ведь есть "работа" Java на "Эльбрусах" в режиме эмуляции x86... Ещё более печальная история...

>>*А исполняемые файлы в 5+ раз большего размера... О-о-о...
>
>Откуда инфа?

Вы даже о таких тривиальных моментах не в курсе ??? Извините, а на основании чего Вы тут вещаете об "Эльбрусах" ??? Вы его хотя бы в глаза вообще видели ???

>Но даже если и так, да хоть бы и в 10, это не имеет значения.

Конечно же имеет. И особенно по части применения в качестве процессора для БРЭО.
От S. Engineer
К Никита Каменский (07.11.2022 02:39:37)
Дата 07.11.2022 02:46:42

Re: Прочитал в...

>Не выдумывайте. Это факт.

А ещё потопайте ногой, тоже будет аргумент такого же качества.


>>>: всякие скриптовые языки, Java та же.
>>
>>Java - не скрипотвый язык. Наверное, путаете с JavaScript, но это совсем разные языки несмотря на сходство в названии.
>
>Я нечётко выразился (надо было точку с запятой поставить).

Да всё нормально, просто вы дилетант с самомнением.

> Java перечислялась в качестве платформы с интерпретирующим компонентом.

Это тоже не совсем так. А вернее из разряда "слышал звон".

>Вы даже о таких тривиальных моментах не в курсе ??? Извините, а на основании чего Вы тут вещаете об "Эльбрусах" ??? Вы его хотя бы в глаза вообще видели ???

Не в курсе, а Эльбрус - да, видел.


>>Но даже если и так, да хоть бы и в 10, это не имеет значения.
>
>Конечно же имеет. И особенно по части применения в качестве процессора для БРЭО.

Конечно же нет. И успешно применяется.
От Никита Каменский
К S. Engineer (07.11.2022 02:46:42)
Дата 07.11.2022 04:49:51

Re: Прочитал в...


>>Не выдумывайте. Это факт.
>
>А ещё потопайте ногой, тоже будет аргумент такого же качества.

Мои аргументы были в моём исходном комментарии. А у Вас - да, только завывания "urban legend"...

>Да всё нормально, просто вы дилетант с самомнением.

Вам нужно отучаться судить о других по себе.

>> Java перечислялась в качестве платформы с интерпретирующим компонентом.
>
>Это тоже не совсем так. А вернее из разряда "слышал звон".

То что Вы о Java ничего не знаете уже понятно. Не усугубляйте.

>>Вы даже о таких тривиальных моментах не в курсе ??? Извините, а на основании чего Вы тут вещаете об "Эльбрусах" ??? Вы его хотя бы в глаза вообще видели ???
>
>Не в курсе, а Эльбрус - да, видел.

На выставке видели ? Или на фото ?

>>>Но даже если и так, да хоть бы и в 10, это не имеет значения.
>>
>>Конечно же имеет. И особенно по части применения в качестве процессора для БРЭО.
>
>Конечно же нет. И успешно применяется.

Точно успешно ? На каком образце установлен ? И как вообще БЦВМ называется ?
От S. Engineer
К Никита Каменский (07.11.2022 04:49:51)
Дата 07.11.2022 09:18:10

Re: Прочитал в...



>>> Java перечислялась в качестве платформы с интерпретирующим компонентом.
>>
>>Это тоже не совсем так. А вернее из разряда "слышал звон".
>
>То что Вы о Java ничего не знаете уже понятно. Не усугубляйте.

Ну вы проконсультируйтесь у независимого специалиста, что ли))

>Точно успешно ? На каком образце установлен ? И как вообще БЦВМ называется ?

ИУС Су-35, ИУС Су-57
От S. Engineer
К S. Engineer (07.11.2022 00:33:27)
Дата 07.11.2022 00:46:02

вдогонку /

> Код для него не портировать нужно, а подправить вычислительное ядро этого кода.

...порой.
От МУРЛО
К Рядовой-К (06.11.2022 14:44:35)
Дата 06.11.2022 15:33:30

Re: Прочитал в...

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

В смысле что на отечественное уже никто не надеется и надо брать китайское.
От NV
К Рядовой-К (06.11.2022 14:44:35)
Дата 06.11.2022 15:13:39

Сверхдлинные командное слово - это зло

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

>Что "эльбрусовским" разработчикам-производителям в этом году три раза отказали о финансировании работ.

Всё уже поняли это, одни бабаяновцы никак не уймутся.

Виталий
От Никита Каменский
К NV (06.11.2022 15:13:39)
Дата 07.11.2022 01:12:48

Re: Сверхдлинные командное...


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

Архитектура "Эльбрусов" не имеет никакого отношения к вопросу...
От S. Engineer
К NV (06.11.2022 15:13:39)
Дата 06.11.2022 19:10:58

Это вы не разбираетесь.

>Всё уже поняли это, одни бабаяновцы никак не уймутся.

1) суть набора команд Эльбруса не в длине командного слова, а возможности управлять логикой процессора.
2) с т.з. архитектуры у Эльбруса всё хорошо. Объективные трудности у них с физ.дизайном, то есть схемотехникой и топологией. Ну а теперь ещё и с производством.
3) у МЦСТ две линейки процессоров, и с длинным командным словом лишь одна из них. Вторая линейка - RISC.
4) Для условной Герани Эльбрус избыточен, а вот для ИУС Су-35/Су-57 как раз - где и используется.
От NV
К S. Engineer (06.11.2022 19:10:58)
Дата 06.11.2022 19:23:15

Я на эту тему с самим Арташесовичем спорил ещё году так в 90-м :)

>>Всё уже поняли это, одни бабаяновцы никак не уймутся.
>
>1) суть набора команд Эльбруса не в длине командного слова, а возможности управлять логикой процессора.

и периодически с их поделиями пересекаюсь до сих пор, крайний раз года 3 назад. Так что разбираюсь. Именно с практической точки применения.

>2) с т.з. архитектуры у Эльбруса всё хорошо. Объективные трудности у них с физ.дизайном, то есть схемотехникой и топологией. Ну а теперь ещё и с производством.

Ровно то же было и 30 лет назад...

>3) у МЦСТ две линейки процессоров, и с длинным командным словом лишь одна из них. Вторая линейка - RISC.

К RISC вопросов нет. Только причём тут Эльбрус как оригинальная архитектура. Кто только SPARC не копировал...

>4) Для условной Герани Эльбрус избыточен, а вот для ИУС Су-35/Су-57 как раз - где и используется.

К использованию архитектуры SPARC вопросов нет.

Виталий
От S. Engineer
К NV (06.11.2022 19:23:15)
Дата 06.11.2022 19:41:45

Сочувствую Борису Арташесовичу.

>>>Всё уже поняли это, одни бабаяновцы никак не уймутся.
>Ровно то же было и 30 лет назад...

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

>>3) у МЦСТ две линейки процессоров, и с длинным командным словом лишь одна из них. Вторая линейка - RISC.
>
>К RISC вопросов нет. Только причём тут Эльбрус как оригинальная архитектура. Кто только SPARC не копировал...

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

PS. А вы дилетант.
От NV
К S. Engineer (06.11.2022 19:41:45)
Дата 06.11.2022 20:35:25

Конечно, необязательно


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

Я и не говорю о том, что это копия. Главное, система команд и принципы работы соблюдены. Можно подумать, это первый случай в истории и какой-либо подвиг. Нет, так бывало много раз ранее. Например, ЕС-1046 вообще не была какой-либо копией машин IBM. Полностью оригинальная конструкция. Но на ней всё ПО прекрасно работало. В том числе оригинальные операционные системы самой IBM.

Это же, на самом деле, хорошо.

>PS. А вы дилетант.

Да хоть горшком назовите. Мне уже 62, мне всё равно :)

Виталий
От S. Engineer
К NV (06.11.2022 20:35:25)
Дата 06.11.2022 20:44:25

Re: Конечно, необязательно


>Я и не говорю о том, что это копия.

Нет, вы сообщением выше так и сказали.

> Главное, система команд и принципы работы соблюдены.

Это какие "принципы работы"?

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

Случай не первый, но и не рядовой.
От NV
К S. Engineer (06.11.2022 20:44:25)
Дата 06.11.2022 21:56:55

Re: Конечно, необязательно


>>Я и не говорю о том, что это копия.
>
>Нет, вы сообщением выше так и сказали.

Дословно я сказал
К использованию архитектуры SPARC вопросов нет.

>> Главное, система команд и принципы работы соблюдены.
>
>Это какие "принципы работы"?

Что такое принципы работы ? Ну вот классическое о принципах работы.
https://www.computer-museum.ru/biblioteka/publication/881/

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

Не спорю.

Виталий
От S. Engineer
К NV (06.11.2022 21:56:55)
Дата 06.11.2022 22:16:29

У вас и к E2k вопросы лишь религиозные. (-)
От Никита Каменский
К Рядовой-К (06.11.2022 14:44:35)
Дата 06.11.2022 14:57:37

Re: Прочитал в...


>Прочитал в Телеге
>Что "эльбрусовским" разработчикам-производителям в этом году три раза отказали о финансировании работ.

Так правильно всё - почти все их разработки для производства на TSMC.
От АМ
К Никита Каменский (06.11.2022 14:57:37)
Дата 06.11.2022 15:00:08

Ре: Прочитал в...


>>Прочитал в Телеге
>>Что "эльбрусовским" разработчикам-производителям в этом году три раза отказали о финансировании работ.
>
>Так правильно всё - почти все их разработки для производства на ТСМЦ.

для другого и финансирования надо больше
От Никита Каменский
К АМ (06.11.2022 15:00:08)
Дата 07.11.2022 01:16:35

Ре: Прочитал в...


>для другого и финансирования надо больше

Для другого надо финансировать совсем других людей. МЦСТ же занимается вполне конкретной темой - разработкой процессоров сотоварищи.