Як довго і яка складність була б залучена до того, щоб Кріс Сойєр писав більшість магнатів з гірки в асемблері?

У цього питання у мене є ще одне питання про те,
як довго і яка складність була б причетною до того, щоб Кріс Сойєр писав більшість магнатів з гірки в асемблері?

Для того, щоб уточнити та розбити це питання, мене цікавить;

1. Приблизно, скільки годин людини (гадаєте), на вашу думку, Крису знадобилося б, щоб написати гру самостійно? Або вкажіть приблизний відсоток від співвідношення годин кодування асемблера, щоб сказати, записуючи все на C / C ++.

2. Чи добре програмісти, які знають асемблер, вважають це надмірно складним завданням для такої мовної абстракції низького рівня? Окрім переваг від продуктивності, це просто химерні природні здібності, якими володіє Кріс, або набір навичок, гідних навчатися в цій мірі? Мене цікавить, якщо люди думають, що складність / продуктивність варто добре вивчити асемблер (для того, щоб писати), чи це "лише того варте", якщо у вас є багато природньо розвинених навичок асемблера (імовірно, від роботи з обладнанням / драйвери обладнання / електроніка / тощо).

З читання його грубої біографії це виглядає як два роки (з початку 1997 року до кінця 1998 року). Зважаючи на те, що він, здається, є людиною "один за одним", а набір інструментів та часові рамки не є великими для "розвитку команди", я б вважав, що це 24 програми-місяці.

На той момент він був професійним програмістом ігор, який працював у складанні з 1983 року, тому я не прирівнював би "два роки Кріса" до "два мені роки" роботи.

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

• Чудовий програміст на 10 разів продуктивніший, ніж хороший програміст
• Програміст важливіший, ніж мова, для продуктивності

Отже, у цьому випадку, наскільки швидше було б записати гірку, що Крис використовував C або Java або Javascript або ...? Напевно, це не мало б значення, крім того, що він, можливо, був трохи повільніше, використовуючи мову вищого рівня, з якою не мав 14 років досвіду роботи ...

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

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

Все-таки я б не зміг це зробити! Я здригаюся думати про спробу ініціалізувати DirectX безпосередньо в зборі! ( Редагувати: Вікіпедія говорить мені, що він написав деякі частини на C для "інтерфейсу з операційною системою Windows", тому я гадаю, що тоді він не ініціалізував DirectX в зборах ... феу!)

Ще одна людина, відома тим, що написала багато програм Windows в асемблері, - Стів Гібсон, автор SpinRite, ShieldsUp! та інші комунальні послуги. Він обговорює його любов до асемблеру тут .

У Ренді Хайда (якого я раніше знав, коли ми писали 6502 код складання для Apple II) з'явилася нова онлайн-книга під назвою Windows програмування мовою складання . Він є великим прихильником використання фантазійних макросів (включаючи циклічні конструкції), щоб зробити програмування монтажу більше схожим на використання мови високого рівня. Сойєр, ймовірно, використовував подібний підхід, щоб бути більш продуктивним.