OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 22 Октябрь, 2019 22:14

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 17 ] 
Автор Сообщение
 Заголовок сообщения: Base64: оптимизация и пр.
СообщениеДобавлено: Понедельник, 09 Август, 2010 13:12 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Выделено: viewtopic.php?p=50438#p50438

У этого решения есть один недостаток -- не портабельно.
Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Август, 2010 13:52 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Alexey Veselovsky писал(а):
У этого решения есть один недостаток -- не портабельно
Эффективность и портабельность - взаимопротиворечивые требования. Тем более, что даже интерфейс (оптимальный!!!) зависит от среды исполнения. Скажем в Дельфи, самое логичное - вернуть тип AnsiString. А где-то будет (да и есть) по другому. Ну и пусть будет...
Другие требования, другое решение. Не такая уж и задача, чтобы напрягаться из за кодинга под другую платформу. Разговоров больше, имхо :)

Alexey Veselovsky писал(а):
Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить.
Зачем... Соревноваться с АСМ-ом, да еще на битах - бессмысленно. При сегодняшем развитии IT-технологий


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Август, 2010 13:56 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Galkov писал(а):
Alexey Veselovsky писал(а):
У этого решения есть один недостаток -- не портабельно
Эффективность и портабельность - взаимопротиворечивые требования. Тем более, что даже интерфейс (оптимальный!!!) зависит от среды исполнения. Скажем в Дельфи, самое логичное - вернуть тип AnsiString. А где-то будет (да и есть) по другому. Ну и пусть будет...
Другие требования, другое решение. Не такая уж и задача, чтобы напрягаться из за кодинга под другую платформу. Разговоров больше, имхо :)

Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово.

Galkov писал(а):
Alexey Veselovsky писал(а):
Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить.
Зачем... Соревноваться с АСМ-ом, да еще на битах - бессмысленно. При сегодняшем развитии IT-технологий

Ну, я ж не соревноваться, а больше ради образовательных целей :-)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Август, 2010 15:53 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8185
Откуда: Троицк, Москва
Alexey Veselovsky писал(а):
Ну, я ж не соревноваться, а больше ради образовательных целей :-)
Это святое :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Август, 2010 16:14 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Alexey Veselovsky писал(а):
Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово.
Что значит сопровождение ???
Типа, изменилась система команд проца, а мы - оппаньки, и подправили ??? :)
Надо написать, чтобы это работало всегда.
Вот я уже говорил "умными словами", в чем отличие работы "профессионала", от "любителя"... То же самое можно выразить более коротко: второй умеет делать чтобы работало, а первый - чтобы работало всегда.
А вообще-то моя главная мысль состоит в том, что не укладываются инженерые решения всегда в один шаблон (базовый!!!). Решение портируемости в виде кодов ANSI-C - это тоже же шаблон. Где-то он работает эффективно, наверное.
Ну скажем, тот же XDS... Или вот Рефаловская компания занимается генерацией выходных кодов в таком виде...
Народ думал, соображал принял решение. Возможно и правильное.
Но для 30-40 байт кода - не тот случай. Это не утверждение, это мне пока так кажется :)

Alexey Veselovsky писал(а):
Ну, я ж не соревноваться, а больше ради образовательных целей :)
Был и у меня период для "образовательнгых целей" :)
Не сразу же я начал для AVR-ок на АСМ-е писать. Сначала я был молод, и верил, что ЯВУ шибко экономит время разработки. Использовал IAR-овский C++. Даже классы соорудил с переопределенными арифметическими операциями (типа один байт умножить на два байта - будет 3 байта).
Потом начал замечать, что гораздо эффективней "запуска сразу" просмотреть сгенерированный АСМ-код - просто на предмет анализа, правильно ли меня ентот C++ понял.
Пробовал "помогать" оптимизатору. Типа короткая серия операций с глобальным указателем. А в регистрах он располагает в первую очередь переменные с минимальной областью видимости. Ну я заводил локальную переменную, инициализировал глобальной, работал с локальной, и возвращал значение обратно в глобальную. Помогало очень хорошо :D
До следующей версии компилятора.
И понял я - глупое это дело, писать оптимальный код на ЯВУ. Компилятор, он хоть и тупой, но ведет себя, будто умнее программиста.
А потом понял еще: решаю я задачу полгода, предположим. В кодинге я половину времени трачу на борьбу с компилятором. Но выполнить работу компилятора ручками - ну максимум 2 дня.... Из полугода.

И спрашиваеися нафига мне такой "экскаватор", когда 2 солдата из стройбата выполнят его работу в два раза эффективнее. Не по времени, а по результату :lol:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 09 Август, 2010 16:40 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Galkov писал(а):
Alexey Veselovsky писал(а):
Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово.
Что значит сопровождение ???
Типа, изменилась система команд проца, а мы - оппаньки, и подправили ??? :)

Именно. Это происходит довольно часто.
Надо написать, чтобы это работало всегда.
Galkov писал(а):
Вот я уже говорил "умными словами", в чем отличие работы "профессионала", от "любителя"... То же самое можно выразить более коротко: второй умеет делать чтобы работало, а первый - чтобы работало всегда.

Так вот, решение на асме "всегда" работать не будет. Будет работать только на той железяке для которой разработано. В общем то ситуация классическая: пишем либу. Изначально x86 и часто винда (но иногда линух). Написали, отладили. Потом рраз, и захотелось это дело использовать на WinMo например. А там, как понимаешь, ARM. А потом раз, и на эльбрусе потребовалось, не тот который большой эльбрус, и не тот который 3М, а тот который спарк. И привет. Если у нас в коде полно асмовых вставок, то простой перекомпиляцией (с переписыванием модулей доступа к устройствам, если таковое необходимо -- это делается ну за неделю где-то) мы не отделаемся. Т.е. асм для наших задач не технологичен.

Часто идут на компромис. Подобные вот вещи пишутся на С/С++, но для некоторых платформ существуют асм-версии. Т.о. при необходимости мы легко собираемся под новую платформу -- обязательных асм-вставок то нет! Если вдруг оказывается, что мы просаживаемся по производительности в этих вот местах, то оные места реализуются на асме для конкретной платформы. При этом С/С++ решение никуда не девается. Это позволяет быстро достичь базовой функциональности при переезде на новую платформу, оттестировать всё. Понять что и где надо допиливать.

Galkov писал(а):
Но для 30-40 байт кода - не тот случай. Это не утверждение, это мне пока так кажется :)

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

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

Цитата:
А потом понял еще: решаю я задачу полгода, предположим. В кодинге я половину времени трачу на борьбу с компилятором. Но выполнить работу компилятора ручками - ну максимум 2 дня.... Из полугода.

И спрашиваеися нафига мне такой "экскаватор", когда 2 солдата из стройбата выполнят его работу в два раза эффективнее. Не по времени, а по результату :lol:

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


Последний раз редактировалось Alexey Veselovsky Понедельник, 09 Август, 2010 18:04, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Понедельник, 09 Август, 2010 17:37 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Смотреть надо по задачам.
DSP и контроллеры, которые живут прямо над железкой - это одно.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Понедельник, 09 Август, 2010 18:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Опять же, давайте не забывать про суперскалярность и VLIW. Под них руками не наоптимизируешься. И в итоге всё равно поведение процессора не угадаешь... В вычислительных комплексах универсального класса безусловно выгоднее программировать на уровне абстрактной машины ЯВУ..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Понедельник, 09 Август, 2010 18:12 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Ну, ARM ведь таки универсального класса? В смартфонах стоит (которые по функционалу как персоналки), в ноутах... Однако вроде бы там нет суперскалярности.

Но вообще таки да. Обычно не нужно. Но иногда нужно. Вот нам таки пригодилось пару алгоритмов на асме воткнуть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 13:48 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Alexey Veselovsky писал(а):
Если уж требуется именно что высокая степень оптимизации
Мне больше нравится (и я его сплошь и рядом использую) совершенно противоположный подход: а насколько убедительны причины для отказа от "высокой степени оптимизации"??? Пусть даже в совершенно конкретном изделии под совершенно конкретную платформу.
Трудозатраты в пару часов, в сравнении с месяцами работы - убедительными мне не представляются.

Alexey Veselovsky писал(а):
Кстати, а в ваших устройствах зачем-то может потребоваться base64?
Мне пока не требовалось. Мне пока даже плавающая арифметика не требовалась... Хотя времена 8051 - я таковую написал, и использовал
А если по большому счету - почему нет. Если есть связь со внешним миром (тот же COM, предположим), то вроде бы нельзя исключить того, что в постановке задачи окажется какой-нибудь стандартный текстовый протокол, использующий data-вставки именно в таком виде...

"У нас чего только может не быть... У нас - всего может не быть. У нас, чего только не захочешь, того может и не быть" ((с) Жванецкий)


Илья Ермаков писал(а):
В вычислительных комплексах универсального класса безусловно выгоднее программировать на уровне абстрактной машины ЯВУ..
А я и не хочу программировать на АСМ-е. А хочу на уровне абстрактной машины ЯВУ.
Но не могу себе позволить, вот и все.

Смотрите: я беру (в смысле - покупаю) электродрель, и моя работа по сверлению дырок становится и значительно эффективнее, и качественнее.
Далее, я плачу несколько килобаксов за компилятор, а в результате моя работа станет менее качественной. Софт, который я раньше помещал в камень за 50 рублёв, теперь требует теперь камня за 100 баксов. Тот же привод: у буржуинов так и есть, иначе как на PCI-карте с ADSP - они эту задачу решать не умеют.
Преимущества (якобы), что компилятор в минуту перелопатит на многие порядки больше кода, чем человек - я не рассматриваю.
Спрашивается - за что я платил (предположительно - фиг я им заплачу, не доросли еще) деньги.

Т.е., я не увидел преимуществ ЯВУ в своей работе. Нет у меня акта отделения софта от железа. Все наоборот: есть задача, я же под нее проектирую железо. И я же пишу софт. Порой даже оказывается что у некого логического узла (например, АЦП методом двойного интегрирования) половина функциональности заложена в схему (Э3), а вторая - в софте.
Не, портируемость - не мой больной вопрос :)

Но справедливости ради скажу - мне известны мои же коллеги, работающие на том же C. Ну не ложится им АСМ в голову... Ну бывает...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 14:00 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Galkov писал(а):
Но справедливости ради скажу - мне известны мои же коллеги, работающие на том же C. Ну не ложится им АСМ в голову... Ну бывает...

(* на всё остальное отвечать не буду, т.к. Илья ответил уже, и лучше наверно я не скажу *)

Во-от. Видите? Не ложится. Асм. В голову. Даже ваших же коллег. Это говорит о чем? О том, что в случае АСМа сложнее нанять специалиста. Программист дороже. Хуже взаимозаменяем. Следовательно производство становится менее технологичным. Сложнее планирование, выше риски. А железки... Железки дешевы, люди -- дороги. Какая разница сколько стоит железяка для производства 2 бакса, или 100 баксов, если для покупателя она один фиг стоить будет 10 000 баксов (минимум)?

Вот как-то так.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 15:14 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Alexey Veselovsky писал(а):
Во-от. Видите? Не ложится. Асм. В голову. Даже ваших же коллег. Это говорит о чем?
О том, что надо в ЯВУ закладывать такой ИИ, чтобы человек (скажем так - большинство) был неконкурентноспособен.
Вот в шахматы меня комп обыгрывает, и фамилию не спрашивает. Как бы серьезных оснований утверждать, что для ЯВУ это кошмарно-никогда неразрешимая задача - нет



Alexey Veselovsky писал(а):
Какая разница сколько стоит железяка для производства 2 бакса, или 100 баксов, если для покупателя она один фиг стоить будет 10 000 баксов (минимум)?
Тут есть два момента :)
1) Ваше утверждение про "какая разница" - на самом деле больше чем конкретный рассчет. Это философия. 10 килобаксов так и получаются, когда такой принцип применяют раз 10..100 в процессе разработки.
2) Ну и ладно. Но если у второго себестоимость производства (не разработки!!!) будет даже 5 килобаксов, то кто "мне" запретит продавать за 8, при себестоимости 1 ???

Размышление: а как иначе жить в майнстриме-то... Соревноваться с китайцами в производстве ширпотреба ??? Или с индусами - в производстве софта их же способом ??? :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 15:26 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Совсем забыл еще один момент, блин :(
Реалтайм!!!!!

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

Ну и посчитал. Проанализировал самые кошмарные стечения обстоятельств. Обработчики всех прерываний (как и закрытие прерываний в основном потоке) уложил в 5мкс.
И я совершенно не представляю себе пока такую процедуру на ЯВУ...
И в Дейкстру как-то это не очень укладывается.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 18:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9147
Откуда: Россия, Орёл
Вот это компонентик - очень важный, может быть - но он маленький и с точки зрения большой системы периферийный. Это "рецептор" или "эффектор" в сложном организме. Его можно как угодно сделать - и любого знатока оптимизации поставить на эту задачу.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 18:52 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Galkov писал(а):
Ну и посчитал. Проанализировал самые кошмарные стечения обстоятельств. Обработчики всех прерываний (как и закрытие прерываний в основном потоке) уложил в 5мкс.
И я совершенно не представляю себе пока такую процедуру на ЯВУ...
И в Дейкстру как-то это не очень укладывается.

Угу. А у нас тут тоже програмка. Мелкая. SIP-телефон. Тремя людьми за 4 месяца. Сейчас вот натравил sloccount на проект, оно мне выдало что в проекте только плюсового кода порядка 140 тысяч строк. Ещё порядка 12 тыс. строк на C# (один из виндовозных гуёв). На асме -- 202 строки :-) Так вот, я совершенно не представляю как такой проект в такие сроки писать с такими ресурсами писать на АСМе, а главное, потом в нем разбираться. И это ж не 140 тысяч строк будет, это будет небось под миллион. При тем, что он должен работать на нескольких архитектурах и под разными операционными системами.

Повторяю -- это МАЛЕНЬКИЙ проект.

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

Именно. Задача должна быть решена в заданные сроки. Эдакий реалтайм. Но не в железке, а в разработке.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 21:00 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
На что я хотел обратить внимание: на камень преткновения в использовании ЯВУ
Ну ладно, про "5мкс" пусть будет сложно... Упростим пример до физического предела.

Сенсорная (в смысле - емкостная) клавиатура. Одна линия камня формирует сигнал, который через резистор типа 10К попадает на приемную линию. Если я "залапал" эту входную линию пальцами (не напрямую, а через емкость порядка 100пф, естественно) - сигнал придет чуток попозже.
Ну вот и последовательность команд: выкинул 1 на улицу, ровно через 3 тика проца прочитал сигнал с приемной линии, вернул первый сигнал в 0. И так с частотой, например, 100Гц (и далее занимайся себе на здоровье антидебезгом, автоповтором, и т.п.)

Спрашивается, какой ЯВУ может гарантировать эти "ровно через 3 тика" ??? Ответ: тот, который имеет возможность АСМ-вставок.
Какой же он после этого ЯВУ.... Так это же была сверх-простая задача


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Base64: оптимизация и пр.
СообщениеДобавлено: Вторник, 10 Август, 2010 21:42 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2180
Откуда: Нижний Новгород
Suum cuique.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 17 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB