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>> Свободно скачивается с

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

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

éÎÔÅÒÅÓÎÙ ÂÙ ÂÙÌÉ ×ÁÛÉ ËÏÍÍÅÎÔÁÒÉÉ ÎÁÓÞÅÔ

Best Regards, Sergey Utlyakov

Hello Harry.

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

HZ> ÷ ÎÅÊÍÁÎÅ ÎÅ ÍÏÇÕÔ! ÷ ÎÅÊÍÁÎÅ ÏÄÎÁ ÛÉÎÁ ÄÁÎÎÙÈ ÎÁ ×ÓÅ. ëÏÇÄÁ ÛÉÎ HZ> ÂÏÌØÛÅ, ÜÔÏ ÕÖÅ ÇÁÒ×ÁÒÄ. ÷ TMS320F28xx ÐÁÍÑÔØ ÔÏÖÅ ÏÄÎÁ, ÎÏ ÛÉÎ 6 ÛÔÕË HZ> É ÁÒÈÉÔÅËÔÕÒÁ ÎÁÚÙ×ÁÅÔÓÑ ÍÏÄÉÆÉÃÉÒÏ×ÁÎÎÏÊ ÇÁÒ×ÁÒÄÓËÏÊ. á ÐÁÍÑÔØ ÏÄÎÁ.

á ×ÏÔ ÔÙ ÓËÁÖÉ - ÓÏ×ÒÅÍÅÎÎÙÊ ÐÅÎÔÉÕÍ - ÜÔÏ ÎÅÊÍÁÎ ÉÌÉ ÇÁÒ×ÁÒÄ? á ÔÏ ÐÏÌÕÞÁÅÔÓÑ ÞÔÏ ÛÉÎÁ Õ ÎÅÇÏ ÏÄÎÁ, ÎÏ ËÅÛ ÄÁÎÎÙÈ É ËÏÍÁÎÄ ÒÁÚÄÅÌØÎÙÊ É ÏÎ ÓÐÏËÏÊÎÏ ÍÏÖÅÔ ÏÄÎÏ×ÒÅÍÅÎÎÏ ×ÙÂÉÒÁÔØ É ÄÁÎÎÙÅ É ËÏÍÁÎÄÕ.

Alexey

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.

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

÷ÓÅÍ ÐÒÉ×ÅÔ.

èÍ... ïÎÉ ÔÁÍ MSP430 È×ÁÌÑÔ ÉÌÉ AVR? óÒÁ×ÎÉÔÅ ÃÅÎÙ - ÐÒÉ×ÅÄÅÎÎÁÑ × ËÁÞÅÓÔ×Å ÐÒÉÍÅÒÁ AtMega8 (2.3$ × ÒÏÚÎÉÃÕ) ÐÏ ËÒÁÊÎÅÊ ÍÅÒÅ × Ä×Á ÒÁÚÁ ÄÅÛÅ×ÌÅ ÐÒÉ×ÅÄÅÎÎÙÈ PIC18 É MSP430... é ÐÒÉ ÜÔÏÍ, ÐÏ ÐÒÉ×ÅÄÅÎÎÙÍ ÔÅÓÔÁÍ, ÏÎÁ ÓÔÁÂÉÌØÎÏ ÎÁ 2-Í ÍÅÓÔÅ. áÒÔÅÍëáä

Привет!

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>>> Свободно скачивается с

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

...

Привет!

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

...

SU> Интересны бы были ваши комментарии насчет SU>

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 раза медленнее у меня даже предположений не возникло.

...

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.