Mail.ruПочтаМой МирОдноклассникиВКонтактеИгрыЗнакомстваНовостиПоискОблакоComboВсе проекты

Предел вычислительных мощностей: как раздутое ПО обесценивает мощные компьютеры

Купили бы вы автомобиль, который расходует 100 или даже больше литров топлива на 100 км? Вряд ли. А ведь именно нечто подобное происходит сейчас с компьютерами. Мощные ПК порой не могут нормально загрузить простенький сайт, но это не их вина, а результат трудов современных разработчиков.

В среде IT-специалистов есть популярное высказывание: «Время программиста дороже времени компьютера». Получается, что мы тратим намного больше компьютерного времени, нежели времени разработчиков. В IT-сфере на протяжении не менее 30 лет нормальной считается практика «забивать» на оптимизацию. Причина проста — современные компьютеры обладают такой производительностью, что переварят все подряд. Увы, на деле не все так однозначно.

Фото: Depositphotos

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

Раздутое программное обеспечение (РПО) – беда современного мира. Софт просто не хотят оптимизировать

В английском языке этот термин носит названия bloatware, fatware или elephantware. Речь идет о наличии огромного количества ненужных функций в утилите. Всерьез о РПО заговорили еще в 1996 году, когда швейцарский специалист в области информатики Никлаус Вирт, создатель языков «Паскаль», «Модула-2» и «Оберон», написал статью «Долой жирные программы». В ней он поднял проблему того, что программное обеспечение разрастается (словно газ, заполняя все пространство) и становится требовательнее к ресурсам быстрее, чем успевает наращивать мощности аппаратура.

Связано это с тем, что разработчики постоянно гонятся за улучшением своих программ, но вовсе не оптимизируя их, а захламляя новыми возможностями и функционалом. Как показало исследование 2002 года, большинство людей постоянно использует 25% возможностей софта, тогда как до 45% функций остаются невостребованными. Напрашивается вывод: лучше создать два разных продукта меньшего размера с более высокой скоростью работы, нежели раздувать одну программу до невиданных величин.

Примеры худших утилит в категории Fatware

В 2008 году сайт Switched Downloadsquad обнародовал ряд худших примеров софта из области «раздутых программ», неспособных быстро работать даже на мощнейших ПК того времени:

  • Acrobat Reader от Adobe;
  • iTunes от Apple;
  • RealPlayer от RealNetworks;
  • Internet Explorer от Microsoft (мемов насчет его заторможенности в интернете не счесть);
  • Microsoft Outlook.

Спустя 12 лет этот список явно можно дополнить еще некоторыми ужасно работающими утилитами. Главная из них — сама ОС Windows, которая в версии XP требовала 64 МБ ОЗУ и 1,5 ГБ на жестком диске, а в следующей версии Vista потребовала в 10 раз больше пространства и втрое более мощный процессор. Неудивительно, что в итоге Vista с треском провалилась.

Со смартфонами ситуация не лучше. Рост мощи привел к росту лени разработчиков

Раздутое, захламленное ПО касается не только компьютеров, но и смартфонов. Что iOS, что система Android — обе в чистом, распакованном виде (только с набором базовых приложений) «весят» не менее 6 ГБ. Например «вес» клавиатуры Gboard в неинсталлированом виде – 35 МБ. Для сравнения, Windows 95 в свое время «весила» 30 МБ, а функциональность у нее явно была повыше, чем у простейшей Google-клавиатуры.

Еще три года назад смартфоны с объемом хранилища на 16 ГБ смотрелись как неплохая бюджетная покупка, а сейчас девайсов с таким объемом памяти попросту нет — старт идет от 32 ГБ. Приложения растут, как на дрожжах, требуя все больше и больше пространства на накопителях, при этом существенно не меняя своего функционала и внешнего вида. О прошивках многих вендоров, особенно Xiaomi, многие могут написать отдельную статью. В среднем, каждую новую версию MIUI «допиливают» минимум 3 месяца до удобоваримого состояния. Столько времени пользователи терпят повышенный расход батареи, «вылеты» программ, тормоза прошивки и прочие «прелести» ОС.

Конец близок – мощность оборудования не будет расти бесконечно

Лет 10 назад программисты могли позволить себе опускать вопрос оптимизации, поскольку закон Мура еще кое-как работал. В современных условиях двукратный прирост мощностей оборудования каждые 24 месяца невозможен.

Производительность новых процессоров, видеокарт или SoC у смартфонов ежегодно увеличивается, но темпы невелики. IT-гигант Intel и вовсе топчется на месте 5 лет, выжимая последние соки из 14-нанометрового техпроцесса. Конечно, в противовес можно привести воспрявшую духом AMD или Apple с ее M1, рост мощности SoC от Qualcomm, но и им осталось недолго.

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

Нехватку мощностей в нынешних условиях можно решить, есть как минимум два способа:

  1. программистам нужно вернуться к истокам, перестав игнорировать вопросы оптимизации и минимизации создаваемых ими программ;
  2. наращивать количество ядер, тактовую частоту и пропускную способность, объем памяти.

Второй вариант решения проблемы менее эффективен, так как продолжая раздувать софт, отсрочить приближение предела вычислительных мощностей получится ненадолго. Однако именно по этому пути идет современное IT-сообщество, что особенно хорошо видно по системным требованиям последних AAA-игр, — так банально проще. Они не могут нормально функционировать на 4 ядрах, загружая их под 100%. Минимальные требования: 6, а еще лучше 8 ядер с 12 и 16 потоками соответственно. И все равно в итоге может получиться «Киберпанк-2077» в консольной версии.

Это тоже интересно:

Обзоры новинок
Подробности о главных премьерах
Комментарии
80
Настя Викторова
Можно привести аналогию с обществом. Людей, задействованных в производстве продуктов, товаров - единичные проценты из общей массы. Остальные занимаются непонятно чем. От этого конечная цена товаров взлетает на порядок от той цены, которая могла бы быть, если бы все люди были задействованы в производстве. Но такая селява. Общие тенденции идут к тому, что сфера услуг расширяется, а производства скукоживаются.
СсылкаПожаловаться
Дмитрий Февралев
В ответ на комментарий от Кирилл Лукьянов
Кирилл Лукьянов
все банально просто, программисту нет смысла изобретать велосипед, потому что за него уже его изобрели. проще прикрутить фреймворк или тяжелую библиотеку, где большая часть, а может быть и все функции реализованы. это банально проще, а значит дешевле для заказчика. вы представьте решить узконаправленную задачку, например с функциями апроксимации, рядами фурье и нейронными сетями в одном флаконе на асемблере с нуля. сколько времени потратит на это человек? лет 10?.. опытная команда сделает это за год. а сколько на это уйдет средств у заказчика? когда пользуясь фреймворком или библиотекой даже не слишком опытный программист сделает это за неделю. да программа будет выполнять эту задачу вместо 1 сек на ассемблере 10 минут. но если это не так важно, то смысл переплачивать, поскольку зависимость стоимости выполнения программы сравнима со стоимостью ее написания в данном случае. сейчас примерно то же происходит на рынке микроконтроллеров с этими arduino ide и малиновыми ос. там куча библиотек, которые нафиг не нужны, прикручены к проекту.
СсылкаПожаловаться
Все именно так: заказчик не заплатит программисту много за хороший код, когда можно заплатить мало за плохой (но он все равно будет работать), и этот код будет готов завтра, а не через неделю/месяц. Не программист зачастую выбирает какой код ему писать, его вынуждает это делать заказчик! Особенно шикарно когда необходимо ЗА СЕГОДНЯ добавить функционал в чужой код! И приходится лепить какие-то дикие костыли, чтобы хоть как-то работало, вместо того чтобы обстоятельно разобраться и сделать красиво и хорошо!
СсылкаПожаловаться
Михаил
В ответ на комментарий от Dmitri
Dmitri
Меня всегда ужасала непрактичность этого изобретения - Объектно Ориентированного Программирования с претензией на
высокую абстрактность (которую реально могут использовать только гении) и якобы легкую модифицируемость и защищенность, провоцирующую раздувание кода за счет интерфейсов и комментариев к оным...Ну некрасивая идея !
Никогда не понимал зачем такое количество языков, рабочая часть которых отличается только написанием - в этом проглядывает только амбиция и корыстный мотив разработчиков
СсылкаПожаловаться
ООП не плох для сложных задач.
Но вот я, к примеру, с подошью CMD или PS могу решить множество задач кодом не несколько десятков байт, редко килобайт, для решения которых школоло ООП програмисты пишут Гигабайтные приложения. При том что пока это приложение запустится, я при помощи конвейеров и командлетов раз 50 могу решить поставленные задачи :)
СсылкаПожаловаться
Сергей Марков
да, раздуты. Ну а что ещё ожидать от команд, работающих по Agile ))
СсылкаПожаловаться
Андрей Меркулов
В ответ на комментарий от Dmitri
Dmitri
Меня всегда ужасала непрактичность этого изобретения - Объектно Ориентированного Программирования с претензией на
высокую абстрактность (которую реально могут использовать только гении) и якобы легкую модифицируемость и защищенность, провоцирующую раздувание кода за счет интерфейсов и комментариев к оным...Ну некрасивая идея !
Никогда не понимал зачем такое количество языков, рабочая часть которых отличается только написанием - в этом проглядывает только амбиция и корыстный мотив разработчиков
СсылкаПожаловаться
Как интересно комментарии могут привести к "раздуванию" кода?
СсылкаПожаловаться
Никита Курочкин
В ответ на комментарий от Кирилл Лукьянов
Кирилл Лукьянов
все банально просто, программисту нет смысла изобретать велосипед, потому что за него уже его изобрели. проще прикрутить фреймворк или тяжелую библиотеку, где большая часть, а может быть и все функции реализованы. это банально проще, а значит дешевле для заказчика. вы представьте решить узконаправленную задачку, например с функциями апроксимации, рядами фурье и нейронными сетями в одном флаконе на асемблере с нуля. сколько времени потратит на это человек? лет 10?.. опытная команда сделает это за год. а сколько на это уйдет средств у заказчика? когда пользуясь фреймворком или библиотекой даже не слишком опытный программист сделает это за неделю. да программа будет выполнять эту задачу вместо 1 сек на ассемблере 10 минут. но если это не так важно, то смысл переплачивать, поскольку зависимость стоимости выполнения программы сравнима со стоимостью ее написания в данном случае. сейчас примерно то же происходит на рынке микроконтроллеров с этими arduino ide и малиновыми ос. там куча библиотек, которые нафиг не нужны, прикручены к проекту.
СсылкаПожаловаться
Регулярно встречаю случаи когда подключают тяжелые библиотеки(может быть даже несколько), чтобы использовать из них всего пару функций, при том это OpenSourse где можно посмотреть реализацию и просто интегрировать в проект только то что действительно нужно без всего остального
СсылкаПожаловаться
Илья Аганичев
В ответ на комментарий от IT ASP История переписки3
IT ASP
Меня в техе учили писать на ассемблере вот только препод никак не смог обьяснить для чего он нужен
СсылкаПожаловаться
Ради интереса найдите ОС "Колибри" и подивитесь, сколько много всего входит на дискету 1.44МБ
СсылкаПожаловаться
Кирилл Лукьянов
все банально просто, программисту нет смысла изобретать велосипед, потому что за него уже его изобрели. проще прикрутить фреймворк или тяжелую библиотеку, где большая часть, а может быть и все функции реализованы. это банально проще, а значит дешевле для заказчика. вы представьте решить узконаправленную задачку, например с функциями апроксимации, рядами фурье и нейронными сетями в одном флаконе на асемблере с нуля. сколько времени потратит на это человек? лет 10?.. опытная команда сделает это за год. а сколько на это уйдет средств у заказчика? когда пользуясь фреймворком или библиотекой даже не слишком опытный программист сделает это за неделю. да программа будет выполнять эту задачу вместо 1 сек на ассемблере 10 минут. но если это не так важно, то смысл переплачивать, поскольку зависимость стоимости выполнения программы сравнима со стоимостью ее написания в данном случае. сейчас примерно то же происходит на рынке микроконтроллеров с этими arduino ide и малиновыми ос. там куча библиотек, которые нафиг не нужны, прикручены к проекту.
СсылкаПожаловаться
OSDF
Вот многие тут сказали Истину ! Киберпанк - не более чем доделанный Ведьмак ... А колом стоит на 90 проц домашних систем ! То ему видео слабовато , то проц - кал .... А игра то по сути кал !
СсылкаПожаловаться
Андрей Петрович Ивлев
В ответ на комментарий от валера
валера
в свое время пришлось писать программу для функционирования автоматической телефонной станции ,так вот то что основные разработчики не могли уместить в 32 Кбайтах памяти (да по тем временам еще были кбайты) и 16 физических микросхемах моя разработка заняла 2 Кбайта и 1 микросхему физически при этом удалось смоделировать работу сельской телефонной станции и узловой городской. При этом удалось добиться существенного расширения функционала и значительно повысить помехоустойчивость всей программы и при этом программа не разу не сбоила т.к была система самодиагностики .
СсылкаПожаловаться
Валера! Умоляю тебя, пробейся в Минцифры на должность министра! Запусти, наконец, тотальную оптимизацию софта в нашей стране.
СсылкаПожаловаться
Андрей Петрович Ивлев
В ответ на комментарий от Людмила История переписки2
Людмила
Вообще складывается ощущение, что производители ПО и железа между собой в доле, или как то координируют свои действия. Чем более навороченное ПО тем дороже оно стоит, и тем требовательней к железу. Соответственно покупателю приходится приобретать и дорогое ПО, и дорогое железо. В общем все довольны, кроме покупателя.
СсылкаПожаловаться
:))) Это "ощущение" было официально раскрыто еще в 1998 году. Тогда Мелкософт, Intel и нескольких производителей игр уличили в сговоре с целью искусственного затормаживания работы приложений на старых версиях windows и старых компьютерах. Ну как старых, прошлогодних...
СсылкаПожаловаться
Юрий Гаррис
Проблема весьма актуальная, но на современном уровне, пока и разработчиков "железа", и программистов всех мастей, такое положение устраивает, да еще продажи растут, ничего коренным образом измениться не может - даже в случае появления квантовых компьютеров.
СсылкаПожаловаться
Dmitri
В ответ на комментарий от Dmitri История переписки3
Dmitri
Фантастика )) Этот Миллениум (как 98-й) вспоминаю как кошмар ))
СсылкаПожаловаться
Н-да...устойчивость - стабильность за счет неэффективности - вот путь программирования
СсылкаПожаловаться
Dmitri
В ответ на комментарий от Юрий Виноградов История переписки2
Юрий Виноградов
Я от нужды (испоьзовать карту цифрового осциллографа) загрузил Мелениум. Получилась гиперзвуковая ракета относительно десятки.
СсылкаПожаловаться
Фантастика )) Этот Миллениум (как 98-й) вспоминаю как кошмар ))
СсылкаПожаловаться
Юрий Виноградов
В ответ на комментарий от Dmitri
Dmitri
Меня всегда ужасала непрактичность этого изобретения - Объектно Ориентированного Программирования с претензией на
высокую абстрактность (которую реально могут использовать только гении) и якобы легкую модифицируемость и защищенность, провоцирующую раздувание кода за счет интерфейсов и комментариев к оным...Ну некрасивая идея !
Никогда не понимал зачем такое количество языков, рабочая часть которых отличается только написанием - в этом проглядывает только амбиция и корыстный мотив разработчиков
СсылкаПожаловаться
Я от нужды (испоьзовать карту цифрового осциллографа) загрузил Мелениум. Получилась гиперзвуковая ракета относительно десятки.
СсылкаПожаловаться
Dmitri
Меня всегда ужасала непрактичность этого изобретения - Объектно Ориентированного Программирования с претензией на
высокую абстрактность (которую реально могут использовать только гении) и якобы легкую модифицируемость и защищенность, провоцирующую раздувание кода за счет интерфейсов и комментариев к оным...Ну некрасивая идея !
Никогда не понимал зачем такое количество языков, рабочая часть которых отличается только написанием - в этом проглядывает только амбиция и корыстный мотив разработчиков
СсылкаПожаловаться
Snow Leopard
В ответ на комментарий от Абвгд
Абвгд
Чушь какая-то, видимо автор не имеет отношения к разработке программ и особенно игр.
СсылкаПожаловаться
Все так и есть. Нужна одна функция - подключаем тяжеленный фреймворк. А с играми что неправда? Джону Кармаку в 90-е Юнити бы даже в страшном сне не приснился
СсылкаПожаловаться
Олег Горюнов
В ответ на комментарий от Овчаров Игорь История переписки2
Овчаров Игорь
Парадокс именно в этом и заключается. С каждым новым поколением программистов языки программирования все повышаются и повышаются. Уже не за горами то время, когда ООП сменит конструктор лего с названиями кубиков(функций). А программисты как дети в детсадике будут с умными лицами лепить из этих кубиков новый программый продукт. А после сборки засовывать в некий 3D сканер-компилятор и он уже выдавать готовый продукт.
Как бы это фантастически не звучало, но все к этому и идет.
СсылкаПожаловаться
оно уже так и есть
СсылкаПожаловаться
Вадим krsk
Не в бровь, а в глаз, как говорится. Вот держу два смарта от Сяоми Редми 4х и Редми ноут 8 Про. Сторонние приложения примерно одни и те же, у первого оперативной памяти 3 Гб, постоянно занято 1.2-1.5, у второго 6 Гб , если свободно 3.2, то это много. Точно так же и с внутренней памятью, в два раза больше занято на заводских настройках (но с внутренней - там хоть гигов море, если кино сериалами не скачивать).
СсылкаПожаловаться
IT ASP
В ответ на комментарий от Попов Максим Александрович История переписки2
Попов Максим Александрович
Полностью поддерживаю!!! Програмистов сейчас не осталось, мало кто из них способен написать что-то на ассемблере.Чем написать программку на 1-2 кб, нужно прикрутить с 10ок библиотек и получить монстра на 2-3 Мб
СсылкаПожаловаться
Меня в техе учили писать на ассемблере вот только препод никак не смог обьяснить для чего он нужен
СсылкаПожаловаться
Чтобы оставить комментарий, вам нужно авторизоваться.
Вы не ввели текст комментария
Вы не ввели текст комментария
Обнаружили ошибку? Выделите ее и нажмите Ctrl+Enter.
Подпишитесь на нас