Embedded Bench (was AVR vs PIC)

Do you have a question? Post it now! No Registration Necessary

Threaded View
Mon, 6 Sep 2004 11:37:58 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

[...]

AG>>> Для компилятора Hi-Tech PICC-18 v8.30 объём 2550 байтов, время 13 285
AG>>> циклов.

HZ>>     Э-э.., правильно ли я понял, что объем вырос чуть ли не вдвое, а
HZ>> время выполнения уменьшилось в два с половиной раза? Hепонятно, откуда
HZ>> такой прирост.
HZ>> Я еще могу понять процентов 30, но не 250 же! И почему объем кода вырос?
HZ>> Что-то _очень_ странное! Тут явно что-то не так.

AG> Hичего такого уж странного, там используются новые (условно новые, их ещё
AG> для PIC17 написали) версии подпрограмм умножения и деления активно
AG> использующие умножитель (если очень интересно, почитай AN575 для того же
AG> PIC17). Там кстати ещё не все возможности оптимизации выбраны, сложение из
AG> AN575 тоже быстрее.

AG> ...

AG>>> Я тогда же результаты и отсылал. Сейчас скомпилировал "плавучку" для
AG>>> v8.30:  объём -- 5820 байтов, время -- 978 178 циклов.

HZ>>     Для MSP430: 3842 байта, время выполнения 512033 цикла.

HZ>>     Что-то как-то не чувствуется кривизна 430-го при работе с памятью,
HZ>> медленность его, неповоротливость.

AG> Это просто факт, он прочитывается в документации.

    Факт в том, 430-й быстрее!! Даже в том аномальном случае.


HZ>> При интесивной работе с данными, а
HZ>> плавучка - это именно интенсивная работа с памятью, он заметно обходит и
HZ>> 18-го PIC'а!

AG> А на предыдущем тесте проигрывает, весь такой 16-разрядный,

    Почему это проигрывает?! 13 285 у 18-го и 12 535 у 430-го. Что больше, а
что меньше, не так уж сложно увидеть. И надо еще разобраться, откуда такая
цифра у 18-го взялась. И почему на другом тесте с плавучкой (который от VV) не
наблюдается такой картины прироста в 3 раза - она, как раз, более правильная и
привычная - где-то в два раза. При этом размер кода у 430-го в полтора раза
меньше!

AG> оптимизированный на регистровые операции... а ведь плавучка это как раз
AG> чисто регистровые операции!

    Плавучка - это, как раз и в первую очередь, работа с памятью - со стеком.
Тут огромное количество пересылок. Собственно регистровые операции, такие как
арифметика, занимают едва ли не меньшую долю в объеме кода.

AG>>> Тест "целочисленки" измеряет погоду в Африке там одна строка выполняется
AG>>> 2/3 времени, поэтому смысла прогонять его не вижу.

HZ>>     Какая строка?

AG>    if(syndrome==syndtable[cj])  // Error position found

    И что тебе не нравится? Как раз та самая работа с памятью, которая на PIC'е
такая быстрая и замечательная. Он, как раз, должен тут проявить свои лучше
качества! Вообще, операция типовая и в значительной степени характеризует
эффективность ядра.

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

    Видимо, PIC'у против MSP430 тут похвастать нечем, вот и ищешь отмазки.


HZ>>     Теперь было бы интересно узнать, как с этими тестами справляется
HZ>> dsPIC!

AG> Да ответ очевиден.

    Ушел от ответа. Сказал бы честно, что, дескать, нету компилятора и взять
негде. Это, кстати, тоже характеризует продукт. :-Р

AG> Если положить те же циклические регистровые алгоритмы что и у MSP430 то
AG> даже в худшем случае получится быстрее чем у MSP430, просто потому что он
AG> ни на что не тратит времени больше чем MSP430. Hо для dsPIC30F вполне
AG> реальны и реализации алгоритмов умножения/деления аналогичные PIC18, скорее
AG> всего малопригодные для MSP430 у которых и умножитель не у всех есть да и
AG> трафик между ним и ядром сожрёт всё выигранное время.

    Если бы да ка бы. Вместо того, чтоб рассуждать, надо взять да положить! Вот
тогда бы все и встало на свои места. Я бы и сам это сделал, но у меня нет этого
компилятора, а найти его с ходу не получилось (а упорно искать не стал, бо без
надобности оно мне).


--
H.Z.

harry.zhurov<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Embedded Bench (was AVR vs PIC)
Hello, Harry Zhurov !

 > HZ>>     Теперь было бы интересно узнать, как с этими тестами справляется
 > HZ>> dsPIC!

 > AG> Да ответ очевиден.

 >     Ушел от ответа. Сказал бы честно, что, дескать, нету компилятора и взять
 > негде. Это, кстати, тоже характеризует продукт. :-Р

Компилятор от IAR был (вместе с краком) доступен в сети eMule/eDonkey еще до
того как появились сэмплы кристаллов... Сейчас (собственно давно уже) у меня
лежит на ftp.

С уважением, Дима Орлов.


Embedded Bench (was AVR vs PIC)
  Привет!

Mon Sep 13 2004 10:32, Harry Zhurov wrote to Alexander Golov:

...

 HZ>>>     Что-то как-то не чувствуется кривизна 430-го при работе с памятью,
 HZ>>> медленность его, неповоротливость.

 AG>> Это просто факт, он прочитывается в документации.

 HZ>     Факт в том, 430-й быстрее!! Даже в том аномальном случае.

Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к этому
вопросу никакого отношения не имеют.

...

 HZ>>> При интесивной работе с данными, а плавучка - это именно интенсивная
 HZ>>> работа с памятью, он заметно обходит и  18-го PIC'а!

 AG>> А на предыдущем тесте проигрывает, весь такой 16-разрядный,

 HZ>     Почему это проигрывает?! 13 285 у 18-го и 12 535 у 430-го. Что
 HZ> больше, а что меньше, не так уж сложно увидеть.

Во-первых, я не ясновидящий: эти цифры тобой озвучены впервые (тогда в 2001-м
называлось что-то около 23 000 циклов, потом порядка 15 000 циклов). А
во-вторых, PIC18 всё равно быстрее из-за более короткого цикла.

 HZ> И надо еще разобраться,
 HZ> откуда такая цифра у 18-го взялась. И почему на другом тесте с плавучкой
 HZ> (который от VV) не наблюдается такой картины прироста в 3 раза - она, как
 HZ> раз, более правильная и привычная - где-то в два раза.

Ну давай попробуем разобраться. Для PIC18 с медленным вариантом библиотек
получается 2 095 003 циклов для программы VV и 28 751 циклов для термометров.
С быстрым вариантом, соответственно -- 978 751 и 13 296. Таким образом
соотношение времени выполнения задач для медленного варианта -- 73 и для
быстрого -- 74.

Для AVR по словам VV время выполнения его задачи составляет 1,9...2 млн.
циклов. Насколько я помню термометры были выполнены за 33 000 циклов и потом
с другой версией компилятора что-то около 28 000. Другими словами мы имеем
схожее соотношение около 60...70. И вот теперь с представленными тобой
показателями для MSP430 (512 033 и 12 535) мы получаем весьма неожиданное
соотношение 41.

Мне, например, интересно, почему при сравнении с AVR у меня сохранилось
близкое отношение для термометров и задачи VV, а вот MSP430 вдруг неожиданное
ускорился почти вдвое?

Далее... Мы имеем корневой цикл занимающий более 90% машинного времени:

 for(j=1;j<=f;j++)
  {
  for(i=j;i<=n;i+=e)
   {
   o=i+f-1;
   o1=i-1;
   p=x[o1]+x[o];  // 185
   r=x[o1]-x[o];  // 211
   q=y[o1]+y[o];  // 185
   t=y[o1]-y[o];  // 211
   x[o]=r*u-t*v;  // 493
   y[o]=t*u+r*v;  // 465
   x[o1]=p;
   y[o1]=q;
   }
  w=u*c-v*s;      // 453
  v=v*c+u*s;      // 462
  u=w;
  }
 }

Тело цикла содержит 8 FP-операций умножения и 8 сложения и выполняется 32 x 6
x 2 = 384 раза. Для случая общего времени 978 751 цикл я имею в среднем 2549
циклов на итерацию или 160 циклов на одну FP-операцию (грубой оценки вполне
достаточно). Это неплохо согласуется с рассчётными показателями времени
работы соответствующих функций (в сущности данный тест отражает
производительность двух операций -- сложения и умножения). Так или иначе в
коде выше привожу реальное время работы тела цикла для каждой строки, для
прямого преобразования на итерации: j = 5. Итого 16 FP-операций в данной
итерации требуют 2665 циклов.

Для заявленного тобой суммарного времени 512 033 цикла, получается среднее
время FP-операции 83 цикла. Достаточно взглянуть на "отшлифованную"
подрограмму умножения 16 x 16 для MSP430:

     clr.w  R14
     clr.w  R15
     clr.w  R13
     mov.w  #1,R10
MPY2 bit.w  R10,R11 ; 1
     jz     MPY1    ; 2
     add.w  R12,R14
     addc.w R13,R15
MPY1 rla.w  R12     ; 1
     rlc.w  R13     ; 1
     rla.w  R10     ; 1
     jnc    MPY2    ; 2
     ret

чтобы убедиться, что даже если сомножитель R11 равен нулю она выполняется не
менее 130 циклов, а простое увеличение числа итераций до 24 (без
соответствующего увеличения разрядности операндов и введения антуража
сопутствующего FP-умножению) сразу выводит время её работы за грань 166
циклов, т.е. даже при нулевом времени работы сложения невозможно достигнуть
скорости 512 033 цикла. Отсюда я делаю вывод, что или я круто отстал в
методологии умножения, или имеет ошибка в опыте, либо один из видов
жульничества.

В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и код
использованных подпрограмм умножения и сложения. Где можно посмотреть код
быстрых функций используемых у Hi-Tech в варианте для PIC17 я ссылку давал,
если очень нужно, могу дать непосредственно Hi-Tech'евский код для для PIC18.

 HZ> При этом размер кода у 430-го в полтора раза меньше!

Код? Вряд ли, в основном это касается размера библиотек. Впрочем, я никогда и
не заявлял, что Hi-Tech даёт компактный вычислительный код. Как раз наоброт,
они там непосредственно гоняют 32-разрядные данные. На PIC16 на асме я
работал по ссылкам и код был существенно плотнее, при том, что на PIC18 это
делать удобнее.

 AG>> оптимизированный на регистровые операции... а ведь плавучка это как раз
 AG>> чисто регистровые операции!

 HZ>     Плавучка - это, как раз и в первую очередь, работа с памятью - со
 HZ> стеком.

Какая память, какой стек? Основные арифметические операции большую часть
времени работают в коротких циклах с небольшим количеством локальных
переменных. Для PIC16 у меня пул данных FP-библиотеки был порядка 16 байтов,
т.е. десятка регистров MSP430 вполне хватит.

 HZ> Тут огромное количество пересылок. Собственно регистровые операции, такие
 HZ> как арифметика, занимают едва ли не меньшую долю в объеме кода.

Сколько бы они кода не занимали, времени они требуют дай бог -- единицы
процентов.

 AG>>>> Тест "целочисленки" измеряет погоду в Африке там одна строка
 AG>>>> выполняется  2/3 времени, поэтому смысла прогонять его не вижу.

 HZ>>>     Какая строка?

 AG>>    if(syndrome==syndtable[cj])  // Error position found

 HZ>     И что тебе не нравится? Как раз та самая работа с памятью, которая на
 HZ> PIC'е такая быстрая и замечательная. Он, как раз, должен тут проявить
 HZ> свои лучше качества! Вообще, операция типовая и в значительной степени
 HZ> характеризует эффективность ядра.

 HZ>     И кроме того, там еще циклы вращаются - а это сравнение и условные
 HZ> переходы. И доля кода цикла значительна. Hе понимаю, что тебя смущает,
 HZ> вполне нормальный тест на производительность, все операции типовые -
 HZ> обращение в память, сравнения, переходы.

 HZ>     Видимо, PIC'у против MSP430 тут похвастать нечем, вот и ищешь
 HZ> отмазки.

Я понятия не имею сколько времени всё это занимает у MSP430, для AVR VV
приводил значение 9670 циклов. Я скомпилировал тот текст в почти неизменном
виде на Hi-Tech PICC18 8.20PL4 и получил время 14 800 циклов. Потом немного
подвигал строчки в тексте и получил 10 240 циклов. Потом написал два десятка
строк на асме -- кусочек ищущий значение в syndtable -- и получил 8100 циклов
и всё это без малейших изменений в алгоритме, модели данных и коде за рамками
поиска в syndtable! В качестве теста чего-либо эта программа совершенно
непригодна.

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

 HZ>>>     Теперь было бы интересно узнать, как с этими тестами справляется
 HZ>>> dsPIC!

 AG>> Да ответ очевиден.

 HZ>     Ушел от ответа. Сказал бы честно, что, дескать, нету компилятора и
 HZ> взять негде. Это, кстати, тоже характеризует продукт. :-Р

Я тебе так прямо ещё несколько писем назад и сказал, чем ты не доволен? А где
взять я знаю: например купить у Hi-Tech (CCS, IAR и т.п.). Только я этого
делать не буду, мне он на данный момент не нужен, как и не нужен мне
компиллятор (наверняка ещё сырой с неоптимизированными библиотеками), чтобы
оценить производительность МК, особенно на критических участках кода, которые
я в любом случае напишу на асме.


Embedded Bench (was AVR vs PIC)
Thu, 23 Sep 2004 16:43:44 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

AG>>> Это просто факт, он прочитывается в документации.

HZ>>     Факт в том, 430-й быстрее!! Даже в том аномальном случае.

AG> Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к
AG> этому вопросу никакого отношения не имеют.

    Нормально он работает с памятью. Как подобает фон Неймановской машине. И в
итоге все равно на вычислениях и обращениях в память быстрее. Что и видно на
тестах.

AG> ...

HZ>>>> При интесивной работе с данными, а плавучка - это именно интенсивная
HZ>>>> работа с памятью, он заметно обходит и  18-го PIC'а!

AG>>> А на предыдущем тесте проигрывает, весь такой 16-разрядный,

HZ>>     Почему это проигрывает?! 13 285 у 18-го и 12 535 у 430-го. Что
HZ>> больше, а что меньше, не так уж сложно увидеть.

AG> Во-первых, я не ясновидящий: эти цифры тобой озвучены впервые (тогда в
AG> 2001-м называлось что-то около 23 000 циклов, потом порядка 15 000 циклов).
AG> А во-вторых, PIC18 всё равно быстрее из-за более короткого цикла.

    Блин! Да ты сравнить два числа-то можешь? Уже явно их написал, а он все про
какие-то "более короткие циклы" толкует. На том тесте MSP430 быстрее по факту!
А уж из чего там складываются выигрыши и проигрыши - другой вопрос.

HZ>> И надо еще разобраться,
HZ>> откуда такая цифра у 18-го взялась. И почему на другом тесте с плавучкой
HZ>> (который от VV) не наблюдается такой картины прироста в 3 раза - она, как
HZ>> раз, более правильная и привычная - где-то в два раза.

AG> Ну давай попробуем разобраться. Для PIC18 с медленным вариантом библиотек
AG> получается 2 095 003 циклов для программы VV и 28 751 циклов для
AG> термометров. С быстрым вариантом, соответственно -- 978 751 и 13 296. Таким
AG> образом соотношение времени выполнения задач для медленного варианта -- 73
AG> и для быстрого -- 74.

    Ты перевел тему в другое русло. Я спрашивал, откуда такой прирост от
простого переписывания библиотеки - в три раза? На это ответа нет! Все же
интересно, что там можно сделать, чтобы так кардинально изменилась
производительность на плавающей точке? Если только при написании предыдущего
варианта не ставилась задача сделать его как можно более тормозным.

AG> Для AVR по словам VV время выполнения его задачи составляет 1,9...2 млн.
AG> циклов. Насколько я помню термометры были выполнены за 33 000 циклов и
AG> потом с другой версией компилятора что-то около 28 000. Другими словами мы
AG> имеем схожее соотношение около 60...70. И вот теперь с представленными
AG> тобой показателями для MSP430 (512 033 и 12 535) мы получаем весьма
AG> неожиданное соотношение 41.

    Не знаю. Не досуг мне разбираться в этом. Могу код показать, если есть
желание копаться в нем. Очевидно, какие-то особенности реализации функций
библиотеки.

AG> Мне, например, интересно, почему при сравнении с AVR у меня сохранилось
AG> близкое отношение для термометров и задачи VV, а вот MSP430 вдруг
AG> неожиданное ускорился почти вдвое?

    С чего ты взял, что он ускорился? Мне дак представляется, что это он на
одном из тестов замедлился очень.

AG> Далее... Мы имеем корневой цикл занимающий более 90% машинного времени:

AG>  for(j=1;j<=f;j++)

[...]

AG> Для заявленного тобой суммарного времени 512 033 цикла, получается среднее
AG> время FP-операции 83 цикла. Достаточно взглянуть на "отшлифованную"
AG> подрограмму умножения 16 x 16 для MSP430:

AG>      clr.w  R14
AG>      clr.w  R15
AG>      clr.w  R13
AG>      mov.w  #1,R10
AG> MPY2 bit.w  R10,R11 ; 1
AG>      jz     MPY1    ; 2
AG>      add.w  R12,R14
AG>      addc.w R13,R15
AG> MPY1 rla.w  R12     ; 1
AG>      rlc.w  R13     ; 1
AG>      rla.w  R10     ; 1
AG>      jnc    MPY2    ; 2
AG>      ret

AG> чтобы убедиться, что даже если сомножитель R11 равен нулю она выполняется
AG> не менее 130 циклов, а простое увеличение числа итераций до 24 (без
AG> соответствующего увеличения разрядности операндов и введения антуража
AG> сопутствующего FP-умножению) сразу выводит время её работы за грань 166
AG> циклов, т.е. даже при нулевом времени работы сложения невозможно достигнуть
AG> скорости 512 033 цикла. Отсюда я делаю вывод, что или я круто отстал в
AG> методологии умножения, или имеет ошибка в опыте, либо один из видов
AG> жульничества.

    Ага, жульничество. Умножение 16х16 на f149 (который использовался в тесте)
выглядит, например для беззнакового умножения, так:

    mov x, &MPY
    mov y, &OP2

    Для знакового:

    mov x, &MPYS
    mov y, &OP2

    И так далее вплоть до умножения с накоплением (если оно нужно). Вот такое
вот жульничество. А то, что ты привел, по объему больше похоже на 32х32
умножение (с 32-битным результатом):


        MOV     L0L, &MPY
        MOV     L1L, &OP_2      // Compute L0L*L1L

        MOV     L0L, &MAC
        MOV     &ResLo, L0L     // Save LSW of product
        MOV     &ResHi, &ResLo  // Accumulate MSW of L0L*L1L
        MOV     L1H, &OP_2      // Accumulate L0L*L1H

        MOV     L0H, &MAC
        MOV     L1L, &OP_2      // Accumulate L0H*L1L

        MOV     &ResLo, L0H     // Save MSW of product


AG> В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и
AG> код использованных подпрограмм умножения и сложения. Где можно посмотреть
AG> код быстрых функций используемых у Hi-Tech в варианте для PIC17 я ссылку
AG> давал, если очень нужно, могу дать непосредственно Hi-Tech'евский код для
AG> для PIC18.

    Ну, так возьми, скачай evaluation trial EW430 v3.20, он месяц полностью
функциональный (при желании можно и таблеткой разжиться в нулевой будке).
Свободно скачивается с www.iar.com. Сюда постить сотни строк листинга я не
буду.

[...]

AG>>> оптимизированный на регистровые операции... а ведь плавучка это как раз
AG>>> чисто регистровые операции!

HZ>>     Плавучка - это, как раз и в первую очередь, работа с памятью - со
HZ>> стеком.

AG> Какая память, какой стек?

    Да такая. Вот фрагмент из кодогенерации того цикла:


********************************************
   for(i=j;i<=n;i+=e)
    {
    o=i+f-1;
         ??fft_1:
0B45                 MOV.W   R5, R11
1B511000             ADD.W   0x10(SP), R11
3B53                 ADD.W   #0xffff, R11
    o1=i-1;
0A45                 MOV.W   R5, R10
3A53                 ADD.W   #0xffff, R10
    p=x[o1]+x[o];
0A5A                 RLA.W   R10
0A5A                 RLA.W   R10
1F410200             MOV.W   0x2(SP), R15
0F5A                 ADD.W   R10, R15
814F0800             MOV.W   R15, 0x8(SP)
0B5B                 RLA.W   R11
0B5B                 RLA.W   R11
1F410200             MOV.W   0x2(SP), R15
0F5B                 ADD.W   R11, R15
814F0600             MOV.W   R15, 0x6(SP)
2E4F                 MOV.W   @R15, R14
1F4F0200             MOV.W   0x2(R15), R15
1D410800             MOV.W   0x8(SP), R13
2C4D                 MOV.W   @R13, R12
1D4D0200             MOV.W   0x2(R13), R13
B012....             CALL    #_Add32f
814C2000             MOV.W   R12, 0x20(SP)
814D2200             MOV.W   R13, 0x22(SP)
    r=x[o1]-x[o];
1F410600             MOV.W   0x6(SP), R15
2E4F                 MOV.W   @R15, R14
1F4F0200             MOV.W   0x2(R15), R15
1D410800             MOV.W   0x8(SP), R13
2C4D                 MOV.W   @R13, R12
1D4D0200             MOV.W   0x2(R13), R13
B012....             CALL    #_Sub32f
814C1C00             MOV.W   R12, 0x1c(SP)
814D1E00             MOV.W   R13, 0x1e(SP)
    q=y[o1]+y[o];
1F410400             MOV.W   0x4(SP), R15
0F5A                 ADD.W   R10, R15
814F0A00             MOV.W   R15, 0xa(SP)
1F410400             MOV.W   0x4(SP), R15
0F5B                 ADD.W   R11, R15
814F0C00             MOV.W   R15, 0xc(SP)
2E4F                 MOV.W   @R15, R14
1F4F0200             MOV.W   0x2(R15), R15
1B410A00             MOV.W   0xa(SP), R11
2C4B                 MOV.W   @R11, R12
1D4B0200             MOV.W   0x2(R11), R13
B012....             CALL    #_Add32f
814C2400             MOV.W   R12, 0x24(SP)
814D2600             MOV.W   R13, 0x26(SP)
********************************************

    Сплошные пересылки между регистрами, памятью и стеком (который тоже есть
память).


AG> Основные арифметические операции большую часть времени работают в коротких
AG> циклах с небольшим количеством локальных переменных.

    Реальные вычисления - они не только данные в регистрах гоняют, они еще и
куча пересылок, сохранение промежуточных результатов. Но ты эту "черновую"
работу, видимо, за работу не считатаешь, хотя ее доля весьма значительна.


HZ>> Тут огромное количество пересылок. Собственно регистровые операции, такие
HZ>> как арифметика, занимают едва ли не меньшую долю в объеме кода.

AG> Сколько бы они кода не занимали, времени они требуют дай бог -- единицы
AG> процентов.

    Доли процентов?!!! Как бы не так! Вот, например, из это же цикла: выражение

        p=x[o1]+x[o];

    на подготовку операндов при передаче их в функцию уходит 33 цикла, а на
выполнению самой функции сложения 49 циклов. И это еще без учета сохранения
результата в стек для дальнейшего его использования. С этими командами (это еще
8 циклов) будет 41 цикл. Почти столько же!.. "Единицы процентов..." :-\

[...]

HZ>>     И кроме того, там еще циклы вращаются - а это сравнение и условные
HZ>> переходы. И доля кода цикла значительна. Hе понимаю, что тебя смущает,
HZ>> вполне нормальный тест на производительность, все операции типовые -
HZ>> обращение в память, сравнения, переходы.

HZ>>     Видимо, PIC'у против MSP430 тут похвастать нечем, вот и ищешь
HZ>> отмазки.

AG> Я понятия не имею сколько времени всё это занимает у MSP430, для AVR VV
AG> приводил значение 9670 циклов. Я скомпилировал тот текст в почти неизменном
AG> виде на Hi-Tech PICC18 8.20PL4 и получил время 14 800 циклов. Потом немного
AG> подвигал строчки в тексте и получил 10 240 циклов. Потом написал два
AG> десятка строк на асме -- кусочек ищущий значение в syndtable -- и получил
AG> 8100 циклов и всё это без малейших изменений в алгоритме, модели данных и
AG> коде за рамками поиска в syndtable! В качестве теста чего-либо эта
AG> программа совершенно непригодна.

    Тем не менее 6380 циклов на MSP430 все равно характеризуют ситуацию. По
крайней мере, пусть далеко не точную, но характеристическую оценку это дает.

AG> Рассматриваемый выше тест FP тоже не намного лучше, т.к. ничего кроме двух
AG> подпрограмм FP-библиотеки не проверяет, но я по крайней мере согласен, что
AG> умножение и сложение (и, наверное, деление) -- действительно самые важные
AG> FP-операции и именно они в общем случае определяют производительность
AG> вычислений.

    Эти тесты - это из реальных задач. И для реальных условий. В жизни всегда
так - есть условия, есть задачи, их надо решать имеющимися средствами. А не
придумывать гипотетическую ситуацию, где бы тот или иной вариант был бы круче.
Реальность такова, что нет у пользователя возможности (времени, квалификации и
т.д.) зарываться в реализацию и оптимизировать, оптимизировать. Ему нужно
решить задачу здесь и сейчас с помощью имеющегося арсенала средств. Вот и взяли
реальные задачи (а не синтетические тесты), реальный имеющийся в наличие
инструментарий, прогнали тест и сравнили результат. Во всех случаях MSP430
быстрее, чем PIC18. Что бы ты там не говорил про особенности.

    Другое дело, что есть тебя устраивает производительность PIC18 на твоих
задачах, то тут тогда и обсуждать нечего - значит не нужен тебе MSP430. Но
медленнее он от этого не становится.

    В заключение: MSP430 является фон Неймановским процессором, у него одна и
та же память и для команд и для данных. Это имеет свои преимущества и удобства,
но производительность тут не сильная сторона. Поэтому он при прочих равных
медленнее, чем процессоры, выполненные по Гарвардской архитектуре, которые
имеют возможность одновременного обращения к памяти программ и памяти данных.
Но по сравнению с 8-битными процессорами MSP430 компенсирует недостаток
"поворотливости" более широкой шиной, что на 16-разрядных операндах уже дает
если не выигрыш, то паритет, а ортогональность регистров, которые могут
быть также и указателями, приводит к почти полному отсутствию накладнОго кода
копирования данных между регистрами (что имеет место, например, в AVR), что
дает еще некоторый прирост. Итого, реальная эффективность MSP430 не так уж
плоха, что и видно на реальном коде.

--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Embedded Bench (was AVR vs PIC)
  Привет!

Mon Sep 27 2004 11:46, Harry Zhurov wrote to Alexander Golov:

...

 AG>> Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к
 AG>> этому вопросу никакого отношения не имеют.

 HZ>     Hормально он работает с памятью. Как подобает фон Hеймановской
 HZ> машине. И в итоге все равно на вычислениях и обращениях в память быстрее.
 HZ> Что и видно на тестах.

На всех примерах пока было видно только, что обращения к памяти медленные. А
"неймановость" тут вообще не причём. Flash, ОЗУ, SFR'ы -- всё разные
устройства и могут выбираться параллельно, независимо от того, что они
отмаппированы в одно адресное пространство. Более того, никого же не
удивляет, что PIC за цикл может дважды обратиться к ОЗУ, т.е. уже в одно
устройство.

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

...

 HZ>     Блин! Да ты сравнить два числа-то можешь? Уже явно их написал, а он
 HZ> все про какие-то "более короткие циклы" толкует. Hа том тесте MSP430
 HZ> быстрее по факту! А уж из чего там складываются выигрыши и проигрыши -
 HZ> другой вопрос.

Могу: 1,32 мс для PIC18 и 1,56 мс для MSP430 -- это по факту, даже без
оглядки на твоё жульничество.

...

 AG>> Hу давай попробуем разобраться. Для PIC18 с медленным вариантом
 AG>> библиотек  получается 2 095 003 циклов для программы VV и 28 751 циклов
 AG>> для  термометров. С быстрым вариантом, соответственно -- 978 751 и 13
 AG>> 296. Таким  образом соотношение времени выполнения задач для медленного
 AG>> варианта -- 73  и для быстрого -- 74.

 HZ>     Ты перевел тему в другое русло. Я спрашивал, откуда такой прирост от
 HZ> простого переписывания библиотеки - в три раза? Hа это ответа нет!
 HZ> Все же интересно, что там можно сделать, чтобы так кардинально изменилась
 HZ> производительность на плавающей точке? Если только при написании
 HZ> предыдущего варианта не ставилась задача сделать его как можно более
 HZ> тормозным.

Я тебе уже неоднократно (впервые ещё в 2001-м году) сообщал, что новые
операции умножения и деления построены не на базе традиционных циклических
алгоритмов, а на линейных с использованием умножителя 8x8 PIC17/18 (например
в делении используются 35 операций умножения и табличные интерполяции). Если
тебя интересует конкретика пожалуйста читай AN535, или могу прислать
HiTech'евские переработчки тех же Microchip'овских исходников.

...

 AG>> Мне, например, интересно, почему при сравнении с AVR у меня сохранилось
 AG>> близкое отношение для термометров и задачи VV, а вот MSP430 вдруг
 AG>> неожиданное ускорился почти вдвое?

 HZ>     С чего ты взял, что он ускорился? Мне дак представляется, что это он
 HZ> на одном из тестов замедлился очень.

Потому что основные операции в обоих тестах одни и те же. А необходимая для
показателя 512000 циклов скорость сложения и умножения применительно к MSP430
навскидку выглядит сюреалистично.

...

 AG>> Для заявленного тобой суммарного времени 512 033 цикла, получается
 AG>> среднее  время FP-операции 83 цикла. Достаточно взглянуть на
 AG>> "отшлифованную"  подрограмму умножения 16 x 16 для MSP430:

...

 AG>> чтобы убедиться, что даже если сомножитель R11 равен нулю она
 AG>> выполняется  не менее 130 циклов, а простое увеличение числа итераций до
 AG>> 24 (без  соответствующего увеличения разрядности операндов и введения
 AG>> антуража  сопутствующего FP-умножению) сразу выводит время её работы за
 AG>> грань 166  циклов, т.е. даже при нулевом времени работы сложения
 AG>> невозможно достигнуть  скорости 512 033 цикла. Отсюда я делаю вывод, что
 AG>> или я круто отстал в  методологии умножения, или имеет ошибка в опыте,
 AG>> либо один из видов  жульничества.

 HZ>     Ага, жульничество. Умножение 16х16 на f149 (который использовался в
 HZ> тесте) выглядит, например для беззнакового умножения, так:

 HZ>     mov x, &MPY
 HZ>     mov y, &OP2

Понятно. Значит при обсуждении проблем производительности _ядра_ MSP430 ты
предъявлешь в качестве результатов теста работу выполненную периферийным
модулем, не являющимся неотъемлемой частью семейства (более 2/3 членов его не
имеет), даже не считая необходимым упоминуть об этом! Это классическое
введение в заблуждение через выборочное умолчание фактов, т.е. жульничество и
есть.

А теперь прошу предъявить результаты работы ядра для теста VV и термометров.

...

 HZ>     И так далее вплоть до умножения с накоплением (если оно нужно). Вот
 HZ> такое вот жульничество. А то, что ты привел, по объему больше похоже на
 HZ> 32х32 умножение (с 32-битным результатом):

То, что я привёл это умножение 16x16->32 -- самый традиционный и самый
примитивный алгоритм взятый их аппнотов, а для FP-умножения в single нужно
умножение мантисс 24x24->24. На 16-разрядном МК это делатся заметно дольше
чем 16x16->32.

...

 HZ>  MOV  L0L, &MPY      4
 HZ>  MOV  L1L, &OP_2     4  // Compute L0L*L1L

 HZ>  MOV  L0L, &MAC      4
 HZ>  MOV  &ResLo, L0L    3  // Save LSW of product
 HZ>  MOV  &ResHi, &ResLo 6  // Accumulate MSW of L0L*L1L
 HZ>  MOV  L1H, &OP_2     4  // Accumulate L0L*L1H

 HZ>  MOV  L0H, &MAC      4
 HZ>  MOV  L1L, &OP_2     4  // Accumulate L0H*L1L

 HZ>  MOV  &ResLo, L0H    3  // Save MSW of product
                        ----
                         36

А вот это очень показательно в плане скорости работы MSP430 по сравнению с
аналогичным умножением на dsPIC30F (причём MSP430 для этого нужен
специальный, а dsPIC30F -- любой, хоть 18-ногий, тогда как среди MSP430
ничего меньше 64 ног с умножителем нет):

    muluu  W6,W1,W8   1
    muluu  W7,W0,W4   1
    add    W4,W8,W8   1
    addc   W5,W9,W9   1
    muluu  W7,W1,W4   1
    muluu  W6,W0,W0   1
    add    W1,W8,W1   1
    addc   W4,W9,W2   1
                    ----
                      8

 AG>> В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и
 AG>> код использованных подпрограмм умножения и сложения. Где можно
 AG>> посмотреть  код быстрых функций используемых у Hi-Tech в варианте для
 AG>> PIC17 я ссылку  давал, если очень нужно, могу дать непосредственно
 AG>> Hi-Tech'евский код для  для PIC18.

 HZ>     Hу, так возьми, скачай evaluation trial EW430 v3.20, он месяц
 HZ> полностью функциональный (при желании можно и таблеткой разжиться в
 HZ> нулевой будке).

Я не имею возможности ставить и разбираться с непростым и совершенно не
нужным мне программным продуктом. Я ведь не заставляю тебя прогонять тесты
для PIC'ов, а делал это сам, так уж и ты изволь проделать эту совсем не
сложную работу, потому что без этих данных принять версию про 512000 циклов я
не смогу. Чем дальше, тем больше у меня сомнений в возможности MSP430
показать такой результат даже вооружишись умножителем.

 HZ> Свободно скачивается с www.iar.com. Сюда постить сотни строк листинга я
 HZ> не буду.

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

Но в любом случае, пришли их мне на snipped-for-privacy@mail.ru.

...

 AG>> Какая память, какой стек?

 HZ>     Да такая. Вот фрагмент из кодогенерации того цикла:

...

 HZ>   p=x[o1]+x[o];
 HZ> RLA.W   R10
 HZ> RLA.W   R10
 HZ> MOV.W   0x2(SP), R15
 HZ> ADD.W   R10, R15
 HZ> MOV.W   R15, 0x8(SP)
 HZ> RLA.W   R11
 HZ> RLA.W   R11
 HZ> MOV.W   0x2(SP), R15
 HZ> ADD.W   R11, R15
 HZ> MOV.W   R15, 0x6(SP)
 HZ> MOV.W   @R15, R14
 HZ> MOV.W   0x2(R15), R15
 HZ> MOV.W   0x8(SP), R13
 HZ> MOV.W   @R13, R12
 HZ> MOV.W   0x2(R13), R13
 HZ> CALL    #_Add32f
 HZ> MOV.W   R12, 0x20(SP)
 HZ> MOV.W   R13, 0x22(SP)

...

Я просил код _Add32f и _Mul32f, а не вызывающий их. Хотя, кстати, аналог
этого кода для dsPIC30F (номера регистров меняются, т.к. W15 это SP):

     sl      w10,#2,w10     1
     mov     [w15+2],w9     1
     add     w10,w9,w1      1
     sl      w11,#2,w11     1
     add     w11,w9,w9      1
     mov.d   [w9],w10       2
     mov.d   [w1],w12       2 <- 9
     rcall   _Add32f        2
     mov     w12,[w15+0x20] 1
     mov     w13,[w15+0x22] 1

Не знаю зачем для MSP430 понадобилось сохранять в локальных переменных
"эффектив-адрес" складываемых значений, но если это внести в код dsPIC30F
добавятся 2 цикла. Ещё немного (посмотреть код Add и Mul) и мы вполне
объективно сможем оценить соотношение производительности MSP430 и dsPIC30F на
данных задачах.

...

 AG>> Сколько бы они кода не занимали, времени они требуют дай бог -- единицы
 AG>> процентов.

 HZ>     Доли процентов?!!! Как бы не так! Вот, например, из это же цикла:
 HZ> выражение

 HZ>         p=x[o1]+x[o];

 HZ>     на подготовку операндов при передаче их в функцию уходит 33 цикла, а
 HZ> на выполнению самой функции сложения 49 циклов.

33 это ожидаемо и без всяких примеров, а вот на FP-сложение за 49, вернее за
вычетом call+ret 41 цикл, я бы с удовольствием посмотрел. Логично, что и
FP-умножение тоже 40 с небольшим циклов производится. Очень интересно как они
там всё остальное успевают при 36 на голом целочисленном 32x32.

...


Embedded Bench (was AVR vs PIC)
Wed, 29 Sep 2004 23:52:43 +0000 (UTC) Alexander Golov wrote to Harry Zhurov:

AG>>> Факт, что он медленно работает с памятью, а упоминаемые тобой случаи к
AG>>> этому вопросу никакого отношения не имеют.

HZ>>     Hормально он работает с памятью. Как подобает фон Hеймановской
HZ>> машине. И в итоге все равно на вычислениях и обращениях в память быстрее.
HZ>> Что и видно на тестах.

AG> На всех примерах пока было видно только, что обращения к памяти медленные.
AG> А "неймановость" тут вообще не причём. Flash, ОЗУ, SFR'ы -- всё разные
AG> устройства и могут выбираться параллельно,

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

AG> независимо от того, что они отмаппированы в одно адресное пространство.
AG> Более того, никого же не удивляет, что PIC за цикл может дважды обратиться
AG> к ОЗУ, т.е. уже в одно устройство.

    За 4 такта. Это и есть цена. Это уже обсудили вдоль и поперек.

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

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

HZ>>     Блин! Да ты сравнить два числа-то можешь? Уже явно их написал, а он
HZ>> все про какие-то "более короткие циклы" толкует. Hа том тесте MSP430
HZ>> быстрее по факту! А уж из чего там складываются выигрыши и проигрыши -
HZ>> другой вопрос.

AG> Могу: 1,32 мс для PIC18 и 1,56 мс для MSP430 -- это по факту, даже без
AG> оглядки на твоё жульничество.

    Какие мс, не пойму. Что за бред? В тактах приведено было суммарное время
выполнения, что еще надо?! Этак и я могу говорить, что MSP430 в несколько раз
быстрее любого PIC'а т.к. add r4, r5 на нем - 1 такт, а пику чтобы два числа
16-битных сложить надо эн циклов. Но я до такой глупости не опускаюсь, понимаю,
что важны не какие-то отдельные команды, а суммарная реальная
производительность, где не только отдельные команды влияют, но и режимы
адресации, необходимость в накладных на пересылках и т.д.

[...]

AG>>> Мне, например, интересно, почему при сравнении с AVR у меня сохранилось
AG>>> близкое отношение для термометров и задачи VV, а вот MSP430 вдруг
AG>>> неожиданное ускорился почти вдвое?

HZ>>     С чего ты взял, что он ускорился? Мне дак представляется, что это он
HZ>> на одном из тестов замедлился очень.

AG> Потому что основные операции в обоих тестах одни и те же. А необходимая для
AG> показателя 512000 циклов скорость сложения и умножения применительно к
AG> MSP430 навскидку выглядит сюреалистично.

    На всех тестах используется цикл. Если в каком-то случае одна из операций
цикла выполняется более или менее эффективно, то это сразу дает ощутимую
разницу. Это очевидно.

AG> ...

AG>>> Для заявленного тобой суммарного времени 512 033 цикла, получается
AG>>> среднее  время FP-операции 83 цикла. Достаточно взглянуть на
AG>>> "отшлифованную"  подрограмму умножения 16 x 16 для MSP430:

AG> ...

AG>>> чтобы убедиться, что даже если сомножитель R11 равен нулю она
AG>>> выполняется  не менее 130 циклов, а простое увеличение числа итераций до
AG>>> 24 (без  соответствующего увеличения разрядности операндов и введения
AG>>> антуража  сопутствующего FP-умножению) сразу выводит время её работы за
AG>>> грань 166  циклов, т.е. даже при нулевом времени работы сложения
AG>>> невозможно достигнуть  скорости 512 033 цикла. Отсюда я делаю вывод, что
AG>>> или я круто отстал в  методологии умножения, или имеет ошибка в опыте,
AG>>> либо один из видов  жульничества.

HZ>>     Ага, жульничество. Умножение 16х16 на f149 (который использовался в
HZ>> тесте) выглядит, например для беззнакового умножения, так:

HZ>>     mov x, &MPY
HZ>>     mov y, &OP2

AG> Понятно. Значит при обсуждении проблем производительности _ядра_ MSP430 ты
AG> предъявлешь в качестве результатов теста работу выполненную периферийным
AG> модулем, не являющимся неотъемлемой частью семейства (более 2/3 членов его
AG> не имеет), даже не считая необходимым упоминуть об этом! Это классическое
AG> введение в заблуждение через выборочное умолчание фактов, т.е. жульничество
AG> и есть.

    Ты за базаром-то следи. Не ты ли обижался и призывал держаться в рамках
технического спора?! Я тебе девайс указал! Ты так глубоко закопался в
исследования MSP430, что выискиваешь там малейшие зацепки неэффективности, а
про MAC не знаешь! Ай-ай! Не надо делать удивленные глаза. Не верю, что "слона
ты не заметил"! Что касается неотъемлемости от ядра - это тоже придирка. Я тебе
уже ранее говорил, что мелочь для дерганья ножкой с 16-битным ядром меня не
интересует. А то, что такой объемный элемент они вынесли из ядра и комплектуют
им только старшие члены, это очень разумный шаг - нафига тащить это в мелочь,
где умножитель не нужен стопудово?! Только удорожать чипы. И тесты эти с
плавучкой уже сами по себе предполагают более-менее серьезный МК, а не мелочь.

AG> А теперь прошу предъявить результаты работы ядра для теста VV и
AG> термометров.

    "А на трубе тебе не сыграть" (с)  Тебе если интересно, то и исследуй
дальше. Я получил результат, меня не интересует случай "если бы да ка бы".
Любой разумный человек будет использовать более эффективный способ, а не тот,
который мог бы получиться, если не пользоваться доступными фичами.


[...]

HZ>>  MOV  L0L, &MPY      4
HZ>>  MOV  L1L, &OP_2     4  // Compute L0L*L1L

HZ>>  MOV  L0L, &MAC      4
HZ>>  MOV  &ResLo, L0L    3  // Save LSW of product
HZ>>  MOV  &ResHi, &ResLo 6  // Accumulate MSW of L0L*L1L
HZ>>  MOV  L1H, &OP_2     4  // Accumulate L0L*L1H

HZ>>  MOV  L0H, &MAC      4
HZ>>  MOV  L1L, &OP_2     4  // Accumulate L0H*L1L

HZ>>  MOV  &ResLo, L0H    3  // Save MSW of product
AG>                         ----
AG>                          36

AG> А вот это очень показательно в плане скорости работы MSP430 по сравнению с
AG> аналогичным умножением на dsPIC30F (причём MSP430 для этого нужен
AG> специальный, а dsPIC30F -- любой, хоть 18-ногий, тогда как среди MSP430
AG> ничего меньше 64 ног с умножителем нет):

AG>     muluu  W6,W1,W8   1
AG>     muluu  W7,W0,W4   1
AG>     add    W4,W8,W8   1
AG>     addc   W5,W9,W9   1
AG>     muluu  W7,W1,W4   1
AG>     muluu  W6,W0,W0   1
AG>     add    W1,W8,W1   1
AG>     addc   W4,W9,W2   1
AG>                     ----
AG>                       8

    Опять "В огороде бузина, а в Киеве дядька" (с)! А на шарке это делается за
один цикл одной командой. А на тигрошарке за цикл делается несколько таких
умножений! И что? При чем тут dsPIC твой? Ты пел про кр00тые линейные алгоритмы
на пике, их что-то не показал тут. Видать, нечем хвастать! Как всегда. :-J


AG>>> В любом случае я хочу видеть построчный тайминг этого цикла для MSP430 и
AG>>> код использованных подпрограмм умножения и сложения. Где можно
AG>>> посмотреть  код быстрых функций используемых у Hi-Tech в варианте для
AG>>> PIC17 я ссылку  давал, если очень нужно, могу дать непосредственно
AG>>> Hi-Tech'евский код для  для PIC18.

HZ>>     Hу, так возьми, скачай evaluation trial EW430 v3.20, он месяц
HZ>> полностью функциональный (при желании можно и таблеткой разжиться в
HZ>> нулевой будке).

AG> Я не имею возможности ставить и разбираться с непростым и совершенно не
AG> нужным мне программным продуктом.

    Это _ОЧЕНЬ_ простой продукт. Я не встречал ничего более простого и
доступного для начального освоения. Для того, чтобы собрать проект с нуля даже
и документацию читать почти не надо, все просто, логично, интуитивно понятно.

AG> Я ведь не заставляю тебя прогонять тесты для PIC'ов, а делал это сам, так
AG> уж и ты изволь проделать эту совсем не сложную работу,

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

AG> потому что без этих данных принять версию про 512000 циклов я не смогу. Чем
AG> дальше, тем больше у меня сомнений в возможности MSP430 показать такой
AG> результат даже вооружишись умножителем.

    Я не придумал эту цифру. Разве что симулятор врет. Но это вряд ли.

HZ>> Свободно скачивается с www.iar.com. Сюда постить сотни строк листинга я
HZ>> не буду.

AG> Судя по твоим дальнейшим заявлениям даже для случая, когда подпрограммы
AG> полностью линейны и состоят только из 1-цикловых команд, должно быть не
AG> более 50 команд. Или они полны таблиц?

AG> Но в любом случае, пришли их мне на snipped-for-privacy@mail.ru.

    Ушло. Там есть листинги. Еще приложил сорцы RTL, где ты можешь посмотреть
вожделенную реализацию этой математики. Скачав пакет, можно эти проекты
прогнать. Там все уже настроено. Запускать файл с расширением .eww.

AG> ...

AG>>> Какая память, какой стек?

HZ>>     Да такая. Вот фрагмент из кодогенерации того цикла:

AG> ...

HZ>>   p=x[o1]+x[o];
HZ>> RLA.W   R10
HZ>> RLA.W   R10
HZ>> MOV.W   0x2(SP), R15
HZ>> ADD.W   R10, R15
HZ>> MOV.W   R15, 0x8(SP)
HZ>> RLA.W   R11
HZ>> RLA.W   R11
HZ>> MOV.W   0x2(SP), R15
HZ>> ADD.W   R11, R15
HZ>> MOV.W   R15, 0x6(SP)
HZ>> MOV.W   @R15, R14
HZ>> MOV.W   0x2(R15), R15
HZ>> MOV.W   0x8(SP), R13
HZ>> MOV.W   @R13, R12
HZ>> MOV.W   0x2(R13), R13
HZ>> CALL    #_Add32f
HZ>> MOV.W   R12, 0x20(SP)
HZ>> MOV.W   R13, 0x22(SP)

AG> ...

AG> Я просил код _Add32f и _Mul32f, а не вызывающий их.

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


AG> Хотя, кстати, аналог этого кода для dsPIC30F (номера регистров меняются,
AG> т.к. W15 это SP):

AG>      sl      w10,#2,w10     1
AG>      mov     [w15+2],w9     1
AG>      add     w10,w9,w1      1
AG>      sl      w11,#2,w11     1
AG>      add     w11,w9,w9      1
AG>      mov.d   [w9],w10       2
AG>      mov.d   [w1],w12       2 <- 9
AG>      rcall   _Add32f        2
AG>      mov     w12,[w15+0x20] 1
AG>      mov     w13,[w15+0x22] 1

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

      p=x[o1]+x[o];
420BDD00      SL        W1,#2,W6
7FB99700      MOV       [W15-2],W2
06014100      ADD       W2,W6,W2
B2BF9F00      MOV       W2,[W15-10]
1201BE00      MOV.D     [W2],W2
D2B79F00      MOV       W2,[W15-22]
E3B79F00      MOV       W3,[W15-20]
C203DD00      SL        W0,#2,W7
7FBF9700      MOV       [W15-2],W14
07074700      ADD       W14,W7,W14
7A805700      SUB       W15,#26,W0
3E187800      MOV       [W14++],[W0++]
2E107800      MOV       [W14--],[W0--]
76805700      SUB       W15,#22,W0
1001BE00      MOV.D     [W0],W2
7A805700      SUB       W15,#26,W0
1000BE00      MOV.D     [W0],W0
............  CALL      `?F_ADD`


AG> Не знаю зачем для MSP430 понадобилось сохранять в локальных переменных
AG> "эффектив-адрес" складываемых значений, но если это внести в код dsPIC30F
AG> добавятся 2 цикла. Ещё немного (посмотреть код Add и Mul) и мы вполне
AG> объективно сможем оценить соотношение производительности MSP430 и dsPIC30F
AG> на данных задачах.

    Объективно этот тест на этих платформах и скомпиленный аналогичными
пакетами одного производителя дает результат по скорости менее, чем в два раза.
IAR EWdsPIC v1.10 дает 284586 циклов. Размер кода 4580 байт. Кстати, поставил
буквально вчера EW430 v2.21A-BETA (пререлиз), так он дает на этом тесте 394525
цикла. :) Уж не знаю, что они там сделали, но факт. Хочешь копаться в этом,
копайся, сорцы библы этой я тебе выслал.

AG>>> Сколько бы они кода не занимали, времени они требуют дай бог -- единицы
AG>>> процентов.

HZ>>     Доли процентов?!!! Как бы не так! Вот, например, из это же цикла:
HZ>> выражение

HZ>>         p=x[o1]+x[o];

HZ>>     на подготовку операндов при передаче их в функцию уходит 33 цикла, а
HZ>> на выполнению самой функции сложения 49 циклов.

AG> 33 это ожидаемо и без всяких примеров, а вот на FP-сложение за 49, вернее
AG> за вычетом call+ret 41 цикл, я бы с удовольствием посмотрел. Логично, что и
AG> FP-умножение тоже 40 с небольшим циклов производится. Очень интересно как
AG> они там всё остальное успевают при 36 на голом целочисленном 32x32.

    Вот и посмотришь, я тебе выслал.


AG>>> В качестве теста чего-либо эта  программа совершенно непригодна.

HZ>>     Тем не менее 6380 циклов на MSP430 все равно характеризуют ситуацию.
HZ>> По крайней мере, пусть далеко не точную, но характеристическую оценку это
HZ>> дает.

AG> Серьёзно?! Тогда вот тебе, новинка сезона. Компилятор HiTech 8.30 (таргет
AG> PIC18F6680), рашпиль, напильник и сухая шкурка: результат 4896 циклов:

AG> -----------------------------------------------------------------------

AG> #include <pic18.h>

AG> unsigned char  CorrectBCH ( unsigned long int * );

AG> void main(void)
AG> {

[...]

AG> Даже без ассемблерных вставок удалось получить 6090 циклов, но вставка
AG> позволила сократить ещё пару-тройку команд в корневом цикле.

AG> Ну что ты теперь расскажешь про: "Тем не менее 6380 циклов на MSP430 все
AG> равно характеризуют ситуацию..."?

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

HZ>>     Другое дело, что есть тебя устраивает производительность PIC18 на
HZ>> твоих задачах, то тут тогда и обсуждать нечего - значит не нужен тебе
HZ>> MSP430. Hо медленнее он от этого не становится.

AG> Реальность такова, что мы имеем 16-разрядный МК, который при использовании
AG> встроенного умножителя 16x16->32 на вполне реальной, наиболее подходящей
AG> под его архитектуру, чисто вычислительной задаче с термометрами получил
AG> относительный выигрыш 6% по отношению к 8-разрядному МК оснащённому
AG> умножителем 8x8->16 и остался в проигрыше по абсолютной производительности
AG> на 18%. Это следствие медленной работы с памятью (с чего начали, тем и
AG> закончили). При этом о реальной производительности ядра мы сможем судить
AG> только после того, как ты опубликуешь данные о времени работы без
AG> умножителя.

    Не надоело еще как попугаю повторять одно и то же?! Мне некогда заниматься
оптимизациями вещей, которые не нужны и, скорее всего, никогда не понадобятся.
Мне есть, чем заняться помимо этого - круг моих профессиональных интересов не
ограничивается пиками, равно как и другими МК.

AG> Сравнение относительной производительности с dsPIC30F на всех примерах, что
AG> удалось от тебя получить подавляющая, вплоть до 3...4 раз, о чём я и
AG> предполагал в самом начале.

    Менее, чем в два раза, как показал сравнительный прогон в _одинаковых_
условиях. О чем я и говорил уже давно. При том, что dsPIC имеет в 4 раза выше
тактовую, и в полтора раза толще опкод. Что выливается в его цену и жручесть.

AG> Результаты работы программы VV (512 000 циклов) я не признаю,

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

AG> до тех пор пока ты не предъявишь код Add и Mul и я смогу убедиться, что они
AG> действительно могут выполнять эти операции за 40...50 циклов.

    Никак не можешь поверить, что PIC пролетает?! Сочувствую. Код я тебе
выслал, развлекайся.

HZ>> Итого, реальная эффективность
HZ>> MSP430 не так уж плоха, что и видно на реальном коде.

AG> Ну хоть тональность изменилась, похоже одним мифом (про фантастические
AG> производительность и малопотребляемость MSP430) становится меньше.

    Опять передергиваешь! Либо воспринимаешь неадекватно!! Я вполне четко
высказался:

=========Beginning of the citation==============
    В заключение: MSP430 является фон Неймановским процессором, у него одна и
та же память и для команд и для данных. Это имеет свои преимущества и удобства,
но производительность тут не сильная сторона. Поэтому он при прочих равных
медленнее, чем процессоры, выполненные по Гарвардской архитектуре, которые
имеют возможность одновременного обращения к памяти программ и памяти данных.
Но по сравнению с 8-битными процессорами MSP430 компенсирует недостаток
"поворотливости" более широкой шиной, что на 16-разрядных операндах уже дает
если не выигрыш, то паритет, а ортогональность регистров, которые могут
быть также и указателями, приводит к почти полному отсутствию накладнОго кода
копирования данных между регистрами (что имеет место, например, в AVR), что
дает еще некоторый прирост. Итого, реальная эффективность MSP430 не так уж
плоха, что и видно на реальном коде.
=========The end of the citation================

    Смысл этой _полной_ цитаты в двух словах следующий: фон Нейман медленнее
других архитектур при обращении в память, но 16-разрядность и ортогональность
режимов адресации дают такой эффект, что "Итого, реальная эффективность MSP430
не так уж плоха, что и видно на реальном коде." Только и всего. И гарвардские
8-битки на вычислениях и работе с 16-ти и более разрядными операндами заметно
слабее при прочих равных.

    Я не хочу вникать, намеренно ли ты это передернул, восприятие ли у тебя
такое или еще какие причины, но видно и тут дискуссия не имеет конструктивного
стержня. Мне она надоела, как и все остальные, которые я веду с тобой уже хрен
знает сколько времени. Нравится тебе твой мирок пиков-дспиков, живи в нем на
здоровье. Я больше не намерен тратить ни секунды времени ни на одну из этих
тем. Благодарю за участие.


--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Embedded Bench (was AVR vs PIC)
  Привет!

Thu Sep 30 2004 10:53, Harry Zhurov wrote to Alexander Golov:

...

 AG>> Hа всех примерах пока было видно только, что обращения к памяти
 AG>> медленные.  А "неймановость" тут вообще не причём. Flash, ОЗУ, SFR'ы --
 AG>> всё разные  устройства и могут выбираться параллельно,

 HZ>     В неймане не могут! В неймане одна шина данных на все. Когда шин
 HZ> больше, это уже гарвард. В TMS320F28xx память тоже одна, но шин 6 штук и
 HZ> архитектура называется модифицированной гарвардской. А память одна. Т.ч.
 HZ> не от количества устройств зависит. И неймановость еще как при чем.

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

 AG>> независимо от того, что они отмаппированы в одно адресное пространство.
 AG>> Более того, никого же не удивляет, что PIC за цикл может дважды
 AG>> обратиться  к ОЗУ, т.е. уже в одно устройство.

 HZ>     За 4 такта. Это и есть цена. Это уже обсудили вдоль и поперек.

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

...

 AG>> Могу: 1,32 мс для PIC18 и 1,56 мс для MSP430 -- это по факту, даже без
 AG>> оглядки на твоё жульничество.

 HZ>     Какие мс, не пойму. Что за бред? В тактах приведено было суммарное
 HZ> время выполнения, что еще надо?! Этак и я могу говорить, что MSP430 в
 HZ> несколько раз быстрее любого PIC'а т.к. add r4, r5 на нем - 1 такт, а
 HZ> пику чтобы два числа 16-битных сложить надо эн циклов.

Не представляю какое отношение сложение двух регистров MSP430 имеет к данному
вопросу, но фактом является, что ни один MSP430 не способен обсчитать за
секунду 750 термометров, а PIC18 может. Лучший результат для обвешанного
умножителями 16-разрядного MSP430 -- 640 термометров за секунду.

...

 AG>> Потому что основные операции в обоих тестах одни и те же. А необходимая
 AG>> для  показателя 512000 циклов скорость сложения и умножения
 AG>> применительно к  MSP430 навскидку выглядит сюреалистично.

 HZ>     Hа всех тестах используется цикл. Если в каком-то случае одна из
 HZ> операций цикла выполняется более или менее эффективно, то это сразу дает
 HZ> ощутимую разницу. Это очевидно.

Что очевидно? Что цикл содержащий лишь 16 голых FP-операций и комплект
соответствующих загрузок и сохранений, может ускорится вдвое из-за каких-то
оптимизаций одной операции? Максимум 6% при нулевом времени выполнения.

...

 AG>> Понятно. Значит при обсуждении проблем производительности _ядра_ MSP430
 AG>> ты  предъявлешь в качестве результатов теста работу выполненную
 AG>> периферийным  модулем, не являющимся неотъемлемой частью семейства
 AG>> (более 2/3 членов его  не имеет), даже не считая необходимым упоминуть
 AG>> об этом! Это классическое  введение в заблуждение через выборочное
 AG>> умолчание фактов, т.е. жульничество  и есть.

 HZ>     Ты за базаром-то следи. Hе ты ли обижался и призывал держаться в
 HZ> рамках технического спора?! Я тебе девайс указал! Ты так глубоко
 HZ> закопался в исследования MSP430, что выискиваешь там малейшие зацепки
 HZ> неэффективности, а про MAC не знаешь! Ай-ай! Hе надо делать удивленные
 HZ> глаза. Hе верю, что "слона ты не заметил"! Что касается неотъемлемости от
 HZ> ядра - это тоже придирка.

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

 HZ>     Для MSP430: 3842 байта, время выполнения 512033 цикла.
 HZ>     Что-то как-то не чувствуется кривизна 430-го при работе с памятью,
 HZ> медленность его, неповоротливость.

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

...

 HZ> Я тебе уже ранее говорил, что мелочь для
 HZ> дерганья ножкой с 16-битным ядром меня не интересует.

Мне нет никакого дела до твоих интересов, я в том споре аргументировал
неэффективность ядра MSP430, а в его составе умножителя нет.

...

 AG>> А теперь прошу предъявить результаты работы ядра для теста VV и
 AG>> термометров.

 HZ>     "А на трубе тебе не сыграть" (с)  Тебе если интересно, то и исследуй
 HZ> дальше. Я получил результат, меня не интересует случай "если бы да ка
 HZ> бы".

Значит результаты настолько плохи, что даже показать стыдно.

...

 AG>> А вот это очень показательно в плане скорости работы MSP430 по сравнению
 AG>> с  аналогичным умножением на dsPIC30F (причём MSP430 для этого нужен
 AG>> специальный, а dsPIC30F -- любой, хоть 18-ногий, тогда как среди MSP430
 AG>> ничего меньше 64 ног с умножителем нет):

 AG>>     muluu  W6,W1,W8   1
 AG>>     muluu  W7,W0,W4   1
 AG>>     add    W4,W8,W8   1
 AG>>     addc   W5,W9,W9   1
 AG>>     muluu  W7,W1,W4   1
 AG>>     muluu  W6,W0,W0   1
 AG>>     add    W1,W8,W1   1
 AG>>     addc   W4,W9,W2   1
 AG>>                     ----
 AG>>                       8

 HZ>     Опять "В огороде бузина, а в Киеве дядька" (с)! А на шарке это
 HZ> делается за один цикл одной командой. А на тигрошарке за цикл делается
 HZ> несколько таких умножений! И что?

То, что мы не "шарки" сравнивали, а dsPIC30F и MSP430. Когда ты усомнился в
моих предположениях о многократном превосходстве dsPIC30F в скорости, я тебя
прямо попросил дать код для MSP430, чтобы я мог сделать перевод-подстрочник,
но ты отказал, вот я и нахожу любую возможность продемострировать, что я был
прав.

...


 HZ> При чем тут dsPIC твой? Ты пел про
 HZ> кр00тые линейные алгоритмы на пике, их что-то не показал тут. Видать,
 HZ> нечем хвастать! Как всегда. :-J

Почему же, есть. 8-разрядный PIC18 с этими алгоритмами выполняет 32-разрядные
FP-вычисления в программе термометра при заданной частоте лишь на 6%
медленнее 16-разрядного MSP430 с умножителем и однозначно быстрее MSP430 без
умножителя. А теперь попробуй посчитать тоже самое на MSP430 в double и оцени
результат, а это как раз и будет аналогом нагрузки на ядро PIC18 при работе с
single.

...

 AG>> потому что без этих данных принять версию про 512000 циклов я не смогу.
 AG>> Чем  дальше, тем больше у меня сомнений в возможности MSP430 показать
 AG>> такой  результат даже вооружишись умножителем.

 HZ>     Я не придумал эту цифру. Разве что симулятор врет. Hо это вряд ли.

В любом случае кто-то врёт, но об этом ниже.

...

 HZ>>> Свободно скачивается с www.iar.com. Сюда постить сотни строк листинга я
 HZ>>> не буду.

 AG>> Судя по твоим дальнейшим заявлениям даже для случая, когда подпрограммы
 AG>> полностью линейны и состоят только из 1-цикловых команд, должно быть не
 AG>> более 50 команд. Или они полны таблиц?

 AG>> Hо в любом случае, пришли их мне на snipped-for-privacy@mail.ru.

 HZ>     Ушло. Там есть листинги. Еще приложил сорцы RTL, где ты можешь
 HZ> посмотреть вожделенную реализацию этой математики.

Посмотрел, самые традиционные реализации, никаких особенностей. Ни при каких
условиях (ни с умножителем, ни тем более без) они не способны выполнить
данный тест за 512 000 циклов.  Имеются:

?Mul32fHw -- умножение с использованием умножителя;
_Mul32f   -- умножение с использованием средств ядра;
_Add32f   -- сложение.

Несложные подсчёты показывают, что ?Mul32fHw выполняется от 155 до 170
циклов, причём до команды dint, предваряющей работу умножителя (кстати, тоже
прелесть -- так запросто на уровне компиллятора запретить прерывания на 63
цикла), проходит 62 цикла (сохранение, проверки, распаковка, суммирование
порядков), затем следует умножение (63 цикла), затем ещё 30...45 циклов
нормализации, проверок, упаковки, восстановления. _Mul32f выполняется за
295...345 циклов, а _ADD32f за 100...205 циклов.

Даже если взять время работы функций по минимуму и добавить по 20 циклов на
трафик данных, то для варианта с умножителем получится не менее 905 000
циклов (155+20+100+20)*8*384, а для программного умножения
(295+20+100+20)*8*384 более 1,33 млн. циклов. С реальными данными скорее
всего будет не менее 1 млн. для умножителя и не менее 1,5 млн. для
программного варианта.

В пределах упоминаемых тобой первых 40 циклов производятся проверки на NAN,
Infinity и ноль и возвраты соответствующих констант, флагов и т.п. Т.е.
другими словами твоя программа не работает, где-то произошло разрушение
значения (сформировался NAN или что-то ещё) и дальнейшие вычисления не
выполняются. В чём причина мне не известно (похоже не в исходнике, присланный
тобой slon.cpp я проверил, Watcom 10.5 показал вполне корректное прямое и
обратное преобразование), глюк в библиотеках, или компилятор
заоптимизировался, ищи сам, но факт -- данный код не работает.

...

 AG>> Я просил код _Add32f и _Mul32f, а не вызывающий их.

 HZ>     Hе надо тут передергивать! Исходно ты заявлял, что плавучка - это
 HZ> одни регистры и поэтому 430-й,

Так оно и есть, посмотри в код тех же _Mul32f и _ADD32f, там кроме нескольких
push/pop никаких обращений к памяти нет, только регистры, а все загрузки и
выгрузки даже на фоне тяжких мук MSP430 не составят и 1/5 времени.

 HZ> у которого их много и работа с ними
 HZ> быстра, должен быть на высоте, а он всего-то от силы раза в два быстрее.

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

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

Надо было всё считать, а не просто просто красивые картинки рассматривать и
хотя бы раз для приличия сходить пошагово в код FP-функции и посмотреть что
же она там такого в течение 40 циклов делает. Не надо быть большим знатоком
FP-арифметики, чтобы обратить внимание, что в сущности функции не
выполняются.

...


Embedded Bench (was AVR vs PIC)
...

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

 HZ> Это фрагмент, сгенеренный аналогичным
 HZ> компилятором, выглядит далеко не так оптимистично:

 HZ>       p=x[o1]+x[o];
 HZ> 420BDD00      SL        W1,#2,W6        1
 HZ> 7FB99700      MOV       [W15-2],W2      1
 HZ> 06014100      ADD       W2,W6,W2        1
 HZ> B2BF9F00      MOV       W2,[W15-10]     1
 HZ> 1201BE00      MOV.D     [W2],W2         2
 HZ> D2B79F00      MOV       W2,[W15-22]     1
 HZ> E3B79F00      MOV       W3,[W15-20]     1
 HZ> C203DD00      SL        W0,#2,W7        1
 HZ> 7FBF9700      MOV       [W15-2],W14     1
 HZ> 07074700      ADD       W14,W7,W14      1
 HZ> 7A805700      SUB       W15,#26,W0      1
 HZ> 3E187800      MOV       [W14++],[W0++]  1
 HZ> 2E107800      MOV       [W14--],[W0--]  1
 HZ> 76805700      SUB       W15,#22,W0      1
 HZ> 1001BE00      MOV.D     [W0],W2         2
 HZ> 7A805700      SUB       W15,#26,W0      1
 HZ> 1000BE00      MOV.D     [W0],W0         2 <- 20
 HZ> ............  CALL      `?F_ADD`        2

А это вовсе и не одно и тоже. Код для MSP430 сохранял во временных переменных
только 16-разрядные эффектив-адреса, а здесь сохраняются сами float-значения.
В принципе ни то ни другое нафиг не нужно, но я ведь ещё раньше отметил, если
хочется адрес сохранить это добавит к времени выполнения лишь 2 цикла, даже
можно один из адресов затереть и опять восстановить из временной переменной,
в точности как в коде для MSP430. Это добавит ещё один цикл и в сумме
получится 12 циклов. А по поводу радужности -- вот напиши приведённый тобой
выше безумный код в точности для MSP430 и ужаснись результату.

...

 HZ>     Объективно этот тест на этих платформах и скомпиленный аналогичными
 HZ> пакетами одного производителя дает результат по скорости менее, чем в два
 HZ> раза.
 HZ> IAR EWdsPIC v1.10 дает 284586 циклов. Размер кода 4580 байт.

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

...

 AG>>>> В качестве теста чего-либо эта  программа совершенно непригодна.

 HZ>>>     Тем не менее 6380 циклов на MSP430 все равно характеризуют
 HZ>>> ситуацию.  По крайней мере, пусть далеко не точную, но
 HZ>>> характеристическую оценку это  дает.

 AG>> Серьёзно?! Тогда вот тебе, новинка сезона. Компилятор HiTech 8.30
 AG>> (таргет  PIC18F6680), рашпиль, напильник и сухая шкурка: результат 4896
 AG>> циклов:

...

 AG>> Hу что ты теперь расскажешь про: "Тем не менее 6380 циклов на MSP430 все
 AG>> равно характеризуют ситуацию..."?

 HZ>     Скажу, что у меня нет ни времени, ни желания заниматься оптимизацией
 HZ> алгоритма этого примера, который не имеет ни малейшего отношения к моей
 HZ> работе.

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

 HZ> Только и всего. Сравнивать оптимизированный алгоритм на пике и
 HZ> неоптимизированный на других процессорах и при этом причмокивать от
 HZ> удовольствия - это не ко мне.

"Видимо, MSP430'у против PIC18 тут похвастать нечем, вот и ищешь отмазки."

...

 AG>> Реальность такова, что мы имеем 16-разрядный МК, который при
 AG>> использовании  встроенного умножителя 16x16->32 на вполне реальной,
 AG>> наиболее подходящей  под его архитектуру, чисто вычислительной задаче с
 AG>> термометрами получил  относительный выигрыш 6% по отношению к
 AG>> 8-разрядному МК оснащённому  умножителем 8x8->16 и остался в проигрыше
 AG>> по абсолютной производительности  на 18%. Это следствие медленной работы
 AG>> с памятью (с чего начали, тем и  закончили). При этом о реальной
 AG>> производительности ядра мы сможем судить  только после того, как ты
 AG>> опубликуешь данные о времени работы без  умножителя.

 HZ>     Hе надоело еще как попугаю повторять одно и то же?! Мне некогда
 HZ> заниматься оптимизациями вещей, которые не нужны и, скорее всего, никогда
 HZ> не понадобятся.
 HZ> Мне есть, чем заняться помимо этого - круг моих профессиональных
 HZ> интересов не ограничивается пиками, равно как и другими МК.

Ещё раз подчёркиваю, мне нет никакого дела до твоих или чьих то ещё
профессиональных и других интересов, а также о наличии у тебя свободного
времени. Я в рамках технического спора готов обсуждать циклы, микросекунды,
микроамперы, байты, работу кода и т.п. Есть технические агрументы --
пожалуйста, нет -- не нужно вываливать на меня разное нытьё "за жисть".

...

 AG>> Результаты работы программы VV (512 000 циклов) я не признаю,

 HZ>     Да сколько угодно, мне от этого не холодно, не жарко. Это факт, я это
 HZ> не придумал. Может быть, там есть ошибка в компиляторе или библиотеке, не
 HZ> знаю, но это вряд ли, т.к. на других задачах плавучка работает правильно.

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

...

 HZ>>> Итого, реальная эффективность
 HZ>>> MSP430 не так уж плоха, что и видно на реальном коде.

 AG>> Hу хоть тональность изменилась, похоже одним мифом (про фантастические
 AG>> производительность и малопотребляемость MSP430) становится меньше.

 HZ>     Опять передергиваешь! Либо воспринимаешь неадекватно!! Я вполне четко
 HZ> высказался:

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

...

 HZ>     Смысл этой _полной_ цитаты в двух словах следующий: фон Hейман
 HZ> медленнее других архитектур при обращении в память, но 16-разрядность и
 HZ> ортогональность режимов адресации дают такой эффект, что "Итого, реальная
 HZ> эффективность MSP430 не так уж плоха, что и видно на реальном коде."
 HZ> Только и всего. И гарвардские 8-битки на вычислениях и работе с 16-ти и
 HZ> более разрядными операндами заметно слабее при прочих равных.

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

 HZ>     Я не хочу вникать, намеренно ли ты это передернул, восприятие ли у
 HZ> тебя такое или еще какие причины, но видно и тут дискуссия не имеет
 HZ> конструктивного стержня. Мне она надоела, как и все остальные, которые я
 HZ> веду с тобой уже хрен знает сколько времени. Hравится тебе твой мирок
 HZ> пиков-дспиков, живи в нем на здоровье. Я больше не намерен тратить ни
 HZ> секунды времени ни на одну из этих тем. Благодарю за участие.

Это уже стало традицией, как только слабые аргументы разбиваются о конкретные
данные дискуссия теряет для тебя интерес. Впрочем, это не так уж и важно
результаты всё равно налицо: не думаю, что в ближайшие годы мы вновь увидим
задорные рассказы про фантастическую производительность вычислений на MSP430.


Re: Embedded Bench (was AVR vs PIC)
Hello Harry.

30 Sep 04 09:53, you wrote to Alexander Golov:

 HZ>     В неймане не могут! В неймане одна шина данных на все. Когда шин
 HZ> больше, это уже гарвард. В TMS320F28xx память тоже одна, но шин 6 штук
 HZ> и архитектура называется модифицированной гарвардской. А память одна.

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

Alexey


Embedded Bench (was AVR vs PIC)
Thu, 30 Sep 2004 12:17:56 +0400 Alexey Boyko wrote to Harry Zhurov:

HZ>>     В неймане не могут! В неймане одна шина данных на все. Когда шин
HZ>> больше, это уже гарвард. В TMS320F28xx память тоже одна, но шин 6 штук
HZ>> и архитектура называется модифицированной гарвардской. А память одна.

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

    Современый пентиум - это вообще, строго говоря, не процессор, а целая
система на кристалле (а были варианты, что и не на кристалле, а гибрид (Pentium
Pro) или с кешем на внешней плате (PII) - вообще целая коробка шла иногда с
радиатором и кулером), где помимо самого х86 совместимого процессора еще FP
сопроцессор, DSP сопроцессор (ММХ который), память (кэш - это ведь память). Что
касается самого ядра, то я его не знаю, не могу сказать, но судя по тому, что
может одновременно обращаться в разные адресные пространства, скорее гарвард. А
если рассматривать весь этот законченный узел по отношению к внешней памяти,
несомненно нейман. АМДшные процы (где-то попадалось) внутри однозначно
гарвардский RISC процессор, эмулирующий систему команд х86.

    А вообще, эта тема (про пентиумы и Со) неоднозначная, флеймоопасная и не
очень интересная (для меня), предлагаю ее не обсуждать! :)



--
H.Z.

h.z<antispam::at>ngs<antispam::period>ru

We've slightly trimmed the long signature. Click to see the full one.
Embedded Bench (was AVR vs PIC)

...

 AG>> В качестве теста чего-либо эта  программа совершенно непригодна.

 HZ>     Тем не менее 6380 циклов на MSP430 все равно характеризуют ситуацию.
 HZ> По крайней мере, пусть далеко не точную, но характеристическую оценку это
 HZ> дает.

Серьёзно?! Тогда вот тебе, новинка сезона. Компилятор HiTech 8.30 (таргет
PIC18F6680), рашпиль, напильник и сухая шкурка: результат 4896 циклов:

-----------------------------------------------------------------------

#include <pic18.h>

unsigned char  CorrectBCH ( unsigned long int * );

void main(void)
{
  unsigned long bchword;
  char a ;

  bchword = 0x06;

  a = CorrectBCH ( & bchword ) ;
}

void InvertBit ( unsigned long int * bchword, char bt )
{
  ( * bchword ) ^= 1lu << bt;
  return ;
}

unsigned char CorrectBCH ( unsigned long int * bchword )
{
  static near unsigned char  ci, cj, parity ;
  unsigned int       syndrome ;
  unsigned long int  dataword ;

  static unsigned int syndtable[31] =
  {
    0x200, 0x300, 0x280, 0x240, 0x220, 0x210, 0x208, 0x204,
    0x202, 0x201, 0x1b4, 0x3da, 0x2ed, 0x1c2, 0x3e1, 0x144,
    0x3a2, 0x2d1, 0x1dc, 0x3ee, 0x2f7, 0x1cf, 0x053, 0x09d,
    0x0fa, 0x37d, 0x10a, 0x385, 0x176, 0x3bb, 0x169
  };

  dataword = ( * bchword ) & 0xfffffffelu ;

  ci = 31 ;
  do
  {
    if ( dataword & 0x80000000lu ) dataword ^= 0xed200000lu ;
    dataword <<= 1 ;
  }
  while ( -- ci ) ;

  syndrome = ( unsigned int )( dataword >> 16 ) ;
  syndrome >>= 6 ;

  dataword = * bchword ;
  parity = 0 ;

  while ( dataword )
  {
    parity ^= dataword & 1 ;
    dataword >>= 1 ;
  }

  if ( ! syndrome )
  {
    if ( ! parity ) return 0 ;
    ( * bchword ) ^= 1 ;
    return 1 ;
  }

  ci = 31 ;
  do
  {
    {
      * ( near unsigned int * )( & FSR0L ) = syndrome ;
      * ( near unsigned int * )( & FSR2L ) = ( unsigned int )( syndtable ) ;
      FSR1L = ci ;
      FSR1H = 0  ;
      #asm
        LL1:  movf    postinc2,w,c
              xorwf   fsr0l,w,c
              bz      LL2
              movf    postinc2,w,c
              decfsz  fsr1l,f,c
              bra     LL1
              bra     LL4

        LL2:  movf    postinc2,w,c
              xorwf   fsr0h,w,c
              bz      LL3
              decfsz  fsr1l,f,c
              bra     LL1
              bra     LL4

        LL3:  bsf     fsr1h,0,c
        LL4:
      #endasm
    }

    if ( FSR1H & 1 )
    {
      cj = ci - cj ;
      if ( ! cj )
      {
        InvertBit ( bchword, ci ) ;
        if ( parity == 1 )  return 1 ;
        ( * bchword ) ^= 1 ;
        return 2 ;
      }
      if ( parity )  return 0xff ;
      InvertBit ( bchword, ci )  ;
      InvertBit ( bchword, ci - cj ) ;
      return 2 ;
    }
    syndrome <<= 1 ;
    if ( syndrome & 0x400 )  syndrome ^= 0x369 ;
    syndrome &= 0x3ff ;
  }
  while ( -- ci != 0 ) ;
  return 0xFF;

-----------------------------------------------------------------------

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

Ну что ты теперь расскажешь про: "Тем не менее 6380 циклов на MSP430 все
равно характеризуют ситуацию..."?

...

 HZ>     Другое дело, что есть тебя устраивает производительность PIC18 на
 HZ> твоих задачах, то тут тогда и обсуждать нечего - значит не нужен тебе
 HZ> MSP430. Hо медленнее он от этого не становится.

Реальность такова, что мы имеем 16-разрядный МК, который при использовании
встроенного умножителя 16x16->32 на вполне реальной, наиболее подходящей под
его архитектуру, чисто вычислительной задаче с термометрами получил
относительный выигрыш 6% по отношению к 8-разрядному МК оснащённому
умножителем 8x8->16 и остался в проигрыше по абсолютной производительности на
18%. Это следствие медленной работы с памятью (с чего начали, тем и
закончили). При этом о реальной производительности ядра мы сможем судить
только после того, как ты опубликуешь данные о времени работы без умножителя.

Сравнение относительной производительности с dsPIC30F на всех примерах, что
удалось от тебя получить подавляющая, вплоть до 3...4 раз, о чём я и
предполагал в самом начале.

Результаты работы программы VV (512 000 циклов) я не признаю, до тех пор пока
ты не предъявишь код Add и Mul и я смогу убедиться, что они действительно
могут выполнять эти операции за 40...50 циклов. В конце концов, если это так,
то эти программы для меня имеют вполне объективную познавательную ценность и
я буду очень признателен.

...

 HZ> Итого, реальная эффективность
 HZ> MSP430 не так уж плоха, что и видно на реальном коде.

Ну хоть тональность изменилась, похоже одним мифом (про фантастические
производительность и малопотребляемость MSP430) становится меньше.


Re: Embedded Bench (was AVR vs PIC)

Quoted text here. Click to load it

Интересны бы были ваши комментарии насчет
http://www.gaw.ru/html.cgi/txt/app/micros/msp430/slaa205.htm
focus.ti.com/lit/an/slaa205/slaa205.pdf


Best Regards,
Sergey Utlyakov

Re: Embedded Bench (was AVR vs PIC)
Всем привет.

Quoted text here. Click to load it

Хм... Они там MSP430 хвалят или AVR? Сравните цены - приведенная в качестве
примера AtMega8 (2.3$ в розницу) по крайней мере в два раза дешевле приведенных
PIC18 и MSP430... И при этом, по приведенным тестам, она стабильно на 2-м месте.

                                   АртемКАД




Re: Embedded Bench (was AVR vs PIC)
  Привет!

Thu Sep 30 2004 11:55, Sergey Utlyakov wrote to Alexander Golov:

...

 >> HZ> Итого, реальная эффективность
 >> HZ> MSP430 не так уж плоха, что и видно на реальном коде.
 >>
 >> Hу хоть тональность изменилась, похоже одним мифом (про фантастические
 >> производительность и малопотребляемость MSP430) становится меньше.
 >>

 SU> Интересны бы были ваши комментарии насчет
 SU> http://www.gaw.ru/html.cgi/txt/app/micros/msp430/slaa205.htm
 SU> focus.ti.com/lit/an/slaa205/slaa205.pdf

Что нужно прокоментировать? Если по поводу отображения этими тестами
производительности PIC18, то можно одним словом: "враньё". Беру компилятор
Hi-Tech 8.30 и получаю:

                        Размер       Циклов

8-bit Math                188          115
8-bit Switch Case         160           51
16-bit Math               320          316
16-bit 2-dim Matrix       450         8433
16-bit Switch Case        196           69
32-bit Math               662          863
Floating-point Math      2158          795
FIR Filter               1496      139 979
Matrix Multiplication     426       10 114

Если качество соответствующего компилятора IAR, то нет слов. Вот посмотрел
код "16-bit 2-dim Matrix" сгенерированный Hi-Tech -- тихий ужас. Не могу
представить зачем HI-Tech понадобилось в 4-х последовательных обращениях к
массиву по одному и тому же индексу 4 раза полностью вычислять адрес
(оптимизация такого уровня -- примитивность и осуществляется ещё на
машинонезависимом уровне), без чего код становится вдвое короче и в 2,3 раза
быстрее. Но как IAR удалось всё это сделать ещё в 3,2 раза медленнее у меня
даже предположений не возникло.


Site Timeline