Просто у Intel/AMD есть широкая линейка процессоров на один разъём (сокет), и там есть что выбирать. У Эльбрусов же моделей мало, так что апгрейдить не на что.
Intel меняет разъём через каждые две архитектуры, и надо покупать новую материнскую плату.
Большая часть результатов не используется, компилятор имеет право удалить хоть весь код с ними связанный, что gcc c O3 и делает, но не делает например clang или lcc. Приводить в примерах код с UB - дурной тон.
Значит там нет UB, если вы не можете привести пример. Значит вы вообще не знаете что такое UB, знаете только название, и что можно всех обвинять в его наличии. Если компилятор соптимизировал код, не значит что в коде был UB.
К тому же что низкого в указании на то что они нарушают GPL?
Я не имею претензий к этой причине. Но у вас просто личная ненависть к МЦСТ, и вы ищете любой повод до них докопаться. И когда все разумные причины закончились - вы начали придумывать проблемы на пустом месте. Которые и не подтверждаются, и которые к МЦСТ не имеют отношения (EDG-фронтенд пишут не МЦСТ).
Давайте вы отстанете от МЦСТ, если вам кто-то отвечает хамством, то вам следует подумать, не в вас ли проблема. А проблема именно в ваших нападках и ненависти к МЦСТ.
А чем это оправдывает мцст? Или чем это делает использование кода с UB в примерах корректным?
Давайте вы мне объясните, в чём там UB?
Пример из 7.4.1, современный gcc оптимизирует в пустой код при сборке с -O3.
Как и этот товарищ пусть объяснит, где в 7.4.1 есть код, который оптимизируется в ноль. Вот ссылка на Compiler Explorer, где я компилирую код из "7.4.1. Умножение векторов", и ничего GCC при -O3 не убирает.
Я смотрю, что вы лишь поводы докопаться до МЦСТ ищете, абсолютно любые, даже самые мелкие. Которые мало того, некорректные и не подтверждаются.
Если будут достойные поводы - критикуйте. Но поведение вас обоих я нахожу предельно низким и недостойным. Никаких доказательств и объяснений. Якобы они нашли что-то, на пустом месте.
LCC это EDG-фронтенд, с бэкэндом для генерации кода для Эльбруса, от МЦСТ только бэкэнд. Помните такой ICC (Intel Compiler) или может NVCC? Они тоже сделаны на базе EDG и большинство проблем LCC на них воспроизводится.
В статье же честно написано, что достать сложно и стоит дорого. Это редкая архитектура, в том и интерес, чтобы её попробовать. Для тех, у кого есть такой интерес. В сопоставлении цена/качество - заведомо проиграет, но если кому-то хочется именно это - то купит даже задорого.
Именно поэтому существует движение "Right To Repair", что борется за доступность документации для ремонта устройств. Также за доступность комплектующих.
Тогда хочу вас попросить получить у китацев документацию на чипы SC6531DA/SC6531E (Spreadtrum, ныне Unisoc), и MT6260/MT6261 (MediaTek). Мне лично надо, зачем - можете посмотреть в моих статьях.
В интернете нашел только предварительные версии (неполноценные) для первых, и короткие (без руководства по программированию) для вторых.
У вас чужие примеры, а у меня личный опыт (я принимал участие в портировании JVM для Эльбруса). У вас его нет, и вы меня минусуете, за то что моё мнение не совпадает с вашими представлениями, основанными на маркетинговых материалах.
Как если бы мы спорили о вкусе фрукта X, который вы не пробовали, а я пробовал, но вы меня отсылаете читать, что об этом думают некие гурманы, которые для вас представляют очень большой авторитет, против неизвестного меня.
Всё это - теоретические фантазии защитников JIT. Что в каком-то редком случае JIT обгонит код собранный без JIT. При этом о всех накладных расходах они забывают, и что в среднем JIT будет хуже нативной компиляции.
Софизм в том, что из "в редком случае лучше" делается вывод, что "в целом лучше".
По хорошему код для VLIW собирают с профилем, собранным на обработке типичных данных. Прирост производительности для Эльбруса при использовании профиля - десятки процентов. В GCC и Clang вообще-то тоже есть сбор профиля, -fprofile-generate, а потом -fprofile-use, просто используют это редко, так как для x86 ускоряет на 5, максимум 10%, что не так уж и заметно. А программисты сейчас ленивые, чтобы еще какое-то профилирование делать.
А для JIT вы сначала гоняете неоптимизированный скомпилированный код с кучей зондов-счётчиков для профилирования, что тормозят работу программы и занимают кучу памяти. И потом еще повторная компиляция.
Нет, VLIW хуже подходит для JIT, потому что VLIW компиляция сложная (много вариантов как разложить инструкции в широких командах). А если делать быстро, то будет неэффективно. Так что у вас или компилятор сильно старается и тормозит общий процесс и отнимает ресурсов, или делает неэффективный код.
Вы каких-то маркетинговых материалов начитались, где всегда привирать будут.
Насчёт инструкций процессора, что мелькало в комментариях.
Частично МЦСТ объяснили инструкции здесь. Очень частично, за что я даже предъявлял им претензии, что некоторых вещей не хватает, чтобы полноценно писать код на ассемблере. Хватает только чтобы примерно понимать ассемблерный код от компилятора.
Дизассемблер должен быть в доступных binutils для Эльбруса. (Ссылка была в комментариях.)
Допустим, что есть язык, основанный на байткоде. Используется там где это разумно. Кто-то пишет JIT чтобы ускорить этот язык. После этого этот язык начинают использовать повсюду, оправдывая тем что есть JIT и теперь работает быстро.
Именно так дошло до появления платформы Electron. А теперь вспомните распространённые жалобы на софт, разработчики которого решили перейти с нативного приложения на Electron. Что стало потреблять много памяти, про скорость работы тоже жалуются, но меньше.
Код всё равно будет работать медленнее нативного, хоть и не в 10-100 раз, как в случае использования интерпретатора. Будет работать близко к не оптимизированному нативному, но медленнее оптимизированного нативного (например SIMD). Системные API через JIT будут работать неуклюже из-за большого количества прослоек. Про потребление памяти уже указал, также при запуске приложения - идёт период "разогрева" когда код сначала выполняется на интерпретаторе и компилируется при достижении определённых счётчиков использования циклов/функций. То есть миллионы пользователей запускают приложение и оно компилируется у каждого, каждый раз.
Лучше всего ситуацию с JIT описывает выражение "благими намерениями вымощена дорога в ад", сначала "давайте ускорим медленный интерпретатор", а потом этот язык начинают использовать где не следует.
Для 128x160 я делаю даунскейл в 2 раза, часть экрана не используется. На SC6531 можно обновлять отдельный прямоугольник на экране, а остальное заливать указанным цветом. Поэтому для такого разрешения буфер размером 160 * 100 * 2 = 32000.
Я проверил, что на "-playdemo demo1" из Shareware версии хватает 650*1024 байт памяти. Как и на первый уровень. Это куча для внутренних данных игры, что аллоцирует функция I_ZoneBase() из "i_system.c".
На код/data/bss у меня уходит 473572 байт. Фреймбуферы игры это 320x200x4 = 256000 байт.
Так что 473572 + 256000 + 650x1024 = 1395172 байт минимум.
Плюс надо настоящий фреймбуфер, в который вы будете конвертировать изображение от игры, что 320x200 с 8 бит палитрой, а телефоны эти работают с 16-бит RGB, то есть площадь экрана вашего телефона x2.
Нет шрифтов в ресурсах. Меню размером 176x220, когда как стандартное разрешение игры 320x200. Так что это модифицированный движок Doom, специально под этот телефон, обычный движок это не запустит.
Это не ограничения, а требования. Всё равно как хотеть чтобы автомобиль работал на педалях и называть требования бензина для работы "ограничением". Вам такое зачем?
Помню читал про упрощенный движок Doom для порта на какую-то приставку. Нашел, но раньше читал не на Хабре.
Просто у Intel/AMD есть широкая линейка процессоров на один разъём (сокет), и там есть что выбирать. У Эльбрусов же моделей мало, так что апгрейдить не на что.
Intel меняет разъём через каждые две архитектуры, и надо покупать новую материнскую плату.
Значит там нет UB, если вы не можете привести пример. Значит вы вообще не знаете что такое UB, знаете только название, и что можно всех обвинять в его наличии. Если компилятор соптимизировал код, не значит что в коде был UB.
Я не имею претензий к этой причине. Но у вас просто личная ненависть к МЦСТ, и вы ищете любой повод до них докопаться. И когда все разумные причины закончились - вы начали придумывать проблемы на пустом месте. Которые и не подтверждаются, и которые к МЦСТ не имеют отношения (EDG-фронтенд пишут не МЦСТ).
Давайте вы отстанете от МЦСТ, если вам кто-то отвечает хамством, то вам следует подумать, не в вас ли проблема. А проблема именно в ваших нападках и ненависти к МЦСТ.
Мне кажется что закроется, похоже автор держит корпус открытым для лучшего притока воздуха к кулеру.
Давайте вы мне объясните, в чём там UB?
Как и этот товарищ пусть объяснит, где в 7.4.1 есть код, который оптимизируется в ноль. Вот ссылка на Compiler Explorer, где я компилирую код из "7.4.1. Умножение векторов", и ничего GCC при -O3 не убирает.
Я смотрю, что вы лишь поводы докопаться до МЦСТ ищете, абсолютно любые, даже самые мелкие. Которые мало того, некорректные и не подтверждаются.
Если будут достойные поводы - критикуйте. Но поведение вас обоих я нахожу предельно низким и недостойным. Никаких доказательств и объяснений. Якобы они нашли что-то, на пустом месте.
LCC это EDG-фронтенд, с бэкэндом для генерации кода для Эльбруса, от МЦСТ только бэкэнд. Помните такой ICC (Intel Compiler) или может NVCC? Они тоже сделаны на базе EDG и большинство проблем LCC на них воспроизводится.
В статье же честно написано, что достать сложно и стоит дорого. Это редкая архитектура, в том и интерес, чтобы её попробовать. Для тех, у кого есть такой интерес. В сопоставлении цена/качество - заведомо проиграет, но если кому-то хочется именно это - то купит даже задорого.
Именно поэтому существует движение "Right To Repair", что борется за доступность документации для ремонта устройств. Также за доступность комплектующих.
Тогда хочу вас попросить получить у китацев документацию на чипы SC6531DA/SC6531E (Spreadtrum, ныне Unisoc), и MT6260/MT6261 (MediaTek). Мне лично надо, зачем - можете посмотреть в моих статьях.
В интернете нашел только предварительные версии (неполноценные) для первых, и короткие (без руководства по программированию) для вторых.
У вас чужие примеры, а у меня личный опыт (я принимал участие в портировании JVM для Эльбруса). У вас его нет, и вы меня минусуете, за то что моё мнение не совпадает с вашими представлениями, основанными на маркетинговых материалах.
Как если бы мы спорили о вкусе фрукта X, который вы не пробовали, а я пробовал, но вы меня отсылаете читать, что об этом думают некие гурманы, которые для вас представляют очень большой авторитет, против неизвестного меня.
Всё это - теоретические фантазии защитников JIT. Что в каком-то редком случае JIT обгонит код собранный без JIT. При этом о всех накладных расходах они забывают, и что в среднем JIT будет хуже нативной компиляции.
Софизм в том, что из "в редком случае лучше" делается вывод, что "в целом лучше".
Эльбрус как предмет роскоши.
По хорошему код для VLIW собирают с профилем, собранным на обработке типичных данных. Прирост производительности для Эльбруса при использовании профиля - десятки процентов. В GCC и Clang вообще-то тоже есть сбор профиля,
-fprofile-generate, а потом-fprofile-use, просто используют это редко, так как для x86 ускоряет на 5, максимум 10%, что не так уж и заметно. А программисты сейчас ленивые, чтобы еще какое-то профилирование делать.Называется это Profile-guided optimization (PGO).
А для JIT вы сначала гоняете неоптимизированный скомпилированный код с кучей зондов-счётчиков для профилирования, что тормозят работу программы и занимают кучу памяти. И потом еще повторная компиляция.
Нет, VLIW хуже подходит для JIT, потому что VLIW компиляция сложная (много вариантов как разложить инструкции в широких командах). А если делать быстро, то будет неэффективно. Так что у вас или компилятор сильно старается и тормозит общий процесс и отнимает ресурсов, или делает неэффективный код.
Вы каких-то маркетинговых материалов начитались, где всегда привирать будут.
Которая обанкротовушилась еще в далёком 2008-м.
Насчёт инструкций процессора, что мелькало в комментариях.
Частично МЦСТ объяснили инструкции здесь. Очень частично, за что я даже предъявлял им претензии, что некоторых вещей не хватает, чтобы полноценно писать код на ассемблере. Хватает только чтобы примерно понимать ассемблерный код от компилятора.
Дизассемблер должен быть в доступных binutils для Эльбруса. (Ссылка была в комментариях.)
Допустим, что есть язык, основанный на байткоде. Используется там где это разумно. Кто-то пишет JIT чтобы ускорить этот язык. После этого этот язык начинают использовать повсюду, оправдывая тем что есть JIT и теперь работает быстро.
Именно так дошло до появления платформы Electron. А теперь вспомните распространённые жалобы на софт, разработчики которого решили перейти с нативного приложения на Electron. Что стало потреблять много памяти, про скорость работы тоже жалуются, но меньше.
Код всё равно будет работать медленнее нативного, хоть и не в 10-100 раз, как в случае использования интерпретатора. Будет работать близко к не оптимизированному нативному, но медленнее оптимизированного нативного (например SIMD). Системные API через JIT будут работать неуклюже из-за большого количества прослоек. Про потребление памяти уже указал, также при запуске приложения - идёт период "разогрева" когда код сначала выполняется на интерпретаторе и компилируется при достижении определённых счётчиков использования циклов/функций. То есть миллионы пользователей запускают приложение и оно компилируется у каждого, каждый раз.
Лучше всего ситуацию с JIT описывает выражение "благими намерениями вымощена дорога в ад", сначала "давайте ускорим медленный интерпретатор", а потом этот язык начинают использовать где не следует.
Это ванильная версия Doom (пропатченные исходники от id Software, что те выложили на Гитхабе). Работает без запуска прошивки телефона.
Для 128x160 я делаю даунскейл в 2 раза, часть экрана не используется. На SC6531 можно обновлять отдельный прямоугольник на экране, а остальное заливать указанным цветом. Поэтому для такого разрешения буфер размером 160 * 100 * 2 = 32000.
LCD разрешением 176x220 мне еще не попадались.
Я проверил, что на "-playdemo demo1" из Shareware версии хватает 650*1024 байт памяти. Как и на первый уровень. Это куча для внутренних данных игры, что аллоцирует функция I_ZoneBase() из "i_system.c".
На код/data/bss у меня уходит 473572 байт. Фреймбуферы игры это 320x200x4 = 256000 байт.
Так что 473572 + 256000 + 650x1024 = 1395172 байт минимум.
Плюс надо настоящий фреймбуфер, в который вы будете конвертировать изображение от игры, что 320x200 с 8 бит палитрой, а телефоны эти работают с 16-бит RGB, то есть площадь экрана вашего телефона x2.
Нет шрифтов в ресурсах. Меню размером 176x220, когда как стандартное разрешение игры 320x200. Так что это модифицированный движок Doom, специально под этот телефон, обычный движок это не запустит.
Это не ограничения, а требования. Всё равно как хотеть чтобы автомобиль работал на педалях и называть требования бензина для работы "ограничением". Вам такое зачем?
Помню читал про упрощенный движок Doom для порта на какую-то приставку. Нашел, но раньше читал не на Хабре.