| Предыдущая версия справа и слеваПредыдущая версияСледующая версия | Предыдущая версияСледующая версияСледующая версия справа и слева |
| igor:istoria [2019/04/29 23:42] – [Специализированные и проблемно-ориентированные компьютеры] igor | igor:istoria [2019/04/30 00:07] – [Операционные системы нового времени] igor |
|---|
| Про язык Си часто говорят, что он дает очень быстрый машинный код, значительно более быстрый, чем дают другие языки. Что мы вкладываем в слово "значительно"? На 10%? На 20? Никаких исследований на эту тему никто не поводил. Это миф, который рассказывают и слушают люди, не готовые разобраться в подлинных причинно-следственных связях между явлениями. Язык Си принципиально ничем не отличается от Паскаля и более того - от Алгола. Более быстрый код дает не язык как таковой, а компилятор. Почему? - Элементарно: компилятор Алгола в 50-е годы создавали с нуля, с чистого листа, а компилятор языка С в 70-е годы разрабатывался с опорой на 15-летний опыт эксплуатации Алгола и ПЛ-1 (да и Фортрана тоже). А раз так, то было бы вполне логично ожидать, что он будет на четверть или даже на треть быстрее. \\ | Про язык Си часто говорят, что он дает очень быстрый машинный код, значительно более быстрый, чем дают другие языки. Что мы вкладываем в слово "значительно"? На 10%? На 20? Никаких исследований на эту тему никто не поводил. Это миф, который рассказывают и слушают люди, не готовые разобраться в подлинных причинно-следственных связях между явлениями. Язык Си принципиально ничем не отличается от Паскаля и более того - от Алгола. Более быстрый код дает не язык как таковой, а компилятор. Почему? - Элементарно: компилятор Алгола в 50-е годы создавали с нуля, с чистого листа, а компилятор языка С в 70-е годы разрабатывался с опорой на 15-летний опыт эксплуатации Алгола и ПЛ-1 (да и Фортрана тоже). А раз так, то было бы вполне логично ожидать, что он будет на четверть или даже на треть быстрее. \\ |
| Еще один миф: язык Си якобы приближен к архитектуре компьютера. КАКОГО компьютера? Разных архитектур очень много - к какой из них этот язык ближе всего? И вопрос номер следующий: если Си - язык высокого уровня, то правильно ли __в принципе__ приближать его к архитектуре какого-либо компьютера? По идее, такой язык должен быть абстракцией, которая к разным компьютерам подходила бы в равной степени. \\ | Еще один миф: язык Си якобы приближен к архитектуре компьютера. КАКОГО компьютера? Разных архитектур очень много - к какой из них этот язык ближе всего? И вопрос номер следующий: если Си - язык высокого уровня, то правильно ли __в принципе__ приближать его к архитектуре какого-либо компьютера? По идее, такой язык должен быть абстракцией, которая к разным компьютерам подходила бы в равной степени. \\ |
| | === Статическая и оверлейная линковка === |
| | Выше мы рассмотрели линковщик как новую (в сравнении с древней эпохой) служебную программу, собирающую загрузочный файл из множества объектных файлов, выданных компилятором. В простейшем случае линковщик помещает в загрузочный файл основную программу со всеми нужными подпрограммами - это //статическая линковка//. В средние века наряду со статической была уже освоена //оверлейная линковка//: весь программный код делился на сравнительно небольшой основной загрузочный модуль и несколько оверлейных модулей. При запуске программы на выполнение основной загрузочный модуль загружался в оперативную память, и ему сразу передавалось управление, а оверлейные модули подгружались только тогда, когда нужно было выполнить содержащиеся в них подпрограммы. Разумеется, вопрос о том, какие части программы включить в основной загрузочный модуль и какие в оверлеи, мог решить только программист: "программист решил - линковщик сделал". Оверлейная линковка позволяла (1) уменьшить затраты времени на загрузку программы в оперативную память и (2) эксплуатировать большую и сложную программу на машине с ограниченной емкостью памяти (пусть хотя бы ценой некоторой "задумчивости" при выполнении некоторых операций), но не спасала от того, что разные программы на половину или больше состоят из одних и тех же деталей: каждый оверлейный модуль принадлежал какой-то одной программе. Отсюда вытекает очевидная идея "обобществить" оверлейные модули, но эта идея - более поздняя. Мы ее коснемся в главе "новое время". \\ |
| === Компиляторы и интерпретаторы === | === Компиляторы и интерпретаторы === |
| Мы рассмотрели компиляционную технологию программирования как наследие древнекомпьютерной цивилизации, дожившее с некоторыми изменениями до нашего времени. В 60-е-70-е годы XX века имело место разделение некогда единой технологии программирования на два "рукава": компиляционный и интерпретационный. В 1964 г. был придуман **Бэйсик**, и так вышло, что именно он, а не Паскаль и не Си, стал королем средневековых языков. \\ | Мы рассмотрели компиляционную технологию программирования как наследие древнекомпьютерной цивилизации, дожившее с некоторыми изменениями до нашего времени. В 60-е-70-е годы XX века имело место разделение некогда единой технологии программирования на два "рукава": компиляционный и интерпретационный. В 1964 г. был придуман **Бэйсик**, и так вышло, что именно он, а не Паскаль и не Си, стал королем средневековых языков. \\ |
| Чем жертвовали создатели Бэйсика и ради чего? Боевыми возможностями языка? Но поскольку язык для начального обучения, то это не считается. То, что язык получился кривой и некрасивый, - это хуже, потому что отрицательно влияет на интеллектуальное становление будущих специалистов. Зато получили первый в истории диалоговый язык, и он же был первым широко распространенным **//интерпретационным//** языком. Компиляторы Фортрана, Алгола и других языков преобразовывали исходный текст программы в машинный код, который затем запускался на выполнение. Бэйсик работает иначе. Интерпретатор просматривает исходный текст строка за строкой и сам выполняет описанные в строке действия. Поскольку каждую строку приходится обрабатывать отдельно, выполнение всей программы происходит намного медленнее, чем выполнение машинного кода, зато отпадает необходимость в компиляции как отдельном этапе работы. Что лучше? Если бы что-то было лучше, все поступали бы только так. Большая и сложная программа, особенно если она обрабатывает большие массивы данных, гораздо эффективнее выполняется с участием компилятора. Но в ряде случаев, особенно при выполнении учебных заданий, выполнение программы "на лету", без компиляции, может быть даже быстрее. И еще одно преимущество интерпретатора: поскольку он не вырабатывает никакого машинного кода, а выполняет все действия сам, неправильно написанная прикладная программа ничего не может испортить. Впрочем, в те годы это преимущество никому не казалось существенным. \\ | Чем жертвовали создатели Бэйсика и ради чего? Боевыми возможностями языка? Но поскольку язык для начального обучения, то это не считается. То, что язык получился кривой и некрасивый, - это хуже, потому что отрицательно влияет на интеллектуальное становление будущих специалистов. Зато получили первый в истории диалоговый язык, и он же был первым широко распространенным **//интерпретационным//** языком. Компиляторы Фортрана, Алгола и других языков преобразовывали исходный текст программы в машинный код, который затем запускался на выполнение. Бэйсик работает иначе. Интерпретатор просматривает исходный текст строка за строкой и сам выполняет описанные в строке действия. Поскольку каждую строку приходится обрабатывать отдельно, выполнение всей программы происходит намного медленнее, чем выполнение машинного кода, зато отпадает необходимость в компиляции как отдельном этапе работы. Что лучше? Если бы что-то было лучше, все поступали бы только так. Большая и сложная программа, особенно если она обрабатывает большие массивы данных, гораздо эффективнее выполняется с участием компилятора. Но в ряде случаев, особенно при выполнении учебных заданий, выполнение программы "на лету", без компиляции, может быть даже быстрее. И еще одно преимущество интерпретатора: поскольку он не вырабатывает никакого машинного кода, а выполняет все действия сам, неправильно написанная прикладная программа ничего не может испортить. Впрочем, в те годы это преимущество никому не казалось существенным. \\ |
| Поскольку интерпретатор не порождает машинного кода, автор программы, написанной на Бэйсике, может передавать ее другим лицам ТОЛЬКО в виде исходного кода. Это с какой-то стороны хорошо, а с какой-то плохо (это кому как!) - ну не бывает на свете идеальных инженерных решений. Безусловно хорошо то, что такая программа может быть запущена на любом компьютере, на котором имеется соответствующий интерпретатор. В какой-то мере интерпретатор Бэйсика (и любого другого языка из тех, что появились позже) может рассматриваться как виртуальная машина - доступная владельцу мелкого компьютера альтернатива СВМ больших мейнфреймов. В предыдущей главе мы отметили, что разработчики __древних__ компьютеров первым делом оснащали свои детища компилятором Фортрана - точно так же в __средние века__ разработчики 16-разрядных мини-ЭВМ (PDP-11, они же СМ-3, СМ-4) оснащали свои операционные системы интерпретатором Бэйсика, хотя для таких машин он уже должен был считаться устаревшим. А разработчики восьмиразрядных домашне-игровых компьютеров своей жизни без Бэйсика не мыслили, потому что написать для такой слабой машины мало-мальски приличный компилятор было весьма непростой задачей, стоимость которой свела бы к нулю всю привлекательность таких машинок. А на советских ПК обычно вообще никакого другого программного обеспечения не было. Более серьезные программисты не жаловали Бэйсик, считали его //суррогатной технологией//. Однако в средние века проблема суррогатных технологий не ощущалась так остро, поэтому к ней я надеюсь вернуться, когда наша история дойдет до нового времени. \\ | Поскольку интерпретатор не порождает машинного кода, автор программы, написанной на Бэйсике, может передавать ее другим лицам ТОЛЬКО в виде исходного кода. Это с какой-то стороны хорошо, а с какой-то плохо (это кому как!) - ну не бывает на свете идеальных инженерных решений. Безусловно хорошо то, что такая программа может быть запущена на любом компьютере, на котором имеется соответствующий интерпретатор. В какой-то мере интерпретатор Бэйсика (и любого другого языка из тех, что появились позже) может рассматриваться как виртуальная машина - доступная владельцу мелкого компьютера альтернатива СВМ больших мейнфреймов. В предыдущей главе мы отметили, что разработчики __древних__ компьютеров первым делом оснащали свои детища компилятором Фортрана - точно так же в __средние века__ разработчики 16-разрядных мини-ЭВМ (PDP-11, они же СМ-3, СМ-4) оснащали свои операционные системы интерпретатором Бэйсика, хотя для таких машин он уже должен был считаться устаревшим. А разработчики восьмиразрядных домашне-игровых компьютеров своей жизни без Бэйсика не мыслили, потому что написать для такой слабой машины мало-мальски приличный компилятор было весьма непростой задачей, стоимость которой свела бы к нулю всю привлекательность таких машинок. А на советских ПК обычно вообще никакого другого программного обеспечения не было. Более серьезные программисты не жаловали Бэйсик, считали его //суррогатной технологией//. Однако в средние века проблема суррогатных технологий не ощущалась так остро, поэтому к ней я надеюсь вернуться, когда наша история дойдет до нового времени. \\ |
| На замену Бэйсику был придуман Фокал, но он не обещал ни чудес, ни революций и в итоге оказался мертворожденным. Несмотря на критику, которой Бэйсик подвергался с "молодости", он пережил несколько реинкарнаций. Однако будущего у него нет. \\ | На замену Бэйсику был придуман Фокал, но он не обещал ни чудес, ни революций и в итоге оказался мертворожденным. Несмотря на критику, которой Бэйсик подвергался с "молодости", он пережил несколько реинкарнаций. Однако будущего у него нет. \\ \\ |
| === Статическая и оверлейная линковка === | |
| Выше мы рассмотрели линковщик как новую (в сравнении с древней эпохой) служебную программу, собирающую загрузочный файл из множества объектных файлов, выданных компилятором. В простейшем случае линковщик помещает в загрузочный файл основную программу со всеми нужными подпрограммами - это //статическая линковка//. В средние века наряду со статической была уже освоена //оверлейная линковка//: весь программный код делился на сравнительно небольшой основной загрузочный модуль и несколько оверлейных модулей. При запуске программы на выполнение основной загрузочный модуль загружался в оперативную память, и ему сразу передавалось управление, а оверлейные модули подгружались только тогда, когда нужно было выполнить содержащиеся в них подпрограммы. Разумеется, вопрос о том, какие части программы включить в основной загрузочный модуль и какие в оверлеи, мог решить только программист: "программист решил - линковщик сделал". Оверлейная линковка позволяла (1) уменьшить затраты времени на загрузку программы в оперативную память и (2) эксплуатировать большую и сложную программу на машине с ограниченной емкостью памяти (пусть хотя бы ценой некоторой "задумчивости" при выполнении некоторых операций), но не спасала от того, что разные программы на половину или больше состоят из одних и тех же деталей: каждый оверлейный модуль принадлежал какой-то одной программе. Отсюда вытекает очевидная идея "обобществить" оверлейные модули, но эта идея - более поздняя. Мы ее коснемся в главе "новое время". \\ \\ | |
| ==== Немного воспоминаний и размышлений ==== | ==== Немного воспоминаний и размышлений ==== |
| В предыдущей главе я рассказывал вам про свою студенческую практику, но не закончил этот рассказ - теперь, как и обещал, продолжу. \\ | В предыдущей главе я рассказывал вам про свою студенческую практику, но не закончил этот рассказ - теперь, как и обещал, продолжу. \\ |
| Сопоставлять Windows и Linux можно еще очень долго, но я сейчас остановлюсь на том, что эти системы существуют и будут существовать в единстве и борьбе еще долго. Так появившиеся в середине XIX века пароходы в течение целого века сосуществовали и соперничали с парусниками, пока в их взаимоотношения не вмешался Дизель (это быль, и в ней намек - добрым молодцам и красным девицам урок). \\ | Сопоставлять Windows и Linux можно еще очень долго, но я сейчас остановлюсь на том, что эти системы существуют и будут существовать в единстве и борьбе еще долго. Так появившиеся в середине XIX века пароходы в течение целого века сосуществовали и соперничали с парусниками, пока в их взаимоотношения не вмешался Дизель (это быль, и в ней намек - добрым молодцам и красным девицам урок). \\ |
| Заметим, что Linux - не единственный идейный наследник UNIX. Подобных операционных систем в 90-е годы и в начале XXI века было создано очень много - вероятно десятки. Но наибольшее распространение наряду с линуксами получили ОС семейства BSD от Университета Беркли (разрабатывалась в 1978-1994 гг., после чего ей на смену пришла бесплатная OpenBSD), и коммерческая MacOS от фирмы "Эппл". Все они - из США. Эти системы очень похожи: кто освоил MacOS, тот легко перейдет на Linux, и наоборот, и BSD аналогично. \\ | Заметим, что Linux - не единственный идейный наследник UNIX. Подобных операционных систем в 90-е годы и в начале XXI века было создано очень много - вероятно десятки. Но наибольшее распространение наряду с линуксами получили ОС семейства BSD от Университета Беркли (разрабатывалась в 1978-1994 гг., после чего ей на смену пришла бесплатная OpenBSD), и коммерческая MacOS от фирмы "Эппл". Все они - из США. Эти системы очень похожи: кто освоил MacOS, тот легко перейдет на Linux, и наоборот, и BSD аналогично. \\ |
| Заканчивая разговор об операционных системах нового времени, я хотел бы обратить внимание читателей вот на какой аспект. Ни Столлман, ни Торвальдс не были бунтарями или новаторами. Они только хотели сделать программное обеспечение доступным для всех, и они это сделали, но не ставили перед собой амбициозных задач типа перелома исторических эпох - они шли в фарватере UNIX. Так идеология операционной системы, разрабатывавшаяся еще в 70-е годы XX века, оказалась законсервирована в новых изделиях. Чуть позже мы будем рассматривать новейшее компьютерное время, практически совпадающее с XXI веком, но в области операционных систем никакого новейшего времени мы не наблюдаем, и в главе "Новейшее компьютерное время" разговора об операционных системах не будет. \\ \\ | Заканчивая разговор об операционных системах нового времени, я хотел бы обратить внимание читателей вот на какой аспект. Ни Столлман, ни Торвальдс не были бунтарями или новаторами. Они только хотели сделать программное обеспечение доступным для всех, и они это сделали, но не ставили перед собой амбициозных задач типа перелома исторических эпох - они шли в кильватере UNIX. Так идеология операционной системы, разрабатывавшаяся еще в 70-е годы XX века, оказалась законсервирована в новых изделиях. Чуть позже мы будем рассматривать новейшее компьютерное время, практически совпадающее с XXI веком, но в области операционных систем никакого новейшего времени мы не наблюдаем, и в главе "Новейшее компьютерное время" разговора об операционных системах не будет. \\ \\ |
| ==== Программирование в новое время ==== | ==== Программирование в новое время ==== |
| === Задачи === | === Задачи === |
