В прошлой Компьютерре, Зверек Харьковский решивший подписаться серьезным наследственным ником Виктор Шепелев, опубликовал три любопытных (спасибо!) статьи на тему своего любимого конька - истории IT. После прочтения одной из них - "Археология исходников", появилось желание сказать несколько слов в догонку, для более полного раскрытия темы.
Сама статья посвящена исходникам, изучение/переработку которых можно смело относить к разряду археологических работ. Основной пойнт статьи, что лучший способ знакомства с кодом - это его "деятельное чтение" (чтение, в самом широком смысле) / отладка / использование / переписывание (практически в любом виде). Ближе к концу статьи делается оговорка, что это не всегда возможно по ряду причин (отсутствует нужная ОС/версия языка/библиотека и т.д. ) и конечно, не написано, что на самом деле наступает полный ёк - что делать с таким кодом не очень-то и понятно.
Как раз для последнего случая (и несколько в пику теории об "деятельном чтении") есть замечательный пример из жизни (не моей :) ). Автор рассказа, Лупин Сергей Андреевич - зам декана факультета Микроприборов и Технической Кибернетики МИЭТ (все что ниже приводится с его слов, по памяти).
Здесь потребуется сделать небольшое отступление - сказать пару слов о предмете археологических раскопок - ЦВМ (цифровая вычислительная машина) очистных сооружений на зеленоградском водоканале. Сами очистные сооружения, очевидно, были построены в первые года-десятилетия после основания города и выгодно отличаются качеством от массы других очистных сооружений в xUSSR. Город активно рос в 90-е и постепенно водоканал начал сталкиваться с прогибами производительности системы - ЦВМ слишком долго обрабатывала данные одного из техпроцессов. Я нарочно пишу ЦВМ, потому как в те лохматые годы еще не существовало рынка микропроцессоров, таким как мы его знаем сегодня и проектирование каждой вычислительной машины было своей отдельной задачей. Линус Торвальдс считающий, что настоящие мужчины сами пишут драйвера - наивный чукотский юноша, потому как настоящие мужчины собирают комп самостоятельно и знают его работу целиком, вплоть до функции отдельно взятого триггера :)
Собственно, с машиной собранной настоящими мужчинами и пришлось столкнуться Лупину. Отдельной строкой требуется сказать о документации для этого хозяйства. Общий объем документов описывающий архитектуру, приемы работы, сопряжение с периферией интерфейсы и т.д. составлял ... мм... 100 страниц? 300? 1000? несколько шкафов? - одну замусоленную страничку с системой команд и количеством пожираемых каждой командой тактов. Естественно, ни о каких refactoring tool, IDE, да даже о языках программирования речь идти не может - чистые машинные коды :) (если конечно на папке с бумагой не прилепить надпись IDE, а на ручке refactoring tool - Recoder :) )
"Настоящие мужчины", конечно же, много лет назад вышли на пенсию из давно разорившегося НИИ и даже найти их, а тем более узнать детали реализации проекта - задача совершенно непосильная (да и по-хорошему, ненужная). Собственно апгрейдом такой штуки и предложили заняться нашему зам декана (наверное именно так у человека за день может поседеть шевелюра :) ).
Все что удалось выудить дополнительно (кроме волшебного листочка) - дамп работающей программы.
(О разработке новой системы, понятное дело, даже не заикались - очень дорого)
Вот тут начинается самое интересное с точки зрения археологии - любая ошибка в программе может наглухо лишить город и кучу предприятий воды, соответственно игры с кодом попросту недопустимы. Найти вторую машину для проверки работоспособности переписанной программы невозможно - на планете есть только одна такая машина. Соответственно решение должно быть рабочим сразу и без багов.
Понятно, что при такой постановке вопроса возможности по творческой переработке кода, сведены к минимуму, все что остается делать - внимательнейшим образом читать машинные коды и пытаться понять, в каких командах можно выжать ускорение.
Не буду долго мучать - Лупину повезло (и всем зеленоградцам вместе с ним :) ) - в емком цикле приложения обнаружилось, что для увеличения переменной в два раза почему-то используется дорогая операция умножения, вместо сдвига. Одной такой минимальной замены операций оказалось достаточно, поэтому изменения удалось внести сравнительно быстро и они практически ничего не стоили.
Не знаю, получил ли Лупин за археологические изыскания премию, но чистая вода льется у нас из-под крана до сих пор :)
Сама статья посвящена исходникам, изучение/переработку которых можно смело относить к разряду археологических работ. Основной пойнт статьи, что лучший способ знакомства с кодом - это его "деятельное чтение" (чтение, в самом широком смысле) / отладка / использование / переписывание (практически в любом виде). Ближе к концу статьи делается оговорка, что это не всегда возможно по ряду причин (отсутствует нужная ОС/версия языка/библиотека и т.д. ) и конечно, не написано, что на самом деле наступает полный ёк - что делать с таким кодом не очень-то и понятно.
Как раз для последнего случая (и несколько в пику теории об "деятельном чтении") есть замечательный пример из жизни (не моей :) ). Автор рассказа, Лупин Сергей Андреевич - зам декана факультета Микроприборов и Технической Кибернетики МИЭТ (все что ниже приводится с его слов, по памяти).
Здесь потребуется сделать небольшое отступление - сказать пару слов о предмете археологических раскопок - ЦВМ (цифровая вычислительная машина) очистных сооружений на зеленоградском водоканале. Сами очистные сооружения, очевидно, были построены в первые года-десятилетия после основания города и выгодно отличаются качеством от массы других очистных сооружений в xUSSR. Город активно рос в 90-е и постепенно водоканал начал сталкиваться с прогибами производительности системы - ЦВМ слишком долго обрабатывала данные одного из техпроцессов. Я нарочно пишу ЦВМ, потому как в те лохматые годы еще не существовало рынка микропроцессоров, таким как мы его знаем сегодня и проектирование каждой вычислительной машины было своей отдельной задачей. Линус Торвальдс считающий, что настоящие мужчины сами пишут драйвера - наивный чукотский юноша, потому как настоящие мужчины собирают комп самостоятельно и знают его работу целиком, вплоть до функции отдельно взятого триггера :)
Собственно, с машиной собранной настоящими мужчинами и пришлось столкнуться Лупину. Отдельной строкой требуется сказать о документации для этого хозяйства. Общий объем документов описывающий архитектуру, приемы работы, сопряжение с периферией интерфейсы и т.д. составлял ... мм... 100 страниц? 300? 1000? несколько шкафов? - одну замусоленную страничку с системой команд и количеством пожираемых каждой командой тактов. Естественно, ни о каких refactoring tool, IDE, да даже о языках программирования речь идти не может - чистые машинные коды :) (если конечно на папке с бумагой не прилепить надпись IDE, а на ручке refactoring tool - Recoder :) )
"Настоящие мужчины", конечно же, много лет назад вышли на пенсию из давно разорившегося НИИ и даже найти их, а тем более узнать детали реализации проекта - задача совершенно непосильная (да и по-хорошему, ненужная). Собственно апгрейдом такой штуки и предложили заняться нашему зам декана (наверное именно так у человека за день может поседеть шевелюра :) ).
Все что удалось выудить дополнительно (кроме волшебного листочка) - дамп работающей программы.
(О разработке новой системы, понятное дело, даже не заикались - очень дорого)
Вот тут начинается самое интересное с точки зрения археологии - любая ошибка в программе может наглухо лишить город и кучу предприятий воды, соответственно игры с кодом попросту недопустимы. Найти вторую машину для проверки работоспособности переписанной программы невозможно - на планете есть только одна такая машина. Соответственно решение должно быть рабочим сразу и без багов.
Понятно, что при такой постановке вопроса возможности по творческой переработке кода, сведены к минимуму, все что остается делать - внимательнейшим образом читать машинные коды и пытаться понять, в каких командах можно выжать ускорение.
Не буду долго мучать - Лупину повезло (и всем зеленоградцам вместе с ним :) ) - в емком цикле приложения обнаружилось, что для увеличения переменной в два раза почему-то используется дорогая операция умножения, вместо сдвига. Одной такой минимальной замены операций оказалось достаточно, поэтому изменения удалось внести сравнительно быстро и они практически ничего не стоили.
Не знаю, получил ли Лупин за археологические изыскания премию, но чистая вода льется у нас из-под крана до сих пор :)
