Сообщество

Первоначально компании нужно определится с линейками процессоров.
И наконец то создать что то отличное от комбинаций ежа и ужа.
После этого для каждой линейки нужно подобрать свои наборы тестов.

bav wrote:

Первоначально компании нужно определится с линейками процессоров.
И наконец то создать что то отличное от комбинаций ежа и ужа.
После этого для каждой линейки нужно подобрать свои наборы тестов.

Когда речь идёт о общей архитектуре, тесты помогают понять насколько она перспективна и производительна и наличие всяких встренных контроллеров переферии на тест вычисления числа Пи никак не влияет. По сути, тесты призваны сдуть всякую шелуху маркетинга и заумные рассуждения о уникальности и несравненности и тупо взять конкретную задачу и посмотреть, как её решает это устройство. Это как раз и позволит позиционировать процессор показав высокую производительность на МГц или Вт в СРАВНЕНИИ С ИЗВЕСТНЫМИ и распространёнными аналагами.
По крайней мере мне понятно, что это как минимум высокопроизводительный микроконтроллер, потому что низкопроизводительный, к примеру - вот:
http://www.ixbt.com/news/2016/01/09/ineda-nachinaet-vypusk-odnokristalnyh-sistem-dlja-nosimoj-jelektroniki-i-iot-s-minimalnym-jenergopotrebleniem.html
Ineda Systems Двухядерный 240 МГц + 80 МГц MIPS 29 мкА/МГц от 300мАч аккума пашет 30 дней, 1.1Мб SRAM, АЦП, FLOAT ALU, 32bit таймеры, контроллер дисплея, MP3, NAND, SPI, SD, eMMC, USB OTG, SDIO и I2S. Из ПО RTOS + стек сетеввых протоколов. ПО 3.5 бакса оптом. Ну и куда тут двигаться? Поэтому двайте ещё раз уделим внимание производительности, а не нише 3 баксовых контроллеров.

ещё тест

6 Sysbench вроде как распространнён на Линукс можно попробовать сделать усечённый вариант (http://pasha.spb.su/arch/430 https://github.com/akopytov/sysbench)

VaalKIA wrote:

bav wrote:

Первоначально компании нужно определится с линейками процессоров.
И наконец то создать что то отличное от комбинаций ежа и ужа.
После этого для каждой линейки нужно подобрать свои наборы тестов.

Когда речь идёт о общей архитектуре, тесты помогают понять насколько она перспективна и производительна и наличие всяких встренных контроллеров переферии на тест вычисления числа Пи никак не влияет. По сути, тесты призваны сдуть всякую шелуху маркетинга и заумные рассуждения о уникальности и несравненности и тупо взять конкретную задачу и посмотреть, как её решает это устройство. Это как раз и позволит позиционировать процессор показав высокую производительность на МГц или Вт в СРАВНЕНИИ С ИЗВЕСТНЫМИ и распространёнными аналагами.
По крайней мере мне понятно, что это как минимум высокопроизводительный микроконтроллер, потому что низкопроизводительный, к примеру - вот:
http://www.ixbt.com/news/2016/01/09/ineda-nachinaet-vypusk-odnokristalnyh-sistem-dlja-nosimoj-jelektroniki-i-iot-s-minimalnym-jenergopotrebleniem.html
Ineda Systems Двухядерный 240 МГц + 80 МГц MIPS 29 мкА/МГц от 300мАч аккума пашет 30 дней, 1.1Мб SRAM, АЦП, FLOAT ALU, 32bit таймеры, контроллер дисплея, MP3, NAND, SPI, SD, eMMC, USB OTG, SDIO и I2S. Из ПО RTOS + стек сетеввых протоколов. ПО 3.5 бакса оптом. Ну и куда тут двигаться? Поэтому двайте ещё раз уделим внимание производительности, а не нише 3 баксовых контроллеров.

ещё тест

6 Sysbench вроде как распространнён на Линукс можно попробовать сделать усечённый вариант (http://pasha.spb.su/arch/430 https://github.com/akopytov/sysbench)

Потребителя процессоров / ядер не интересует сферическая производительность.
Его интересует производительность для конкретных задач.
В разных линейках эти задачи разные.
В DSP - одно.
В процессорах приложений второе.
В микроконтроллерах третье.
Но начинается это все с грамотного позиционирования линеек.
Сейчас мультиклет есть гибрид ежа и ужа.

bav wrote:

VaalKIA wrote:
Потребителя процессоров / ядер не интересует сферическая производительность.
Его интересует производительность для конкретных задач.

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

В разных линейках эти задачи разные.
В DSP - одно.

Верно, но на DSP по моему мнению Мультиклет сейчас не тянет, нет там специализированных потоковых комманд.

В процессорах приложений второе.
В микроконтроллерах третье.

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

Но начинается это все с грамотного позиционирования линеек.
Сейчас мультиклет есть гибрид ежа и ужа.

Если отбросить ДСП, то есть некий условный набор по управлению переферией и очень устойчивая тенденция проникновения полноценных процесоров в микроконтроллерную сферу, то есть, мощные процессоры универсального назначения, выполненные по оптимизированному на энергосбережение техпроцессору, с урезанным количеством ядер и частотами начинают использоваться в качестве микроконтроллеров. Тот же МИПС, что я приводил по ссылке, это 32 разрядный проц (не проверял, но мегабайт встроенной памяти и такой же разрядности таймеры..), а МИПС уже давно стал процессором общего назначения и Китай принял курс на внедрение его в DeskTop и Server сегменты как ОСНОВНОГО.
http://www.ixbt.com/news/hard/index.shtml?18/22/83
http://www.pcweek.ru/infrastructure/article/detail.php?ID=177355
И что, им надо тоже определиться с грамотным позиционированием?
Нет, всё давно уже проще - должен быть основной набор переферии (тут у Мультиклета для стартовых поизиций всё есть, для конкурентноспособного решения, конечно надо расширить и добавить много чего и в части переферии и в части более производительных процов типа графических возможностей и MMU) и решение, при этом, должно быть производительным и энергоэффективным, тогда оно масштабируюется ВНИЗ - в сторону микроконтроллеров. А вот потом уже идут DSP, ускорители нейронных сетей для автомобилей, акселераторы видеопотоков и распознавания, но они уже делаются под конкретные устройства. Мультиклет же, насколько я понимаю, не с видеорегистраторами ни со сферой автомобилестроения не связан. А вот, действительно ли это масштабируемое решение которое и в ускорителях применимо (что даст ему возможность тягаться не только с микроконтроллерами и десктопами, а залезть и в ниши DSP акселераторов), либо же это просто средненький проц, которому долго и мучительно десятилетями набираться силёнок, что бы вырасти из ниши микроконтроллеров, как это делали Арм и тот же МИПС.. этот путь в наш век уже вряд ли возможен, и восьмибитное прошлое тоже уже не вернуть, как я уже описал, направление изменилось в обратную сторону, а плыть против течения...
Я считаю, что Мультиклет претендует на высокопроизводительные вычисления и хотелось бы увидеть подтверждение в цифрах в сравнении с другими платформами, то есть: больше тестов хороших и разных.

7. SPEC CPU2006 вроде UNIX нужен, но поскольку всегда есть исходники, то это к программерам (http://www.ixbt.com/cpu/speccpu2k6-intro.shtml)

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

VaalKIA wrote:

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

Они наверно не могут ещё тесты эти компилировать, т.к. компилятор у них не доделан и плох в плане оптимизации.
Т.е. архитектура может и хороша, но компилятор может выдасть такой код, который выставит её в худшем виде.

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

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

bav wrote:

Потребителя процессоров / ядер не интересует сферическая производительность.
Его интересует производительность для конкретных задач.

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

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

Сейчас мультиклет есть гибрид ежа и ужа.

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

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

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

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

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

VaalKIA wrote:

2. Архивирование/разархивирование ZIP
Имеет практическую ценность, есть готовые результаты на других платформах, в других темах я давал ссылки на zlib, правда в инете в качестве теста популярен 7zip и требуется идентичный набор данных. http://www.kitguru.net/wp-content/uploads/2015/08/7-zip-bench.png

Набор данных можно, к примеру, этот использовать http://corpus.canterbury.ac.nz/

Тестирование производительности Эльбруса:
http://www.kpda.ru/upload/iblock/607/senkov_elbrus.pdf
Использовались тесты:
Dhrystone 2.1
Whetstone
CoreMark
CoreMark MT Multithread
Linpack

7зип:
https://geektimes.ru/post/269914/
А тут пытались мучить факториалом и Монте-Карло:
http://www.sdelanounas.ru/blogs/71419

Ну и для общего развития статья "Как и зачем мерить" FLOPSы http://habrahabr.ru/company/intel/blog/144388/

Ждём аналогичного для Мультиклет.