Если это ваш первый визит, рекомендуем почитать справку по форуму. Для размещения своих сообщений необходимо зарегистрироваться. Для просмотра сообщений выберите раздел. |
Ассемблер. Рациональность использования и вопросы. |
Философия, технологии, алгоритмы! |
|
Опции темы |
31.01.2012, 09:58 | #1 |
IGBT
Сообщений: 535
Регистрация: 09.10.2005
Не в сети |
Ассемблер. Рациональность использования и вопросы.
Spectator:
Это ветка соседней темы. Общая постановка вопроса: Насколько рационально сегодня знать / использовать ассемблер. Плюс в теме имеет смысл задавать и обсуждать возникающие вопросы по ассемблеру, коли такие появятся. Просто низкоуровневое программирование сейчас мало востребовано. Надо куда-то 8 ядер, ведра кеша и кучу оперативки девать. При этом задачи, должны быть сделаны вчера и выгрызать по такту у процессора, нахрен никому не надо. В конкретной задаче atmega32 у нее, насколько я помню нет умножения и деления, только сдвиги, сложения, вычитания. Я на ней диплом делал, управление асинхронным двигателем, намучился я с ней. Сейчас на работе у меня контроллеры все с ФАПЧ. Они тупо разгоняются. У ARM вобще 72 Мгц, куча каналов DMA, можно часть операций с памятью и периферией, как жесткую логику настроить. Все удовольствие стоит 100-200 р. Для действительно критичных ко времени выполнения операций, используется DSP ядро, преобразования Фурье, умножение с накоплением, все в железе сделано. Обращаюсь к этому через библиотечку на Сях, любезно предоставленную производителем. Ни грамма ассемблерного кода, при желании на другой контроллер переносится, переписыванием hal слоя. Таково положение дел сегодня. Это не плохо и не хорошо. Просто надо принять это. Виртуальная машина, поверх процессора, на ней скриптовой движок и через все эти слои будем складывать a+b. Последний раз редактировалось Spectator; 31.01.2012 в 21:25. |
31.01.2012, 10:23 | #2 |
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
Всё верно написал, за исключением только одного момента - низкоуровневое программирование мало востребовано, это факт, и из-за причин, которые ты описал, и не в меньшей степени из-за многократно возросших объемах кода в современных программах, написать на чистом асме движок Half-Life - это лет десять бы заняло)
НО! Надо понимать ассемблерный код, и знать устройство процессора, под который ты программируешь. На случай неведомой фигни или возникновения диких тормозов там где они не предполагались. Чтобы можно было влезть с отладчиком / профайлером и разобраться - что пошло не так. Компилятор/оптимизатор перемудрил, или ты чуть-чуть не влез в критическом цикле в кэш первого / второго уровня и т.д. Для этого нужно понимать архитектуру процессора и знать ассемблер на уровне чтения (я лично его так и знаю, понять что в отладке происходит - спокойно, написать процедурку на чистом асме - с огромным скрипом и матюками с Зубковым в зубах). |
31.01.2012, 12:52 | #3 | |
IGBT
Сообщений: 535
Регистрация: 09.10.2005
Не в сети |
Цитата:
1) Устройство процессора - как часть computer science. Надо знать почти всем. Большинство современных архитектур похожи. Тем более надо знать хотя бы, что такое стек и как вызов метода происходит, даже если на .Net пишешь, чтобы не удивляться, когда при рекурсии получишь StackOverflowException. 2) ассемблер - как язык мнемоники. А нужен ли его действительно знать? Я например, имея весь скромный опыт работы и программерства, писал низкоуровневые программы под x86, 8051, AVR, PIC24, ARM (Cortex M3). И асм я знал только у первых двух архитектур (ибо похожи). Зачем мне знать весь зоопарк мнемоник и регистров состояния? Причем собственно функциональные блоки у всех процессоров похожи. 3) вот правда интересно в какой задаче, кроме спортивного программирования, понадобилось участок переписывать на асме? Или это было в бородатые годы, когда кеши были маленькие, а компьютеры большими? Сейчас в большинстве случаев под x86 достаточно вынести тяжелые вычисления в отдельный поток и приделать прогресс бар. Или обрабатывать в несколько потоков. |
|
31.01.2012, 17:37 | #5 | ||
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
Цитата:
Речь об этом. Цитата:
Спартак, снести флуд в болталку? А то плавно но явно удалились от изначального вопроса. |
||
31.01.2012, 21:05 | #7 |
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
Сравнил задницу с пальцем.
Судоку гораздо сложнее чем саперы и пасьянсы. http://lenta.ru/news/2012/01/09/sudoku/ Как следствие, перебор удалось свести к чуть менее чем 5,5 миллиарда вариантам (всего правильных вариантов заполнения судоку порядка 1021). Эти вычисления, которым предшествовало двухлетнее тестирование алгоритма, были проделаны на суперкомпьютере. В результате ученые установили, что 16 подсказок (или меньше) недостаточно для того, чтобы "убить" все плохие множества, поэтому придумать головоломку с таким количеством подсказок и однозначным решением невозможно. Если непонятно - 1021 миллиард вариантов. Прикладная задача, которую решал я - генерация судоку, она делается оптимизированным перебором, каждый вариант необходимо проверить на то что решение уникально. При определенных параметрах (количество изначально данных чисел и сложности), простейший, написанный в лоб алгоритм, будет работать сутками. Казалось бы - при чем тут сапер? Асм сейчас точно выпилю в отдельную тему. Уже хотя бы потому что срачи возникают постоянно. |
31.01.2012, 22:10 | #8 | |
Форумец
Сообщений: 2,014
Регистрация: 06.10.2011
Возраст: 31
Не в сети |
Цитата:
|
|
31.01.2012, 22:13 | #9 |
Registered User
Сообщений: 402
Регистрация: 14.11.2007
Возраст: 38
Не в сети |
одна сторона утверждает, что асм не нужен ввиду того, что уже есть достаточное количество библиотек; другая, напротив, утверждает его важность!!!
я за необходимость по следующим причинам: 1. это жёсткая алКоритмизация. 2. Отладка кода. 3. простота до нельзя! внедрите опрос!!! |
31.01.2012, 22:19 | #10 | |
highly mean
Сообщений: 1,128
Регистрация: 26.05.2011
Возраст: 35
Не в сети |
Цитата:
Кто эта сторона? o_O |
|
31.01.2012, 23:11 | #13 |
Форумец
Сообщений: 2,014
Регистрация: 06.10.2011
Возраст: 31
Не в сети |
silly, а что вам именно интересно?
|
31.01.2012, 23:49 | #15 |
Форумец
Сообщений: 2,014
Регистрация: 06.10.2011
Возраст: 31
Не в сети |
silly, как бы сказать. Я новичёк который незнает в какую область податся, вот и занимается всякой хренью. Так ясно? Обычно не вырезаю, а делаю через dumpbin /exports и lib.exe статическую и потом офсетами, и char *...
|
01.02.2012, 00:00 | #17 |
highly mean
Сообщений: 1,128
Регистрация: 26.05.2011
Возраст: 35
Не в сети |
Э… Как вот здесь http://sandsprite.com/CodeStuff/Usin..._as_a_dll.html? (Моя так не умеет, однако.) Нет, правда, где это на практике можно использовать?
|
01.02.2012, 00:39 | #18 |
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
В сотни раз быстрее стало. Пойми, дело не в использовании ассемблера как в таковом, а в низкоуровневой оптимизации, использовании особенностей процессора. Если у тебя внутри цикла используются только регистры и если у тебя внутри цикла постоянно дергают внешнюю к процессору память - разница будет коллосальная. Если не выходишь за рамки кэша инструкций (грубо говоря - если тело цикла без вызовов умещается в определенный объем памяти, и весьма небольшой) - это одно, если выходишь - совсем другое. Проконтролировать это на языке высокого уровня ПРОСТО НЕВОЗМОЖНО. Принципиально.
|
01.02.2012, 10:33 | #21 |
Registered User
Сообщений: 1,114
Регистрация: 23.06.2007
Возраст: 57
Не в сети |
|
01.02.2012, 11:02 | #23 |
IGBT
Сообщений: 535
Регистрация: 09.10.2005
Не в сети |
Не у сферических архитектур, а конкретно у AVR, PIC24, Cortex M3 (Thumb v2) отличаются мнемоники branch и data transfer, на мой взгляд неспециалиста, сильно отличаются. А компилятор в большинстве случаев "лажает" именно в этих местах. Хотя мне трудно представить, как "слажает" компилятор продуцируя код на RISC процессор, где все достаточно однозначно. с А чтобы реально понять, что он "слажал", нужно достаточно плотно погрузиться в документацию на ассемблер. А это время и денежки. А проблема может быть в другом месте. Возникали проблемы недостаточной скорости на контроллерах, проблема была не в компиляторе, а в кривых руках. Все оптимизировалось алгоритмически и получался хорошо структурированный и читабельный Си код.
|
01.02.2012, 11:26 | #24 |
Registered User
Сообщений: 1,114
Регистрация: 23.06.2007
Возраст: 57
Не в сети |
Скорее всего имелось ввиду это:
Рекомендуемые опции для конкретных процессоров |
01.02.2012, 11:48 | #25 |
старый хрыч
Сообщений: 6,705
Регистрация: 17.12.2006
Возраст: 37
Не в сети |
именно. Интел оперативно выпускают новые версии компиляторов с учетом особенностей архитектуры новых процессоров
|
01.02.2012, 13:07 | #26 | ||
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
Цитата:
Цитата:
Я, допустим, в критических циклах всегда пытаюсь добиться чтобы по максимуму использовались регистры, вернее наоборот - по минимуму использовался стек. Чтобы понять что линейный (последовательный) обход массива всё же не стоит делать через индекс там, где нужна скорость, стоит посмотреть на то к каким командам это в результате приводит. И в итоге там где можно я всегда избегаю ассемблерных вставок, поскольку отлаживать и править их - та еще "радость", где не выходит компилятор убедить чтобы он сделал по моему))), там приходится делать вставки. |
||
01.02.2012, 17:07 | #28 |
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
Имеет смысл цитировать сообщения, на которые отвечаешь. Для этого используется кнопка "Цитата" под постом (сообщением), после чего оставляем необходимый минимум, чтобы было понятно на что отвечаешь и пишешь ответ.
|
01.02.2012, 17:34 | #29 |
IGBT
Сообщений: 535
Регистрация: 09.10.2005
Не в сети |
В конечном счете знания АСМа в 21 веке нужны:
1) вирусы, реверс-инжиниринг 2) оптимизация тяжелой математики (веторные инструкции и прочее, что не потянул компилятор). Хотя можно кое-что и на видюхе посчитать, если решение не будет сильно тиражироваться. 3) спортивная оптимизация программ (доказывать, что человек умнее тупой машины). У меня i7 дома L1-64Kb,L2-1024Kb,L3-8192Kb. Че куда невлезет? 4) низкоуровневое программирование: драйвера, ядра ос и прочее. Хотя многое можно без асма и на Сях сделать |
01.02.2012, 18:14 | #30 |
Форумец
Сообщений: 40,958
Регистрация: 27.05.2003
Возраст: 46
Не в сети |
1) безусловно
2) Почему только математика? Переборные алгоритмы, шифрация/дешифрация, аудио-видео кодеки, игры и т.д. 3) Кэш - совсем не панацея. Его еще неплохо бы уметь правильно использовать для этого знание ассемблера тоже не помешает. 4) Совершенно верно, такие вещи обычно пишут на чистом C (не C++) 5) (от меня уже) Самое важное - знания АСМа нужны для того чтобы понимать как работает то что ты делаешь, и во что выльется твой код. 6) Для того чтобы эффективно оптимизировать программы как на языке высокого уровня так и непосредственно на ассемблере. 7) Исправление ошибок из ряда "это ДОЛЖНО работать, какого хрена?" Кстати, вспомнил еще об одном применении, в список не буду включать, бо довольно специфичное. Когда я писал оболочку для винды, у меня задача была чтобы всё было очень красиво и динамично, чтобы она выдвигалась плавно, а не резко как обычная виндовая, и всякие такие красивые прибамбасы. Но при этом эта штука не должна была жрать процессор. Поскольку по сути это - погремушка, кому она нужна, если будет отнимать 10% процессорного времени в ущерб, скажем, компилятора, игры и пр. Я стал исследовать внутренности частовызываемых виндовых функций и с удивлением обнаружил что многие, даже очень небольшие, фунции являются заглушками (stub) для других, большая часть из которых недокументирована. В некоторых были предварительные проверки параметров, в некоторых нет. Я заменил вызовы на прямые, возможно некоторые из этих stub'были нужны для совместимости с прошыми / будущими версиями винды, но у меня проект изначально был жестко заточен на конкретную операционку. После этого программа заработала заметно быстрее, в плане того что стала меньше грузить процессор, больше 1% не было даже на "самых крутых поворотах" (вполне реально, там даже окон не было, вся отрисовка на DirectDraw). Хотя собственно ассемблерных вставок там ЕМНИП и не было. Таким образом добавляется еще один пункт, отдельный: 8) Реверсинжиниринг операционки с целью оптимизации программы |