Легенды и мифы процессора Эльбрус в примерах

В ответ на мою статью про тупиковость развития линейки процессоров Эльбрус в качестве базовой платформы для отечественных general-purpose CPU, пользователь @alexanius (Алексей Маркин) написал свою статью-ответ, где привёл возражения моим тезисам. Дабы не превращать дискуссию в формат форумной перепалки, я попытаюсь структурировать изложенные возражения, максимально опустив малозначимые на мой взляд детали и не относящиеся к делу реплики. Также мы оставим на совести Алексея некорректные высказывания и переходы на личности. Это мишура, которая не поможет нам глубже понять суть проблемы.

Итак, если суммировать, то в моей статьей были приведены следующие недостатки Эльбруса:

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

2. Проблема принципиального проигрыша RISC/CISC системам по производительности ввиду:

   1. Более низких тактовых частот дизайна VLIW процессоров

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

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

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

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

Итак, давайте пройдёмся по тексту от @alexanius и по каждому из данных пунктов посмотрим, действительно ли приведённые им аргументы меняют картину.

Слабость программной экосистемы

Какие возражения были приведены в по данному вопросу?

В момент продвижения архитектуры ARM все дружно двинулись переносить своё ПО на него, никто не говорил, что собственная архитектура — это плохо. Сейчас в Европе активно продвигается RISC-V, но никто не плачет о новой несовместимой архитектуре — все дружно берут и переносят своё ПО. Но почему-то как только речь заходит про архитектуру Эльбрус, сразу начинаются стоны о том что своё — это плохо и сложно

В этих рассуждениях мне видится два важных момента. Первый – это фундаментальное непонимание причин того, почему «все дружно берут и переносят своё ПО». Второй (как следствие первого) – это назначение в качестве виноватых разработчиков софта, которые не хотят портировать софт на Эльбрусы.

Алексей, дело в том, что жизни всё устроено так, что если люди или предприятия заинтересованы в портировании софта, если аппаратная платформа удобна и удовлетворяет их требованиям, если им это выгодно – то они берут и портируют. А если предлагаемая платформа даже недоступна в свободной продаже, если система команд закрыта, если в свободном доступе нет нормальных отладчиков, симуляторов, профилировщиков и прочей базовой программной экосистемы, и всё вышеизложенное – это принципиальный подход компании-производителя процессора, то люди даже при всём желании не смогут эффективно заниматься процессом портирования. Поэтому, при возможности выбирать, портировать на Эльбрус или, допустим, на Arm или RISC-V, люди будут очевидно выбирать второй вариант. И одна из главнейших причин этого – политика компании МЦСТ.

На текущий момент в нём портировано более 14500 пакетов

Это прекрасно, но это мизер по сравнению с теми же ARM или RISC-V. Для RISC-V, которая фактически ещё находится в стадии своего зарождения, уже портированы популярные дистрибутивы Ubuntu, Debian, Fedora с десятками тысяч пакетов каждый, сделана поддержка в Qemu, gcc, lllvm, OpenJDK, v8 и т.д. и т.д. Т.е. уже создана экосистема, на порядок превосходящая Эльбрусовскую. В случае ARM разрыв ещё более драматичный.

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

Простим автору его неинформированность. Система бинарной трансляции не является уникальной возможностью процессора Эльбрус. Для Arm существуют как минимум Rosetta 2 и ExaGear. Qemu имеет хоть и медленный, но зато поддерживающей широкий спектр host-архитектур движок бинарной трансляции.

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

Проблема принципиального проигрыша Эльбрусом по производительности RISC/CISC процессорам

Частота

Для начала кратко обговорим вопрос с частотой. На моё утверждение, что VLIW принципиально уступает по частотам RISC/CISC, Алексей заявляет следующее:

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

Эта фраза рассчитана на тех, кто умеет внимательно читать. В таблице приведено сравнение различных VLIW архитектур (Итаниум и Эльбрус) с аналогами RISC/CISC, разработанных на таких же техпроцессах в одних и тех же компаниях. И везде видно, что VLIW решения всегда своим конкурентам уступают по частоте. И у этого есть вполне определённая причина – особенности архитектуры у VLIW-процессоров. А конкретно для Алексея вопрос можно переформулировать следующим образом – почему Эльбрус(e2k), который постоянно выставляется как главный процессор от МЦСТ и в который вкладываются основные разработческие ресурсы, уступает по частоте процессорам линейки Sparc от МЦСТ, в которые всегда вкладывались намного меньше? Т.е. дело не деньгах и нанометрах, а в принципиальных ограничениях VLIW-архитектур.

В конце концов, в МЦСТ есть профильные специалисты, которые вполне профессионально могут ответить на вопрос, а какие предельные частоты достижимы на Эльбрусах семейства e2k? Я могу оценить эту цифру в диапазоне 2.5-3 ГГц. Но было бы здорово, если эксперты прокомментируют данный вопрос. Напомню, что топовые x86 процессоры преодолевают отметку в 5 Ггц.

Микроархитектурная скорость и снижение производительности на реальных задачах

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

В области разработки компиляторов существует целое направление, занимающееся решением именно этой проблемы — анализ указателей

Получается ли разрывать зависимости на практике? Да, получается, много где. Более того, в Эльбрусе разрыв зависимостей возможен не только во время компиляции, но и во время исполнения. Одним из таких механизмов является DAM, позволяющий аппаратно разрывать зависимости, которые не смог порвать компилятор

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

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

И в итоге заключает:

только вот в реальной жизни как раз всё обычно весьма неплохо

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

Как говорится, вместо тысячи слов – дайте код. Давайте воспользуемся любезно предоставленным Алексеем godbolt сервером и просто посмотрим, что происходит в реальности. Я зашёл в гугл, набрал в поиске «сортировка вставками github» и скопировал код с первой же ссылки в окно godbolt-сервера (только увеличил ARRAY_SIZE до 100000 для удобства запуска):

#include<stdlib.h>
#include<stdio.h>
#define ARRAY_SIZE 100000
void fill_random(int*a)
{
    for(int i=0;i<ARRAY_SIZE;i++)
    {
        a[i]=rand();
    }
}
void Sort(int*a)
{
    int t, // временная переменная для хранения значения элемента сортируемого массива
        p; // индекс предыдущего элемента
    for (int c = 1; c < ARRAY_SIZE; c++)
    {
        t = a[c]; // инициализируем временную переменную текущим значением элемента массива
        p = c-1; // запоминаем индекс предыдущего элемента массива
        while(p >= 0 && a[p] > t) // пока индекс не равен 0 и предыдущий элемент массива больше текущего
        {
            a[p + 1] = a[p]; // перестановка элементов массива
            a[p] = t;
            p--;
        }
    }
}
void print_array(int*a)
{
    for(int p=0;p<ARRAY_SIZE;p++)
    {
        printf("%d n",a[p]);
    }
}
int main()
{
    int*array=(int*)malloc(ARRAY_SIZE*sizeof(int));
    fill_random(array);
    print_array(array);
    Sort(array);
    print_array(array);
    system("pause");
    return 0;
}

Выставил в качестве компилятора e2k lcc 1.26.04, опции оптимизации -O4.

Итак, что же у нас получилось? Пытливый читатель может в качестве тренировки зайти на сервер и самостоятельно оценить легкость восприятия e2k-ассемблера. Я же приведу здесь выжимку. В данном примере основной код, определяющий производительность теста – это внутренний цикл while в алгоритме сортировки (функция Sort). Для Эльбруса он выглядит вот так:

.L619:
        {
          nop 2
          disp  %ctpr1, .L636
          ldw,0 %dr10, %dr3, %r0
        }
        {
          nop 2
          cmplesb,0     %r0, %r5, %pred0
        }
        {
          ct    %ctpr1 ? %pred0
        }
        {
          disp  %ctpr1, .L619
          subs,0        %r4, 0x1, %r4
          stw,2 %dr10, %dr3, %r5
          subd,3,sm     %dr3, 0x4, %dr3
          stw,5 %dr7, %dr3, %r0
        }
        {
          nop 3
          cmplsb,0      %r4, 0x0, %pred0
        }
        {
          ct    %ctpr1 ? ~%pred0
        }

Что мы видим? Одна итерация основного цикла занимает 13 тактов. В нём 9 семантически полезных инструкций (остальные – это специфика Эльбруса, не влияющее на реальное IPC). Т.е. IPC составляет 0.69 инструкций в такт. Эффективность использования широкой команды в данном случае очевидна – она крайне низкая. Никаких разрывов зависимостей не произошло, DAM не применился, но зато произошёл абсолютно бессмысленный инлайн функции Sort в функцию main.

Превентивно закрою здесь все дальнейшие рассуждения на тему «но здесь же есть пересечение между load и store, поэтому там что-то не применилось!». В любом минимально реалистичном коде возникают такого, и даже более сложного рода проблемы. Здесь мы имеем практически идеальный для Эльбруса случай – никаких сторонних модулей, 40 строчек кода, регулярный проход по массиву. И даже в таком простейшем по факту случае статический анализ не смог создать оптимальный код.

А что же происходит, например, на x86? Код основного цикла из под gcc 7.5.0 (на старших версиях там вообще векторизация включается, поэтому я использовал для более равного сравнения немного более старую версию):

.L8:
        mov     edx, DWORD PTR [rax]
        cmp     edx, ecx
        jle     .L7
        mov     DWORD PTR [rax+4], edx
        mov     DWORD PTR [rax], ecx
        sub     rax, 4
        cmp     rsi, rax
        jne     .L8

В основом цикле 8 инструкций, одна итерация занимает ~3 такта, IPC 2.67 (проверено на Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz)

В итоге, микроархитектурная скорость исполнения данного кода на x86 превышает Эльбрус в 13/3 = 4.33 раза. Т.е. во столько бы раз проиграл Эльбрус, будь он по частоте сопоставим с топовыми RISC/CISC системами.

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

Пойдём далее.

Вообще, когда говорят о производительности ВК (вычислительных комплексов), существуют общепризнанные тесты, на результаты которых принято ссылаться. Например, ни один профессионал не сошлётся на результаты теста drystone или whetstone — его просто на смех поднимут. Если мы говорим про производительность на широком круге задач, то не существует набора тестов лучше чем SPEC CPU 2017 или его более старой версии 2006 года

Обсуждение проблемы профессионализма с сотрудниками компании МЦСТ можно начинать с вопроса публикации результатов всевозможных бенчмарков. Для примера, вот как это сделано у ваших коллег из Байкал Электроникс. А от МЦСТ для Spec CPU 2017 мы видим 2 цифры без указания каких-либо подробностей вообще, полуподпольно напечатанных в статье-ответе. Но т.к. нам не остаётся ничего другого, будем отталкиваться от тех значений, которые были приведены.

Из результатов следует что Эльбрус 2016 года выпуска с частотой 1300 МГц работает быстрее Байкала 2019 года выпуска с частотой 1500 МГц

Точнее, Spec CPU 2006 и Spec CPU 2017 работают быстрее на Эльбрусе, чем на Байкал-М. Но мы с вами давайте посмотрим на вопрос производительности чуть более широко. Я взял цифры из данной статьи за основу и поправил их исходя из уточнённых данных от Алексея и отчёта Байкал Электроникс. Там, где новых данных нет, всё оставил как есть:

Что мы видим? Эльбрус существенно выигрывает у Байкал-М на тестах, на которых важна работа подсистемы памяти. Это вполне объяснимо, т.к. в Эльбрусе, чтобы нивелировать недостатки микроархитектуры ядра, приходится делать акцент на улучшении подсистемы папяти, увеличивая размеры кэшей, количество load/store операций исполняемых процессором за такт, количество каналов памяти. И не забываем, что в конце концов, Эльбрус – это изначально серверный процессор, с TDP в районе ~90 Вт, тогда как Байкал-М основан на ядре для мобильного рынка и его TDP составляет ~30Вт.

На тестах Javascript Эльбрус существенно проигрывает Байкал-М. Опять-таки, очевидно почему – разработать хороший JS компилятор для VLIW-архитектуры задача сложная и трудоёмкая. Результат тут, как говорится, налицо (и в догонку к вопросе об экосистеме).

А вот со счётными бенчмарками интереснее. На простеньком Coremark Эльбрус умудрился существенно проиграть. Dhrystone/Whetstone/Blender/7zip показывают примерно одинаковые результаты. И только на Spec CPU 2006 / Spec CPU 2017 результаты Эльбруса в 1.5-2 раза выше. Но собственно, именно к этому факту мной было сказано, что цифры для Spec CPU 2006/2017 вылизывались на компиляторе многие годы. И в реальности они показывают ту пиковую производительность, которую можно на Эльбрусах достичь. Но проблема в том, что для бОльшей части остального кода такие показатели будут недостижимы, т.к. компиляторные эвристики и опции, заточенные на Spec CPU 2006/2017, там будут работать существенно хуже. В то время как для тех же RISC/CISC архитектур с ОоО разница между «наоптимизированными бенчмарками» и кодом из реальной жизни будет существенно ниже. Что мы, собственно, и видим в табличке.

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

Теперь давайте всё же разберёмся со Spec CPU 2017 и микроархитектурной скоростью, которую на ней показывают различные процессоры. Помним, что это – лучший бенчмарк для Эльбруса.

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

Во-первых, целью моей статьи не было сравнение российских процессоров. То, что сейчас Эльбрус-8СВ обыгрывает по сути единственного конкурента Байкал-М (и то, далеко не всегда, как мы уже увидели) само по себе мало о чём говорит. МЦСТ почти уже 30 лет разрабатывает high-performance GP CPU и бОльшую часть времени было практически единственным российским разработчиком в данной нише. Но в итоге оказалось, что первый же конкурент - компания Байкал Электроникс, которая имела нулевой опыт создания процессоров, но зато имела сложности с лицензиями, финансированием, управлением из-за проблем владельца, набила кучу шишок первого продукта, за несколько лет выдала чип, который конкурентен чипам от МЦСТ. В данный момент тот же Байкал Электроникс готовит к выпуску процессор Байкал-S, как раз предназначенный для северного рынка. Можно грубо прикинуть производительность будущего чипа. Если Байкал-М основан на ядре Cortex-A57, то Байкал-S будет основан на Cortex-A75. С учётом роста частоты и микроархитектурной производительности, одно ядро добавит где-то в 2-3 раза Spec Rate на Spec CPU 2017. А увеличение количества ядер до 48 увеличит суммарный Spec Rate ещё примерно в 6 раз. Т.е. итоговый Spec Rate для Байкал-S будет где-то около 100 (и для SpecINT, и для SpecFP), или даже выше. А конкурент от МЦСТ новый Эльбрус-16С от текущих цифр Эльбрус-8СВ прибавит лишь 2.67 в максимуме ( В 1.33 раза вырастет частота и в 2 раза количество ядер). Итоговый Spec Rate будет в районе 28 для SpecINT и 44 для SpecFP. Вот и вся история. И причина этого в том, о чём была написана моя первая статья.

Во-вторых, спрашивать сравнение с импортными процессорами достаточно странно, потому что ситуация там абсолютно катастрофична для Эльбруса. Но если кому-то хочется мазохизма - пожалуйста. Вот ссылка на официальные результаты бенчмарка Spec CPU 2017 для различных систем. Если мы говорим про максимальные цифры, то там есть системы со значениями больше 1000 (и для SpecINT, и для SpecFP). Для 8-ми ядерных систем (как Эльбрус-8СВ) средние значения колеблятся в районе 70-80 для SpecFP и 50-60 для SpecINT, для топовых систем подбираясь и переваливая за 100. Например, результат ASUS RS520A-E11(KMPA-U16) Server System 3.70 GHz, AMD EPYC 72F3 составляет 98 для SpecINT и 124 для SpecFP. Напомню, для Эльбрус-8СВ эти цифры 10.68 и 16.55 соответственно. Т.е. в 9 и 7.5 раз меньше на САМОМ лучшем для Эльбруса бенчмарке.

На основе имеющихся результатов Spec CPU 2017 можно, кстати, достаточно хорошо оценить микроархитектурную скорость своременных RISC/CISC процессоров. Она колеблется в среднем в диапазоне 2-3 SpecRate на один гигагерц одного ядра, переваливая за 4 для SpecFP для топовых решений (как для приведенного выше решения на базе AMD EPYC 72F3). Для Эльбруса же эта микроархитектурная скорость равна 0.9 для SpecINT и 1.4 для SpecFP.

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

Мне кажется, после приведённых цифр и примеров, вопрос о проблемах микроархитектурной скорости Эльбруса можно закрыть – она катастрофически уступает RISC/CISC аналогам.

Осталось только разобрать следующий пример:

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

Я сэкономлю время читателей и скажу кратко – приведённый тест FIO предназначен для измерения скорости работы с дисками. Производительность данного теста упирается в скорость работы самих дисков, их микроконтроллеров и подсистемы памяти процессора. Реальная вычислительная производительность процессорного ядра там неважна. Для специализированных решений для дата-цетров разрабатывают системы на нишевых in-order процессорах, которые там отлично справляются. Ну и показательно, что нам сначала рассказывали про то, что Spec CPU 2006/2017 это самый показательный бенчмарк. Но когда дошло дело до сравнения, тут оказался почему-то не Spec CPU 2006/2017, а FIO.

Трудоёмкость разработки под архитектуру Эльбрус

Мне кажется, всё вышеизложенное достаточно ёмко описывает, какова трудоёмкость разработки под Эльбрус – она существенно выше, чем для RISC/CISC архитектур. И ввиду сложности кода ассемблера для понимания (godbolt в помощь), и ввиду сложности компилятора и необходимости постоянного анализа кода и настройки опций.

Что же касается данного высказывания:

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

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

но пожалуй остановлюсь на том, что автор не в курсе вектора разработок МЦСТ, и одно из направлений — это как раз отчёт о применении оптимизаций для помощи пользователю

Это абсолютно бесполезная вещь для пользователя. Вы просто в очередной раз тратите своё время в пустую.

В заключение, я бы хотел прокомментировать пару тезисов из статьи Алексея, не упомянутых выше, но мимо которых мне всё же сложно пройти.

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

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

И как же так получилось что у энтузиастов поднят godbolt сервер с компилятором, в музее Яндекса стоит машина со свободным доступом к ней, а получить удалённый доступ можно практически свободно, зайдя в эльбрусовский чатик? Я уже не говорю про такие шедевры как любительский ютуб канал с запуском игр на Эльбрусах

Люди спрашивают про свободный доступ к машинам. Про открытие ситемы команд. Про открытый качественный тулчейн для разработки. А в ответ получают предложение зайти в чатик и на любительский ютуб канал. И самое печальное, что сотрудники МЦСТ действительно считают такую ситуацию нормальной.

Думаю что на основе всего выше сказанного я поставлю под сомнение это утверждение

Вы пытаетесь поставить под сомнение не просто вышесказанное, а мнение, сложившееся у экспертов в индустрии. Например, Линуса Торвальдса, Хеннеси и Паттерсона, и даже отец Эльбруса Б. Бабаян соответствующе высказался по поводу VLIW:

Мы думали: ну, сделать 32 цуга – и будет у нас настоящий параллелизм! Но я допустил тогда ошибку. Я подумал, что это очень сложно, а ведь есть подход попроще – подход широкой команды. Ну мы и решили его попробовать. Ведь мы тогда минусов не знали этой широкой команды…

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

Тупиковость развития VLIW-архитектур для general-purpose CPU стала понятна экспертам в индустрии ещё в середине 2000-х(а некоторым возможно и раньше). И много людей в самом же МЦСТ также прекрасно понимали (и понимают) проблему.

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