0,0
рейтинг
8 января 2013 в 14:09

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

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

Сразу стоит заметить, что я рассматриваю только разработку на 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.
Стоит ли организовать публичный удаленный доступ к отладочной плате Мультиклета?

Проголосовало 274 человека. Воздержалось 172 человека.

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

Михаил Сваричевский @BarsMonster
карма
966,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (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
                            habrahabr.ru/post/146964/
                            VLIW подобная архитектура если быть точным.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                тогда жду спеки по опкодам :)
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            может быть — иногда подзабываю русский.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    С текущим состоянием C-компилятора производительность фатально низкая (соответствующая 5-10Мгц абстрактного не-суперскалярного процессора) из-за не оптимизированного кода


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

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

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

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