Чому ви програмуєте в збірці? [зачинено]

У мене є запитання до всіх жорстких хакерів низького рівня. Я натрапив на це речення в блозі. Я насправді не думаю, що джерело має значення (це Haack, якщо вам дійсно все одно), оскільки це, здається, загальне твердження.

Наприклад, у багатьох сучасних тривимірних іграх є основний двигун високої продуктивності, написаний на C ++ та в зборі.

Що стосується збірки - чи написаний код у збірці, тому що ви не хочете, щоб компілятор видавав зайві інструкції або використовував надмірну кількість байтів, або ви використовуєте кращі алгоритми, які ви не можете виразити на мові C (або не можете виразити без компілятор їх обговорює)?

Я цілком розумію, що важливо розуміти речі низького рівня. Я просто хочу зрозуміти, чому програма в збірці після того, як ви це зрозумієте.

Я думаю, ви неправильно читаєте це твердження:

Наприклад, у багатьох сучасних тривимірних іграх є основний двигун високої продуктивності, написаний на C ++ та в зборі.

Ігри (і більшість програм в наші дні) не "написані в збірці" так само, як "написані на C ++". Цей блог не говорить про те, що значна частина гри розроблена в збірці, або що команда програмістів сидить і розвивається в збірці як їх основна мова.

Це насправді означає, що розробники спочатку пишуть гру і запускають її в роботі на C ++. Потім вони профілюють це, з’ясовують, які вузькі місця є, і якщо це варто, вони оптимізують їх у зборі. Або, якщо вони вже мають досвід, вони знають, які частини стануть вузькими місцями, і у них є оптимізовані шматки з інших створених ними ігор.

Точка програмування в зборі так само , як це завжди було: швидкість . Було б смішно писати багато коду в ассемблері, але є деякі оптимізації, про які компілятор не знає, і для досить малого вікна коду людина буде робити краще.

Наприклад, для плаваючої крапки компілятори, як правило, досить консервативні і можуть не знати про деякі вдосконалені можливості вашої архітектури. Якщо ви готові прийняти якусь помилку, як правило, ви можете зробити це краще, ніж компілятор, і варто написати таку трохи коду в збірці, якщо виявите, що на це витрачено багато часу.

Ось ще кілька відповідних прикладів:

Приклади з Ігор

• Стаття від Intel про оптимізацію ігрового движка за допомогою внутрішніх характеристик SSE. Остаточний код використовує властивості (не вбудований асемблер), тому кількість чистого складання дуже мала. Але вони розглядають результати роботи асемблера компілятора, щоб зрозуміти, що саме оптимізувати.

• Швидкий зворотний квадратний корінь Quake . Знову ж таки, в рутині немає асемблера, але вам потрібно щось знати про архітектуру, щоб зробити такий вид оптимізації. Автори знають, які операції швидкі (множення, зсув), а які повільні (ділити, sqrt). Тож вони придумують дуже хитру реалізацію квадратного кореня, яка повністю уникає повільних операцій.

Високопродуктивні обчислення

• Поза сферою ігор люди, які займаються науковими обчисленнями, часто оптимізують безглуздя, щоб швидко працювати на найновішому обладнанні. Подумайте про це як про ігри, де ви не можете обдурити фізику.

  Чудовим недавнім прикладом цього є решітчаста квантова хромодинаміка (гратчаста КХД) . У даній статті описується , як ця проблема в значній мірі зводиться до однієї дуже маленькому обчислювальному ядру, який був оптимізований в великій мірі для PowerPC 440 на з IBM Blue Gene / L . Кожен 440 має два FPU, і вони підтримують деякі спеціальні потрійні операції, які складно використовувати для компіляторів. Без цих оптимізацій Lattice QCD працював би набагато повільніше, що коштує дорого, коли для вашої проблеми потрібні мільйони годин процесора на дорогих машинах.

  Якщо вам цікаво, чому це важливо, перегляньте статтю в Science, яка вийшла з цієї роботи. Використовуючи гратчасту КХД, ці хлопці розрахували масу протона за першими принципами і в минулому році показали, що 90% маси походить від енергії сильного зв’язування сили, а решта - від кварків. Це E = mc ² в дії. Ось короткий зміст .

З огляду на все вищезазначене, програми не розроблені або написані на 100% у збірці - навіть близько. Але коли людям дійсно потрібна швидкість, вони зосереджуються на написанні ключових частин свого коду для використання на конкретному обладнанні.

Я багато років не кодував мовою асемблер, але можу навести кілька причин, які часто бачив:

• Не всі компілятори можуть використовувати певні оптимізації процесора та набір команд (наприклад, нові набори інструкцій, які Intel додає час від часу). Чекати, поки автори компіляторів наздоженуть, означає втратити конкурентну перевагу.

• Простіше підібрати фактичний код до відомої архітектури та оптимізації процесора. Наприклад, речі, які ви знаєте про механізм завантаження, кешування тощо. Це має бути прозорим для розробника, але справа в тому, що це не так, тому автори компіляторів можуть оптимізувати.

• Доступ до певного апаратного рівня можливий / практичний лише за допомогою асемблерної мови (наприклад, під час написання драйвера пристрою).

• Формальні міркування іноді насправді простіші для мови асемблера, ніж для мови високого рівня, оскільки ви вже знаєте, що таке остаточний чи майже остаточний макет коду.

• Програмування певних 3D-графічних карт (приблизно наприкінці 1990-х) за відсутності API часто було більш практичним та ефективним на мові асемблера, а іноді неможливим на інших мовах. Але знову ж таки, це стосувалося справді ігор експертного рівня, заснованих на архітектурі прискорювача, таких як ручне переміщення даних у певний порядок та введення.

Я сумніваюся, що багато людей використовують мову асемблерів, коли мова цього зробить мова більш високого рівня, особливо коли це мова C. Це оптимізація ручної оптимізації великої кількості загального коду недоцільна.

Є один аспект програмування на асемблері, про який інші не згадували - відчуття задоволення, яке ти отримуєш, знаючи, що кожен байт у програмі - це результат твоїх зусиль, а не компілятора. Я ні на секунду не хотів би повертатися до написання цілих програм на асемблері, як це робилося на початку 80-х, але мені часом не вистачає цього відчуття ...

Зазвичай непрофесійна збірка відбувається повільніше, ніж C (через оптимізацію C), але багато ігор (я чітко пам’ятаю Doom ) повинні були мати певні розділи гри в Асамблеї, щоб вона могла нормально працювати на звичайних машинах.

Ось приклад, на який я посилаюся.

Я почав професійне програмування на мові асемблер на першій роботі (80-ті). Для вбудованих систем вимоги до пам'яті - оперативної пам'яті та EPROM - були низькими. Ви можете написати щільний код, який був простий на ресурсах.

Наприкінці 80-х я перейшов на C. Код було простіше писати, налагоджувати та підтримувати. Дуже маленькі фрагменти коду були написані в ассемблері - для мене це було тоді, коли я писав перемикання контексту в самовідданому RTOS. (Те, що ви більше не повинні робити, якщо це не "науковий проект".)

Ви побачите фрагменти асемблера в коді ядра Linux. Зовсім недавно я переглядав його у спінлокках та іншому коді синхронізації. Ці фрагменти коду повинні отримати доступ до атомарних операцій тестування та встановлення, маніпулювання кешами тощо.

Я думаю, що вам важко буде оптимізувати сучасні компілятори C для найбільш загального програмування.

Я погоджуюсь з @altCognito, що ваш час, мабуть, краще витратити, щоб ретельніше подумати про проблему та зробити щось краще. З якоїсь причини програмісти часто зосереджуються на мікроефективності та нехтують макроефективністю. Асемблерна мова для підвищення продуктивності - це мікроефективність. Відступ назад для більш широкого погляду на систему може виявити макропроблеми в системі. Вирішення макропроблем часто може призвести до кращого підвищення продуктивності. Після того, як проблеми з макросом вирішені, згортаються на мікрорівень.

Я думаю, мікро проблеми знаходяться під контролем одного програміста та в меншому домені. Зміна поведінки на макрорівні вимагає спілкування з більшою кількістю людей, чого деякі програмісти уникають. Цей весь ковбой проти командної справи.

"Так". Але, розумійте, що переваги написання коду в асемблері переважно не варті зусиль. Повернення, отримане за написання його в збірці, як правило, менше, ніж просто зосередження уваги на роздумах над проблемою та витрачання часу на роздуми щодо кращого способу виконання знань.

Джон Кармак і Майкл Абраш, які в основному відповідали за написання Quake, і весь високопродуктивний код, який входив в ігрові двигуни ID, детально описують це в цій книзі .

Я б також погодився з Ólafur Waage, що сьогодні компілятори досить розумні і часто використовують багато методів, які використовують переваги прихованих архітектурних посилень.

Сьогодні, принаймні для послідовних кодів, гідний компілятор майже завжди перемагає навіть досвідченого програміста на мові асемблера. Але щодо векторних кодів це інша історія. Широко розгорнуті компілятори не роблять такої чудової роботи, наприклад, використовуючи паралельно-векторні можливості блоку x86 SSE, наприклад. Я розробник компіляторів, і використання SSE очолює мій список причин піти самостійно, а не довіряти компілятору.

Код SSE працює краще у збірці, ніж внутрішні компоненти компілятора, принаймні в MSVC. (тобто не створює зайвих копій даних)

У мене в роботі три-чотири програми асемблера (приблизно у 20 МБ джерела). Усі вони є SSE (2) і пов’язані з операціями над (досить великими - думаю 2400x2048 і більшими) зображеннями.

Для хобі я працюю над компілятором, а там у вас більше асемблера. Бібліотеки середовища виконання їх часто заповнені, більшість із них пов’язані з матеріалами, що не відповідають нормальному процедурному режиму (наприклад, помічники для винятків тощо)

У мене немає асемблера для мого мікроконтролера. Більшість сучасних мікроконтролерів мають настільки периферійне обладнання (контролери переривань, навіть цілі квадратурні кодери та послідовні будівельні блоки), що використання асемблера для оптимізації циклів часто більше не потрібно. При поточних цінах флеш-пам’яті те саме стосується і пам'яті коду. Крім того, часто існує ряд пристроїв, сумісних з висновками, тому збільшення масштабу, якщо у вас систематично закінчується потужність процесора або флеш-пам'яті, часто не є проблемою

Якщо ви дійсно не поставите 100000 пристроїв та асемблер програмування, це зможе по-справжньому значно заощадити, просто помістивши у флеш-чіп категорії меншої категорії. Але я не в цій категорії.

Багато людей вважають, що вбудований привід є виправданням для асемблера, але їх контролери мають більшу потужність процесора, ніж машини, на яких розроблявся Unix . (Мікрочіп постачається з мікроконтролерами 40 і 60 MIPS вартістю до 10 доларів США ).

Однак багато людей застрягли у спадщині, оскільки змінити архітектуру мікрочіпів непросто. Також код HLL дуже залежить від архітектури (оскільки він використовує апаратну периферію, регістри для управління введенням-виведенням тощо). Тому іноді є вагомі причини продовжувати підтримувати проект в асемблері (мені пощастило, що я мав змогу налаштувати справи на новій архітектурі з нуля). Але часто люди жартують, що асемблер їм дійсно потрібен.

Мені все ще подобається відповідь, яку професор дав, коли ми запитали, чи можемо ми використовувати GOTO (але ви можете прочитати це також як ASSEMBLER): "якщо ви вважаєте, що варто написати есе на 3 сторінки про те, навіщо вам потрібна ця функція, ви можете використовувати її Будь ласка, надішліть есе з результатами. "

Я використав це як керівний принцип для функцій низького рівня. Не будьте занадто тісними, щоб ним користуватися, але переконайтесь, що ви мотивуєте це правильно. Навіть підкиньте штучний бар’єр або два (як есе), щоб уникнути заплутаних міркувань як виправдання.

Деякі інструкції / прапори / управління просто відсутні на рівні С.

Наприклад, перевірка переповнення на x86 - це простий прапор переповнення. Цей параметр недоступний на мові C.

Дефекти, як правило, виконуються на кожен рядок (оператор, кодова точка тощо); хоча це правда, що для більшості проблем збірка використовує набагато більше рядків, ніж мови вищого рівня, іноді бувають випадки, коли це найкраще (найбільш стисле, найменше рядків) відображення розглянутої проблеми. Більшість із цих випадків стосуються звичайних підозрюваних, таких як драйвери та розбиття бітів у вбудованих системах.

Інша причина може полягати в тому, що доступний компілятор просто недостатньо хороший для архітектури, і кількість коду, необхідного в програмі, не така довга або складна, як для програміста, щоб загубитися в ній. Спробуйте програмувати мікроконтролер для вбудованої системи, зазвичай складання буде набагато простішим.

Окрім інших згаданих речей, усі вищі мови мають певні обмеження. Ось чому деякі люди вирішують програмувати на ASM, щоб мати повний контроль над своїм кодом.

Інші користуються дуже маленькими виконуваними файлами, в межах 20-60 КБ, наприклад, перевіряють HiEditor , який реалізований автором елемента керування HiEdit, чудового потужного контролю редагування для Windows із підсвічуванням синтаксису та вкладками всього ~ 50 кб). У своїй колекції я маю більше 20 таких золотих елементів керування від Excell, таких як таблиці до HTML-рендерів.

Думаю, багато розробників ігор будуть здивовані такою частиною інформації.

Більшість ігор, я знаю, використовують якомога менше збірок. У деяких випадках взагалі немає, а в гіршому - одна або дві петлі або функції.

Ця цитата надто узагальнена і майже не така правдива, як десять років тому.

Але привіт, лише факти не повинні перешкоджати справжньому хакерському походу на користь зборів. ;)

Якщо ви програмуєте 8-розрядний мікроконтролер низького класу із 128 байтами оперативної пам'яті та 4K програмної пам'яті, у вас немає великого вибору щодо використання збірки. Іноді, хоча при використанні більш потужного мікроконтролера вам потрібна певна дія, яка повинна відбутися в точно визначений час. Тоді мова асемблер є корисною, оскільки ви можете порахувати інструкції і таким чином виміряти тактові цикли, використовувані вашим кодом.

Якби ви були поруч із усіма зусиллями з відновлення Y2K, ви могли б заробити багато грошей, якби знали Асамблею. Навколо все ще існує багато застарілого коду, і цей код час від часу потребує обслуговування.

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

У деяких випадках все, що насправді потрібно, це замінити якусь мовну конструкцію інструкцією, яку не можна очікувати від оптимізатора, щоб зрозуміти, як використовувати. Типовий приклад - у програмах DSP, де оптимізатору важко знайти оптимізатору векторні операції та операції множення-накопичення, але легко передати код.

Наприклад, певні моделі SH4 містять матрицю 4х4 та 4 векторні інструкції. Я побачив значне покращення продуктивності алгоритму кольорової корекції, замінивши еквівалентні операції C на матриці 3x3 на відповідні інструкції, за незначну ціну збільшення матриці корекції до 4x4, щоб відповідати припущенню апаратного забезпечення. Цього було досягнуто шляхом написання не більше десятка рядків збірки та перенесення відповідних коригувань відповідних типів даних та зберігання в кілька місць в оточуючому коді C.

Здається, про це не згадується, тому я подумав додати: у сучасній розробці ігор я думаю, що принаймні частина написаної збірки зовсім не для процесора. Це для графічного процесора, у вигляді шейдерних програм .

Це може знадобитися з різних причин, іноді просто тому, що будь-яка використовувана мова затінення вищого рівня не дозволяє точною операцією бути вираженою в точній кількості потрібних інструкцій, щоб відповідати певним обмеженням розміру, швидкості або будь-якій комбінації . Я думаю, як і зазвичай з програмуванням на асемблерній мові.

Майже кожен середній і великий ігровий движок або бібліотека, які я бачив на сьогоднішній день, має деякі оптимізовані вручну збірні версії, доступні для матричних операцій, таких як конкатенація матриць 4x4. Здається, компілятори неминуче пропускають деякі розумні оптимізації (повторне використання регістрів, розгортання циклів максимально ефективним способом, використання переваг машинних інструкцій тощо) при роботі з великими матрицями. Ці функції маніпуляції матрицею майже завжди є "гарячими точками" у профілі.

Я також бачив, що збірки, кодовані вручну, часто використовуються для власної відправки - такі речі, як FastDelegate, але специфічні для компілятора та машини.

Нарешті, якщо у вас є процедури обслуговування переривань, asm може змінити все у світі - є певні операції, які ви просто не хочете, щоб відбувалися під час переривання, і ви хочете, щоб ваші обробники переривань "швидко входили і виходили". .. ти майже точно знаєш , що відбудеться у твоєму ISR, якщо він у asm, і це заохочує тебе тримати криваві речі короткими (що в будь-якому випадку є хорошою практикою).

Ігри досить голодні, і хоча тим часом оптимізатори досить непогані, "майстер-програміст" все ще може видавити трохи більшої продуктивності, кодуючи вручну потрібні деталі в збірці.

Ніколи не починайте оптимізувати програму, не сформулювавши її спочатку. Після профілювання слід мати можливість виявити вузькі місця, і якщо ви знайдете кращі алгоритми тощо, більше не вирізайте їх, ви можете спробувати вручну кодувати щось у збірці.

Я лише особисто говорив з одним розробником про те, як він використовує збірку. Він працював над прошивкою, яка мала справу з елементами управління портативного mp3-програвача. Виконання робіт у збірці мало 2 цілі:

1. Швидкість: затримки мали бути мінімальними.
2. Вартість: мінімально використовуючи код, апаратне забезпечення, необхідне для його запуску, може бути трохи менш потужним. При масовому випуску мільйонів одиниць це може скластися.

Єдине асемблерне кодування, яке я продовжую робити, це для вбудованого обладнання з мізерними ресурсами. Як згадує leander, збірка все ще добре підходить для ISR , де код повинен бути швидким і добре зрозумілим.

Другорядною причиною для мене є збереження функціональних знань щодо складання. Можливість вивчити та зрозуміти кроки, які робить центральний процесор, щоб виконати мою заявку, просто відчуває себе добре.

Останній раз я писав в ассемблері, коли не зміг переконати компілятор створити код, вільний від позицій, без libc.

Наступного разу, мабуть, буде з тієї ж причини.

Звичайно, раніше у мене були інші причини .

Багато людей люблять зневажати асемблерну мову, тому що вони ніколи не навчилися кодувати її, а лише неясно стикалися з нею, і це їх бентежило або дещо залякувало. Справжні талановиті програмісти зрозуміють, що безглуздо бити C або Асамблею, бо вони безкоштовні. насправді перевага одного - недолік іншого. Організовані синтаксичні правила C покращують чіткість, але в той же час відмовляються від усіх потужностей, що мають агрегат, від звільнення від будь-яких структурних правил! Інструкції з коду С створюються для створення неблокуючого коду, який, як можна стверджувати, змушує чіткість наміру програмування, але це втрата потужності. У C компілятор не дозволить перейти всередину if / elseif / else / end. Або вам заборонено писати два цикли for / end для різних змінних, які перекривають один одного, ви не можете писати самомодифікуючий код (або не можете це зробити безперешкодно) і т.д. . Ось правда: Сьогодні ми маємо машину з обчислювальною потужністю, щоб зробити набагато більше, ніж додаток, для якого ми їх використовуємо, але людський мозок занадто не здатний кодувати їх у вільному від правил середовищі кодування (= складання) і потребує обмежувальних правил, які значно зменшити спектр та спростити кодування. Я сам написав код, який неможливо записати на коді C, не стаючи надзвичайно неефективним через вищезазначені обмеження. І я ще не говорив про швидкість, яка, на думку більшості людей, є основною причиною написання в зборі, добре, якщо ваш розум обмежений мисленням на C, то ви назавжди є рабом вашого компілятора. Я завжди думав, що майстри шахістів будуть ідеальними програмістами збірки, тоді як програмісти C просто грають у "Dames".

Вже не швидкість, а Контроль . Швидкість іноді походить від контролю, але це єдина причина кодування в збірці. Будь-яка інша причина зводиться до контролю (тобто SSE та інша оптимізація рук, драйвери пристроїв та код, що залежить від пристрою тощо).

Якщо я зможу перевершити GCC та Visual C ++ 2008 (відомий також як Visual C ++ 9.0), тоді людям буде цікаво взяти у мене інтерв’ю про те, як це можливо.

Ось чому на даний момент я просто читаю речі в збірці і просто пишу __asm ​​int 3, коли це потрібно.

Сподіваюся, це допоможе ...

Я не писав на зборах кілька років, але дві причини, якими я звик:

• Виклик речі! Кілька місяців тому я пройшов кілька місяців тому, коли писав все у збірці x86 (часи DOS та Windows 3.1). В основному це навчило мене шматку операцій низького рівня, апаратного вводу-виводу тощо.
• Для деяких речей він мав невеликий розмір (знову DOS та Windows 3.1 під час написання TSR )

Я продовжую дивитись на збірку кодування, і це не що інше, як виклик і радість від справи. У мене немає інших причин для цього :-)

Одного разу я взяв на себе проект DSP, який попередній програміст писав переважно в коді збірки, за винятком логіки виявлення тону, яка була написана на мові C, з використанням плаваючої крапки (на DSP з фіксованою крапкою!). Логіка визначення тону працювала приблизно на 1/20 реального часу.

У підсумку я переписав майже все з нуля. Майже все було в C, за винятком деяких невеликих обробників переривань і кількох десятків рядків коду, пов'язаних з обробкою переривань і виявленням низьких частот, що працює більше ніж у 100 разів швидше, ніж старий код.

Думаю, важливо пам’ятати, що в багатьох випадках для збільшення швидкості з невеликими процедурами буде набагато більше можливостей, ніж великими, особливо якщо написаний від руки асемблер вміщує все в регістри, але компілятор не буде цілком вдається. Якщо шлейф достатньо великий, щоб він і так не міг зберігати все в реєстрах, можливостей для вдосконалення значно менше.

Віртуальна машина Dalvik, яка інтерпретує байт-код для програм Java на телефонах Android, використовує асемблер для диспетчера. Цей фільм (приблизно 31 хв., Але варто переглянути весь фільм!) Пояснює, як

"все ще є випадки, коли людина може робити краще, ніж компілятор".

Я не маю, але я вирішив хоча б спробувати і дуже постаратися в якийсь момент у майбутньому (сподіваюся, незабаром). Не може бути поганим, коли я програмую мовою високого рівня, дізнатися більше про речі низького рівня та про те, як все працює за кадром. На жаль, час важко знайти, якщо працювати на повний робочий день розробником / консультантом та батьком. Але я дам у свій час, це точно.