OberonCore https://forum.oberoncore.ru/ |
|
Base64: оптимизация и пр. https://forum.oberoncore.ru/viewtopic.php?f=27&t=2772 |
Страница 1 из 1 |
Автор: | Alexey Veselovsky [ Понедельник, 09 Август, 2010 13:12 ] |
Заголовок сообщения: | Base64: оптимизация и пр. |
Выделено: viewtopic.php?p=50438#p50438 У этого решения есть один недостаток -- не портабельно. Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить. |
Автор: | Galkov [ Понедельник, 09 Август, 2010 13:52 ] |
Заголовок сообщения: | Re: Пример алгоритма Base64-кодирования |
Alexey Veselovsky писал(а): У этого решения есть один недостаток -- не портабельно Эффективность и портабельность - взаимопротиворечивые требования. Тем более, что даже интерфейс (оптимальный!!!) зависит от среды исполнения. Скажем в Дельфи, самое логичное - вернуть тип AnsiString. А где-то будет (да и есть) по другому. Ну и пусть будет...Другие требования, другое решение. Не такая уж и задача, чтобы напрягаться из за кодинга под другую платформу. Разговоров больше, имхо Alexey Veselovsky писал(а): Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить. Зачем... Соревноваться с АСМ-ом, да еще на битах - бессмысленно. При сегодняшем развитии IT-технологий
|
Автор: | Alexey Veselovsky [ Понедельник, 09 Август, 2010 13:56 ] |
Заголовок сообщения: | Re: Пример алгоритма Base64-кодирования |
Galkov писал(а): Alexey Veselovsky писал(а): У этого решения есть один недостаток -- не портабельно Эффективность и портабельность - взаимопротиворечивые требования. Тем более, что даже интерфейс (оптимальный!!!) зависит от среды исполнения. Скажем в Дельфи, самое логичное - вернуть тип AnsiString. А где-то будет (да и есть) по другому. Ну и пусть будет...Другие требования, другое решение. Не такая уж и задача, чтобы напрягаться из за кодинга под другую платформу. Разговоров больше, имхо Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово. Galkov писал(а): Alexey Veselovsky писал(а): Кстати, могу попозже не портабельную (но, видимо, более быструю) версию на С/С++ подготовить. Зачем... Соревноваться с АСМ-ом, да еще на битах - бессмысленно. При сегодняшем развитии IT-технологийНу, я ж не соревноваться, а больше ради образовательных целей |
Автор: | Info21 [ Понедельник, 09 Август, 2010 15:53 ] |
Заголовок сообщения: | Re: Пример алгоритма Base64-кодирования |
Alexey Veselovsky писал(а): Ну, я ж не соревноваться, а больше ради образовательных целей Это святое
|
Автор: | Galkov [ Понедельник, 09 Август, 2010 16:14 ] |
Заголовок сообщения: | Re: Пример алгоритма Base64-кодирования |
Alexey Veselovsky писал(а): Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово. Что значит сопровождение ???Типа, изменилась система команд проца, а мы - оппаньки, и подправили ??? Надо написать, чтобы это работало всегда. Вот я уже говорил "умными словами", в чем отличие работы "профессионала", от "любителя"... То же самое можно выразить более коротко: второй умеет делать чтобы работало, а первый - чтобы работало всегда. А вообще-то моя главная мысль состоит в том, что не укладываются инженерые решения всегда в один шаблон (базовый!!!). Решение портируемости в виде кодов ANSI-C - это тоже же шаблон. Где-то он работает эффективно, наверное. Ну скажем, тот же XDS... Или вот Рефаловская компания занимается генерацией выходных кодов в таком виде... Народ думал, соображал принял решение. Возможно и правильное. Но для 30-40 байт кода - не тот случай. Это не утверждение, это мне пока так кажется Alexey Veselovsky писал(а): Ну, я ж не соревноваться, а больше ради образовательных целей Был и у меня период для "образовательнгых целей" Не сразу же я начал для AVR-ок на АСМ-е писать. Сначала я был молод, и верил, что ЯВУ шибко экономит время разработки. Использовал IAR-овский C++. Даже классы соорудил с переопределенными арифметическими операциями (типа один байт умножить на два байта - будет 3 байта). Потом начал замечать, что гораздо эффективней "запуска сразу" просмотреть сгенерированный АСМ-код - просто на предмет анализа, правильно ли меня ентот C++ понял. Пробовал "помогать" оптимизатору. Типа короткая серия операций с глобальным указателем. А в регистрах он располагает в первую очередь переменные с минимальной областью видимости. Ну я заводил локальную переменную, инициализировал глобальной, работал с локальной, и возвращал значение обратно в глобальную. Помогало очень хорошо До следующей версии компилятора. И понял я - глупое это дело, писать оптимальный код на ЯВУ. Компилятор, он хоть и тупой, но ведет себя, будто умнее программиста. А потом понял еще: решаю я задачу полгода, предположим. В кодинге я половину времени трачу на борьбу с компилятором. Но выполнить работу компилятора ручками - ну максимум 2 дня.... Из полугода. И спрашиваеися нафига мне такой "экскаватор", когда 2 солдата из стройбата выполнят его работу в два раза эффективнее. Не по времени, а по результату |
Автор: | Alexey Veselovsky [ Понедельник, 09 Август, 2010 16:40 ] |
Заголовок сообщения: | Re: Пример алгоритма Base64-кодирования |
Galkov писал(а): Alexey Veselovsky писал(а): Отдельный код для каждой из платформ увеличивает стоимость сопровождения продукта. Что не здорово. Что значит сопровождение ???Типа, изменилась система команд проца, а мы - оппаньки, и подправили ??? Именно. Это происходит довольно часто. Надо написать, чтобы это работало всегда. Galkov писал(а): Вот я уже говорил "умными словами", в чем отличие работы "профессионала", от "любителя"... То же самое можно выразить более коротко: второй умеет делать чтобы работало, а первый - чтобы работало всегда. Так вот, решение на асме "всегда" работать не будет. Будет работать только на той железяке для которой разработано. В общем то ситуация классическая: пишем либу. Изначально x86 и часто винда (но иногда линух). Написали, отладили. Потом рраз, и захотелось это дело использовать на WinMo например. А там, как понимаешь, ARM. А потом раз, и на эльбрусе потребовалось, не тот который большой эльбрус, и не тот который 3М, а тот который спарк. И привет. Если у нас в коде полно асмовых вставок, то простой перекомпиляцией (с переписыванием модулей доступа к устройствам, если таковое необходимо -- это делается ну за неделю где-то) мы не отделаемся. Т.е. асм для наших задач не технологичен. Часто идут на компромис. Подобные вот вещи пишутся на С/С++, но для некоторых платформ существуют асм-версии. Т.о. при необходимости мы легко собираемся под новую платформу -- обязательных асм-вставок то нет! Если вдруг оказывается, что мы просаживаемся по производительности в этих вот местах, то оные места реализуются на асме для конкретной платформы. При этом С/С++ решение никуда не девается. Это позволяет быстро достичь базовой функциональности при переезде на новую платформу, оттестировать всё. Понять что и где надо допиливать. Galkov писал(а): Но для 30-40 байт кода - не тот случай. Это не утверждение, это мне пока так кажется "Всегда только Си" -- это плохой шаблон. Не годный. "Си по умолчанию, асм опционально" -- намного более годный шаблон. С таким ключиком у нас собирается всё сишное. С эдаким реализации некоторых алгоритмов используются асмовые для целевой платформы. С другой стороны, да. Я думаю что этот шаблон слишком жиррный для разработки ПО для всяких мелких устройств. Там, быть может, решение на Си будет менее портабельным и применимым чем асм, потому, как оно просто банально не уложится в память устройства. Т.е., быть может, с вашей колокольни АСМ предпочтительней. Цитата: А потом понял еще: решаю я задачу полгода, предположим. В кодинге я половину времени трачу на борьбу с компилятором. Но выполнить работу компилятора ручками - ну максимум 2 дня.... Из полугода. И спрашиваеися нафига мне такой "экскаватор", когда 2 солдата из стройбата выполнят его работу в два раза эффективнее. Не по времени, а по результату Ну, я и говорю, в ваших задачах, быть может, и да, асм предпочтительней. Если уж требуется именно что высокая степень оптимизации. Кстати, а в ваших устройствах зачем-то может потребоваться base64? С ходу не придумываются задачи с base64 для такого класса устройств. |
Автор: | Илья Ермаков [ Понедельник, 09 Август, 2010 17:37 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Смотреть надо по задачам. DSP и контроллеры, которые живут прямо над железкой - это одно. Код системного назначения на основных машинах, даже в системах реального времени - совсем другое. Там просадки начинаются на вводе-выводе и прочем, конкретные дробления битов резко падают в удельной цене. С памятью надо хорошо работать, параллелизм диспетчить подходящим образом, не полагаясь на ОС, на "квадрат" в алгоритмах не попадать и не мудрить с усложнением структур данных (обычно вместо оптимизации за счёт усложнения просадка получается). Помню, года три назад я реализовывал алгоритмы защиты информации на КП - в итоге ничего и оптимизировать не пришлось, для своей задачи прекрасно хватило, хотя там гигабайты обрабатываться должны были за разумное время... |
Автор: | Илья Ермаков [ Понедельник, 09 Август, 2010 18:08 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Опять же, давайте не забывать про суперскалярность и VLIW. Под них руками не наоптимизируешься. И в итоге всё равно поведение процессора не угадаешь... В вычислительных комплексах универсального класса безусловно выгоднее программировать на уровне абстрактной машины ЯВУ.. |
Автор: | Alexey Veselovsky [ Понедельник, 09 Август, 2010 18:12 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Ну, ARM ведь таки универсального класса? В смартфонах стоит (которые по функционалу как персоналки), в ноутах... Однако вроде бы там нет суперскалярности. Но вообще таки да. Обычно не нужно. Но иногда нужно. Вот нам таки пригодилось пару алгоритмов на асме воткнуть. |
Автор: | Galkov [ Вторник, 10 Август, 2010 13:48 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Alexey Veselovsky писал(а): Если уж требуется именно что высокая степень оптимизации Мне больше нравится (и я его сплошь и рядом использую) совершенно противоположный подход: а насколько убедительны причины для отказа от "высокой степени оптимизации"??? Пусть даже в совершенно конкретном изделии под совершенно конкретную платформу.Трудозатраты в пару часов, в сравнении с месяцами работы - убедительными мне не представляются. Alexey Veselovsky писал(а): Кстати, а в ваших устройствах зачем-то может потребоваться base64? Мне пока не требовалось. Мне пока даже плавающая арифметика не требовалась... Хотя времена 8051 - я таковую написал, и использовалА если по большому счету - почему нет. Если есть связь со внешним миром (тот же COM, предположим), то вроде бы нельзя исключить того, что в постановке задачи окажется какой-нибудь стандартный текстовый протокол, использующий data-вставки именно в таком виде... "У нас чего только может не быть... У нас - всего может не быть. У нас, чего только не захочешь, того может и не быть" ((с) Жванецкий) Илья Ермаков писал(а): В вычислительных комплексах универсального класса безусловно выгоднее программировать на уровне абстрактной машины ЯВУ.. А я и не хочу программировать на АСМ-е. А хочу на уровне абстрактной машины ЯВУ.Но не могу себе позволить, вот и все. Смотрите: я беру (в смысле - покупаю) электродрель, и моя работа по сверлению дырок становится и значительно эффективнее, и качественнее. Далее, я плачу несколько килобаксов за компилятор, а в результате моя работа станет менее качественной. Софт, который я раньше помещал в камень за 50 рублёв, теперь требует теперь камня за 100 баксов. Тот же привод: у буржуинов так и есть, иначе как на PCI-карте с ADSP - они эту задачу решать не умеют. Преимущества (якобы), что компилятор в минуту перелопатит на многие порядки больше кода, чем человек - я не рассматриваю. Спрашивается - за что я платил (предположительно - фиг я им заплачу, не доросли еще) деньги. Т.е., я не увидел преимуществ ЯВУ в своей работе. Нет у меня акта отделения софта от железа. Все наоборот: есть задача, я же под нее проектирую железо. И я же пишу софт. Порой даже оказывается что у некого логического узла (например, АЦП методом двойного интегрирования) половина функциональности заложена в схему (Э3), а вторая - в софте. Не, портируемость - не мой больной вопрос Но справедливости ради скажу - мне известны мои же коллеги, работающие на том же C. Ну не ложится им АСМ в голову... Ну бывает... |
Автор: | Alexey Veselovsky [ Вторник, 10 Август, 2010 14:00 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Galkov писал(а): Но справедливости ради скажу - мне известны мои же коллеги, работающие на том же C. Ну не ложится им АСМ в голову... Ну бывает... (* на всё остальное отвечать не буду, т.к. Илья ответил уже, и лучше наверно я не скажу *) Во-от. Видите? Не ложится. Асм. В голову. Даже ваших же коллег. Это говорит о чем? О том, что в случае АСМа сложнее нанять специалиста. Программист дороже. Хуже взаимозаменяем. Следовательно производство становится менее технологичным. Сложнее планирование, выше риски. А железки... Железки дешевы, люди -- дороги. Какая разница сколько стоит железяка для производства 2 бакса, или 100 баксов, если для покупателя она один фиг стоить будет 10 000 баксов (минимум)? Вот как-то так. |
Автор: | Galkov [ Вторник, 10 Август, 2010 15:14 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Alexey Veselovsky писал(а): Во-от. Видите? Не ложится. Асм. В голову. Даже ваших же коллег. Это говорит о чем? О том, что надо в ЯВУ закладывать такой ИИ, чтобы человек (скажем так - большинство) был неконкурентноспособен.Вот в шахматы меня комп обыгрывает, и фамилию не спрашивает. Как бы серьезных оснований утверждать, что для ЯВУ это кошмарно-никогда неразрешимая задача - нет Alexey Veselovsky писал(а): Какая разница сколько стоит железяка для производства 2 бакса, или 100 баксов, если для покупателя она один фиг стоить будет 10 000 баксов (минимум)? Тут есть два момента 1) Ваше утверждение про "какая разница" - на самом деле больше чем конкретный рассчет. Это философия. 10 килобаксов так и получаются, когда такой принцип применяют раз 10..100 в процессе разработки. 2) Ну и ладно. Но если у второго себестоимость производства (не разработки!!!) будет даже 5 килобаксов, то кто "мне" запретит продавать за 8, при себестоимости 1 ??? Размышление: а как иначе жить в майнстриме-то... Соревноваться с китайцами в производстве ширпотреба ??? Или с индусами - в производстве софта их же способом ??? |
Автор: | Galkov [ Вторник, 10 Август, 2010 15:26 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Совсем забыл еще один момент, блин Реалтайм!!!!! Предположим, мне надо провести некие вычисления каждые 62.5мкс. Не примерно каждые, а по настоящему - каждые. И успеть закончить расчеты до прихода следующего "момента истины" А тут такая беда - у меня еще около 4-процессов сидят на прерываниях... И все это я должен посчитать. Ну и посчитал. Проанализировал самые кошмарные стечения обстоятельств. Обработчики всех прерываний (как и закрытие прерываний в основном потоке) уложил в 5мкс. И я совершенно не представляю себе пока такую процедуру на ЯВУ... И в Дейкстру как-то это не очень укладывается. Первично: есть постановка - задача должна быть решена. А всякие там: "не укладывается в голове", "нет в Дейкстре", "не создана общая теория", "нас этому учили не этому, а ставили технику" - это все вторичное |
Автор: | Илья Ермаков [ Вторник, 10 Август, 2010 18:17 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Вот это компонентик - очень важный, может быть - но он маленький и с точки зрения большой системы периферийный. Это "рецептор" или "эффектор" в сложном организме. Его можно как угодно сделать - и любого знатока оптимизации поставить на эту задачу. А системный архитектор и знать не будет, как оно там написано. Правильность "неканонического" кусочка кода может быть проверена путём рецензирования несколькими людьми в сочетании с тестированием (покрыть такой модулёк несложно обычно). Хотя другая забота - правильность правильностью, а доказательство формальное по временному поведению делать нужно будет, если железка важная. |
Автор: | Alexey Veselovsky [ Вторник, 10 Август, 2010 18:52 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Galkov писал(а): Ну и посчитал. Проанализировал самые кошмарные стечения обстоятельств. Обработчики всех прерываний (как и закрытие прерываний в основном потоке) уложил в 5мкс. И я совершенно не представляю себе пока такую процедуру на ЯВУ... И в Дейкстру как-то это не очень укладывается. Угу. А у нас тут тоже програмка. Мелкая. SIP-телефон. Тремя людьми за 4 месяца. Сейчас вот натравил sloccount на проект, оно мне выдало что в проекте только плюсового кода порядка 140 тысяч строк. Ещё порядка 12 тыс. строк на C# (один из виндовозных гуёв). На асме -- 202 строки Так вот, я совершенно не представляю как такой проект в такие сроки писать с такими ресурсами писать на АСМе, а главное, потом в нем разбираться. И это ж не 140 тысяч строк будет, это будет небось под миллион. При тем, что он должен работать на нескольких архитектурах и под разными операционными системами. Повторяю -- это МАЛЕНЬКИЙ проект. Galkov писал(а): Первично: есть постановка - задача должна быть решена. А всякие там: "не укладывается в голове", "нет в Дейкстре", "не создана общая теория", "нас этому учили не этому, а ставили технику" - это все вторичное Именно. Задача должна быть решена в заданные сроки. Эдакий реалтайм. Но не в железке, а в разработке. |
Автор: | Galkov [ Вторник, 10 Август, 2010 21:00 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
На что я хотел обратить внимание: на камень преткновения в использовании ЯВУ Ну ладно, про "5мкс" пусть будет сложно... Упростим пример до физического предела. Сенсорная (в смысле - емкостная) клавиатура. Одна линия камня формирует сигнал, который через резистор типа 10К попадает на приемную линию. Если я "залапал" эту входную линию пальцами (не напрямую, а через емкость порядка 100пф, естественно) - сигнал придет чуток попозже. Ну вот и последовательность команд: выкинул 1 на улицу, ровно через 3 тика проца прочитал сигнал с приемной линии, вернул первый сигнал в 0. И так с частотой, например, 100Гц (и далее занимайся себе на здоровье антидебезгом, автоповтором, и т.п.) Спрашивается, какой ЯВУ может гарантировать эти "ровно через 3 тика" ??? Ответ: тот, который имеет возможность АСМ-вставок. Какой же он после этого ЯВУ.... Так это же была сверх-простая задача |
Автор: | Alexey Veselovsky [ Вторник, 10 Август, 2010 21:42 ] |
Заголовок сообщения: | Re: Base64: оптимизация и пр. |
Suum cuique. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |