Опубликована система команд Эльбрус

Да, но есть нюанс. Для того чтобы сгенерировать ассемблер, ему нужен as, который находится в binutils и не является частью gcc.

Нет, очевидно.

Можно подробно посмотреть что там вызывается по опции -v

Нужно лучше смотреть.

Нет, очевидно. Аноним выше всё правильно сказал. Что amd, что nvidia - это вливы. Никаких рисов, ядер, gcn-ов не существует. Ничего иного в принципе не существует и существовать не может. А используется в методичках лишь потому, что рядовой говноваятель в прицнипе не способен понять что-то за рамками скалярного дерьма. Вот ему и придумывают все эти истории с ядрами.

В реальности же там влив, создаётся мега-инструкция, которая выполняется атомарно.

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

Нет. Компиляция в контексте программирования - это перевод программы с исходного языка в целевой.

Нет, компиляция - это создание исполняемых программ. Правда сейчас уже всё что угодно называют компилятором - так солиднее. В такой случае g++ - это 10 компиляторов, потому как там множество всяких языков между которыми он гоняет код. Очевидно, что такая классификация несостоятельна.

Выше уже три человека написали как работает gcc.

Написали неправильно.

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

Нет. Любой фронт является транслятором, а значит в нём должен быть кодогенератор. Основная фишка llvm"а в том, что он как раз тебе даёт фреймворк для кодогенерации, но это мало что меняет.

К тому же, в рамках твоей классификации компиляция разделилась на несколько компиляций. Откуда ты взял какие-то части? Части есть у целого. Но и фронт и бек являются компиляторами, в рамках твоих определений.

чё-то звучит похоже на типичную суперскалярность

Ну в зависимости от обстоятельств - да. Нужна только передняя часть с транслятором в представление конкретного компилятора.

А, ну теперь «передняя часть» уже транслятор, но ведь компилятор - это:

это перевод программы с исходного языка в целевой.

Исходный язык для фронта - его язык. Целевой язык - промежуточное представление.

В любом случае даже любой транслятор должен уметь в кодогенерацию.

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

Написали неправильно.

Где в gcc или в llvm (не его компоненте llvm-mc) генерация конкретного платформенного кода, не ассемблера или IR, который потом транслируется в бинарное представление чем-то ещё, а именно бинарника? Я, как написавший «неправильно», жду откровений.

Нет, компиляция - это создание исполняемых программ

Это твое личное определение. Читай книги, узнаешь много нового.

Правда сейчас уже всё что угодно называют компилятором - так солиднее

«Сейчас»? Сколько лет dragon book?

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

Суперскаляр - это обычное скалярное дерьмо с неявным параллелизмом. Да, достигается это за счёт какого-то шедулинга на уровня железки, а не прямого исполнения. Но из этого не следует, что наличие любого шедулинга - признак суперскаляра.

Это больше похоже на smt поверх влива. Потому как параллелизм там явный.

Т.е. есть отдельное скалярное дерьмо, далее оно собирается в ту самую большую инструкцию блок/варп. И оно выполняется атомарно. Если необходима какая-то параллельность(а она необходима), там заранее делится контекст по варпам/блокам. Причём они независмы.

Но в любом случае никакого неявного параллельного исполнения нет. Оно там просто ненужно.

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

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

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

Где в gcc или в llvm (не его компоненте llvm-mc)

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

Где - везде. Если попроще. Какой-либо генератор над ir - это просто обходчик его «ast». Таких обходчиков миллионы. Это просто кусок кода. Это не какой-то компонент, отдельная программа и прочая чушь.

Да и с каких пор asm/ir стал не платформенным.

генерация конкретного платформенного кода, не ассемблера или IR, который потом транслируется в бинарное представление чем-то ещё, а именно бинарника?

Я не понимаю к чему эти потуги. Какой платформенный код, какое бинарное, какой бинарник - что ты несёшь? Конкретный свой тезис давай, а не придумывай какую-то херню постфактум.

Я, как написавший «неправильно», жду откровений.

Компилятор, который не сможет сгенерировать исполняемую программу не нужен

Компиялторов, не генерирующих исполняемую программу, куда больше остальных. То-то их авторы расстроятся…

Шучу, не расстроятся. Они изучали тему, и не путаются в простейших определениях как ты.

Да, но есть нюанс. Для того чтобы сгенерировать ассемблер, ему нужен as, который находится в binutils и не является частью gcc.

Нет, очевидно.

Давай сделаем так. Если у тебя здесь замечание серьёзней чем s/ассемблер/объектник/, то распиши его.

Нет, компиляция - это создание исполняемых программ.

Ну и давай ты будешь приводить источник своих определений. Потому что меня совершенно устраивает определение из «запартного сортирного чтива».

Очевидно, что такая классификация несостоятельна.

Мне не очевидно. gcc - это хренова туча компиляторов в GENERIC + 1 компилятор в ассемблер.

К тому же, в рамках твоей классификации компиляция разделилась на несколько компиляций. Откуда ты взял какие-то части? Части есть у целого. Но и фронт и бек являются компиляторами, в рамках твоих определений.

Я страшную тайну открою. Компилятор именно так и работает. И фронт может быть выполнен либо как отдельный транслятор (clang), либо как часть монолита с бэком (cc1 из gcc). И то, в gcc есть режимы при которых cc1 работает только транслятором.

facepalm

Конкретный свой тезис давай

Что мы имеем на выходе GCC? И что мы имеем в llvm до того как код пришёл в llc?

А вообще что-то я не узнаю - Царь ты чтоль?

Что мы имеем на выходе GCC? И что мы имеем в llvm до того как код пришёл в llc?

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

Давай сделаем так. Если у тебя здесь замечание серьёзней чем s/ассемблер/объектник/, то распиши его.

В данном случае замечание следующие - gcc для генерации asm не нужно никаких as. И это действительно так и смотрел ты -v не внимательно.

Ну и давай ты будешь приводить источник своих определений.

Я не клоун запартный - мне никакой источник не нужен.

Потому что меня совершенно устраивает определение из «запартного сортирного чтива».

Правда адепты запартного сортирного чтива никакого отношения к компиляторострению не имеют.

Кстати, удивительное рядом.

Programming languages are notations for describing computations to people and to machines. The world as we know it depends on programming languages, because all the software running on all the computers was written in some programming language. But, before a program can be run, it first must be translated into a form in which it can be executed by a computer. The software systems that do this translation are called compilers.

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

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

Мне не очевидно. gcc - это хренова туча компиляторов в GENERIC + 1 компилятор в ассемблер.

Нет, никакого одного компилятора в ассемблер нет. Если мы говорим в контексте «один язык - один таргет». Если говорим про гцц в целом - там куча ассеблеров и прочих таргетов.

Это ещё без учёта того, что внутри него самого ещё множество «компиляторов» из одного представления в другое.

Скорее всего подобные рассуждения вызваны compiler collection, но сообщаю. Под коллекцией имеется ввиду не фронты, а компиляторы. Т.е. каждый язык в исполняемую программу. Это и есть компиляторы, а их набор и есть коллекция.

Тоже самое и с llvm. В рамках llvm clang называется фронтом, а не компилятором. А вне llvm clang уже компилятор. Никто фронты/беки компиляторами не называет.

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

Я страшную тайну открою. Компилятор именно так и работает.

Не важно как он работает - важно то, что ни фронт, ни бек не называются компиляторами.

И фронт может быть выполнен либо как отдельный транслятор (clang), либо как часть монолита с бэком (cc1 из gcc).

Полная чушь. Ещё раз вам повторяю - у вас проблемы с пониманием. То, что вы где-то там увидели отдельные тулы - это ничего не значит. Их не существует на самом деле.

Никакого отдельного транслятора, никакого монолита не существует. Это всё рудименты и виртуальное разделение. драйвер - это не компилятор. clang - это просто пускалка драйвера(cc1), которая занимается только одним - его конфигурацией. Сама по себе делать ничего не может.

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

И то, в gcc есть режимы при которых cc1 работает только транслятором.

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

А то как-то странно. Говорил одно, потом напрямую столкнулся с контр-примером в рамках которого определения поломалась. И просто решил факап проигнорировать.

Из чего оно его генерирует-то, гений.

Сходи хоть читни про llc и lli, как они не существуют и что не генерируют, гений.

https://llvm.org/docs/CommandGuide/llc.html https://llvm.org/docs/CommandGuide/lli.html

gcc для генерации asm не нужно никаких as

А CPU-то прямо вот asm текстом исполняет, гений?

мая 30, 2020

Проблевался. Хотели писать по американски, но передумали?

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

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

Просто людям сложно понять, что те программки которые они пускают из консоли - это не части компилятора. Из наличия их не следует, что компиляция разделена на какие-то части.

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

Т.е. компиляция - это не объединение каких-то там стадий. И выделение их на уровне инструментария - это просто разделение стадий для упрощения взаимодействия с компилятором.

Самое интересное тут то, что сортирное чтиво согласно со мною

Это не определение, а частный случай. Найди разницу между

The software systems that do this translation are called compilers

и

compiler is the software system that do this translation

Определением была бы вторая формула, и она дана чуть ниже:

Попросту говоря, компилятор — это программа, которая считывает текст программы, написанной на одном языке — исходном, и транслирует (переводит) его в эквивалентный текст на другом языке — целевом (рис. 1.1).

Сходи хоть читни про llc и lli, как они не существуют и что не генерируют, гений.

Обожаю этих эникеев. Он мне кидает доки для домохозяек и думает, что из них что-то следует.

Сообщаю тебе ещё раз, никаких llc/lli как стадий компиляции не существует и никакая компиляция их не использует.

То, что ты где-то их увидел и нихрена не понял - никаким образом ничего не значит. Давай попроще. Ты балаболишь «из А следует Б» - тебе говорят, что нет. Ты поломался и начинаешь орать «дак вот же, А есть - смотри». Но это не та задача, которую тебе нужно выполнить. Ты должен обосновать следствие.

Тоже самое и со свойствами. Ты орёшь «А обладает свойством Х», а в качеству доказательства предъявляешь наличие А. Но из наличия А не следует приписываемое тобою ему свойство.

Это не определение, а частный случай. Найди разницу между

Нет, очевидно. Там написано определение, а далее написано «то, что ему удовлетворяет и есть компилятор». Это никакой не частный случай. Частный случай - это лишь то, что компилятор является частным случаем транслятора.

Определением была бы вторая формула, и она дана чуть ниже:

Никакой второй формулы там нет. Первое не отменяет второе, к тому же они определено уже позже и в контексте упрощения.

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

Унесите Царя!

Унесите Царя!

Внезапно поддержу. Для обсуждения вопросов определения компилятора лучше создать отдельный тред с перенесением в него Царя и всех заинтересованных.

PS. Делать это я, конечно же, не буду

Тебя, гения, изначально тупо просят указать конкретно в gcc есть модуль генерирующий конечный бинарный модуль под таргетную платформу, а не ассемблерное представление, которое надо ещё as-ом собирать в бинарник, для чего как раз нужны опкоды.

Я говорю, что gcc так не умеет, ты говоришь что умеет. Логично, что ты, гений, ткнёшь меня носом в код, или документацию, где это написано.

А пока я, даже как пользователь, вижу выхлоп gcc

$ gcc -v -c test.c
 
Using built-in specs.
COLLECT_GCC=gcc
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -quiet -v -imultiarch x86_64-linux-gnu test.c -quiet -dumpbase test.c -mtune=generic -march=x86-64 -auxbase test -version -fstack-protector-strong -Wformat -Wformat-security -o /tmp/cc8bsJr3.s
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
	compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/7/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/7/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (Ubuntu 7.5.0-3ubuntu1~18.04) version 7.5.0 (x86_64-linux-gnu)
	compiled by GNU C version 7.5.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b62ed4a2880cd4159476ea8293b72fa8
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 as -v --64 -o test.o /tmp/cc8bsJr3.s
GNU ассемблер, версия 2.30 (x86_64-linux-gnu); используется BFD версии (GNU Binutils for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'

Aceler, по-моему тред вообще не там. Железячникам это не нужно, а заинтересованные программеры его не видят.

а далее написано «то, что ему удовлетворяет и есть компилятор»

Нет, там написано что такие системы называются компиляторами. Из чего не следует, что другие системы так не называются. Что и уточняется ниже.

Плюсую что обсуждение идет немного не там. Вопрос интересный, я бы еще источники привел, включая и те что со мной не согласны. Специально для царя: спор о терминах – это и есть спор об источниках.

Я ничего не понимаю. Тебе что сообщили? Что-бы ты показал конкретный тезис свой, который я неправомерно назвал несостоятельным.

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

Нет, там написано что такие системы называются компиляторами. Из чего не следует, что другие системы так не называются. Что и уточняется ниже.

Нет. Да и вообще пытаться понять сортирное птушное чтиво - такая себе затея. Там изначально используется базворд «трансляция» и существует транслятор, который производит трансляцию и это и является обобщением.

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

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

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

спор о терминах – это и есть спор об источниках.

Нет, очевидно. Меня не интересуют все эти запартные истории. Я говорю о состоятельности какой-либо классификации. И моя претензия в том, что классификация дерьма несостоятельна.

Что её адепт и продемонстрировал выше. Запутавшись и съехав на транслятор, хотя по методичке там должен быть компилятор.

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

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

В 60-е годы впервые был реализован следующий шаг - изменение последовательности команд отно- сительно друг друга прямо в процессе исполнения. Такой подход назвали out-of-order superscalar

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

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

В 80-е годы начала развиваться альтернативная архитектура процессоров. Их отличительной особенно- стью является переупорядочивание команд не во время исполнения, а во время компиляции програм- мы. Также ключевой характеристикой этой архитектуры является использование так называемых ши- роких команд, которые позволяли выразить параллельность множества операций в ассемблере. Такая архитектура называется VLIW — «очень длинная машинная команда».

Ну нет же. Никаким образом переупорядочивание во время компиляции не относится к вливу. Оно возможно(и используется) и без него, как и в рамках влива может использоваться переупорядочивание в рантайме. Ключевой особенностью влива относительно суперскаляра является явность параллелизма.

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

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

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

Уровень параллелизма в рядовом колхозном говнокоде практически равна нулю. И что-то там искать - имеет мало смысла. Да и задача не в планировании, а в разделении скалярного дерьма на отдельные потоки выполнения.

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

И никакое lto никакую проблему не решит. Никто его использовать не будет, потому как 1) сложно, 2) нужны гигантские ресурсы для сборки. И это с учётом суперскаляра и привычного для него примитивного анализа. Я даже представить не могу на сколько их компилятор тормозит, а дальше будет только хуже. Да и нужно понимать, что lto уже давно мёртв. Все давно отказались от каких-либо серьёзных глобальных оптимизаций.

При компи- ляции каждого фрагмента программы происходит максимальное распараллеливание вычислительного процесса по всему полю возможных вычислительных устройств.

каждого фрагмента программы

Что и требовалось доказать. Только вот никакого параллелизма в этом фрагменте почти нет, а тот что есть - почти невозможно использовать.

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

И параллельность как бы есть, но одновременно с этим это мало что даёт.

компилятор VLIW, и аппаратура OOOSS видят, что операция 3 зависит от операции 2 и требует ее завершения, но при этом операции 4 и 5 никак не зависят от результата первых трех операций, поэтому их можно начать исполнять раньше операции 3.

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

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

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

Но только вот ничего не мешает ему помочь.

Это позволяет в некоторых случаях лучше выявлять независимые операции для их параллельного исполнения.

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

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

Зачем кому-то нужны адреса операций чтения/записи? Какая разница какие они? Ключевое отличие суперскаляра как раз таки в том, что очереди разгребаются независимо. Т.е. сами потоки исполнения никак не завязаны на поток инструкций. А вот у влива завязаны.

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

В любом случае это фундаментальная проблема, которая никак не решена(либо о её решении не написано).

ˆ

перестановка и параллельное исполнение операций обеспечивается аппаратно в пределах окна исполняемых в данный момент операций;

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

для переупорядочивания используются скрытые буфера, скрытый регистровый файл, неявная спекулятивность;

Нет. Регистровый файл действительно скрыт, потому как регистры в суперскаляре чисто виртуальны и служат лишь для связи операций между собою. ˆ

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

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

Но всё тоже самое нужно и вливу. Ведь это борьба не с природой суперскаляра, а с природой говнокода.

И все эти апаратные циклы, предикатное исполнение есть в суперскалярах и нужно им так же.

явно выраженный в коде параллелизм исполнения элементарных операций;

Да.

точное последовательное исполнение широких команд;

Это слабость, к тому же не свойства влива. А свойство реализации.

особая роль оптимизирующей компиляции;

Тоже не свойство влива. Это попытка решить слабости. Но подобные слабости есть и суперскаляра и ему так же нужен компилятор, правда в меньшей степени.

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

дополнительные архитектурные решения для повышения параллелизма операций.

Это универсальные решения. Но зависимости от них у влива больше, да.

Преимущества и недостатки VLIW и OOOSS (курсивом помечены недостатки).

VLIW:

ˆ

больше открытых возможностей для выражения параллелизма инструкций;

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

лучшая энергоэффективность при схожей производительности;

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

возможные ухудшения производительности при исполнении legacy-кодов;

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

более сложный код для отладки и анализа;

Просто форма асма говно. Да и это проблема привычки.

более сложный компилятор.

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

более сложный компилятор.

OOOSS:

ˆ

эффективное исполнение legacy-кодов;

Эффективное исполнение в принципе любого кода дерьма.

дополнительная информация о параллельности операций, доступная в динамике исполнения;

Не только. Вся архитектура и подходы построены под суперскаляр.

расход энергии на многократное планирование одних и тех же операций;

Расходы есть, но опять же никаких конкретных сравнений нет. Никакого многократного планирования нет, потому как никакого планирования по сути нет.

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

Опять же, его достаточно и оно так же расширяется компилятором. Как и у влива.

Начало тут . И ладно-бы докопался, что я с дуру написал не llc, а llvm-mc, но пока только словесный понос и ни ссылки на доки.

Хотя, впрочем, Царь - это клиника. Лечить клинически больных - не моя специализация.

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

Ничего не объясняется, ничего не знакомым с темой непонятно. А потом срачи на тысячи постов, в которых никто ничего не понимает.

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

Работать нормально оно не может и не сможет. Нужно что-то менять. Но ничего об этом не слышно.

Да даже такая базовая вещь. Наш asm не читаемый? А похрен - пусть будет дерьмо. Зачем думать, зачем решать проблему. Зачем придумывать читаемое представление?

Не, эта херня не прокатит. Во-первых тезиса нет, а во-вторых ссылка опять же оправдания после факапа, а не до.

Ссылаться ты должен на потуги до, а не после. Вот и попытайся хотя-бы оправдываться не так позорно.

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

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

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

Отличная новость. И даже если в прикладном контексте не взлетит, то будет задел на будущее. Удачи разработчикам отечественного железа, была бы еще реальная производственная платформа.

прощай самомодицифирующийся код

ЕМНИП, в Эльбрусе он и так пресекается, на аппаратном уровне.

https://www.kommersant.ru/doc/4357158

Один threadripper дешевле в разы, производительнее в сотни раз.

другое дело - эльбрус по сути «неуловимый Джо», потому сомневаюсь что кто-то что-то запилит…

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

Удивления всё больше. Консистентность текста поражает.

Читаешь часть про perf и прочую пристню. Какой ещё перф, какие ещё функции? В рамках твоей архитектуры в принципе никаких функций не должно оставаться.

Каким образом можно предлагать то, что вообще никак не поможет и не может работать?

Ну читаем далее:

inline:

ˆусложнение кода для отладки;

Да, действительно. И конечно же гениальные рассуждения про сам инлайн.

Можно выделить как позитивный, так и негативный эффект от inline-подстановки.

Позитив:

ˆ

удаление операций вызова, возврата, передачи параметров;

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

Такое ощущение, что писал студент, который наслушался дефолтной херни про инлайн. И вся эта херня, конечно же, существует только в рамках суперскаляра. ˆ

в некоторых случаях контекст для других оптимизаций: упрощение вычислений, протаскивание констант, упрощение управления;

А, ну если в некоторых случаях - земля пухом. Очевидно, что во всех. Как гений собрался искать параллелизм, если любой вызов функции ломает алиас-анализ. Столько много найдётся, пацаны охренеют.

увеличение степени параллельности операций.

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

Негатив:

ˆ

усложнение кода для отладки;

Было выше.

увеличение времени компиляции;

Опять же, такое ощущение что просто перепаста запартное методички. У тебя увеличение времени компиляции - свойство архитектуры. Это не следствие инлайна - эта следствие последующих оптимизаций/трансформаций.

снижение hit rate для кэша команд.

Опять же, хит-рейт - это чисто запартная херня. Как только кто-то о нём говорит - можно сразу установить, что пациент ничего в теме не понимает.

Ничего подобного из инлайна не следует. Уже чисто потому, что это не свойство инлайна - это свойство любой оптимизации под твою архитектуру.

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

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

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

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

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

Да ниужели. Подожди, но если программа состоит из функций, а каждый вызов - ломает оптимизацию, то о какой оптимизации может идти речь? ранее же это было «в некоторых случаях», а теперь уже во всех. Какие откровения.

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

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

А, ну теперь уже это проблема. Правда ранее почему-то о ней не говорилось. И оказывается какая-то вариация -fwhole-program с инлайнгов всех сорцев в один «модуль». Это даже не lto, которое хотя бы возможно добавить в рядовую колхозную сборку. Подобное же не добавить и никто это использовать не будет.

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

Второй проблемой является вызов по косвенности. Компилятор может бороться с косвен- ностью:

Да неужели. А куда же это делось в перечислении преимуществ суперскаляра? К тому же, проблемы

Рассмотрим пример, который на ВК «Эльбрус» будет выполняться быстрее, чем на ВК с архитектурой х86_64. Все примеры в этом методическом пособии будут проводиться в сравнении между следующими машинами:

# lcc -v
lcc:1.24.04:Jul-2-2019:e2k-v4-linux
Thread model: posix
gcc version 7.3.0 compatible.
# cat /etc/mcst_version

Модель многопоточности: pogcc версия 5.5.0 (GCC)

Обожаю эту бездарную пропаганду. В 2019 году колхозники используют гцц 5.

-833855398

real    0m0,554s
user    0m0,554s
sys     0m0,000s

Да, уровень действительно поражает. Кстати, самое интересное тут даже не в этом.

• Код - птушное дерьмо. Примерны достойные. Подумаешь, что и у этого кода и того, кто его писал - шансов на что-то ровно ноль.

• Взят древний компилятор, непонятно как и что собрано. Результаты не воспроизводятся. Достойно.

• В целом предпринята попытка воспользоваться тем, что обыватель не понимает сути фокусов. Во-первых сюда впендюрено деление из-за чего х86 и тормозит. Причём, всё это в контексте влива и параллелизма с которым деление не совместимо. Во-вторых фокусы с fma. Чего в х86 для интов нет.

• просто обман с временем выполнения.

• Пример специально подобран таким образом, чтобы его оптимизировать. Специальные циклы дерьма, макрсоня и прочее. Счётчики дерьма. В контексте же x86 - это код никак не оптимизируется особо. Это во много проблема оптимизации, а не х86. А выдаётся именно за проблему х86

• код специально подобран таким образом, чтобы поломать векторизацию. Очевидно, что в реальности такое дерьмо никто писать не будет.

VLIW:

Без конвейеризации все итерации цикла будут исполняться строго последовательно.

Нет, просто код дерьма.

Конвейе-ризация дает многократное ускорение циклов. Заметим, что эффект, схожий с конвейериза- цией, предоставляет распространенная компиляторная оптимизация «раскрутка цикла» (loop unrolling).

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

OOOS:

Для ООOSS конвейеризация происходит за счёт аппаратного планирования. В OOOSS предска- затель переходов предсказывает переход по обратной дуге, и это позволяет начать исполнять операции со следующей итерации еще до конца текущей.

Меня утомляет эта чушь. Никакого планирования нет. Никакой предсказатель переходов ничего не значит. Никакой конвейеризации циклов нет.

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

Никакие итерации суперскаляр не исполняет до конца текущих - он не может этого делать. Суперскаляр вообще ничего не исполняет. О чём я так же говорил выше. К тому же, у штеуда есть lsd. Который детектирует повторяющиеся последовательности и уже сам занимается их генерацией.

Эффективность конвейеризации цик- ла в OOOSS ограничена объемами ROB (буфер переупорядочения) и количеством операций на одной итерации цикла.

Нет, никакой конвейеризации циклов нет, повторюсь. В рамках суперскаляра есть «конвейеризация» для всего. Это есть циклы у тебя, потому со всем остальным проблемы и пусть будет хоть что-то.

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

Поднялись вверх операции i++ и i_+8.

Уровень, конечно, поражает. Если кто не понял, выше я уже говорил о том, что эта конвейеризация - дерьмо. И вот здесь явно видно одну из проблем. Мы форфан вынуждены каждый раз вычислять значения индексов. Это попросту не нужно и тратит вычислительные ресурсы, а во-вторых это увеличивает тот самый критический путь.

Т.е. мы не можем выполнять следующую итерацию, пока не посчитаем ++i и не вычислим адрес a[i]. Конечно, в рамках примитивных циклов мы можем передавать offset конвейеризатору. И скорее всего у них это реализовано, иначе было бы совсем позорно. Но мы пока до неё не дошли.

В OOOSS переименование регистров производится аппаратно с помощью скрытого регистрового файла.

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

К тому же, для этого не используется переименование регистров. Для этого используется именно семантический анализ последовательностей. Т.е. суперскаляр понимает семантику зануления, перезаписи и прочего. И она используется для инициации новых потоков/цепочек. Для этого никакое переименование ненужно.

А вот далее регистры(скрытые) уже используются для передачи данных между операциями. Они назначаются произвольно и это и есть переименование. Но само переименование поднятую задачу не выполняет.

Для архитектуры Эльбрус используется механизм явного переименования регистров - базированные регистры. Они описаны в разделе Пространство ре- гистров подвижной базы. Программные соглашения использования базированных регистров . %b[]

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

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

• отсутствие операций вызова в теле цикла; ˆ
• наличие единственной обратной дуги и единственного выхода как альтернативы обратной дуге; ˆ
• отсутствие ветвлений в теле цикла.

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

Таблица 6.3: Время выполнения программы

Ой, и тут пропаганда опять нам врёт:

244176687 123914132 63020334

real    0m0,233s
user    0m0,233s
sys     0m0,000s

Ой, ведь если бы этот код писал человек - он бы написал:

void sample(int ind) {
  int S;
  S = rn[ind];

  a += ((S & 1) && (S < (1 << 30)));
  b += (((S >> 3) & 1) && (S < (1 << 29)));
  c += (((S >> 5) & 1) && (S < (1 << 28)));
}

А далее мы чётко видим:

void sample(int ind) {
  int S;
  S = rn[ind];

  a[n] += ((S[n] & 1) && (S[n] < (1 << 30)));
  b[n] += (((S[n] >> 3) & 1) && (S[n] < (1 << 29)));
  c[n] += (((S[n] >> 5) & 1) && (S[n] < (1 << 28)));
  
  a = a[0] + ... + a[n];
  b = b[0] + ... + b[n];
  c = c[0] + ... + c[n];
}

Ой, а что это у нас такое. Неужели векторизация. Ой, а неужели gcc смог это понять. Ой, а неужели нам сообщили, что время выполнения 14.3 секунды на интел, а реально в 50+ раз быстрее?

Ладно, мне лень это читать дальше. Буду там пару раз в день минут по 10 почитывать. Но в целом уровень, конечно же, поражает воображение. С таким подходом оптимизация действительно обеспечена и интел будет побеждён.

Один threadripper дешевле в разы

Это никак не связано с говнорипером. Это обусловлено его массовым производством.

К тому же, говнориппер говно. Меньше потребляй пропаганды. Он в хлам сливает интелу и потенциал его крайне скуден.

производительнее в сотни раз.

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

Потому как изначально можно было всё объяснить. А когда придёт факап - никто в объяснения уже не поверит, даже если объяснения будут честными и обоснованными.

К тому же, что самое интересное - подходы необходимые эльбрусу так же необходимы и интелу. И на этом можно было выехать, но похоже это им не очевидно.

Нет, компиляция - это создание исполняемых программ. Правда сейчас уже всё что угодно называют компилятором - так солиднее. В такой случае g++ - это 10 компиляторов, потому как там множество всяких языков между которыми он гоняет код. Очевидно, что такая классификация несостоятельна.

Шиза as is.

Всё же повторю вопрос, насколько я понял какая-то связь с эльбрусом есть.

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

Соответственно, единственным адекватным направлением является следующие.

• чёткое формулирование проблем.

• выход на то, что эти проблемы есть и у суперскаляра, а у х86 их ещё больше.

• выход на то, что эти проблемы необходимо решать в любом случае.

• выход на то, что у vliw куда больше потенциала.

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

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

• решение этих проблем. Всё описанные в книге подходы и оптимизации - работают и для х86, причём дают не меньший(а возможно даже больше) профит. Причём поднятые там темы достаточно миноры.

• люди не будут изучать что-то для какого-то эльбруса. Люди хотят изучать что-то полезное.

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

Вокруг столько примеров на которых можно похайпить, объяснить. Сломать мозг людям. Нет, мы рождаем какую-то непонятную книгу в которой нихрена не объясняется.

Хотя-бы объяснили людям как суперскаляр работает, но там объяснения бесполезные и птушные. Кто это будет читать? Опять же всё возвращается к тому, что у людей нет мотивации читать. Потому что у них нет никаких эльбрусов.

Я уже ранее это спрашивал, но это удивительно. Нету людей? Ну дак ищете/спросите. Даже я бы за просто так помог с этим делом, да и много кто ещё.

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

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

Если уж ты считаешь себя таким экспертом в данном вопросе, то расскажи чего ты достиг. Степень? Публикации? Участие в проектах? Может быть ты действительно сумрачный гений, а нам не хватает просветления чтобы это понять?

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

Ну пусть модераторы перенесут и вынесут его величество.

Ладно, в последний раз отвечу. Пособие написано очень хорошо и с пониманием.

Какие этому есть основания? Какие у тебя достижения, что-бы ты мог оценивать его качество? Либо это типичная оценка тем, кто ничего не понимает?

Людьми, которые не первый десяток лет в теме.

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

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

Ну да, и ты это смог оценить? А каким образом?

Если уж ты считаешь себя таким экспертом в данном вопросе, то расскажи чего ты достиг. Степень?

Степень в помойке, которая ничего не значит? И результаты уровня лабы? Да, это достойно.

Публикации?

Показывай свои публикации, и публикации этих экспертов. К тому же, этими публикациями можно только жопу вытереть. Потому как они никому не интересны.

Участие в проектах? Может быть ты действительно сумрачный гений, а нам не хватает просветления чтобы это понять?

Да, не хватает. Очевидно, что рядовой шаблонной запартной херни не хватит, что-бы что-то понять.

От того мы и видим эти нелепые результаты. И эти нелепые факапы в макулатуре. Этого уже достаточно.

Пособие написано для людей, которые будут писать приложения для Эльбрусов,

Удачи с такими писателями. Они многому научатся. И очень много результатов видно. Почему все эти эксперты по норам прячутся? Как и все эти люди.

Ну выходи, конкурируй. Почему всё происходит в крысу? Иди побеждай. Запомни, говорить о каком-то уровне тогда, когда ты убежал от конкуренции - это попросту позорно.

и которым нужно понимать что и как происходит на платформе.

Ну что-то понимания я не вижу. А факапы вижу.

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

А, отзывы кого? Запартных, подневольных? Никакие отзывы ничего не значат.

Таблетки закончились? Закажи доставку на дом.