caxapa.ru :: "вот поэтому я и не женюсь" (С) сижу на ассемблере :)) В "эмбеддед" это пока не сильно заметно (ну если не смотреть на всякие "кубы", "гармонии" и прочие фреймворки, которые уверенной поступью движутся именно туда, о чём статья :) С некоторых пор - сто раз подумаю, прежде, чем обновлять привычный софт (в т.ч. и рабочий, а не только сервисный). К счастью

Adept (24.12.2021 13:10, просмотров: 372) ответил Evgeny_CD на Хабр. Крик души. В софте все всрато и становится еще всратее

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

Обновления на многие вещи выходят раз-два в год и не содержат зачастую критически важных правок. А так-то да, - современный софт - в сравнении с тем же 10-20 летней давности - просто ппц какой-то . Да, не спорю, появилось много новых мелких (и часто важных) "рюшечек", но , блин, такое впечатление, что выполняется принцип 80/20 (ну или 90/10), только не применительно к работе и трудозатратам, а примерно так: 90% функционала покрывается 10% кода, оставшиеся 10% добавляют ещё 90% объёма кода программы. Про прожорливость к ресурсам - даже не знаю как сформулировать... Это просто "какой-то позор" (С) лютый трешЪ :((

...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)

Ответить

- На asm'е ты сидишь исключительно потому что все твои проекты - это твои проекты, и сколько ты убиваешь на них времени - ты в принципе никогда не считал. RxTx(45 знак., 24.12.2021 23:10)
  - Не зависит срок от языка , в нашем деле.Да и один хрен 95% кода берется из старого отлаженного проекта. - PlainUser(25.12.2021 17:59)
  - считал :) средний срок поднятия комплексного проекта с нуля до запуска в производство (независимо от сложности), - полгода. Это: концепция устройства; концепция дизайна и проработка функционала; дизайн/разработка хост ПО (если надо); структура, написание и отладка встроенного ПО; схемотехника; печатная плата; конструктив; инженерные расчёты (тепло, прочность, ЭМС, если надо); запуск в производство и тестовое оборудование; пилотная партия (упаковка и мануалы, если надо). Adept(629 знак., 25.12.2021 06:23)
- Устройства простые. Три буквы VCP и ассемблер практически исключается. - VLLV(24.12.2021 13:19)
  - образно говоря, я п~~ока~~ в DOS-е Вы в Win95 (ну мож 3.11 пока :)) Я выбрал нишу эксклюзива, где всегда будет место и творчеству и неспешному ассемблерокопанию и себе в удовольствие и заказчику на радость (обхожусь минимальными ресурсами проца в большинстве задач, а в мелких проектах бывает стоимость проца 20..40% стоимости электроники :). Конечно, если ориентироваться на "вал" Adept(683 знак., 24.12.2021 13:40)
    - Меня другое бесит. Нет продвинутых средств разработки, которые бы комбинировали ассемблерный подход и эффективность разработки. Evgeny_CD(321 знак., 24.12.2021 14:13)
      - ИМХО конечно, но думается мне что корень проблемы в том, что все эти замечтательные библиотеки/фреймворки имеют общий недостаток: они наследуют императивный ассемблерный подход. Соответственно возможности оптимизации компилятором изрядно ограничены. Будущее "большого" программирования за декларативным подходом (а-ля SQL) и могучим компилятором с нейросетками ~~и профурсетками~~. Не погромист будет решать, как хранить данные: в массиве, списке или хэш-таблице. А LightElf(230 знак., 24.12.2021 15:33)
        
        Корень какой проблемы? Нет никакой проблемы. Процессоры процессируют, погромисты погромируют, круговорот бабла в природе не останавливается. Всё прекрасно. - SciFi(24.12.2021 15:50)
        
        Иногда хочется помечтать о дивном будущем, в котором программы будут создаваться не для прокормления программистов, а для решения задач пользователей. - LightElf(24.12.2021 15:55)
        
        Этот пост оскорбляет чувства программистов. И вообще, вы видели этих пользователей? Они не оценят такую заботу :-) - SciFi(24.12.2021 16:00)
        
        Я вижу вокруг достаточно людей, реально платящих заметные деньги, чтобы в телефоне интерфейс не тормозил. - LightElf(24.12.2021 16:02)
        
        Ценой желтого пятна прожженного в экране разогнанным процессором? Видели у Ксхуаеми. - PlainUser(25.12.2021 18:03)
        
        Ржака! Загуглил, действительно. - RxTx(25.12.2021 21:12)
        
        а я вижу достаточно говнокодеров, которые такие "ухты, у юзверей мощи в телефоне дохренища, айда всё на электроне писать!" - Mahagam(24.12.2021 16:30)
        
        Дык беда не в том, что много говнокодеров. А в том, что кроме говнокодеров больше никого и не видно. - LightElf(24.12.2021 17:06)
        
        © «Не мы такие, время такое». Сказали бы говнокодеры. - RxTx(25.12.2021 02:48)
        
        Вы так говорите, как будто это плохо. Уберёте им тормоза бесплатно, они потратят эти деньги на другую бесполезную фигню. Продавцы ойфонов найдут другой способ срубить с них бабло. - SciFi(24.12.2021 16:11)
        
        Я разве предлагаю делать это бесплатно? - LightElf(24.12.2021 17:07)
        
        Буржуи не идиоты. Если бы такое продавалось, уже сделали бы. - SciFi(24.12.2021 17:11)
        
        Возможно есть трудности с осознанием проблемы. В приципе, мелкомягкие экспериментируют с нейросетями для написания кода. - LightElf(24.12.2021 17:17)
        
        А где взять декларативный компилятор для компиляции декларативного компилятора? - =AlexD=(24.12.2021 15:37)
        
        там же, где берут императивные компиляторы для компиляции императивных компиляторов. Раскруткой. Сначала пишут примитивный на чем ни попадя (ассемблер, бейсик, питон, C++). Им компилируют самого себя. Потом потихоньку расширяют-углубляют. - LightElf(24.12.2021 15:45)
        
        и контрольный вопрос - а где взять декларативный процессор? нонешние все сцуко древний мерзкий императивный машинный код жрут. недоделки поганыя. - Mahagam(24.12.2021 15:43)
        
        Не, процессор остается какой есть. И у него конечно остается какой-то ассемблер для крайних случаев, всяких там загрузчиков, кусочков ОС и тыды. И языки типа Цэ никуда не денутся. А вот эта вся тряхомудия, вроде жаб и прочих котлинов - должна сгинуть, бо втыкая между железом и целевой задачей 100500 прослоек ничего не дает в смысле возможностей алгоритмической оптимизации. - LightElf(24.12.2021 15:52)
        
        Твой компилятор врятли нормально заработает без нейросетки достаточно большого масштаба. - =AlexD=(24.12.2021 16:32)
        
        Ну вот к примеру Verilog (который я не знаю). Он, вроде как, вполне декларативный. То есть описывается что должно получиться, а не "которую 2И-НЕ с этим триггером соединить". Вроде же справляются как-то, синтезируют в сильно разные плиски и не жужат. - LightElf(24.12.2021 17:05)
        
        там как раз примерно "хочу 2и-не и с триггером". ты когда пишешь int i; не поясняешь, где это i должно быть - в общей куче, на стеке или в регистре. так и верилог - ты ему "хочу 2И-НЕ", а он тебе "а я тебе в LUT`ы логику запихнул, оно будет работать, не сумлевайся". - Mahagam(24.12.2021 17:17)
        
        Ну да, оно (как я понимаю) само выбирает куда запихнуть и что с чем соединить, чтобы получить заданную логическую функцию. Когда я пишу LightElf(537 знак., 24.12.2021 17:31)
        
        этой "скрываемой потенциально важной инфы" слишком дохрена. а на каком проце оно будет распараллеливаться? а стоит ли дёргать работой 32 ядра, если поиск в 32-х элементах? а с какого конца лучше искать? да почитай статью про процы на хабре. VLIW не смогли осилить потому что компилятор под это дело хрен напишешь. так там задача проста и ясна - вот текст программы, выдай код чтобы все исполнительные блоки запрячь. - Mahagam(24.12.2021 17:37)
        
        Дык я именно об этом. Компилятор не смогли осилить (точнее результат так себе) именно потому, что текст программы уже написан на императивном языке (C, ++, еще что-то), в котором важная информация уже потеряна. Компилятор пытается выцедить параллелизм из текста, изначально подразумевавшего последовательное выполнение. Т.е. сначала программист раскладывает задачу на набор последовательных маленьких шагов, а потом компилятор пытается из фарша слепить стейк. LightElf(518 знак., 24.12.2021 17:59 - 18:09)
        
        CUDA, OpenCL - там есть подсказки компилеру, что параллелить. - Evgeny_CD(24.12.2021 18:24)
        
        но туда изначально суют только распараллеливаемые задачи. иначе оно будет медленнее atom`а - Mahagam(24.12.2021 18:34)
        
        Это вторая часть проблемы. - Evgeny_CD(24.12.2021 18:59)
        
        я в своё время пытался обогнать memcpy самописным кодом на ARM7. ничего не получилось. посмотрел в отладчике - там если размер мелкий, то оно копировалось классическим методом, по байтику за раз. но как только размер для копирования был более чем N байт, то организовывался хитрый цикл с командами ldm stm, а некратный N остаток копировался опять же по классике. так что нормальные библиотеки учитывают множество различных случаев. - Mahagam(24.12.2021 18:13)
        
        Ага. Но это только к небольшому числу довольно мелких функций самого нижнего уровня относится. Чем выше - тем хуже. И на уровне андроидного окошечка с кнопочкой уже фига. - LightElf(24.12.2021 18:44)
        
        нет. статью читай. инфы и так дохрена, loop_unroll компиляторы умеют, и паралеллизм находят. просто зависимостей между возможностями и ограничениями исполнительных блоков становится так много, что хре всё учтёшь оптимально. - Mahagam(24.12.2021 18:03)
        
        Мы пошли по кругу. loop_unroll - это мелкая локальная оптимизация на уровне нескольких инструкций процессора. Я же говорю об оптимизациях совершенно другого масштаба. Когда компилятор, в зависимости от исходных данных сам определяет, а нужен ли вообще этот цикл или можно как-то по-другому задачу решить. Но для этого компилятор должен видеть не конкретную реализацию конкретного алгоритма, а саму задачу целиком. Императивные языки этого не позволяют, а тот же SQL (теоретически) LightElf(6 знак., 24.12.2021 18:38)
        
        иногда человек не знает как задачу решить в целом. а ты хошь чтобы тебе компилятор решение выдал, да не простое, а сразу оптимальное. вот даже простой выбор как хранить большие структуры данных, в виде SoA или AoS ? оно ж зависит от того что с ними делают сейчас, и что планируют делать завтра. и в каких объёмах. - Mahagam(24.12.2021 18:50)
        
        Компилятор вполне может просчитать, что в данной конкретной программе выгоднее и сам выбрать SoA или AoS. Более того, он может воткнуть код преобразования туда-обратно, если оно того стоит в конкретном млучае. Вполне может быть, что для VLIW выгоднее одно, а для обычных процов - другое. - LightElf(24.12.2021 19:03)
        
        вот только компилятор не знает на чём оно будет исполнятся. и это ломает всю сказку. в случае VLIW даже при знании того для чего компилят - и то не могут найти оптимальное решение более простой задачи - Mahagam(24.12.2021 19:49)
        
        Почему это не знает? Даже у gcc есть ключи компиляции под конкретную архитектуру, а уж гипотетическому "языку будущего" они в обязательном порядке нужны. На дискетах/CD софт давно не распространяется, а при загрузке с инета можно выдавать юзеру бинарник, оптимизированный под его систему. Хоть какая-то польза будет от анальных зондов. LightElf(1 знак., 24.12.2021 20:46, ссылка)
        
        ключи есть, а вы когда с нета любую софтинку скачиваете, вы вот под свой конкретно проц скачиваете? или просто x64 версию? то-то и оно. создавая софт на сторону, никто не будет делать набор сборок под разные процы. а когда собираете для VLIW TMS320C6747, то вы собираете под конкретно это ядро C674x. и на другом вы запускать код не будете без пересборки - Mahagam(24.12.2021 21:09)
        
        Выглядит как придумывание отмазки ;-) Нет ни одной проблемы делать сборки со всеми возможными ключами и выдавать их юзеру. Те же линуховые репозитории держат несколько архитектур и не жужат. Ну будет не пять вариантов, а пятьдесят. Докупят места на хостинге. Со всякими гугломаркетами и того проще. - LightElf(24.12.2021 21:58)
        
        ну 50 вариантов. а как юзер будет знать какой качать? - Mahagam(24.12.2021 22:38)
        
        А как сейчас юзер делает выбор из 5 вариантов? Всю работу выполняет менеджер пакетов (в линухе), плеймаркет (в андроиде), инсталлятор в винде. Запустился, проверил что за процессор и выкачал бинарник под него. - LightElf(25.12.2021 04:19)
        
        там другая оптимизация - как написать пиздец какой сложный софт скудным человеческим умишком. и чтобы он не разваливался на ходу. - Mahagam(24.12.2021 16:31)
        
        Придумать свою прослоечку. Круг замкнулся! - VLLV(24.12.2021 16:44)

Средства и методы разработки