-
- Интересно, в DSP Lib'е такие же товарищи как "оптимизаторы" языка C
покопались? Я тут пытался недавно применить целочисленные фильтры и
выяснил (вначале экспериментально, а когда офигел, потом уж и по
исходникам), что с какого-то релиза там делается округление суммы
не в конце, а в середине процесса, в результате чего оно, конечно,
процентов на 30 быстрее работает, но результаты вычислений можно
сразу выбрасывать в помойку - ar-elec(01.12.2021 18:08)
- Ну, это ,типа...ардуино-LIB'ерасты поляну осваивают. ;) - SERGHIO(01.12.2021 21:47)
- А это какой из DSP либов? - Evgeny_CD(01.12.2021 18:20)
- В языках программирования действует железное правило "Каждый последующий хуже предыдущего". - PlainUser(01.12.2021 16:53)
- Статья про UB и кривизну компиляторов. Undefined behaviour - это
вполне определённое поведение, но зависимое от компилятора и
процессора. На асме тоже можно писать всякую дичь, никто же не
делает это. Авторы (молодые ребята) "ищут" как художники и хотят
самоутвердиться. Не нравится им "опасные" int и арифметика с
указателями, но во всех старых учебниках всегда предупреждали про
int. А с указателями они из-за юного возраста, наверное, мало
работали. У них модель памяти всегда Costic(238 знак., 01.12.2021 16:17)
- В этом вся суть нашей Сишечки. С одной стороны, сам по себе С, даже
С11 по стандарту, это не шибко сложная вещь. Но! Если хочешь писать
реально переносимый код на MCU, то нужно одновременно в голове
держать просто срань правил и методов написания кода, от чего
реальный стандарт промышленного С будет 5к страниц, наверное, и
учить его надо 10 лет до уровня Гуру. - Evgeny_CD(01.12.2021 16:30)
- Всё-таки, Си - низкоуровневый язык, машинно-зависимый. Переносимость и повторное использование кода были целями С++ и Java, но не очень они добились этих целей. А вот вопрос машинно-зависимости - неоднозначный. Сейчас вот много говорят про потокобезопасность, защиту памяти и стека, атомарность ит.д. Лет 30 назад такие вопросы не были актуальны. Когда в Windows 2000 через переполнение стека попёрли вирусы, то на наши strcpy() и т.д. повесили "чёрную метку". Сейчас многоядерные Costic(152 знак., 01.12.2021 17:03)
- Если мы идем по пути "насрать на абстрактную машину, я пишу для
конкретного MCU", то это путь в ад. Новый MCU, и, в особенности,
компилятор для него, могут многие тонкие моменты реализовывать по
своему, не нарушая стандарта. И перенос старого кода в "новую,
улучшенную реальность" приведет к тому, что Арианы будут падать с
промышленной регулярностью. - Evgeny_CD(01.12.2021 16:37)
- дык проблема ж в том, что новый стандарт вместо того, чтобы
зафиксировать устоявшееся (хоть и не совсем правильное) поведение
описывает его заново так, что старые программы начинают ломаться. - Mahagam(01.12.2021 21:44)
- Это очень непростая дилемма. В общем и целом, полной переносимости
исходников C90 - > C11 нет. Ну если совсем дотошно. Как я
понял, ломающий практику вариант позволяет несколько ускорить код.
И если писать новый код сразу по новому стандарту, то он будет
быстрее. Т.е. переписываем старые исходники с матюками и болью, и
оно будет хорошо. Evgeny_CD(312 знак., 01.12.2021 22:10)
- ну давай, ускорь проверку переполнения знаковых чисел. которое теперь UB. когда аппаратную особенность подменяют программным костылём - быстрее точно не будет. - Mahagam(01.12.2021 22:42)
- Просто некоторые придурки восприняли UB как "компилятор будет творить непонятную, но очень быструю фигню" - LightElf(01.12.2021 22:34)
- Это очень непростая дилемма. В общем и целом, полной переносимости
исходников C90 - > C11 нет. Ну если совсем дотошно. Как я
понял, ломающий практику вариант позволяет несколько ускорить код.
И если писать новый код сразу по новому стандарту, то он будет
быстрее. Т.е. переписываем старые исходники с матюками и болью, и
оно будет хорошо. Evgeny_CD(312 знак., 01.12.2021 22:10)
- дык проблема ж в том, что новый стандарт вместо того, чтобы
зафиксировать устоявшееся (хоть и не совсем правильное) поведение
описывает его заново так, что старые программы начинают ломаться. - Mahagam(01.12.2021 21:44)
- В этом вся суть нашей Сишечки. С одной стороны, сам по себе С, даже
С11 по стандарту, это не шибко сложная вещь. Но! Если хочешь писать
реально переносимый код на MCU, то нужно одновременно в голове
держать просто срань правил и методов написания кода, от чего
реальный стандарт промышленного С будет 5к страниц, наверное, и
учить его надо 10 лет до уровня Гуру. - Evgeny_CD(01.12.2021 16:30)
- Умереть должен не язык Цэ, а комитет по стандартизации оного языка.
Выписать всем замаравшимся по пять лет расстрела через повешенье -
и жизнь наладится. - LightElf(01.12.2021 14:18)
- На чём писать другие языки тогда? fort и Oberon переживут, а вот
много других - не уверен, что просто. Так что "высокоуровневый
ассемблер" не зря так живуч. - Dingo(01.12.2021 17:53)
- "Все было, в общем-то, неплохо. Пока не стали улучшать" - LightElf(01.12.2021 19:30)
- Есть там коммент: Costic(69 знак., 01.12.2021 15:57)
- Помнится, в Иране как-то расстреляли кучу метеорологов, которые
пропустили какой-то там катаклизьм. Однако прогнозы погоды от этого
точнее не стали. - Evgeny_CD(01.12.2021 14:21)
- Стандартизаторы языка Цэ стремятся сделать из Цэ какой-то убогий
жабоскрипт. Норовя втащить в него плоды своих высокомудрых
размышлений, вместо адаптации сложившейся практики. Ну нет уже ни
одного процессора, не использующего дополнительный код для
отрицательных чисел. Нахера сохранять в этом вопросе UB? Нахера
тащить плюсатые атомики? Ладно хоть VLA в последних стандартах
выпилили. - LightElf(01.12.2021 14:30 - 14:34)
- Скоро "C90" будет знаком качества :-) - SciFi(01.12.2021 14:45)
- Они с завистью смотрят на стандартизаторов С++ и мечтают повторить
хотя бы толику их успеха :) - Evgeny_CD(01.12.2021 14:33)
- Не ту контору "бешеным принтером" назвали! - SciFi(01.12.2021 16:23)
- +100500! - Evgeny_CD(01.12.2021 16:37)
- Наблюдая результаты трудов "комитетов по стандартизации" трудно не
стать поклонником абсолютной монархии. - LightElf(01.12.2021 14:36)
- Где-то далеко тепло улыбнулся Скрипач) - Cкpипaч(01.12.2021 14:49)
- Не ту контору "бешеным принтером" назвали! - SciFi(01.12.2021 16:23)
- Стандартизаторы языка Цэ стремятся сделать из Цэ какой-то убогий
жабоскрипт. Норовя втащить в него плоды своих высокомудрых
размышлений, вместо адаптации сложившейся практики. Ну нет уже ни
одного процессора, не использующего дополнительный код для
отрицательных чисел. Нахера сохранять в этом вопросе UB? Нахера
тащить плюсатые атомики? Ладно хоть VLA в последних стандартах
выпилили. - LightElf(01.12.2021 14:30 - 14:34)
- На чём писать другие языки тогда? fort и Oberon переживут, а вот
много других - не уверен, что просто. Так что "высокоуровневый
ассемблер" не зря так живуч. - Dingo(01.12.2021 17:53)
- раньше не понимал IAR, а теперь глянул, а у них веселье в самом разгаре Mahagam(234 знак., 01.12.2021 14:12)
- Название опуса эмоционально заряжено, как и содержание. Но там есть ссылка на годный материал по этой теме >>> SciFi(1 знак., 01.12.2021 12:25, ссылка)
- Интересно, в DSP Lib'е такие же товарищи как "оптимизаторы" языка C
покопались? Я тут пытался недавно применить целочисленные фильтры и
выяснил (вначале экспериментально, а когда офигел, потом уж и по
исходникам), что с какого-то релиза там делается округление суммы
не в конце, а в середине процесса, в результате чего оно, конечно,
процентов на 30 быстрее работает, но результаты вычислений можно
сразу выбрасывать в помойку - ar-elec(01.12.2021 18:08)