Обзор и сравнительное тестирование пэвм «эльбрус 401?pc». часть третья — средства разработки

Обзор и сравнительное тестирование пэвм «эльбрус 401?pc». часть третья — средства разработки

Продолжаем обзор нового отечественного компьютера. По окончании краткого знакомства с изюминками архитектуры «Эльбрус», разглядим предлагаемые нам средства разработки ПО.
Смотрите кроме этого: КИС от Минэкономики: серверы «Эльбрус» на Linux и полный запрет на зарубежное деловое ПО

Импортозамещение в госкомпаниях делается ещё брутальнееСерверы «Эльбрус-4.4» на процессоре «Эльбрус-4С» разработки столичной компании МЦСТ. Фото: Донат Сорокин / ТАССДо сих пор импортозамещение в госорганизациях проходило по «мягкой» схеме. Не так долго осталось ждать это может измениться, в то время, когда государственной компании будут обязаны брать отечественный софт.

Министерство экономразвития создало проект доклада, что предоставит президенту Российской Федерации, для получения одобрения на трансформации в закон «Об информации». В закон предлагают внести понятие «корпоративная информационная совокупность» (КИС).

Напоминаем структуру статьи:

  1. обзор аппаратного обеспечения:
    • процесс приобретения;
    • аппаратное обеспечение;
    • обзор ПО:
      • запуск ОС;
      • штатное ПО;
      • обзор средств разработки:
        • изюминки архитектуры;
        • машинный язык;
        • средства разработки;
        • сравнительное тестирование производительности:
          • описание соперничающих компьютеров;
          • результаты бенчмарков;
          • подведение итогов.

          Приятного чтения!Особенности архитектурыСформулировать сущность архитектуры E2K в одной фразе возможно так: 64-битные регистры, явный параллелизм выполнения руководств и строгоконтролируемый доступк памяти.К примеру, процессоры архитектуры x86 либо SPARC, талантливые делать более одной инструкции за такт (суперскалярные), а время от времени ещё и вне очерёдности, имеют неявный параллелизм: процессор прямо в настоящем времени разбирает зависимости между руководствами на маленьком участке кода и, в случае если вычисляет вероятным, нагружает те либо иные аккуратные устройства в один момент, — время от времени чересчур оптимистично (спекулятивно, с отбрасыванием результата либо откатом транзакции в случае неудачного предсказания), время от времени, напротив, чересчур пессимистично (предполагая зависимости между значениями регистров либо частей регистров, которых на самом деле нет с точки зрения исполняемой программы). При явном параллелизме тот же анализ проходит на этапе компиляции, и все машинные руководства, определённые для параллельного выполнения, записываются в одно широкое командное слово (very large instruction word, VLIW), — причём у «Эльбруса» протяженность этого «слова» не фиксирована и может составлять от 1 до 8 двойных слов (в данном контексте, одинарное слово имеет разрядность 32 бита).Несомненно, компилятор располагает намного большими возможностями в замысле количества охватываемого кода, затрачиваемого времени и памяти, а при написании машинного кода вручную программист может осуществить ещё более интеллектуальную оптимизацию.

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

          Наконец, оптимизирующий компилятор мало окажет помощь при интерпретации динамических языков.Всё это замечательно знают в МЦСТ, очевидно, и потому в «Эльбрусе» также реализованы технологии спекулятивного исполнения, заблаговременная подкачка кода и данных, комбинированные вычислительные операции. Исходя из этого, вместо того дабы до бесконечности теоретизировать и прикидывать, сколько гипотетических гигафлопсов может выдать та либо другая платформа при успешном стечении событий, в четвёртой части статьи мы и оценим фактическую производительность настоящих программ — прикладных и синтетических.VLIW: прорыв либо тупик?Бытует вывод, что концепция VLIW не хорошо подходит для процессоров неспециализированного назначения: дескать, выпускались же в то время, когда?то Transmeta Crusoe — не «выстрелили».

          Автору необычно слышать такие утверждения, так как десять лет назад он проводил тестирование ноутбука на базе Efficeon (это новое поколение той же линейки) и отыскал его очень многообещающим. Если не знать, что под капотом выполняется трансляция x86-кода в родные команды, додуматься об этом было нереально. Да, тягаться с Pentium M он не имел возможность, но производительность на уровне Pentium 4 показывал, причём потребление энергии было куда скромнее.

          И уж совершенно верно он был на голову выше VIA C3, что в полной мере себе x86.Не меньший интерес из?за собственной экзотичности вызывает разработка защищённого выполнения программ на языках C/C++, где применение указателей предоставляет широкий круг возможностей выстрелить себе в ногу. Концепция контекстной защиты, совместно реализуемая компилятором на этапе сборки и процессором на этапе исполнения, а кроме этого ОС в части управления памятью, не разрешит нарушить область видимости переменных, — будь то обращение к закрытой переменной класса, частным данным другого модуля, локальным переменным вызывающей функции.

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

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

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

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

          Помимо этого, более твёрдый контроль со стороны компилятора заставляет переписывать «дурно пахнущий» и непереносимый код, соответственно, косвенно повышает культуру программирования.Порядок байтов при хранении чисел в памяти у «Эльбруса», в отличие от SPARC, — little endian (первым идёт младший байт), то имеется как на х86. Подобно, потому, что платформа пытается к помощи x86-кода, отсутствуют какие-либо ограничения на выравнивание данных в памяти.Порядок, выравнивание и переносимостьДля программистов, избалованных комфортным миром Intel, может стать откровением, что за пределами этого мира обращение к памяти без выравнивания (к примеру, запись 32?битного значения по адресу 0x04000005) — это не легко нежелательная операция, выполняющаяся медленнее простой, а запрещённое воздействие, приводящее к аппаратному исключению.

          Исходя из этого портирование номинально кросс-платформенного проекта, сначала сводящееся к минимальным правкам, по окончании первого же запуска может зайти в тупик, — в то время, когда делается ясно, что вся сериализация и десериализация данных (вещественные числа и целые, текст UTF?16), рассыпанная по всему многомегабайтному коду, производится напрямую, без выделенного уровня платформенной абстракции, и в каждом конкретном случае оформлена по?собственному. Определённо, имей любой программист возможность контролировать собственные нетленные шедевры на других платформах, — к примеру, SPARC, — общемировое уровень качества кода точно бы повысилось.Более детально об устройстве компьютеров МЦСТ на архитектурах SPARC и E2K возможно прочесть в книге «вычислительные комплексы и Микропроцессоры семейства Эльбрус», которая вышла в издательстве «Питер» минимальным тиражом и в далеком прошлом уже разошлась по рукам, но безвозмездно дешева в виде PDF (6 Мбайт) и за маленькую плату в Гугл Play.

          На фоне отсутствия второй подробной информации в открытом доступе, это издание — прямо таки кладезь знаний. Но текст сконцентрирован в основном на аппаратной части, методах конвейеров и работы буферов, кэшей и арифметико-логических устройств, — совсем не затрагивается тема написания [эффективных] программ, и кроме того легко упоминания машинных инструкции возможно по пальцам пересчитать.Машинный языкПомимо компиляции высокоуровневых языков C, C++, Fortran, документация при каждом эргономичном случае не забывает упомянуть возможность написания программ конкретно на Ассемблере, но нигде не уточняется, как же как раз возможно приобщиться к этому филигранному мастерству, — где не смотря на то, что бы забрать справочник по машинным командам.

          К счастью, в совокупности имеется отладчик GDB, что может дизассемблировать код ранее скомпилированных программ. Дабы не выходить за рамки статьи, напишем несложную арифметическую функцию, имеющую хороший задел для распараллеливания.uint64_t CalcParallel( uint64_t a, uint64_t b, uint64_t c, uint32_t d, uint32_t e, uint16_t f, uint16_t g, uint8_t h ) { return (a * b) + (c * d) — (e * f) + (g / h); } Вот во что она транслируется при компиляции в режиме ?O3:0x0000000000010490 : muld,1 %dr0, %dr1, %dg20 sxt,2 6, %r3, %dg19 getfs,3 %r6, _f32,_lts2 0x2400, %g17 getfs,4 %r5, _lit32_ref, _lts2 0x00002400, %g18 getfs,5 %r7, _f32,_lts3 0x200, %g16 return %ctpr3 setwd wsz = 0x5, nfx = 0x1 setbp psz = 0x0 0x00000000000104c8 : nop 5 muld,0 %dr2, %dg19, %dg18 muls,3 %r4, %g18, %g17 sdivs,5 %g17, %g16, %g16 0x00000000000104e0 : sxt,0 6, %g17, %dg17 addd,1 %dg20, %dg18, %dg18 0x00000000000104f0 : nop 5 subd,0 %dg18, %dg17, %dg17 0x00000000000104f8 : sxt,0 2, %g16, %dg16 0x0000000000010500 : ct %ctpr3 ipd 3 addd,0 %dg17, %dg16, %dr0 Первое, что кидается в глаза, — любая команда декодируется сходу в пара руководств, делаемых параллельно.

          Мнемоническое обозначение руководств в целом интуитивно ясно, не смотря на то, что кое-какие заглавия кажутся непривычными по окончании Intel: к примеру, инструкция беззнакового расширения тут именуется sxt, а не movzx. Параметром многих вычислительных команд, кроме фактически операндов, есть номер аккуратного устройства, — недаром «ELBRUS» расшифровывается как explicit basic resources utilization scheduling, то имеется «явное планирование применения главных ресурсов».Для обращения к полному 64-битному значению регистра, добавляется префикс «d»; по идее, вероятно кроме этого обращение к младшим 16 и 8 битам значения.

          Обозначение глобальных регистров неспециализированного назначения, которых тут 32 штуки, перед номером имеет префикс «g», а локальные регистры процедур — префикс «r». Размер окна локальных регистров, запрашиваемый инструкцией setwd, может быть около 224 штуки, а откачка в стек производится машинально по мере необходимости.Метод применения некоторых руководств прямо-таки сбивает с толку: к примеру, return, как нетрудно додуматься, помогает для возврата управления вызывающей процедуре, но во всех изученных примерах кода эта инструкция видится задолго до последней команды (где кроме этого присутствует какое?то манипулирование контекстом), — время от времени кроме того в самом первом командном слове, как тут.

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

          Будем сохранять надежду, что в один раз руководство и справочник команд по программированию и оптимизации станут достоянием общественности.Средства разработкиШтатным компилятором языков C/C++ в ОС «Эльбрус» есть LCC — личная разработка компании МЦСТ, совместимая с GCC. Подробная информация о структуре и правилах работы этого компилятора не публикуется, но если доверять интервью бывшего разработчика одного из нескольких развиваемых подвидов компилятора, для высокоуровневого разбора исходных кодов употребляется фронтэнд от Edison Design Group, а низкоуровневая трансляция в машинные команды может выполняться по?различному — без оптимизации либо с оптимизацией.

          Конечным пользователям поставляется как раз оптимизирующий компилятор, причём не лишь на платформе E2K, для которой попросту не существует других генераторов машинного кода, но и на платформах семейства SPARC, где кроме этого дешёв простой GCC в составе ОС МСВС.Учитывая ранееперечисленные архитектурные изюминки, — явный параллелизм, защищённое выполнение программ, — компилятор LCC, разумеется, реализует в себе большое количество неповторимых ответов, хороших самого проверки и скрупулёзного изучения на практике. К сожалению, на момент написания этих строчков создатель не имеет ни достаточной квалификации для этого, ни времени на подобные изучения; возможно, что рано либо поздно данным вопросом займётся значительно более широкий круг представителей ИТ-сообщества, а также более компетентных.Из того, что всё?таки удалось подметить невооружённым глазом при сборке программ для тестирования производительности, — LCC на E2K чаще вторых выдаёт предупреждения о вероятных неточностях, неграмотных конструкциях либо легко странных местах в коде.

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

          К примеру, в коде Postgresql одна и та же конструкция четырежды видится в одном файле с маленькими вариациями:for (i = 0, ptr = cont-cells; *ptr; i++, ptr++) { //….// /* is string only whitespace? */ if ((*ptr)[strspn(*ptr, \t)] == ‘\0’) fputs(, fout); else html_escaped_print(*ptr, fout); //….// } Компилятор предрекает вероятный выход за пределы 1?мерного массива в строчке с вызовом функции strspn. При каких событиях такое может случиться, автору не ясно (и на вторых платформах для того чтобы предупреждения не было, не смотря на то, что режим испытаний ?Warray-bounds есть стандартным для GCC), но привлекает внимание  многократное тиражирование одной и той же нетривиальной конструкции (раз уж пригодилось пояснять её назначение в комментарии), вместо того, дабы вынести её в отдельную функцию с красноречивым заглавием, не требующим пояснений.

          Кроме того в случае если тревога была фальшивой, обнаружение дурно пахнущего кода — нужный эффект; этак авторы статического анализатора PVS?Studio останутся без работы. А в случае если серьёзно, то было бы занятно и полезно сравнить, какие конкретно дополнительные неточности в коде вправду способен обнаруживать LCC благодаря неповторимым изюминкам архитектуры E2K, — заодно мир свободного ПО смог бы взять очередную порцию баг-репортов.Ещё одним курьёзным результатом знакомства с говорливым LCC стало просвещение автора, а после этого и его более умелых сотрудников, на тему, что такое триграфы (trigraphs) в языках C/C++, и из-за чего они по умолчанию не поддерживаются, к счастью.

          Вот так живёшь и не подозреваешь, что безобидное на первый взор сочетание знаков пунктуации в текстовых литералах либо комментариях может оказаться миной замедленного действия — либо хорошим материалом для программной закладки, смотря с какой стороны баррикад вы находитесь.Неприятным следствием самостийности LCC есть то, что формат его сообщений отличается от такового у GCC, и при компиляции из среды разработки (к примеру, Qt Creator) эти сообщения попадают только в неспециализированный издание работы, но не в перечень выявленных неприятностей. Быть может, это всё неким образом поддаётся настройке, — либо со стороны компилятора, либо в среде разработки, — но как минимум «из коробки» одно другого не осознаёт.Традиционно остро для отечественных платформ, учитывая их относительно низкую производительность, стоит вопрос кросс-компиляции, то имеется сборки программ под конкретный набор и целевую архитектуру системных библиотек, применяя ресурсы более замечательных компьютеров, с другой архитектурой и иным программным обеспечением. Если судить по опознавательным строчкам в ядре совокупности «Эльбрус» и в самом компиляторе LCC, их сборка производится на Linux i386, но в дистрибутив самой совокупности данный инструментарий для х86, понятное дело, не входит. Весьма интересно, а возможно ли напротив: на «Эльбрусе» собирать программы для вторых платформ? (Продвинуться дальше первой фазы сборки GCC для i386 у автора не вышло.)Версии важнейших пакетов для разработчика:

          • компиляторы: lcc 1.19.18 (gcc 4.4.0 compatible);
          • интерпретаторы: erlang 15.b.1, светло синий 4.0.2, lua 5.1.4, openjdk 1.6.0_27 (jvm 20.0?b12), perl 5.16.3, php 5.4.11, python 2.7.3, slang 2.2.4, tcl 8.6.1;
          • средства сборки: autoconf 2.69, automake 1.13.1, cmake 2.8.10.2, distcc 3.1, m4 1.4.16, make 3.81, makedepend 1.0.4, pkgtools 13.1, pmake 1.45;
          • средства компоновки: binutils 2.23.1, elfutils 0.153, patchelf 0.6;
          • фреймворки: boost 1.53.0, qt 4.8.4, qt 5.2.1;
          • библиотеки: expat 2.1.0, ffi 3.0.10, gettext 0.18.2, glib 2.36.3, glibc 2.16.0, gmp 4.3.1, gtk+ 2.24.17, mesa 10.0.4, ncurses 5.9, opencv 2.4.8, pcap 1.3.0, popt 1.7, protobuf 2.4.1, sdl 1.2.13, sqlite 3.6.13, tk 8.6.0, usb 1.0.9, wxgtk 2.8.12, xml?parser 2.41, zlib 1.2.7;
          • отладки и средства тестирования: cppunit 1.12.1, dprof 1.3, gdb 7.2, perf 3.5.7;
          • среды разработки: anjuta 2.32.1.1, glade 2.12.0, glade 3.5.1, qt?creator 2.7.1;
          • совокупности контроля предположений: bzr 2.2.4, cvs 1.11.22, git 1.8.0, patch 2.7, subversion 1.7.7.

          Снова же, если вы ожидали GCC 5, PHP 7 и Java 9, то это — ваши неприятности, как говорит один узнаваемый футболист. В данном случае нужно ещё сообщить благодарю, что не смотря на то, что бы не GCC 3.4.6 (LCC 1.16.12), как в составе прошлых предположений совокупности «Эльбрус», либо GCC 3.3.6 в составе МСВС 3.0; кстати, главным компилятором в МСВС 3.0 и поныне есть GCC 2.95.4 (а чему удивляться, в то время, когда в том месте ядро из 2.4-ветки?).

          По сравнению с прошлой обстановкой, в то время, когда возможно было наткнуться на баг GCC, исправленный в апстриме ещё десять лет назад, в новой совокупности практически райские условия, — возможно кроме того на С++11 замахнуться, если не требуется сохранять обратную совместимость.Появление OpenJDK хоть в каком-то виде уже возможно назвать громадным прорывом, — так как нелюбовь к Java и Mono в подобных системах в далеком прошлом известна; и нелюбовь эту можно понять, в то время, когда кроме того нативные программы чуть шевелятся. Потому, что среди сотрудников автора имеется большое количество джавистов, в силу перечисленных выше событий вынужденных сдерживать души красивые порывы, было решено отдельную серию тестов производительности посвятить Java.

          Забегая вперёд, напомним, что результаты были обескураживающими кроме того в относительном выражении: с таким же успехом возможно писать трактуемые скрипты на PHP либо Python, возможно.Помощью одних лишь C и C++ заявленная совместимость с GNU Compiler Collection не ограничивается: в совокупности ещё имеется транслятор Фортрана. Потому, что создатель знаком разве что с доктором наук Фортраном, всем интересующимся возможно порекомендовать декабрьский топик на «Сделано у нас», где в комментариях затрагивается тема применения этого языка в качестве бенчмарка.На десерт мы припасли самое вкусное: последняя часть статьи посвящена изучению быстродействия «Эльбруса» в сравнении с самыми различными аппаратно-программными платформами, а также и отечественными.

          Случайная статья:

          Курсы тестировщиков онлайн. Урок 8. Регрессионное тестирование что это


          Похожие статьи:

          Комментирование и размещение ссылок запрещено.

          Обсуждение закрыто.