|
|
|
Странное предупреждение |
|
|
|
Jun 20 2018, 10:24
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(juvf @ Jun 20 2018, 13:10) Bера в церкви. Вы как гуру должны не верить, а знать, что for-loop будет работать не быстрее, чем любые практические реализации memcpy()[/url]. Я и знаю, что это не так. И знаю почему. И я знаю как внутри работает memcpy(). Поэтому он будет быстрее только в определённых случаях. А в общем случае быстрее будет for loop. Особенно если вспомнить, что компиляторы умеют оптимизировать. Цитата(juvf @ Jun 20 2018, 13:10) а про безопастность - так ТС стрельнул себе в ногу своим forech, причем даже где-то gcc не ругнулся. C memcpy не нужны манимуляции с j. Не знаю, что Вы имеете в виду под "безопасностью", но даже Вы в своём совете с memcpy() допустили пару неточностей.
|
|
|
|
|
Jun 20 2018, 10:37
|
Профессионал
Группа: Свой
Сообщений: 1 261
Регистрация: 14-05-09
Из: Челябинск
Пользователь №: 49 045
|
Цитата(jcxz @ Jun 20 2018, 15:24) но даже Вы в своём совете с memcpy() допустили пару неточностей. какую? Цитата Поэтому он будет быстрее только в определённых случаях. в каких? поделитесь?
|
|
|
|
|
Jun 20 2018, 17:59
|
Местный
Группа: Свой
Сообщений: 475
Регистрация: 14-04-05
Из: Москва
Пользователь №: 4 140
|
Цитата(scifi @ Jun 20 2018, 15:52) Интересно, куда все торопятся? Если я знаю несколько способов решить одну и ту же задачу, то естественно выберу тот который работает быстрее и/или занимает меньше ресурсов. Иначе будет как с "640K ought to be enough for anybody". Цитата(scifi @ Jun 20 2018, 15:52) Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко Именно потому что опыт это и есть набор эффективных реализаций, которые не тормозят там где не надо.
|
|
|
|
|
Jun 20 2018, 18:30
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(juvf @ Jun 20 2018, 13:37) какую? Причём вообще в данном примере memcpy()? ...если ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник? С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит? Причём там вообще memcpy()??? Научитесь читать исходники! Цитата(scifi @ Jun 20 2018, 15:52) Интересно, куда все торопятся? Если судить по моему опыту в ымбеддед, ставить рекорды скорости приходится крайне редко И экономить электроэнергию - тоже редко?
|
|
|
|
|
Jun 20 2018, 18:42
|
Гуру
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702
|
Цитата(jcxz @ Jun 20 2018, 21:30) С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит? Это очевидно из строчки DataBuffer[i] = (data_out[j++]<<8) | data_out[j++]; Если data_out будет больше 8 бит, то операция | будет перемешивать биты из двух соседних значений. (data_out[j++]<<8) | data_out[j++] имеет в этом случае не более 16 значащих бит. Соответственно DataBuffer не менее 16 бит. Какой смысл делать больше?
|
|
|
|
|
Jun 20 2018, 19:31
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(adnega @ Jun 20 2018, 21:42) Это очевидно из строчки DataBuffer[i] = (data_out[j++]<<8) | data_out[j++]; Уважаемый, из этой строчки очевидно только, что к некоему объекту DataBuffer применяются операции индексирования и присвоения значения, а к объекту data_out - операции индексирования и операции приведения к другому типу (возможно целочисленному). Всё остальное - Ваши фантазии, не более. Цитата(adnega @ Jun 20 2018, 21:42) Если data_out будет больше 8 бит, то операция | будет перемешивать биты из двух соседних значений. И что? Может это и есть цель ТСа? Цитата(adnega @ Jun 20 2018, 21:42) Соответственно DataBuffer не менее 16 бит. Какой смысл делать больше? Я видимо ошибся форумом... Думал - тут форум программистов и электронщиков, а оказывается - гадалок и экстрасенсов. Я, как можете заметить, не пытаюсь домысливать тайные намерения автора. И я понятия не имею - чего же он пытается изобразить. Я просто основываюсь на том, что вижу в вопросе. И всех возможных в мире задач я тоже не знаю - мало ли чего человек хочет? Может ему требуется читать из источника пары байт и записывать их по адресу назначения с расширением до 32-бит. Не задумывались? Опять спросите "зачем"? Ну хотя бы например: 1. Многие МК имеют SPI-контроллеры, у которых передаваемое данное записывается в регистр, младшие 16 бит которого - собственно передаваемые биты, а старшие биты - различные биты управления (управление сигналами CS, управление межсловным интервалом и т.п.). Знаю несколько таких МК. Вот если нужно скажем передавать байты в SPI в том порядке, в котором они лежат в памяти, но передавать 16-битными словами (для уменьшения блока пересылки DMA) и при этом к словам добавить управляющую информацию, то может и потребоваться перевёртывание 16-битных слов с расширением их до 32 бит. 2. Или например - он готовит фрейм для передачи в видеопамять LCD-контроллера (опять-же по 16-битному SPI), который (контроллер) принимает пиксели с глубиной цвета 32 бита, а в памяти автора отрисовка идёт 16-битными пикселями. Соответственно - при передаче необходимо расширение каждого пикселя до 32 бит. 3. Или: у автора в устройстве на SPI висит пара слэйвов, соединённых в daisy-chain. Каждый из них имеет размер слова ==16 бит. И он хочет записывать в дальний в цепочке слэйв слова из data_out, а в ближний - нули. Ну скажем эти два слэйва - два 16-разрядных ЦАП, соединённых в daisy-chain. И его DMA должен по неким запросам выдавать по 32 бита на запрос (по слову в каждый ЦАП). Вот он и формирует буфер для DMA таким образом. И это - всего три из тысяч возможных вариантов!
|
|
|
|
|
Jun 21 2018, 04:24
|
Профессионал
Группа: Свой
Сообщений: 1 261
Регистрация: 14-05-09
Из: Челябинск
Пользователь №: 49 045
|
Цитата(Obam @ Jun 20 2018, 23:49) GCC не ругнётся нигде и никогда: у ТСа IAR 2 Obam, читаем ещё раз первый пост ТС до конца Цитата В GCC компайлере такого предупреждения нет. Цитата Причём вообще в данном примере memcpy()? ...если ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник? С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит? Причём там вообще memcpy()??? Научитесь читать исходники! adnega - ППКС, 2jcxz - из кода видно, что с вероятностью близкой к 100, данные из какого-то байтового тх/рх буфера перекидываются в нужный массив DataBuffer. Научитесь читать исходники!. Но не факт что это так, поэтому я сразу написал Цитата если нет перевёртывания с эндианами и DataBuffer - это 16-ти разрядное, то 2jcxz - Научитесь читать посты участников. Цитата мало ли чего человек хочет? Может ему требуется читать из источника пары байт и записывать их по адресу назначения с расширением до 32-бит. Не задумывались? Может быть! Согласен. Может data_out - это класс, а операторы << и | перегруженны. Может даже оператор "++" перегружен в "--". Может где то false переопределён в true. Но из кода видно, что с большей вероятностью просто перекачка из 8 бит массива в 16 битный, поэтому я и сделал оговорку. Что касается memcpy() и остального.... Цитата И я знаю как внутри работает memcpy() Как вы можете знать, как работает memcpy() у ТС, если memcpy реализуется разработчиками каждого компилятора под каждую архитектуру? Вы знаете как каждый memcpy() реализован? У каждого своя реализация. Как правило, memcpy() реализован так, что из всех возможных реализаций код memcpy будет самый оптимальный, вплоть до ухода в асм. Если пользователь компилятора/библиотеки и решит написать свой копипаст, то он будет менее эффективный, в лучшем случае будет такойже, поэтому при копировании памяти не нужно замарачиваться и изобретать скоростной велосипед, а просто использовать memcpy(). Наверно бывают случаю, что memcpy сырой, написан индусами и можно свой написать оптимальней, но это на столько редко.... и нужно хорошо знать архитектуру. Потратите много времени, выиграете 1-2 такта на копировании 1 байта.более того, если ЕСЛИ всё же нет перевертывания и это 8 и 16 бит, то даже плохой memcpy будет быстрее кода ТС. Посмотрите сколько лишних операций в for у ТС! какие-то приведения типов, операторы, << и |, дополнительный j, операции j++!!! УЖАС!!!(кстати.... j++ достаточно медленный, по сравнению с ++j). Более того, если ЕСЛИ data_out - это signed char или int8_t, то в коде ТС ошибка, которая обнаружиться только при выполнении, и хорошо если на столе ТС, а может и через год-два у пользователя. jcxz я сюда не батлится с вами захожу, я тут черпаю чужой опыт, делюсь своим и чужим опытом. Поделитесь вы..... Цитата Поэтому он будет быстрее только в определённых случаях. В каких случаях? Цитата Вы в своём совете с memcpy() допустили пару неточностей. какие неточности? Опять же, mне на батл пофиг, просто я не хочу ошибаться и других вводить в заблуждение в отличие от некоторых Или вы пустослов? Тогда можно нужно отфильтровать ваши посты, ибо это всё равно что "на заборе написано". ps вы сами себе противоречите, причем сразу в одном посте..... Цитата ТС судя по всему пытается поменять байты местами при перемещении из источника в приёмник... С чего Вы вообще взяли, что DataBuffer имеет размерность 16 бит, а data_out - 8 бит? так всё таки "ТС ... пытается поменять байты" или "С чего Вы вообще взяли, что ... data_out - 8 бит?" С чего вы решили, что я утверждаю, что DataBuffer 16 бит, а data_out - 8 бит? Я писал ЕСЛИ, вы знаете значение слова "если"?
|
|
|
|
|
Jun 21 2018, 05:32
|
Гуру
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702
|
Цитата(juvf @ Jun 21 2018, 07:24) С чего вы решили, что я утверждаю, что DataBuffer 16 бит, а data_out - 8 бит? Я писал ЕСЛИ, вы знаете значение слова "если"? Среди профессионалов принято так: если есть наиболее вероятное и простое объяснение, то нужно пользоваться именно им. В противном случае один мой знакомый говорил: "а если инопланетяне прилетели и сделали {подставить нужное}". Если ТС-инопланетянин, пишет, вроде, по нашему, но по ихнему это совсем другой смысл, то jcxz должен посыпать голову пеплом раз не предположил, что такое возможно. Дальше смысл беседы в этом направлении теряется. Если по исходнику понятно, что источник шире 8 байт приведет к перемешиванию бит, а в приемнике в итоге получается только 16 значащих бит, то с уверенностью можно принять за факт их размеры 8 и 16 бит соответственно, и при необходимости заявлять "сам дурак", если ТС начнет добавлять противоречащие новые обстоятельства. В соседней ветке про таймеры ТС на третей станице пошел по второму кругу, хотя у меня была полная уверенность, что точка в вопросе поставлена. В этой связи, jcxz поддерживаю, т.к. без телепатии, а на одной только логике, не понять, что нужно ТС.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|