Ну, вообще-то, даже полевых транзисторов отнюдь не два типа, а ведь есть ещё и биполярные, на которых строились все машины средней и высокой производительности вплоть до конца 1980-х. Понятно, что описывать их все в подобной статье смысла нет, но хотя б упомянуть, что мир этим не исчерпывается, стоило бы.
Реализация АЛУ тоже... скажем так, типична для ПЛИС, но не шибко эффективна: много лишней логики получается. Можно сравнить, например, с устройством классического АЛУ SN74181, а заодно разобраться в ограничениях по скорости из-за переносов и как они могут быть смягчены в реальных схемах.
Писал. Проблем не было. Как и постоянных несовместимых изменений внутри самого ядра, делающих непригодными драйверы для предыдущих версий системы. (Ну ладно, драйверную модель для видюх таки перепилили при переходе от ХП к Висте, так что, надо полагать, драйвер для ХП не пойдёт на более поздних системах -- хотя не уверен, так как в них не вникал; но для видюх, по крайней мере, таки имелись веские технические основания: из всех устройств именно они сильней всего изменились, не говоря о том, что ныне они являются самыми сложными устройствами -- это не УАРТ и даже не хост-контроллер УСБ).
Работа в браузере -- не показатель, ибо очень сильно зависит от скорости передачи данных, т.е. от внешних факторов.
Сама по себе система работала, с точки зрения пользователя, примерно с такой же скоростью, что и современные версии, однако железо-то было во много-много-много раз слабее.
Стоило б отметить, что, во-первых, Система 370 и не должна была стать революционной -- это развитие Системы 360, сохраняющее с ней совместимость. А во-вторых, эта линейка развивается и по сей день, и современные мэйнфреймы z/Architecture -- далёкие потоки Системы 360, сохраняющие с ней совместимость на уровне прикладного кода, что делает эту линейку архитектур самой старой из не утративших актуальность.
Давайте разберем локомотив в качестве примера. Хотя двигатель поезда имеет округлые поверхности и довольно сложные формы, он фактически собран из 762 тысяч плоских треугольников, используя 382 000 вершин и 9 различных материалов/цветов, нанесенных на поверхности треугольников.
Вы утверждаете, что в присутствующем в кадре одном цилиндре паровой машины -- а именно она является двигателем паровоза -- имеется 762 тысячи треугольников? Мне вот кажется, что эта величина относится ко всему локомотиву, который на английском называется "steam engine" -- точно так же, как и собственно паровая машина.
Перевод так себе. "Двигатель поезда", в частности, "порадовал". Нет чтоб написать "паровоз" или "локомотив" (как временами и сделали), а при повторении -- просто "он".
Насчёт устарелости и недостаточной конкурентоспособности правильно лишь отчасти. Да, для смартфонов или топовых ПК процы, производимые на имеющихся у нас мощностях (и даже на оборудовании, появление которого в ближайшие несколько лет фантастикой не является), будут совершенно никакими, если их сравнивать с западными или китайскими. Однако реальный рынок намного шире. Скажем, на некоторых моих разработках стоят микроконтроллеры с ядрами ARM, выполненные по "дубовым" технологиям (от 65 нм и хуже); понятно, что такое мы производить в состоянии -- и оно реально востребовано. Зачем МК, управляющему, скажем, силовыми приводами, сверхтонкие технологические нормы и сверхнизкое потребление? Использование отечественных МК в таких задачах сильно ограничено как раз их заоблачной ценой по сравнению с буржуйско-китайскими, а отнюдь не техническими характеристиками (ну, ещё практической доставабельностью, если ты не из оборонки, но тут государство тоже вполне может сыграть положительную роль).
По моему опыту, самый лучший СМовский терминал был, особенно в плане клавиатуры.
Ну и поправка к "общим словам" статьи: в СМ ЭВМ входили не только аналоги PDP-11, но и аналоги HP21xx, которые автор упоминает только в рамках АСВТ: СМ-1 и СМ-2 -- это как раз HP21xx, а не PDP-11.
Существовавшие тогда ЭВМ (прежде всего ENIAC) работали в диалоговом режиме: заранее сформированные входные данные передавались в компьютер, который обрабатывал их и выдавал готоввый результат.
Такой режим -- не диалоговый, а пакетный. В диалоговом режиме машина как раз ждёт реакции человека, отвечает на неё, опять ждёт и т.д., а не обрабатывает заранее подготовленные данные. Авиатренажёр, по сути, -- это как раз диалоговый режим, просто ввод человека осуществляется не через клавиатуру/мышь/сенсорный экран и т.п., а через органы управления самолётом или их имитацию (джойстик, например).
Угу. Поэтому предлагать подобное решение можно лишь в случае, если оговорена необязательная переносимость и прочие возможные ограничения или их отсутствие. У меня, исходя из начала этой статьи, сложилось впечатление, что неявно сформулированная задача заключалась в вводе строк исключительно стандартными средствами библиотеки языка.
Но такое решение уже будет непереносимым, так как полагается на наличие у ОС такой возможности. А её может и не быть -- скажем, если программе придётся работать на микроконтроллере, где виртуальной памяти в принципе не существует.
В дельфях не просто шустро -- иногда в сотни раз шустрей, чем на сях... Плюс там достаточно надёжная типизация (и отсутствие надёжности и си), и модули, а не дурные инклуды... Собсно, главный недостаток -- что пошли по пути копирования функционала жабы/сишарпа, а не с++ (убогие генерики вместо полноценных шаблонов, например).
Я вот под голое железо на С++ пишу. И постоянно его... ругаю тихими словами (но чистый Це ещё хуже: те же самые проблемы, только ещё и функционал убогий).
1) Физика сама по себе к реальному миру привязана, ибо ему и посвящена, а математика абстрактна. 2) С физикой начинают знакомиться ещё в школе, причём раньше, чем с "серьёзной" математикой. Поэтому, вводя в старших классах производные с интегралами, правильней было бы их применять на примере уже знакомой ученикам механики (например, решение задач, связанных с равноускоренным движением). 3) В вузах проблема менее острая, поскольку учатся уже взрослые люди, но даже и там не следует одно давать в полном отрыве от другого. Скажем, знакомишься с той же ТОЭ, решаешь уравнения сначала "по-школьному", а потом знакомишься со "взрослыми" способами, в т.ч. как системы уравнений решаются на ЭВМ. Или начинаешь изучать обработку сигналов, знакомишься с тем, что это вообще такое и для чего нужно -- и сразу вот тебе математический аппарат, который для этого применяется (а не сначала математику, которая хз для чего нужна, и лишь потом...)
Ну, вообще-то, даже полевых транзисторов отнюдь не два типа, а ведь есть ещё и биполярные, на которых строились все машины средней и высокой производительности вплоть до конца 1980-х. Понятно, что описывать их все в подобной статье смысла нет, но хотя б упомянуть, что мир этим не исчерпывается, стоило бы.
Реализация АЛУ тоже... скажем так, типична для ПЛИС, но не шибко эффективна: много лишней логики получается. Можно сравнить, например, с устройством классического АЛУ SN74181, а заодно разобраться в ограничениях по скорости из-за переносов и как они могут быть смягчены в реальных схемах.
Писал. Проблем не было. Как и постоянных несовместимых изменений внутри самого ядра, делающих непригодными драйверы для предыдущих версий системы. (Ну ладно, драйверную модель для видюх таки перепилили при переходе от ХП к Висте, так что, надо полагать, драйвер для ХП не пойдёт на более поздних системах -- хотя не уверен, так как в них не вникал; но для видюх, по крайней мере, таки имелись веские технические основания: из всех устройств именно они сильней всего изменились, не говоря о том, что ныне они являются самыми сложными устройствами -- это не УАРТ и даже не хост-контроллер УСБ).
Работа в браузере -- не показатель, ибо очень сильно зависит от скорости передачи данных, т.е. от внешних факторов.
Сама по себе система работала, с точки зрения пользователя, примерно с такой же скоростью, что и современные версии, однако железо-то было во много-много-много раз слабее.
Дык не было всяких мало кому нужных служб и т.п., запускаемых в обязательном порядке; про шпионские модули я уж молчу.
Использовал её на своём первом собственном компе, пока не появилась Вынь-2000. 95/98 только на работе использовались.
Стоило б отметить, что, во-первых, Система 370 и не должна была стать революционной -- это развитие Системы 360, сохраняющее с ней совместимость. А во-вторых, эта линейка развивается и по сей день, и современные мэйнфреймы z/Architecture -- далёкие потоки Системы 360, сохраняющие с ней совместимость на уровне прикладного кода, что делает эту линейку архитектур самой старой из не утративших актуальность.
Цитирую:
Вы утверждаете, что в присутствующем в кадре одном цилиндре паровой машины -- а именно она является двигателем паровоза -- имеется 762 тысячи треугольников? Мне вот кажется, что эта величина относится ко всему локомотиву, который на английском называется "steam engine" -- точно так же, как и собственно паровая машина.
Перевод так себе. "Двигатель поезда", в частности, "порадовал". Нет чтоб написать "паровоз" или "локомотив" (как временами и сделали), а при повторении -- просто "он".
APL -- язык программирования будущего для программистской техники прошлого. Открывает новую эру для любителей кодирования (с) не помню кто
Насчёт устарелости и недостаточной конкурентоспособности правильно лишь отчасти. Да, для смартфонов или топовых ПК процы, производимые на имеющихся у нас мощностях (и даже на оборудовании, появление которого в ближайшие несколько лет фантастикой не является), будут совершенно никакими, если их сравнивать с западными или китайскими. Однако реальный рынок намного шире. Скажем, на некоторых моих разработках стоят микроконтроллеры с ядрами ARM, выполненные по "дубовым" технологиям (от 65 нм и хуже); понятно, что такое мы производить в состоянии -- и оно реально востребовано. Зачем МК, управляющему, скажем, силовыми приводами, сверхтонкие технологические нормы и сверхнизкое потребление? Использование отечественных МК в таких задачах сильно ограничено как раз их заоблачной ценой по сравнению с буржуйско-китайскими, а отнюдь не техническими характеристиками (ну, ещё практической доставабельностью, если ты не из оборонки, но тут государство тоже вполне может сыграть положительную роль).
Маньяк этот Ivan -- прям как я (и, кстати, тоже Иван) :) Вполне может быть, стащу в будущем его решение для себя.
По моему опыту, самый лучший СМовский терминал был, особенно в плане клавиатуры.
Ну и поправка к "общим словам" статьи: в СМ ЭВМ входили не только аналоги PDP-11, но и аналоги HP21xx, которые автор упоминает только в рамках АСВТ: СМ-1 и СМ-2 -- это как раз HP21xx, а не PDP-11.
Мы играли. На 80386DX-33 окно уменьшать не приходилось, на SX-25 (или даже 20, не помню) -- там да, приходилось.
Первый DOOM благополучно работал на 80386.
Существовавшие тогда ЭВМ (прежде всего ENIAC) работали в диалоговом режиме: заранее сформированные входные данные передавались в компьютер, который обрабатывал их и выдавал готоввый результат.Такой режим -- не диалоговый, а пакетный. В диалоговом режиме машина как раз ждёт реакции человека, отвечает на неё, опять ждёт и т.д., а не обрабатывает заранее подготовленные данные. Авиатренажёр, по сути, -- это как раз диалоговый режим, просто ввод человека осуществляется не через клавиатуру/мышь/сенсорный экран и т.п., а через органы управления самолётом или их имитацию (джойстик, например).
Ну и очепятка в слое "готоввый" :)
Угу. Поэтому предлагать подобное решение можно лишь в случае, если оговорена необязательная переносимость и прочие возможные ограничения или их отсутствие. У меня, исходя из начала этой статьи, сложилось впечатление, что неявно сформулированная задача заключалась в вводе строк исключительно стандартными средствами библиотеки языка.
Но такое решение уже будет непереносимым, так как полагается на наличие у ОС такой возможности. А её может и не быть -- скажем, если программе придётся работать на микроконтроллере, где виртуальной памяти в принципе не существует.
В дельфях не просто шустро -- иногда в сотни раз шустрей, чем на сях... Плюс там достаточно надёжная типизация (и отсутствие надёжности и си), и модули, а не дурные инклуды... Собсно, главный недостаток -- что пошли по пути копирования функционала жабы/сишарпа, а не с++ (убогие генерики вместо полноценных шаблонов, например).
Я вот под голое железо на С++ пишу. И постоянно его... ругаю тихими словами (но чистый Це ещё хуже: те же самые проблемы, только ещё и функционал убогий).
1) Физика сама по себе к реальному миру привязана, ибо ему и посвящена, а математика абстрактна. 2) С физикой начинают знакомиться ещё в школе, причём раньше, чем с "серьёзной" математикой. Поэтому, вводя в старших классах производные с интегралами, правильней было бы их применять на примере уже знакомой ученикам механики (например, решение задач, связанных с равноускоренным движением). 3) В вузах проблема менее острая, поскольку учатся уже взрослые люди, но даже и там не следует одно давать в полном отрыве от другого. Скажем, знакомишься с той же ТОЭ, решаешь уравнения сначала "по-школьному", а потом знакомишься со "взрослыми" способами, в т.ч. как системы уравнений решаются на ЭВМ. Или начинаешь изучать обработку сигналов, знакомишься с тем, что это вообще такое и для чего нужно -- и сразу вот тебе математический аппарат, который для этого применяется (а не сначала математику, которая хз для чего нужна, и лишь потом...)