Здравствуйте, vayerx, Вы писали:
V>Для проверки оптимизации — безусловно. Но для написания кода в 90% случаев — моветон, если имеются в виду PC-игры. V>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
Видимо не такой уж он гуру.
Потому как обычно результат получается как раз наоборот описанному, если руки ровные и голова со знаниями.
Здравствуйте, Сергей Мухин, Вы писали:
СМ>Здравствуйте, Pavel Dvorkin, Вы писали:
V>>>Был у меня один коллега "старой закалки", гуру. За пару недель он написал на ассемблере функцию, вручную развернул все циклы, использование всех юнитов рассчитал, кэш учел. Эта же функция на с++ (с использованием интринсиков, разумеется) работала с такой же скоростью, а после добавления платформенно-специфичных прагм, даже быстре процентов на 20.
PD>>Я тоже "старой закалки", хоть и не гуру. И лет 10 назад мы с коллегой писали нечто подобное. На ассемблере с использованием MMX регистров. В результате это работало раза в 1.5 быстрее, чем C++ код.
СМ>а сколько потратили времени?
СМ>а проверить скорость на современных компиляторах?
Даже используя Intel C++ 10.1 кое какой код пришлось написать руками на асме после изучения того, что нагенерил компилер. Правда надо признать что этих функций на весь проект всего около пяти, и каждая не превышает 20 асм команд.
Разница в скорости 20-23%
Здравствуйте, 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>А никто целиком модуль на асме не пишет. Пишут обычно "кирпичики", из которых уже на более высокоуровневом языке строят остальное.
На кирпичиках нередко можно потерять больше, чем выиграть за счет перехода на ассемблер. У компилятора остается меньше возможностей для оптимизации, к примеру, вложенных циклов, если часть используемого во внешем цикле кода написанна на ассемблере. Нет, я вовсе не имею в виду, что если что-то переписывать, то непременно всю функцию целиком. Но иногда такое переписывание не приносит пользы либо она значительно меньше, чем могла бы быть. Разумеется, верно и обратное — компилятору иногда не хватает регистров и нужно реструктурировать вычисления, декомпозировать и т.д.
Здравствуйте, vayerx, Вы писали:
СМ>>умеют! MS перегенерит программу после профилирования автоматически.
V>Согласитесь, это не то же самое, что самообучение
Здравствуйте, Сергей Мухин, Вы писали:
СМ>это порочная логика. всегда можно привести пример, когда что-нибудь так пригодиться, что хоть в петлю лезь. Например. Вчера заглохла моя машина, так быстро схему посмотрел и паяльником починил. Но я предпочитаю не тратить время на изучение схемы машины, вообще что такое электричество, я предпочитаю тратить время на обучению программированию, которое даст мне достаточно денег, что бы вызвать механика.
Вообще-то изучение ассемблера и есть изучение программирования, так что может сразу на 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
Здравствуйте, Сергей Мухин, Вы писали:
СМ>программирование = структуры данных + алгоритмы
Это у Вирта
СМ>Где тут ассемблер?
А где тут 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
Здравствуйте, Сергей Мухин, Вы писали:
СМ>даже не смешно. я (уверен и ты тоже) всё время вызываю ф-ии, исходников которых у меня нет: 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.
.
