> Ребята, > насколько хоророшо C++ программист должен знать Assembler? > В абстракциях, или знать конкретно все в тонкостях того или иного процессора? > > Как часто вы используете asm в своей работе?
На уровне примерного понимания чего нагенерировал компиллятор. Полезно для разбора крэшдампов и отладки вообще.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
По моему опыту ассемблер полезен не столько для того, чтобы писать, сколько для того, чтобы читать. Часто при отладке гораздо проще разобраться по ассемблерному коду где и что произошло.
А вообще, все может пригодится. Тут недавно при отладке пригодился не то что ассемблер — машинные коды.
Здравствуйте, Sergey Chadov, Вы писали:
А>>1) Доверяйте оптимизатору SC>[skipped]
SC>По моему опыту ассемблер полезен не столько для того, чтобы писать, сколько для того, чтобы читать. Часто при отладке гораздо проще разобраться по ассемблерному коду где и что произошло.
SC>А вообще, все может пригодится. Тут недавно при отладке пригодился не то что ассемблер — машинные коды.
это порочная логика. всегда можно привести пример, когда что-нибудь так пригодиться, что хоть в петлю лезь. Например. Вчера заглохла моя машина, так быстро схему посмотрел и паяльником починил. Но я предпочитаю не тратить время на изучение схемы машины, вообще что такое электричество, я предпочитаю тратить время на обучению программированию, которое даст мне достаточно денег, что бы вызвать механика.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>программирование = структуры данных + алгоритмы
Это у Вирта
СМ>Где тут ассемблер?
А где тут C++?
Даже произвольный набор байт в памяти — и алгоритм, и данные одновременно.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Сергей Мухин,
ГМ>>Знание ассемблера — это еще одна степень свободы для программиста при решении инженерных задач.
СМ>это еще одна степень зашоренности, ты намертво привязываешь реализацию к к процессору.
--
Я бы сказал — к семейству процессоров. Потому что производители как general-purpose, так и специализированных процессоров, все таки поддерживают преемственность. Это резко снижает уровень моей зашоренности
К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного (в подтверждение своих слов рискну предложить прочитать заметку "A Computer for the Clouds" в последнем номере IEEE Spectrum о разработке очень специализированных суперкомпьютеров для решения очень специализированных задач, причем и стоимость и потребление энергии, по сравнению с general-purpose, уменьшается как минимум на порядок).
IMHO, лучше таки-да решить задачу, чем отказаться ее рашать вообще из-за опасений возможной непереносимости решения.
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler?
Вопрос иначе надо сформулировать — что этот программист собирается на С++ делать ? Если работать с БД — необязательно, так как основное время все равно уйдет на доступ к БД. Если писать свои программы обработки графики на субпиксельном уровне — очень даже желательно.
А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
А>Как часто вы используете asm в своей работе?
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
Как уже писали выше, все зависит от области деятельности.
А>Как часто вы используете asm в своей работе?
Когда писал прошивки для устройств реального времени — в среднем, за месяц хотя бы раз, а то и чаще, приходилось смотреть код в целях проверки оптимизации и поиска затычек компилятора (регистров где-то не хватило, цикл где-то не развернулся, etc). При более "высокоуровневой" разработке — многократно реже, но тоже, в основном, при оптимизации узких мест — раз в полгода-год.
Резюме: насильнику-системщику ассемблер нужно знать как азбуку, насильнику-офиснику — скорее всего, не нужен.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, Pavel Dvorkin, Вы писали:
V>>>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
PD>>Я тоже "старой закалки", хоть и не гуру. И лет 10 назад мы с коллегой писали нечто подобное. На ассемблере с использованием MMX регистров. В результате это работало раза в 1.5 быстрее, чем C++ код.
СМ>а сколько потратили времени?
СМ>а проверить скорость на современных компиляторах?
Даже используя Intel C++ 10.1 кое какой код пришлось написать руками на асме после изучения того, что нагенерил компилер. Правда надо признать что этих функций на весь проект всего около пяти, и каждая не превышает 20 асм команд.
Разница в скорости 20-23%
Здравствуйте, Sergey, Вы писали:
>> Ребята, >> насколько хоророшо C++ программист должен знать Assembler? >> В абстракциях, или знать конкретно все в тонкостях того или иного процессора? >> >> Как часто вы используете asm в своей работе?
S>На уровне примерного понимания чего нагенерировал компиллятор. Полезно для разбора крэшдампов и отладки вообще.
точнее даже так: на уровне понимания что нагенерит компилятор из твоего кода -- т.е. глядя на свой код полезно предствлять что примерно из этого выйдет (это в общем случае)... частности начинаются если ты занимаешься задачами требующими "выжимания максимума производительности"
Здравствуйте,
А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
--
Знать ассемблер того процессора, для которого пишутся программы, весьма полезно. Писать на этом ассемблере не стоит.
Знание ассемблера — это еще одна степень свободы для программиста при решении инженерных задач.
А>Как часто вы используете asm в своей работе?
--
Не часто, но практически в каждом проекте рассматривались варианты использования ассемблера. Иногда такие варианты реализовывались.
Например, использовались специфические команды процессора, которым нет соответсвия в С/С++, или реализовывались специфические простые системные функции при портировании с одной ОС на другую (InterlockedExchangeAdd).
насколько хоророшо C++ программист должен знать Assembler?
Могу ошибаться, но на мой взгляд зависит от области деятельности. Реверсер — великолепно, GUI'шник вообще может не знать .
Как часто вы используете asm в своей работе?
Много лет назад, когда трава была зеленее а заклятья сильнее, я очень хорошо знал ассемблер. Писал на нем 3д движки и 4к демо.
А за последние 10 лет программирования на С++ подо все что движется — забыл напрочь . Тоесть конечно если я что-то уроню в WinDbg, то приблизительно пойму что там в коде происходит. Но с первого взгляда стека не увижу и аргументов функции не определю . Да и инструкций незнакомых много будет. Не используется ассемблер .
Здравствуйте, Сергей Мухин, Вы писали:
СМ>это порочная логика. всегда можно привести пример, когда что-нибудь так пригодиться, что хоть в петлю лезь. Например. Вчера заглохла моя машина, так быстро схему посмотрел и паяльником починил. Но я предпочитаю не тратить время на изучение схемы машины, вообще что такое электричество, я предпочитаю тратить время на обучению программированию, которое даст мне достаточно денег, что бы вызвать механика.
И кого ты будешь вызывать, если не можешь разобраться, почему падает вызов некой функции, исходников которой у тебя нет ? А между тем, иногда помогвет элементарная трассировка входа в функцию, после чего становится ясно, что ты ей банально передал что-то не то.
Здравствуйте, Pavel Dvorkin, Вы писали:
СМ>>лучше C# или Java быстрей пригодиться
PD>Кому ? Абстрактному начинающему программисту или все же программисту на C++ ? Если второму (а о нем здесь вроде идет речь) — вряд ли
программисту С++ надо учить С++, вряд ли кто знает его на 100%
Здравствуйте, vayerx, Вы писали:
СМ>>умеют! MS перегенерит программу после профилирования автоматически.
V>Согласитесь, это не то же самое, что самообучение
Здравствуйте, Pavel Dvorkin, Вы писали:
СМ>>а сколько потратили времени?
PD>несколько дней
СМ>>а проверить скорость на современных компиляторах?
PD>А может еще и на 10-летней давности компьютерах ? На свалке их поискать ? Или надо было ничего не делать, а подождать 10 лет ?
ну вот, потратили несколько дней, что бы с экономить пару секунд. Теперь бедной программе надо 50 лет работать, что бы наверстать эти несколько дней
---
С уважением,
Сергей Мухин
C++ и Assembler
От:
Аноним
Дата:
18.08.08 10:24
Оценка:
Ребята,
насколько хоророшо C++ программист должен знать Assembler?
В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
имхо достаточно в абстракциях
А>Как часто вы используете asm в своей работе?
Здравствуйте, Аноним, Вы писали:
А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
Иметь представление -- обязательно.
Знать в тонкостях -- бессмысленно в 99% случаев.
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
ИМХО не очень нужно.
А>Как часто вы используете asm в своей работе?
Только для отладки или анализа крэш-дампа — оказывается полезно понимать что сгенерировал компилятор, чтобы увидеть, например, в каком именно операторе AV или значение переменной, которое не отображается средой вследствие оптимизации.
Один раз писал на asm: немного кода для заполнения структуры для StackWalk64 (ни GetThreadContext ни GetExceptionInformation не устраивала). Тоже можно считать редкий случай отладки.
Здравствуйте, <Аноним>, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler?
Ча четыре года работы, могу вспомнть только один раз.
Изучали вылет на удалении объектов созданных в библиотеке, после выгрузки данной библиотеки из памяти.
Пригодилось знание одной единственной инструкции jmp
Больше какжется не пригождалось.
Большей части коллектива вообще ни разу не пригодилось.
Здравствуйте, <Аноним>, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler?
Для C программиста, достаточно понимать, что C — ассемблер PDP с кривым (опс, нетрадиционным) синтаксисом и редкими багами в трансляторе.
Современному C++ программисту ассемблер, скорее всего, совсем не нужен. Если софт упадёт по неизвестной причине, то можно будет найти ошибку логами, тулзами, танцами с бубном и вопросами к коллегам\на форумах.
А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
Тонкости нужны, если писать вещи вроде прехватчиков функций, обработчиков прерываний, или... что-то вроде спинлоков и lock-free алгоритмов
А>Как часто вы используете asm в своей работе?
В исключитальных случаях, или из диверсионных побуждений Дело в том, что ассемблерный код зачастую практически неподдерживаемый (если не считать автора, пока ему не надоело). Временами переписываю с него на C++
Если хочешь мыслить на уровне ассемблера, полезнее прочитать Hacker's Delight. Да и в D&E Страуструпа что-то было на эту тему
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re: C++ и Assembler
От:
Аноним
Дата:
26.08.08 13:30
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
А>Как часто вы используете asm в своей работе?
1) Доверяйте оптимизатору
2) Если производительность не устраивает, используйте профилировку
3) Горячие участки перепишите, либо изменив алгоритм, либо использовав стороннюю библиотеку (да, да! в этом мире многое уже решено!), либо перформанс примитивы типа Intel Performance Primitives
4) Не помогает? Подумайте, правильно ли вы решаете задачу на концептуальном уровне
5) Еще раз подумайте, приняв во внимание, что asm портит многие алгоритмы машинной оптимизации, бракуя fetching. Ваше решение становится машинно зависимым, трудно сопровождаемым. Качественная asm вставка зиждется на хорошем понимании конкретной архитектуры: вам придется выбирать, будет ли ваше приложение всех поражать эффективностью на P4, Core, AMD архитектурах (или вы хотите предоставлять несколько имплементаций?).
Здравствуйте, valheru, Вы писали: V>В разработке игр используется довольно часто.
Для проверки оптимизации — безусловно. Но для написания кода в 90% случаев — моветон, если имеются в виду PC-игры.
Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
Да, безусловно, компиляторы не всемогущи. Под какие-то платформы они воистину убоги. Но на "популярных" платформах с++ рулит в 99%
Здравствуйте, vayerx, Вы писали:
V>Для проверки оптимизации — безусловно. Но для написания кода в 90% случаев — моветон, если имеются в виду PC-игры.
Разумеется, почти все пишется на С++. Но отдельные места оптимизируются с помошью векторых команд (MMX/SSE/Altivec).
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>-- ГМ>Знать ассемблер того процессора, для которого пишутся программы, весьма полезно. Писать на этом ассемблере не стоит.
ГМ>Знание ассемблера — это еще одна степень свободы для программиста при решении инженерных задач.
это еще одна степень зашоренности, ты намертво привязываешь реализацию к к процессору.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, Геннадий Майко, Вы писали: ГМ>>Знать ассемблер того процессора, для которого пишутся программы, весьма полезно. Писать на этом ассемблере не стоит. ГМ>>Знание ассемблера — это еще одна степень свободы для программиста при решении инженерных задач.
СМ>это еще одна степень зашоренности, ты намертво привязываешь реализацию к к процессору.
не соглашусь — коренным образом зависит от задачи. безусловно, в большинстве случаев, от процессора можно и нужно абстрагироваться
Здравствуйте, valheru, Вы писали:
V>Разумеется, почти все пишется на С++. Но отдельные места оптимизируются с помошью векторых команд (MMX/SSE/Altivec).
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного (в подтверждение своих слов рискну предложить прочитать заметку "A Computer for the Clouds" в последнем номере IEEE Spectrum о разработке очень специализированных суперкомпьютеров для решения очень специализированных задач, причем и стоимость и потребление энергии, по сравнению с general-purpose, уменьшается как минимум на порядок).
бред какой-то. мы говорим о простом С++ и ассемблере а не о специальных машин! Более того в статье НИЧЕГО не сказано пишут ли они на ассемблере!
ГМ>IMHO, лучше таки-да решить задачу, чем отказаться ее рашать вообще из-за опасений возможной непереносимости решения.
ИМHO тут ТЗ рулит, и если требуется ассемблер, то никто и не спорит, но в 99.999% он не нужен вообще.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>бред какой-то. мы говорим о простом С++ и ассемблере
Что такое "простой С++" я еще могу представить. Думаю что подразумевается С++ 100% соответствующий стандарту.
Но что такое простой ассемблер — это как то непонятно. Ассемблер сам по себе всегда привязан к процессору.
Здравствуйте, Сергей Мухин,
ГМ>>К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного (в подтверждение своих слов рискну предложить прочитать заметку "A Computer for the Clouds" в последнем номере IEEE Spectrum о разработке очень специализированных суперкомпьютеров для решения очень специализированных задач, причем и стоимость и потребление энергии, по сравнению с general-purpose, уменьшается как минимум на порядок).
СМ>бред какой-то.
--
К чему относятся эти Ваши слова?
СМ>мы говорим о простом С++ и ассемблере а не о специальных машин! Более того в статье НИЧЕГО не сказано пишут ли они на ассемблере!
--
Похоже, Вы не поняли аналогии. Ничего страшного в этом нет.
ГМ>>IMHO, лучше таки-да решить задачу, чем отказаться ее рашать вообще из-за опасений возможной непереносимости решения.
СМ>ИМHO тут ТЗ рулит, и если требуется ассемблер, то никто и не спорит, но в 99.999% он не нужен вообще.
--
Обратите внимание, что с самом первом моем сообщении я как раз и призывал не писать на ассемблере, а использовать его тогда, когда он может быть полезным.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>К чему относятся эти Ваши слова?
они написаны сразу за текстом, к которым относятся.
СМ>>мы говорим о простом С++ и ассемблере а не о специальных машин! Более того в статье НИЧЕГО не сказано пишут ли они на ассемблере! ГМ>-- ГМ>Похоже, Вы не поняли аналогии. Ничего страшного в этом нет.
ничего себе! привел статью, ссылку не дал, статья абсолютно не про то. я бы понял аналогию фортран и ассемблер, но это совсем из другой жизни.
ГМ>>>IMHO, лучше таки-да решить задачу, чем отказаться ее рашать вообще из-за опасений возможной непереносимости решения.
СМ>>ИМHO тут ТЗ рулит, и если требуется ассемблер, то никто и не спорит, но в 99.999% он не нужен вообще. ГМ>-- ГМ>Обратите внимание, что с самом первом моем сообщении я как раз и призывал не писать на ассемблере, а использовать его тогда, когда он может быть полезным.
ну я не держу в голове все сообщения. сорри.
в общем сошлись, что без веских причин не надо пользоваться ассемблером.
Здравствуйте, Сергей Мухин,
СМ>>>мы говорим о простом С++ и ассемблере а не о специальных машин! Более того в статье НИЧЕГО не сказано пишут ли они на ассемблере! ГМ>>-- ГМ>>Похоже, Вы не поняли аналогии. Ничего страшного в этом нет.
СМ>ничего себе! привел статью, ссылку не дал, статья абсолютно не про то. я бы понял аналогию фортран и ассемблер, но это совсем из другой жизни.
--
Да, виноват. Вот ссылка, которая будет самой первой в списке, выдаваемой google на поиск полного названия статьи.
СМ>в общем сошлись, что без веских причин не надо пользоваться ассемблером.
--
Да, это хороший итог нашей дискуссии.
Более того, это даже косвенно потдверждает и мое предложение таки да изучать язык ассемблера. Ведь если я не знаю языка ассемблера, как же я могу его иногда, как Вы согласились, использовать?
ГМ>Более того, это даже косвенно потдверждает и мое предложение таки да изучать язык ассемблера. Ведь если я не знаю языка ассемблера, как же я могу его иногда, как Вы согласились, использовать?
Здравствуйте, vayerx, Вы писали:
V>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
Я тоже "старой закалки", хоть и не гуру. И лет 10 назад мы с коллегой писали нечто подобное. На ассемблере с использованием MMX регистров. В результате это работало раза в 1.5 быстрее, чем C++ код.
Здравствуйте, Геннадий Майко, Вы писали:
ГМ>К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного
Если решение некоей задачи привязано к ОС Windows (а это сплошь и рядом), то фактически это та же привязка к процессору (не учитывая Itanium, который мало кто видел), Windows == x86/x64
Здравствуйте, Pavel Dvorkin, Вы писали:
СМ>>это порочная логика. всегда можно привести пример, когда что-нибудь так пригодиться, что хоть в петлю лезь. Например. Вчера заглохла моя машина, так быстро схему посмотрел и паяльником починил. Но я предпочитаю не тратить время на изучение схемы машины, вообще что такое электричество, я предпочитаю тратить время на обучению программированию, которое даст мне достаточно денег, что бы вызвать механика.
PD>И кого ты будешь вызывать, если не можешь разобраться, почему падает вызов некой функции, исходников которой у тебя нет ? А между тем, иногда помогвет элементарная трассировка входа в функцию, после чего становится ясно, что ты ей банально передал что-то не то.
даже не смешно. я (уверен и ты тоже) всё время вызываю ф-ии, исходников которых у меня нет: strcpy, CreateFile и тп
Здравствуйте, Pavel Dvorkin, Вы писали:
V>>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
PD>Я тоже "старой закалки", хоть и не гуру. И лет 10 назад мы с коллегой писали нечто подобное. На ассемблере с использованием MMX регистров. В результате это работало раза в 1.5 быстрее, чем C++ код.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Геннадий Майко, Вы писали:
ГМ>>К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного
PD>Если решение некоей задачи привязано к ОС Windows (а это сплошь и рядом), то фактически это та же привязка к процессору (не учитывая Itanium, который мало кто видел), Windows == x86/x64
ну ну, а Windows CE (или как ее там сейчас называют) и тп — ни у кого уже нет в кармане?
Здравствуйте, vayerx, Вы писали:
V>Для проверки оптимизации — безусловно. Но для написания кода в 90% случаев — моветон, если имеются в виду PC-игры. V>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
Видимо не такой уж он гуру.
Потому как обычно результат получается как раз наоборот описанному, если руки ровные и голова со знаниями.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Геннадий Майко, Вы писали:
ГМ>>К таким ситуациям я отношусь прагматично. Если решение конкретной инженерной задачи оказывается намертво привязанной к конкретному процессору, я не вижу здесь ничего страшного
PD>Если решение некоей задачи привязано к ОС Windows (а это сплошь и рядом), то фактически это та же привязка к процессору (не учитывая Itanium, который мало кто видел), Windows == x86/x64
Не совсем. Вот Win2003 работает начиная с Celeron 300A (гарантированно — было у меня такое железо)
Между прочим PII и Core 2 Duo очень сильно отличаются. И асм код, который написан для C2D на PII работать не будет вообще, а асм код для PII на C2D может работать далеко не оптимально.
Так что разброс есть даже в архитектуре + набор команд сильно расширился
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vayerx, Вы писали:
V>>Для проверки оптимизации — безусловно. Но для написания кода в 90% случаев — моветон, если имеются в виду PC-игры. V>>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20. CC>Видимо не такой уж он гуру. CC>Потому как обычно результат получается как раз наоборот описанному, если руки ровные и голова со знаниями.
Для того, чтобы получилось наоборот, нужно потратить довольно много времени на рассчет множества вариантов использования процессорных юнитов, кратности развернутых циклов и т.п. При этом при переходе на другой процессор операцию нужно повторять. Многолетняя практика показывает, что нередко даже во вроде бы хорошо отпрофилированных и оптимизорованных программах можно в одних местах пожертвовать частью производительности, компенсировав ее в других местах.
Кроме того, если речь идет о "функции из 20 инструкций", то проблем с отладкой, как правило, не возникает. А если речь идет о модуле со сложной матричной математикой, которая к тому же время от времени переписывается?
Здравствуйте, CreatorCray, Вы писали:
CC>Даже используя Intel C++ 10.1 кое какой код пришлось написать руками на асме после изучения того, что нагенерил компилер. Правда надо признать что этих функций на весь проект всего около пяти, и каждая не превышает 20 асм команд. CC>Разница в скорости 20-23%
На небольших линейных фунциях действительно иногда можно что-то вытянуть, хотя 20-23% — многовато. Можеь это было связанно со спецификой вызывющих функций?
Разумеется, компиляторы несовершенны и пока, в отличие от людей, не умеют учиться на своих ошибках. Тем нее менее, в оптимизации они ошибаются все реже и реже. Думаю, сейчас уже сейчас компиляторы статистически реже выбирают неоптимальное решение, чем люди.
Здравствуйте, vayerx, Вы писали:
V>На небольших линейных фунциях действительно иногда можно что-то вытянуть, хотя 20-23% — многовато. Можеь это было связанно со спецификой вызывющих функций? V>Разумеется, компиляторы несовершенны и пока, в отличие от людей, не умеют учиться на своих ошибках.
умеют! MS перегенерит программу после профилирования автоматически.
V>Тем нее менее, в оптимизации они ошибаются все реже и реже. Думаю, сейчас уже сейчас компиляторы статистически реже выбирают неоптимальное решение, чем люди.
Здравствуйте, vayerx, Вы писали:
V>Для того, чтобы получилось наоборот, нужно потратить довольно много времени на рассчет множества вариантов использования процессорных юнитов, кратности развернутых циклов и т.п. При этом при переходе на другой процессор операцию нужно повторять. Многолетняя практика показывает, что нередко даже во вроде бы хорошо отпрофилированных и оптимизорованных программах можно в одних местах пожертвовать частью производительности, компенсировав ее в других местах.
Не всегда
Иногда на асме переписывают только потому, что либо язык не позволяет без лишних преобразований данных выразить то, что надо сделать, либо компилятор генерирует не совсем оптимальный код опять таки из-за ограничений языка.
V>Кроме того, если речь идет о "функции из 20 инструкций", то проблем с отладкой, как правило, не возникает. А если речь идет о модуле со сложной матричной математикой, которая к тому же время от времени переписывается?
А никто целиком модуль на асме не пишет. Пишут обычно "кирпичики", из которых уже на более высокоуровневом языке строят остальное.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, vayerx, Вы писали:
V>>Разумеется, компиляторы несовершенны и пока, в отличие от людей, не умеют учиться на своих ошибках. СМ>умеют! MS перегенерит программу после профилирования автоматически.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vayerx, Вы писали:
CC>Иногда на асме переписывают только потому, что либо язык не позволяет без лишних преобразований данных выразить то, что надо сделать, либо компилятор генерирует не совсем оптимальный код опять таки из-за ограничений языка.
Это верно. Но на моей практике серьезных потерь из-за ограничений языка не было — большинство ограничений языка закрываются интринсиками.
V>>Кроме того, если речь идет о "функции из 20 инструкций", то проблем с отладкой, как правило, не возникает. А если речь идет о модуле со сложной матричной математикой, которая к тому же время от времени переписывается? CC>А никто целиком модуль на асме не пишет. Пишут обычно "кирпичики", из которых уже на более высокоуровневом языке строят остальное.
На кирпичиках нередко можно потерять больше, чем выиграть за счет перехода на ассемблер. У компилятора остается меньше возможностей для оптимизации, к примеру, вложенных циклов, если часть используемого во внешем цикле кода написанна на ассемблере. Нет, я вовсе не имею в виду, что если что-то переписывать, то непременно всю функцию целиком. Но иногда такое переписывание не приносит пользы либо она значительно меньше, чем могла бы быть. Разумеется, верно и обратное — компилятору иногда не хватает регистров и нужно реструктурировать вычисления, декомпозировать и т.д.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>это порочная логика. всегда можно привести пример, когда что-нибудь так пригодиться, что хоть в петлю лезь. Например. Вчера заглохла моя машина, так быстро схему посмотрел и паяльником починил. Но я предпочитаю не тратить время на изучение схемы машины, вообще что такое электричество, я предпочитаю тратить время на обучению программированию, которое даст мне достаточно денег, что бы вызвать механика.
Вообще-то изучение ассемблера и есть изучение программирования, так что может сразу на 2х механников хватить...
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Сергей Мухин, Вы писали:
СМ>даже не смешно. я (уверен и ты тоже) всё время вызываю ф-ии, исходников которых у меня нет: strcpy, CreateFile и тп
СМ>И чем мне поможет в этом ассемблер?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>даже не смешно. я (уверен и ты тоже) всё время вызываю ф-ии, исходников которых у меня нет: strcpy, CreateFile и тп
СМ>>И чем мне поможет в этом ассемблер?
PD>Вызови strcpy с NULL и поймешь.
это ответ в мою пользу. Такая ошибка легко ищется простым отладчиком, без знания ассемблера!
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>программирование = структуры данных + алгоритмы
GN>Это у Вирта
СМ>>Где тут ассемблер?
GN>А где тут C++?
Да нет тут С++! Раз у Вирта — не может быть никакого С++. Только Паскаль и Модула могут быть. Ну еще Оберон.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Сергей Мухин, Вы писали:
СМ>>это ответ в мою пользу. Такая ошибка легко ищется простым отладчиком, без знания ассемблера!
PD>При условии, что ты знаешь, что strcpy нельзя вызывать с NULL. А (допустим) я не знаю. В документации, кстати, об этом ничего не написано
ну уж не написано. Написано что можно строку. NULL не строка.
strDestination
Destination string.
strSource
Null-terminated source string.
PD>Но в действительности все гораздо серьезнее. Из личного опыта — находил у моих студентов таким образом несогласование calling conventions.
1. Ни в коей мере не сомневаясь в Ваших преподавательских способностях, я бы не стал искать ошибки у студентов (их много- я один), если программа не работает — незачет.
2. надо стараться так сделать , разные .h файлы, опции и тп. — незачет два раза
3. при нормальных опциях MSVC ловит многие не стыковки calling conventions.
.
Здравствуйте, CreatorCray, Вы писали:
CC>Не совсем. Вот Win2003 работает начиная с Celeron 300A (гарантированно — было у меня такое железо)
Не пробовал. И на какой памяти ?
CC>Между прочим PII и Core 2 Duo очень сильно отличаются. И асм код, который написан для C2D на PII работать не будет вообще, а асм код для PII на C2D может работать далеко не оптимально.
А тут ничего особенного. Никто сверху вниз не обещал совместимости. И код для 386+ гарантированно не будет работать для 286 , а код для Pentium вполне может не работать для 486. Да ладно — код для Pentium MMX не будет работать под простым Pentium, если в нем есть MMX-команды.
CC>Так что разброс есть даже в архитектуре + набор команд сильно расширился
Расширился. Но не сильно (я не говорю про x64 и про расширения типа MMX/SSE/3dNow...)
Здравствуйте, Аноним, Вы писали:
А>Ребята, А>насколько хоророшо C++ программист должен знать Assembler? А>В абстракциях, или знать конкретно все в тонкостях того или иного процессора?
Хояты бы в абстракциях знать очень полезно.
А>Как часто вы используете asm в своей работе?
Мне за 6 лет понадобился только раз, при портировании на sparc, в коде было 50 строчек на асме.
Здравствуйте, Pavel Dvorkin, Вы писали:
CC>>Не совсем. Вот Win2003 работает начиная с Celeron 300A (гарантированно — было у меня такое железо) PD>Не пробовал. И на какой памяти ?
384 Мб
CC>>Так что разброс есть даже в архитектуре + набор команд сильно расширился PD>Расширился. Но не сильно (я не говорю про x64 и про расширения типа MMX/SSE/3dNow...)
Не, надо их учитывать — потому как сейчас они активно используются компиляторами. MMX уже не используется, а вот SSE — так очень даже.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>ну уж не написано. Написано что можно строку. NULL не строка.
Ладно, оставим это. О вкусах не спорят, с ними борются
СМ>1. Ни в коей мере не сомневаясь в Ваших преподавательских способностях, я бы не стал искать ошибки у студентов (их много- я один), если программа не работает — незачет.
Это еще с грехом пополам годится при окончательном приеме программы. Но вот приходит ко мне студент и просит помочь — я что, должен ему сказать — не буду, иди прочь, незачет тебе ? Я для того и преподаватель, чтобы их учить и им помогать. Да, их много, я один, но мне именно за эту работу зарплату платят.
СМ>3. при нормальных опциях MSVC ловит многие не стыковки calling conventions.
Нет, в данном случае ловить не мог. Вызов был функции из DLL, а студент, описав указатель к функции из DLL (она через GetProcAddress вызывалась), забыл __stdcall.
быстрей пригодиться
.
Перекуём баги на фичи!
