Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Хорошо что я так и не заказал себе подобную плату.
Еще рано делать такие выводы, допилят компилятор — будет видно. Отечественных процов почти нет, а здесь интересный новый подход в построении архитектуры, поэтому как появится возможность обязательно прикуплю макетку.
То есть вы предлагаете купить отладочную плату, положить на полочку и ждать пока допилят компилятор?
Если эта тема будет развиваться (а она развиваться будет, т.к. отечественных процессоров нема, а они как воздух нужны оборонке), то допилен будет не только софт, но и камень. Так что в покупке экземпляра из первой пробной партии не вижу смысла (для тех, кто с оборонными проектами не связан).
Ну кроме, конечно, «спортивного интереса», который для увлеченных людей все остальное перевешивает.
Ну кроме, конечно, «спортивного интереса», который для увлеченных людей все остальное перевешивает.
Отечественные процессоры уже складывать некуда — МЦСТ-R150, R500, R1000, Эльбрус-S, Эльбрус-2С+, Кварк, куча процессоров и DSP от ЗАО НТЦ «Модуль», и еще кучка от Миландра (включая отечественные ARM-ы) и «Элвис»-а. И это только то, что публично доступно.
Спасибо, что-то раньше они на глаза не попадались. Поизучаю ассортимент пока.
В том то и дело, это называется «складывать некуда»?
Отечественных процессоров мало и используются в основном вояками, космос, авиация и тд,
обыкновенные разработчики обычно выбирают зарубежную ЭРИ — дешево, просто, нормальные маны, есть из чего выбрать.
Отечественных процессоров мало и используются в основном вояками, космос, авиация и тд,
обыкновенные разработчики обычно выбирают зарубежную ЭРИ — дешево, просто, нормальные маны, есть из чего выбрать.
Так массового производства гражданской продукции нет — нет и гражданских компонент.
Процессоры и микроконтроллеры окупаются только при миллионных тиражах.
Любители со своими мелкосерийными продуктами ничего не решают.
Из гражданских продуктов — есть только микроконтроллеры Миландра по 165 рублей (128кб флеша, 32Kb SRAM, ARM Cortex-M3 80Mhz), которые продаются по сравнимой с буржуйскими аналогами с теми же параметрами цене. И получилось так только потому что за разработку и производство заплачено военными, а потом готовый МК можно и в гражданском варианте продавать.
Процессоры и микроконтроллеры окупаются только при миллионных тиражах.
Любители со своими мелкосерийными продуктами ничего не решают.
Из гражданских продуктов — есть только микроконтроллеры Миландра по 165 рублей (128кб флеша, 32Kb SRAM, ARM Cortex-M3 80Mhz), которые продаются по сравнимой с буржуйскими аналогами с теми же параметрами цене. И получилось так только потому что за разработку и производство заплачено военными, а потом готовый МК можно и в гражданском варианте продавать.
Отечественных процессоров много, но вот какие ядра в них используются, многие процессоры, которые относят к нашим имеют в качестве управляющих ядра архитектуры MIPS (Элвис), ARM (Миландр, Модуль), Spark (МЦСТ). Хотя специализированные вычислители(сопроцессоры) они разрабатывают самостоятельно(Элвис, Модуль).
Так а какие проблемы с известными ядрами? Их не берут как черный ящик, а получают с исходными кодами и модифицируют в соответствии с требованиями.
Как бесплатный бонус — сразу получают нормальные оптимизирующие компиляторы отлаженные годами.
Как бесплатный бонус — сразу получают нормальные оптимизирующие компиляторы отлаженные годами.
Ну ещё вопрос что именно модифицируется. Архитектуру изменить они не могут. Получается, что отечественным процессором управляет зарубежное ядро подправленное под сопроцессор и периферию. И конечно же им гораздо легче, когда не нужно думать за целый компилятор, но мы вносим что-то своё и компилятор через некоторое время будет способен показывать нормальные значения по оптимизации.
Спасибо за первые тесты производительности. Получается, от плотного BLAS'a следует ждать 800MFLOPs максимум. Хотя: напомните, пожалуйста, для скалярных умножений комплексных чисел там одна сложная команда или несколько составных? Если второе, то может специальные ухищрения с чередованием арифметики и загрузки могут помочь выжать больше. Для сомневающихся — GotoBLAS/OpenBLAS писан на смеси си и ассемблера для достижения максимальной производительности. Когда дело касается высокой производительности, люди готовы выкладываться несмотря на «время программиста стоит дорого».
Еще, вы не оценивали задержки доступа к памяти?
Еще, вы не оценивали задержки доступа к памяти?
При умножении комплексных чисел — выполняется 4 умножения и 2 сложения за 1 такт в каждой клетке.
Задержку обращения к набортной памяти (128кб) — не мерял, тут нужно на ассемблере колдовать.
Насчет библиотек и ассемблера — согласен с вами, ими потом тысячи пользуются.
Задержку обращения к набортной памяти (128кб) — не мерял, тут нужно на ассемблере колдовать.
Насчет библиотек и ассемблера — согласен с вами, ими потом тысячи пользуются.
Совсем не обязательно, по крайней мере для базовых тестов. Чтоб посмотреть разницу во времени доступа к регистрам и памяти (не знаю как устроена, но для простоты наверное можно предполагать, что это такой L1 cache), достаточно векторов операции сложности O(n) типа скалярного умножения, запустить ее для разных n и посмотреть насколько просели, когда кончился регистровый файл. Хотя я может не ловлю каких-то частностей неоптимизирующего компиллятора и архитектуры.
Вообще, было бы интересно поиграть с вашей помощью, например вести вики со списком уже пройденных тестов
Вообще, было бы интересно поиграть с вашей помощью, например вести вики со списком уже пройденных тестов
Это наверное и было бы удобнее сделать с удаленным запуском прог и автоматическим бенчмарком.
С текущим компилятором не думаю что возможно отловить латентность памяти, там говорят все в памяти сейчас. Так что только ассемблер, только хардкор.
С текущим компилятором не думаю что возможно отловить латентность памяти, там говорят все в памяти сейчас. Так что только ассемблер, только хардкор.
Так у вас получалось 800 Mflops с данными из памяти?
С данными из памяти 800 не получится. Операции не могут брать операнды из памяти.
Загрузка 8 байт из памяти — отдельной операцией.
И я лично тестировал только код на С, а теоретическая производительнось — получена из изучения документации.
Загрузка 8 байт из памяти — отдельной операцией.
И я лично тестировал только код на С, а теоретическая производительнось — получена из изучения документации.
Кстати, я правильно же понимаю, что у вашего кода получилось выжать ((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. Тут либо бесконечно медленная память, либо не упакованная арифметика, либо все вместе.
В последнем примере кода примерно 15 операций на иттерацию внутреннего цикла (которых теперь 25 млн/4 = 6.25), соответственно 6.25млн*15/8 = 11.71 MFLOPS, или ~6,83 такта на флопс (причем тактов 4-х клеток).
Получается так из-за отсутствия оптимизаций в компиляторе на данный момент.
Получается так из-за отсутствия оптимизаций в компиляторе на данный момент.
кстати, подумалось, а все не так отвратительно, для специфических задач.
Сначала вопрос для уточнения — под скалярным умножением двух комплексных чисел 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 или скалярное произведение. Для скалярных произведений, правда, придется периодически знак минус пририсовывать и потом убирать обратно.
Сначала вопрос для уточнения — под скалярным умножением двух комплексных чисел 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 или скалярное произведение. Для скалярных произведений, правда, придется периодически знак минус пририсовывать и потом убирать обратно.
Да, обычное. Только все-же 6 операций а не 7, плюс в серединке-то в уме :-)
Согласен с тем, что на определенных задачах это может быть полезно.
Согласен с тем, что на определенных задачах это может быть полезно.
да, один плюс зазря посчитал.
А вообще, если разработчики процессора это читают, было бы полезно заодно ввести отдельные команды для скалярного и косого произведения — в железе ведь это уже есть, а польза очевидна. Плюс к этому, если б была операция для произведения любых полиномов первого порядка, не только по i, у этого тоже наверняка нашлось бы применение: интерполяция, методы конечных элементов высокого порядка (там идеи близкие к интерполяции) и т.п.
Лучше бы сделали процессоры для сетевых устройств. Поскольку Я слабо представляю где можно использовать данный процессор.
— для шифрования — так проще DSP
— для управления трафиком — очень слабый, нету портированных ОС
— для тонких клиентов — вообще сомнительно
других вариантов Я не вижу, может кто подскажет?
— для шифрования — так проще DSP
— для управления трафиком — очень слабый, нету портированных ОС
— для тонких клиентов — вообще сомнительно
других вариантов Я не вижу, может кто подскажет?
в том виде как он есть и правда неясно, что это. Но сама технология крайне интересная, по крайней мере идея динамического распараллеливания, это ж рай программиста: можно о параллельности не думать, компиллятор независимые участки сам размечает, а дальше оно само на полной скорости…
Я таких замечательных обещаний слышал от Transmeta — думаю Вы знаете где они сейчас.
Вопрос — зачем мне нужна паралелльность на 80MHz? Проще задействовать OpenCL (ручками) и получить на несколько порядков больший выхлоп.
Вопрос — зачем мне нужна паралелльность на 80MHz? Проще задействовать OpenCL (ручками) и получить на несколько порядков больший выхлоп.
Для примера у Intel есть хорошая технология HT — которая делает форк потока управления на 2 конвеера.
Если кто вспомнит Transmeta Efficon и Crusoe с VLIW — то там тоже был подобный принцип — но там показатели чипа были на порядок лучше… и… с оптимизациями там тоже было туго.
Паралелльность на уровне инструкции уже давно есть — например SSE в Intel выполняются сейчас за 1 такт ядра (особый конвеер), все остальное сильно сложно делать. Многопоточность в этом плане лучше.
OpenCL — это технология (ну или язык — кому как понятнее) — для выполнения вычислений на GPU как абстракции поверх DirectX и OpenGL. C Мультиклетом это вообще никак не связано — точнее связано с многопоточностью, но к ТС не относится.
Если кто вспомнит Transmeta Efficon и Crusoe с VLIW — то там тоже был подобный принцип — но там показатели чипа были на порядок лучше… и… с оптимизациями там тоже было туго.
Паралелльность на уровне инструкции уже давно есть — например SSE в Intel выполняются сейчас за 1 такт ядра (особый конвеер), все остальное сильно сложно делать. Многопоточность в этом плане лучше.
OpenCL — это технология (ну или язык — кому как понятнее) — для выполнения вычислений на GPU как абстракции поверх DirectX и OpenGL. C Мультиклетом это вообще никак не связано — точнее связано с многопоточностью, но к ТС не относится.
ОК. Однако учтите что SSE может быть использовано для операции над числами И для пересылки данных (через xmm регистры) в памяти. Несколько разнородных операций одновременно — если могут быть выполнены паралелльно — то можно самому упаковать в SSE — если же они сильно разные — то их паралеллизм может выйти боком — например просто выражение вида b = a/2 c = b/3 x = c*2 (хотя пример не совсем в тему) — кстати неявные оптимизации для VLIW очень хорошо оценены Transmeta — и это очень большая тема.
P.S. думаю поэтому разработчики Мультиклета так и не сделали еще оптимизирующий компилятор — таже Transmeta очень долго искала решение проблемой оптимизации.
P.S. думаю поэтому разработчики Мультиклета так и не сделали еще оптимизирующий компилятор — таже Transmeta очень долго искала решение проблемой оптимизации.
К сожалению от Transmeta сейчас мало чего осталось — в основном они теперь только патентами торгуют. (Intel, AMD и другим)
В 2001-2002 активно интересовался этой темой, но сейчас ссылки уже не найду.
В 2001-2002 активно интересовался этой темой, но сейчас ссылки уже не найду.
И не из Intel — и смешно думать так :) (могли бы тогда еще и в Transmeta записать)
Если Вы не поняли — то поясняю — то речь шла о VLIW — и применительности, ведь Мультиклет именно сделать по VLIW технологии.
Если Вы не поняли — то поясняю — то речь шла о VLIW — и применительности, ведь Мультиклет именно сделать по VLIW технологии.
habrahabr.ru/post/146964/
VLIW подобная архитектура если быть точным.
VLIW подобная архитектура если быть точным.
тогда жду спеки по опкодам :)
habrahabr.ru/post/163057 в данной теме кое-что по опкодам было
С текущим состоянием C-компилятора производительность фатально низкая (соответствующая 5-10Мгц абстрактного не-суперскалярного процессора) из-за не оптимизированного кода
А есть возможность пояснить подробнее как получилась такая оценка. У всех процессоров имеется пиковая производительность и к ней нельзя привязаться, можно ли скомпилировать ваш тест под конкретный не-суперскалярный процессор?
P.S. Спасибо BarsMonster что занимаетесь анализом мультиклеточного процессора, отладочной платы и си компилятора. Стоит заметить, что завершающие работы по новому Си компилятору ведутся очень активно. В течение этой недели появятся новые примеры и библиотеки с файлами констант.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультиклет: Первые практические тесты и производительность