Здравствуйте, Mamut, Вы писали:
N>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться?
M>А откуда он возьмется выделенное у С++ника?
Здравствуйте, MxMsk, Вы писали:
N>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться? MM>Всё когда-нибудь бывает в первый раз. Если человек чего-то не знает, это же не означает, что он не способен узнать об этом в будущем.
Для получения некоторых знаний нужна предварительная подготовка. Не зря тут говорят, что нормальное знание С++ появляется через год (или больше, или вообще не появляется) программирования на нём. Это всё тонкости, о которых не прочитаешь в обычных книгах по языку. И в С++ таких ньюансов, к сожалению, много.
Здравствуйте, Nuzhny, Вы писали:
M>>А откуда он возьмется выделенное у С++ника? N>Из практической каждодневной деятельности.
Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему. О, кстати, ДотНет-чики тоже умеют при необходимости: тынц1
Здравствуйте, vladimir_i, Вы писали:
_>>>Гугл дает тот самый шанс Линуксу, которого у него небыло. А мы посмотрим, годен он для десктопов или нет. И если да, то проприетарные языки MS вымрут. MM>>А если нет?
_>Тогда MS будет благополучно иметь 95% десктопов. Что-то перепадет эплу. C# будут преподавать даже на филологическом факультете.
Угу. Только десктопы останутся у 5% юзеров. А планшетникам перепадёт остальные 95%. А C# будут преподавать только на истории информатики =)))
Здравствуйте, MxMsk, Вы писали:
MM>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему.
А что там заниматься? Запустил профайлер, посмотрел результаты, он тебе сам и показывает твой код вместе с дизассемблером. По нему и смотришь: что конкретно выполняется и как долго.
Тоже самое с ошибками: иногда бывает непонятно, в какой момент падает программа (даже с отладчиком). Нажимаешь (в студии) Show Disassembly и всё видно.
MM>О, кстати, ДотНет-чики тоже умеют при необходимости: тынц1
и далее поиск... N>Ассемблер же у них другой, со своей спецификой и ньюансами.
Среди ссылок был разбор не только IL, но и обычного ассемблера. Целью этих примеров было показать, что даже, если люди пишут на managed языках, это не значит, что они не разбираются в том, как исполняется программа.
Здравствуйте, Mamut, Вы писали:
N>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться? M>А откуда он возьмется выделенное у С++ника?
Т.е. откуда?
Профайлеры для native кода очень давно есть в наличии.
И очень мощные, типа VTune, который юзает HW средства профайлинга процессора. Показывает как С++ сурс (при наличии PDB) так и ассемблер.
Здравствуйте, Nuzhny, Вы писали:
N>Для получения некоторых знаний нужна предварительная подготовка. Не зря тут говорят, что нормальное знание С++ появляется через год (или больше, или вообще не появляется) программирования на нём. Это всё тонкости, о которых не прочитаешь в обычных книгах по языку. И в С++ таких ньюансов, к сожалению, много.
Давай еще раз. Есть человек без опыта в программировании. Он начинает работать и осваивает определенный язык. В какой-то момент выясняется, что для выполнения задачи нужно углубиться в детали конечного кода, исполняемого процессором. Ни программист на C++, ни программист на Managed языке ни разу до этого не рассматривали итоговые ассемблерные команды. Они оба находятся в одном и том же положении по части умения дизассемблировать.
Здравствуйте, MxMsk, Вы писали:
MM>если люди пишут на managed языках, это не значит, что они не разбираются в том, как исполняется программа.
Всё таки среди managed people понимание native ассемблера — довольно редкое явление.
Здравствуйте, MxMsk, Вы писали:
M>>>А откуда он возьмется выделенное у С++ника? N>>Из практической каждодневной деятельности. MM>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием.
Такое ощущение что дизассемблирование это какое то таинство.
Любой нормальный отладчик или профайлер показывает asm код при необходимости.
Если на уровне С++ сурсов не понятно в чём проблема — тыкается одна кнопка и переходим в asm, где смотрим что там компилер нагенерил и что про это думает профайлер.
MM> Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему.
Такую статистику взять просто неоткуда.
Впрочем в asm лезть надо довольно редко и то в основном в профайлинге, когда компилер умудряется не особо хорошо нагенерить. Не так давно кстати выкинул из одного performance critical кода последние asm вставки, т.к. новый ICC осилил сгенерить код, который по замерам работал практически так же быстро.
Здравствуйте, MxMsk, Вы писали:
MM>Среди ссылок был разбор не только IL, но и обычного ассемблера. Целью этих примеров было показать, что даже, если люди пишут на managed языках, это не значит, что они не разбираются в том, как исполняется программа.
Здравствуйте, Nuzhny, Вы писали:
MM>>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему. N>А что там заниматься? Запустил профайлер, посмотрел результаты, он тебе сам и показывает твой код вместе с дизассемблером. По нему и смотришь: что конкретно выполняется и как долго. N>Тоже самое с ошибками: иногда бывает непонятно, в какой момент падает программа (даже с отладчиком). Нажимаешь (в студии) Show Disassembly и всё видно.
Для Managed проектов эта функция тоже действует. Я повторюсь. Managed языки не избавляют от понимания, как оно работает. Они избавляют от рутиных действий по части памяти. Безусловно это накладывает свои ограничения, но мы не об этом.
Здравствуйте, MxMsk, Вы писали:
MM>Давай еще раз. Есть человек без опыта в программировании. Он начинает работать и осваивает определенный язык. В какой-то момент выясняется, что для выполнения задачи нужно углубиться в детали конечного кода, исполняемого процессором. Ни программист на C++, ни программист на Managed языке ни разу до этого не рассматривали итоговые ассемблерные команды. Они оба находятся в одном и том же положении по части умения дизассемблировать.
Программисту на С++ углубляться требуется чаще. Поэтому у него знаний и опыта больше. Это так очевидно, что даже спорить незачем. Хотя бы потому, что ниши у языков разные: на С# не пишут системные или высокопроизводительные вещи, не используют asm вставки, не так часто занимаются профилированием программ.
Здравствуйте, Nuzhny, Вы писали:
N>Программисту на С++ углубляться требуется чаще. Поэтому у него знаний и опыта больше. Это так очевидно, что даже спорить незачем. Хотя бы потому, что ниши у языков разные: на С# не пишут системные или высокопроизводительные вещи, не используют asm вставки, не так часто занимаются профилированием программ.
Теперь понятно. С такими убеждениями спорить действительно незачем.
Здравствуйте, CreatorCray, Вы писали:
M>>>>А откуда он возьмется выделенное у С++ника? N>>>Из практической каждодневной деятельности. MM>>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. CC>Такое ощущение что дизассемблирование это какое то таинство. CC>Любой нормальный отладчик или профайлер показывает asm код при необходимости. CC>Если на уровне С++ сурсов не понятно в чём проблема — тыкается одна кнопка и переходим в asm, где смотрим что там компилер нагенерил и что про это думает профайлер.
Дык, я и не считаю дизассемблер таинством. Инструмент, как инструмент. Кому-то нужный, кому-то нет
Здравствуйте, MxMsk, Вы писали:
MM>В какой-то момент выясняется, что для выполнения задачи нужно углубиться в детали конечного кода, исполняемого процессором.
Давай для начала проясним что это за задача для неопытного, когда надо лезть в потроха?
MM> Ни программист на C++, ни программист на Managed языке ни разу до этого не рассматривали итоговые ассемблерные команды. Они оба находятся в одном и том же положении по части умения дизассемблировать.
Оба ничего не смогут сделать без изучения asm и приобретения понимания как это всё работает.
N>>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться?
M>>А откуда он возьмется выделенное у С++ника?
N>Из практической каждодневной деятельности.
Вот только не надо мне тут сказки рассказывать. Средний С++ник так же далек от анализа дизассемблера профайлером, как и средний дотнетчик
N>>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться? M>>А откуда он возьмется выделенное у С++ника? CC>Т.е. откуда? CC>Профайлеры для native кода очень давно есть в наличии. CC>И очень мощные, типа VTune, который юзает HW средства профайлинга процессора. Показывает как С++ сурс (при наличии PDB) так и ассемблер.
Я не совсем верно выделил. Откуда взяться опыту анализа дизассемблера профайлером у С++ника? Средний С++ник так же далек от анализа дизассемблера профайлером, как и средний дотнетчик
Здравствуйте, MxMsk, Вы писали:
N>>Программисту на С++ углубляться требуется чаще. Поэтому у него знаний и опыта больше. Это так очевидно, что даже спорить незачем. Хотя бы потому, что ниши у языков разные: на С# не пишут системные или высокопроизводительные вещи, не используют asm вставки, не так часто занимаются профилированием программ. MM>Теперь понятно. С такими убеждениями спорить действительно незачем.
Хорошо. Драйвера на C# в студию! асм-вставки в студию! Высокопроизводительные вещи (не исследовательские, такие и на Питоне пишут) в студию!
