Статьи по Assembler
Зачем он нужен, этот ассемблер? - часть 4
В этой статье мы избрали вот какой способ ответа на заглавный вопрос. Возьмем какую-нибудь задачку, достаточно ограниченную, чтобы можно было ее анализировать, но в то же время достаточно серьезную, чтобы можно было наблюдать тенденции. И напишем ее два раза - на ассемблере и на C++. При этом не станем применять никаких специфических для того и для другого языка приемов, чтобы сохранить сравнимость результатов. И посмотрим, какие выводы из этого можно сделать.
Итак, приложение называется MyCall и представляет собой простейший пользовательский интерфейс для Remote Access Service, то есть звонилку. Реализовано на C++ и на ассемблере. Имеются исходные тексты:
Вариант на C++:
Вариант на ассемблере:
Общие для обоих вариантов:
Начнем сравнение с трудозатрат программиста. Непосредственно сравнить время разработки не представляется возможным, так как порядок разработки был такой: сначала была написана реализация на C++, а затем, пользуясь уже отработанными решениями - на ассемблере. Можно отметить только субъективное ощущение, что на ассемблере приложение писалось бы несколько дольше, процентов на 20.
Зато можно сравнить объективные показатели.
Объем исходного текста на C++ - 14 Кбайт, на ассемблере - 17,5 Кбайта. Во втором случае пришлось сделать почти на 20% больше ударов по клавишам. Туннельного синдрома, конечно, не заполучил, но ведь и приложеньице-то масенькое.
Число строк исходного текста на C++ - 384, на ассемблере - 693. Почти в два раза больше приходится скроллить листинг вверх-вниз.
Кроме того, для реализации на ассемблере пришлось тратить время на составление файла системных заголовков windows.inc.
В целом можно сделать вывод, что общие трудозатраты на разработку небольшого приложения в хаотическом стиле на ассемблере на 20-30% больше, чем на C/C++. Что касается больших проектов, то все зависит от того, насколько правильно будет организована работа и насколько принимаемые технические решения будут соответствовать задаче. То, что для C++ и для ассемблера эти решения будут разными - очевидно, поэтому заранее трудно сказать, какие из них ускорят разработку, а какие замедлят. Можно ведь и со всей мощью ООП утонуть в соблюдении формальных правил стиля, диктуемого языком, а можно и в изначально хаотическом языке найти такие приемы, которые дадут многократный прирост производительности труда. Тем более что в среде Windows объектно-ориентированное программирование становится вполне доступным ассемблеру (например, COM. Недавно в одной из конференций прозвучало мнение, что с COM работать на ассемблере проще, чем на C++. Спорно, но поспорить есть о чем.). Но a priori следует ожидать, что разработка проекта на C++ будет несколько менее трудоемка, чем на ассемблере.
