>>60085
как раз таки я не реверсер) а твои аргументы к личности - это полный слив. демагог хренов))

вот на еще тогда пасту в догонку.

знание ассемблера не помогает большей части программистов ровным счетом никак. Ведь если от него нет пользы, то оно никак не может быть необходимым требованием к программисту, иначе с тем же успехом можно сказать "кто не знает древнеегипетский, программистом не является". Для того, чтобы некое знание было полезным для программиста, оно должно хотя бы иногда им применятся.

В далекие времена 8086 и DOS программист на C или Pascal, а это было большинство, имея знания ассемблера, вполне мог предположить во что примерно превращается его код на уровне машинных инструкций. И это действительно помогало при разработке критических по скорости участков, а еще он мог часть кода вообще переписать на ассемблере и это почти всегда давало выигрыш в скорости. Ну а скриптовые языки всерьез тогда никто не воспринимал из-за никакой производительности. Однако эти времена давным давно прошли.

Скриптовые языки вышли на первый план. Их производительность достаточна для широкого круга задач, в отдельных случаях даже превосходя код на С без экспертных оптимизаций, а скорость разработки на них несоизмеримо выше. Да и сами языки шагнули далеко вперед: именно в них чаще всего есть функциональщина, замыкания, лямбды, фабрики, метапрограммирование, интроспекция, DSL и прочие изыски, умение работать с которыми и отличает опытного программиста от новичка, этакий матан программирования. А вот C и ассемблеры остались практически теми же. Кстати, опытные программисты на С или асме пишут на скриптовых языках чуть ли не хуже новичков, ибо таких сложных концепций в их языках нет и думать на должном уровне абстракции они не обучены. Ну и само собой представить во что превратится код на скриптовом языке после перевода в конечные инструкции чаще всего невозможно, а при попытке оптимизировать скриптовый код на основе знаний C/Asm "спецы" садятся в лужу, ибо вместо ускорения зачастую получают замедление, иногда даже катастрофическое.

Но и в области старого доброго С тоже не все гладко. Для того чтобы хотя бы примерно узнать во что превратится код нужно учитывать:
1) архитектуру процессора(x86, arm, mips.)
2) конкретную версию ядра процессора (между i386 и core2 пропасть)
3) компилятор и его версию(gcc, clang, msvc, icc генерируют очень разный код, с серьезной разницей в производительности, аналогично с их версиями)
4) опции компилятора(в зависимости от них вышеприведенный простейший фрагмент может быть выброшен вообще, реализован как есть или реализован с разворачиванием цикла, догадайтесь что будет на действительно сложном коде)
Как следствие узнать во что превратится код без запуска отладчика/дизассемблера не получится. Но даже с ними мы видим только одну из версий, а ведь программу могут позже скомпилировать совсем другим способом и все тонкие оптимизации вылетят в трубу.

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

Так что же особенного дает знание ассемблера современному программисту? Может понимание таких вещей как работа с байтами и битами, разница между int и float, выделение и освобождение памяти, указатели? Да все это, мои дорогие Ъ программисты, есть даже в скриптовых языках, не говоря уже о С. В современном мире большинству программистов ассемблер не несет ничего полезного. Он нужен только узким специалистам, например разработчикам компиляторов, драйверов и кодеков. То есть ничтожному проценту от общего числа. Да и те стараются использовать его по минимуму. В ядре линукса процент ассемблерных строк неуклонно падает и составляет на данный момент чуть больше 2%. И это в строках, надеюсь Ъ программисты хотя бы представляют разницу в полезной нагрузке на строчку кода на С и asm.