Для того чтобы умники не занимались оптимизацией кода разработчики используют недокументированные возможности процессоров, модифицирующийся исполняемый код и другие ухищрения.
Раньше на ассемблере все кодили, сейчас любое говно типа навороченного текстового редактора весит столько же сколько "весил" весь дистрибутив винды 3.11 на дискетах...
Да, понятно, скорость разработки повышается,
но к примеру вес "Microsoft Office" сегодня какой?
А "NI labview" только дистрибутив включая модули 45GB!
Такое впечатление, что код специально забивают NOPами для увеличения веса, солидности и стоимости софта.
Вот к примеру работы настоящих КОДЕРОВ — ролики размером 64к:
Только совсем не факт, что вроде бы оптимальный по быстродействию ассемблерный код будет оптимальным в реальности — внутри х86 не то, чем он кажется снаружи :)
"Вашими устами — да мёд пить" — я компутер немного пользую, от программирования очень далёк. Но упомянутые соображения всегда меня сильно смущали — чем дальше — тем больше. Начиная с 90-х. Пользовал несколько редакторов, ещё в то время, и удивлялся, как один из них в состоянии был сделать практически всё, что и другие, включая "резиновые таблицы", и, будучи всего несколько десятков килобайт, в десятки раз меньше остальных. По-моему назывался "слово и дело" или похоже
Не забываем что разрядность увеличилась, utf-8 и прочее.. это просто даже не трогая саму логику увеличивает объем. Компиляторы сейчас любят "раскручивать циклы" тоже свои копейки добавляет. И да сделать офис на ассемблере.. это жёстко тем более что его надо делать под разные платформы...А для офисного работника задержка в 0.1s или в 0.5s роли играть не будет. Но увеличит багучесть, падучесть софта и стоимость разработки. Увы но это факт. Иначе бы ни кто не заморачивался.
Дык, и еще какой-то баг если возникнет — с регистрами передачи параметров и управления, счетчиками, аккумулятором,сдвиговыми регистрами,стеком и кучей. адресами переходов, возврата, который в самом Helium не учтён. Поведение кода и исполнение может быть каким угодно. Написанные на Fortran прикладные системы и комплексы так можно оптимизировать — но там и так есть механизмы работы с OBJ, они совершенны несмотря на то что им уже 40 с лишним лет.
а фильтры это и есть код в самом чистом виде и там очень много повторяющихся строк, очень много. Примерно так что на каждый пиксель изображения штук 20 строк. Замерить, установить, замерить, установить, замерить, установить, сравнить с соседним, замерить цвет, если цвет голубой, добавить белого, сравнить с соседним. перейти на следующий пиксель. Человек просто не в состоянии охватить всё разом, чтоб загнать всё в функции и переменные.
Скорее всего вот так и появился у меня в телефоне фотошоп (винфон)
То, что Вы описали — это не код, а алгоритм. Код будет содержать строк пять: перемножение пары матриц в цикле и сравнение. В понятиях статьи оптимизация кода — это его распараллеливание, чтобы все ядра (или их максимально возможно количество) в современных процах задействовать.
Комментарии
Да, понятно, скорость разработки повышается,
но к примеру вес "Microsoft Office" сегодня какой?
А "NI labview" только дистрибутив включая модули 45GB!
Такое впечатление, что код специально забивают NOPами для увеличения веса, солидности и стоимости софта.
Вот к примеру работы настоящих КОДЕРОВ — ролики размером 64к:
youtube.com
youtube.com
awards.scene.org
Понятно что фракталы и алгоритмы, но тем не менее уважуха спецам!
Скорее всего вот так и появился у меня в телефоне фотошоп (винфон)