Мультиклет: Первые практические тесты и производительность

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

    Сразу стоит заметить, что я рассматриваю только разработку на C (а не на Ассемблере) т.к. нынче время работы программистов стоит дороже мегагерцев и памяти. У С-компилятора Мультиклета тяжелая судьба, и на _данный момент_ он находится в зачаточном состоянии (в частности, не реализованы какие-либо оптимизации). Ситуация обещает исправиться к середине/концу года.

    Железо


    Это отладочный комплект НW1-MCp04 (более старый и дорогой). Процессор тут работает на частоте 80Мгц. Разведены интерфейсы RS232, установлены контроллеры USB(1.1, Full-Speed, 12Mbit) и LAN (10/100 MBit). Какой-либо программной поддержки USB и LAN на данный момент нет.

    «IDE»

    IDE Мультиклета представляет собой PSPad с забиндеными горячими кнопками для компиляции и загрузки бинарника в отладочную плату. Такая IDE мне показалась бесполезной, но к счастью, собирать проект и заливать прошивку в плату можно и скриптами:

    Компиляция:
    MultiClet\SDK\shell\MultiClet\build_project.cmd <директория с исходниками>

    Из коробки скрипт компиляции не заработал — т.к. внутри не был указан путь к платформо-зависимым инклудам, добавить его можно и самому:
    rem Ключи запуска препроцессора компилятора Си
    set CPP_KEYS=%CPP_KEYS% -Wp-I.. -Wp-I"%INCDIR%" -Wp-I"[..ваш путь..]\MultiClet\Projects\inc\c"
    Видимо с этой проблемой сталкивались и разработчики поставляемых примеров на C, т.к. в некоторых из них или скопировано содержимое нужных инклудов, или скопированы сами подключаемые из SDK файлы.

    Заливка прошивки в плату:
    MultiClet\SDK\bin\mc-ploader <файл с собранным бинарником>
    Загружать нужно при зажатой кнопке reset на плате.

    Чтобы работала заливка прошивки — нужно установить драйверы для PicoTap. К сожалению, сами драйверы PicoTap не подписаны (!?!), соответственно загрузить их затруднительно. Если отключить в Windows проверку подписи драйверов — то Windows (8 x64) блокирует их загрузку из-за известной несовместимости.

    Решение — руками выбрать для PicoTap драйвер FTDI, и проигнорировать предупреждение Windows что ей не кажеться что этот драйвер подойдет. Это заставляет надеяться что создание самодельного адаптора на FTDI-чипе вполне возможно.

    Внутрисхемной отладки нет.

    Пишем Hello World

    Выводить сообщения будем через RS232. При соединении с компьютером в стандартном кабеле папа-мама нужно поменять местами пины RX и TX (2 и 3). Берем стандартный пример uart, перенастраиваем его на скорость работы 115200 бод:

    void uart_init(UART_TypeDef *UART)
    {
      int port, bitrate, control;
      port = 0x00000300; //alternative port function for uart0
      bitrate = 0x56;//115200 bps
      control = 0x00000003; //rx, tx enable
      GPIOB->BPS = port;
      UART->BDR = bitrate;
      UART->CR = control;
    }
    Значение Bitrate вычисляется по формуле 80Мгц/115200/8 = 86 (0x56) или 87.

    Дописываем функцию вывода строки и вывода символа с проверкой на переполнение буфера UART:
    void uart_send_with_delay(char byte, UART_TypeDef *UART)
    {
      while(uart_fifo_full(UART0) == 1);
      uart_send_byte(byte, UART);
    }
    
    void uart_puts(char *msg, UART_TypeDef *UART)
    {
      while(*msg)uart_send_with_delay(*msg++, UART);
    }
    

    и наконец:
    
    void main()
    {
     uart_init(UART0); //config uart0
     uart_puts("Hello world from Multiclet!!\r\n", UART0);
    }
    Подключаемся к COM-порту любым удобным терминалом и получаем ожидаемый результат.

    Практическая производительность

    Возьмем простейшую программу для теста:
    float i,j,result;
    for(i=0;i<1;i+=0.0002)
       for(j=0;j<1;j+=0.0002)
       {
         result+=i*j;
       }

    Тело внутреннего цикла выполняется 25 млн раз. На Мультиклете с частотой 80Мгц этот код работает 20.3 секунды с текущим компилятором. Посчитаем, какой производительности абстрактного классического процессора соответствуют эти цифры: 25млн циклов * ~5 операций за иттерацию цикла / 20.3 секунды — 6.1 млн операций в секунду.

    Т.е. производительность на данный момент получается на уровне абстрактного не-суперскалярного процессора с частотой 5-10Мгц. Безусловно, производительность будет существенно улучшена по мере развития компилятора.

    Если мы немного поможем компилятору, и руками развернем цикл:
    for(i=0;i<1;i+=0.0002)//8 seconds
       for(j=0;j<1;j+=0.0008)
       {
         result+=i*j+i*(j+0.0002)+i*(j+0.0004)+i*(j+0.0006);
       }
    То тест будет работать уже 8 секунд, если упростить выражение до result+=i*(j*4+0.0012), то 6.8 секунды.

    Теоретическая производительность

    Наконец, стало окончательно ясно, какая теоретически-достижимая производительность у Мультиклета при идеальном распараллеливании на частоте 100Мгц:

    2.4 GFLOP: Если все 4 клетки выполняют только операцию комплексного умножения, и больше ничего.
    800 MFLOP: Если все 4 клетки выполняют остальные арифметические операции в упакованном виде (т.е. одна и та же операция выполняется над обоими 32-х битными половинками).
    400 MFLOP — Если у нас операции нужно делать только по одному разу, а не парами (как обычно это бывает на не-вычислительном коде).

    Наконец, если у нас распараллеливание на все 4 клетки не получается — то рассчитывать можно будет только на 150-300 MFLOP.

    Вручную оптимизированный на ассемблере код быстрого преобразования фурье с практически идеальным распараллеливанием, с вырезанными блоками сохранения-загрузки (разработчики уверяют что в будущем их удасться соптимизировать) дает ~1.2 GFLOP (меньше 2.4 получается именно потому что не все операции — комплексное умножение, нужны еще сложения/вычитания и другие).

    Потребление энергии

    При максимальной нагрузке:
    1.8V — 0.39A
    3.3V — 7.2mA
    Соответственно, потребляемая мощность — 0,725Вт на частоте 80Мгц (на 100Мгц будет выше).

    При зажатом reset-е потребление падает до 0.3А по шине 1.8V, и 0.8ма по шине 3.3V.

    Резюме

    С текущим состоянием C-компилятора производительность фатально низкая (соответствующая 5-10Мгц абстрактного не-суперскалярного процессора) из-за не оптимизированного кода. Вся надежда на то, что разработчики компилятора за 2013 год его допилят, и Мультиклет тогда сможет конкурировать с другими отечественными разработками.

    PS. В противники Мультиклета меня записывать не стоит — я обоими руками за то, чтобы у него все работало отлично и он всех рвал, и также обоими руками за отечественную микроэлектронику.

    PPS. Насчет вопроса о том, как должен работать удаленный доступ я вполне серьёзно — пока у меня нет идей кроме прошивать присланный бинарник и присылать обратно все, что вываливается из RS232.
    Стоит ли организовать публичный удаленный доступ к отладочной плате Мультиклета?

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

    Метки:
    Поделиться публикацией
    Комментарии 53
    • +3
      Хорошо что я так и не заказал себе подобную плату.
      • +1
        Еще рано делать такие выводы, допилят компилятор — будет видно. Отечественных процов почти нет, а здесь интересный новый подход в построении архитектуры, поэтому как появится возможность обязательно прикуплю макетку.
        • +5
          То есть вы предлагаете купить отладочную плату, положить на полочку и ждать пока допилят компилятор?
          • 0
            Если эта тема будет развиваться (а она развиваться будет, т.к. отечественных процессоров нема, а они как воздух нужны оборонке), то допилен будет не только софт, но и камень. Так что в покупке экземпляра из первой пробной партии не вижу смысла (для тех, кто с оборонными проектами не связан).
            Ну кроме, конечно, «спортивного интереса», который для увлеченных людей все остальное перевешивает.
            • 0
              Отечественные процессоры уже складывать некуда — МЦСТ-R150, R500, R1000, Эльбрус-S, Эльбрус-2С+, Кварк, куча процессоров и DSP от ЗАО НТЦ «Модуль», и еще кучка от Миландра (включая отечественные ARM-ы) и «Элвис»-а. И это только то, что публично доступно.
              • 0
                Спасибо, что-то раньше они на глаза не попадались. Поизучаю ассортимент пока.
                • 0
                  В том то и дело, это называется «складывать некуда»?
                  Отечественных процессоров мало и используются в основном вояками, космос, авиация и тд,
                  обыкновенные разработчики обычно выбирают зарубежную ЭРИ — дешево, просто, нормальные маны, есть из чего выбрать.
                  • +2
                    Так массового производства гражданской продукции нет — нет и гражданских компонент.
                    Процессоры и микроконтроллеры окупаются только при миллионных тиражах.
                    Любители со своими мелкосерийными продуктами ничего не решают.

                    Из гражданских продуктов — есть только микроконтроллеры Миландра по 165 рублей (128кб флеша, 32Kb SRAM, ARM Cortex-M3 80Mhz), которые продаются по сравнимой с буржуйскими аналогами с теми же параметрами цене. И получилось так только потому что за разработку и производство заплачено военными, а потом готовый МК можно и в гражданском варианте продавать.
                  • 0
                    Отечественных процессоров много, но вот какие ядра в них используются, многие процессоры, которые относят к нашим имеют в качестве управляющих ядра архитектуры MIPS (Элвис), ARM (Миландр, Модуль), Spark (МЦСТ). Хотя специализированные вычислители(сопроцессоры) они разрабатывают самостоятельно(Элвис, Модуль).
                    • 0
                      Так а какие проблемы с известными ядрами? Их не берут как черный ящик, а получают с исходными кодами и модифицируют в соответствии с требованиями.

                      Как бесплатный бонус — сразу получают нормальные оптимизирующие компиляторы отлаженные годами.
                      • 0
                        Ну ещё вопрос что именно модифицируется. Архитектуру изменить они не могут. Получается, что отечественным процессором управляет зарубежное ядро подправленное под сопроцессор и периферию. И конечно же им гораздо легче, когда не нужно думать за целый компилятор, но мы вносим что-то своё и компилятор через некоторое время будет способен показывать нормальные значения по оптимизации.
                        • 0
                          > Ну ещё вопрос что именно модифицируется. Архитектуру изменить они не могут.
                          Есть разные типы лицензии, ARM могут продать не только готовое ядро, но и право его модифицировать.
            • +1
              Спасибо за первые тесты производительности. Получается, от плотного BLAS'a следует ждать 800MFLOPs максимум. Хотя: напомните, пожалуйста, для скалярных умножений комплексных чисел там одна сложная команда или несколько составных? Если второе, то может специальные ухищрения с чередованием арифметики и загрузки могут помочь выжать больше. Для сомневающихся — GotoBLAS/OpenBLAS писан на смеси си и ассемблера для достижения максимальной производительности. Когда дело касается высокой производительности, люди готовы выкладываться несмотря на «время программиста стоит дорого».

              Еще, вы не оценивали задержки доступа к памяти?
              • 0
                При умножении комплексных чисел — выполняется 4 умножения и 2 сложения за 1 такт в каждой клетке.
                Задержку обращения к набортной памяти (128кб) — не мерял, тут нужно на ассемблере колдовать.

                Насчет библиотек и ассемблера — согласен с вами, ими потом тысячи пользуются.
                • 0
                  Совсем не обязательно, по крайней мере для базовых тестов. Чтоб посмотреть разницу во времени доступа к регистрам и памяти (не знаю как устроена, но для простоты наверное можно предполагать, что это такой L1 cache), достаточно векторов операции сложности O(n) типа скалярного умножения, запустить ее для разных n и посмотреть насколько просели, когда кончился регистровый файл. Хотя я может не ловлю каких-то частностей неоптимизирующего компиллятора и архитектуры.

                  Вообще, было бы интересно поиграть с вашей помощью, например вести вики со списком уже пройденных тестов
                  • 0
                    Это наверное и было бы удобнее сделать с удаленным запуском прог и автоматическим бенчмарком.

                    С текущим компилятором не думаю что возможно отловить латентность памяти, там говорят все в памяти сейчас. Так что только ассемблер, только хардкор.
                    • 0
                      Так у вас получалось 800 Mflops с данными из памяти?
                      • 0
                        С данными из памяти 800 не получится. Операции не могут брать операнды из памяти.
                        Загрузка 8 байт из памяти — отдельной операцией.

                        И я лично тестировал только код на С, а теоретическая производительнось — получена из изучения документации.
                        • 0
                          Кстати, я правильно же понимаю, что у вашего кода получилось выжать ((1÷0.0002)×(1 + (1÷0.0008)×(1+4))÷6.8 ~ 4596323.5 flops ~ 4.6 Mflops? И у вас получилось 6.8*80*1000^2/((1÷0.0002)×(1 + (1÷0.0008)×(1+4) = 17.4 такта на итерацию? Получается 3.48 такта на флопс, а это очень много, если сравнивать с x86. Тут либо бесконечно медленная память, либо не упакованная арифметика, либо все вместе.
                          • 0
                            В последнем примере кода примерно 15 операций на иттерацию внутреннего цикла (которых теперь 25 млн/4 = 6.25), соответственно 6.25млн*15/8 = 11.71 MFLOPS, или ~6,83 такта на флопс (причем тактов 4-х клеток).

                            Получается так из-за отсутствия оптимизаций в компиляторе на данный момент.
                            • 0
                              Как у вас получается 15? Я считал так: одна операция j+=0.0008, четыре операции в оптимизированном выражении ( result+=i*(j*4+0.0012) ), итого 5 во внутреннем цикле, и не забыть i+=0.0002, которое приходит в ~10^3 раз реже, но все-таки учел.
                              • 0
                                Я брал не до конца оптимизированное выражение:

                                result+=i*j+i*(j+0.0002)+i*(j+0.0004)+i*(j+0.0006);

                                +инкремент и проверка условия окночания цикла еще сколько то.
                                • +1
                                  Тогда мы разное сравниваем, я брал до конца оптимизированное выражение. А вот условия перехода я в свою оценку не включал.
                  • +1
                    кстати, подумалось, а все не так отвратительно, для специфических задач.

                    Сначала вопрос для уточнения — под скалярным умножением двух комплексных чисел z = a+bi и w = c+di имеется ввиду обычное умножение z*w=(ac-bd)+i(ad+bc), или адамарово, ac + bdi? У первого выражения 7 арифметических операций, 2.4Gflops/7 ~ 342 Mflops на одну операцию, примерно соответствует производительности арифметических операций поодиночке, значит видимо речь все-таки о простом умножении комплексных чисел.

                    Дело в том, что это очень неплохо, когда нужно считать детерминанты (их можно блочно-матрично считать, элементарный блок 2х2 получается за один такт — хорошо!), произведения полиномов и просто скалярные умножения векторов. Особенно можно развернуться с алгоритмами типа умножения Карацубы. То есть, я предлагаю выполнить команду, расчитанную на умножения комплексных чисел, но половину результата отбросить, в зависимости от того, нужно косое произведение как в детерминанте 2х2 или скалярное произведение. Для скалярных произведений, правда, придется периодически знак минус пририсовывать и потом убирать обратно.
                    • 0
                      Да, обычное. Только все-же 6 операций а не 7, плюс в серединке-то в уме :-)

                      Согласен с тем, что на определенных задачах это может быть полезно.
                      • 0
                        да, один плюс зазря посчитал.
                        • 0
                          А вообще, если разработчики процессора это читают, было бы полезно заодно ввести отдельные команды для скалярного и косого произведения — в железе ведь это уже есть, а польза очевидна. Плюс к этому, если б была операция для произведения любых полиномов первого порядка, не только по i, у этого тоже наверняка нашлось бы применение: интерполяция, методы конечных элементов высокого порядка (там идеи близкие к интерполяции) и т.п.
                          • 0
                            То что это «уже есть в железе» — это не факт. Это могло быть легко реализовано, но кремний уже не изменить. Так что если нет — то не судьба (по крайней мере в ближайшие 1-2 года).
                  • +2
                    Лучше бы сделали процессоры для сетевых устройств. Поскольку Я слабо представляю где можно использовать данный процессор.
                    — для шифрования — так проще DSP
                    — для управления трафиком — очень слабый, нету портированных ОС
                    — для тонких клиентов — вообще сомнительно
                    других вариантов Я не вижу, может кто подскажет?
                    • 0
                      в том виде как он есть и правда неясно, что это. Но сама технология крайне интересная, по крайней мере идея динамического распараллеливания, это ж рай программиста: можно о параллельности не думать, компиллятор независимые участки сам размечает, а дальше оно само на полной скорости…
                      • +1
                        Я таких замечательных обещаний слышал от Transmeta — думаю Вы знаете где они сейчас.
                        Вопрос — зачем мне нужна паралелльность на 80MHz? Проще задействовать OpenCL (ручками) и получить на несколько порядков больший выхлоп.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Для примера у Intel есть хорошая технология HT — которая делает форк потока управления на 2 конвеера.
                            Если кто вспомнит Transmeta Efficon и Crusoe с VLIW — то там тоже был подобный принцип — но там показатели чипа были на порядок лучше… и… с оптимизациями там тоже было туго.
                            Паралелльность на уровне инструкции уже давно есть — например SSE в Intel выполняются сейчас за 1 такт ядра (особый конвеер), все остальное сильно сложно делать. Многопоточность в этом плане лучше.
                            OpenCL — это технология (ну или язык — кому как понятнее) — для выполнения вычислений на GPU как абстракции поверх DirectX и OpenGL. C Мультиклетом это вообще никак не связано — точнее связано с многопоточностью, но к ТС не относится.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                ОК. Однако учтите что SSE может быть использовано для операции над числами И для пересылки данных (через xmm регистры) в памяти. Несколько разнородных операций одновременно — если могут быть выполнены паралелльно — то можно самому упаковать в SSE — если же они сильно разные — то их паралеллизм может выйти боком — например просто выражение вида b = a/2 c = b/3 x = c*2 (хотя пример не совсем в тему) — кстати неявные оптимизации для VLIW очень хорошо оценены Transmeta — и это очень большая тема.
                                P.S. думаю поэтому разработчики Мультиклета так и не сделали еще оптимизирующий компилятор — таже Transmeta очень долго искала решение проблемой оптимизации.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0
                                    К сожалению от Transmeta сейчас мало чего осталось — в основном они теперь только патентами торгуют. (Intel, AMD и другим)
                                    В 2001-2002 активно интересовался этой темой, но сейчас ссылки уже не найду.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        И не из Intel — и смешно думать так :) (могли бы тогда еще и в Transmeta записать)
                                        Если Вы не поняли — то поясняю — то речь шла о VLIW — и применительности, ведь Мультиклет именно сделать по VLIW технологии.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            может быть — иногда подзабываю русский.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        С текущим состоянием C-компилятора производительность фатально низкая (соответствующая 5-10Мгц абстрактного не-суперскалярного процессора) из-за не оптимизированного кода


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

                        P.S. Спасибо BarsMonster что занимаетесь анализом мультиклеточного процессора, отладочной платы и си компилятора. Стоит заметить, что завершающие работы по новому Си компилятору ведутся очень активно. В течение этой недели появятся новые примеры и библиотеки с файлами констант.
                        • 0
                          Цифра получилась в результате ручной оценки количества требуемых операций для внутреннего цикла (включая операции по организации цикла).

                          Для первого примера кода ~ 5 операций во внутреннем цикле, умножаем на 25млн делим на 20.3 секунды — получаем в среднем 6.1 млн операций в секунду.
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Стоит — ~20$ процессор, зачем нужно — пока вопрос. Возможности будет видно после появления оптимизирующего компилятора, а сейчас что-то полезное сделать трудно.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                Насколько я знаю, это еще не оптимизирующий. А оптимизирующий обещали в районе марта — как выйдет — будем смотреть.

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