От tarasv
К S. Engineer
Дата 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

вдогонку /

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

...порой.