Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 68
половина из этого была на Amiga в 1985г
Да и для PC тут масса всего переврана. 80386 вышел в 1985. Первые «мультизадачные 32-битные ОС» и «MMU и подкачка» появились примерно одновременно с его выходом или плюс-минус пара лет — тот же Xenix в 1987 был уже полностью портирован на 80386. В 1989-1990 было уже несколько готовых портов BSD на 80386, но они попали в очередной круг юридических дрязг на тему «кому принадлежит и как лицензируется BSD».
Увеличение количества регистров, вообще говоря, напротив, сильно усложняет генерацию (да и предсказуемость выполнения) кода.
«Архитектура ввода/вывода с прямым доступом к памяти и очередями команд» — это некий странный конгломерат. «Архитектура» и «очереди команд» на самом деле существует в виде SCSI с ~1981-1982 года. Если речь про DMA — то поддержка DMA существует с ISA шины оригинального IBM PC (1981 год). ATA-4 и UltraDMA, вообще говоря, не были чем-то суперноваторским с технической точки зрения — DMA был и до них, новизна по сути только в новом аппаратном решении с 80-жильным кабелем, дававшим в разы большую помехоустойчивость, что позволило задрать частоты и уплотнить передачи.
В общем, инженеров IBM PC есть, за что ругать — но отнюдь не за то, что они, дескать, тупые и не скопировали с «большого брата» всякие полезные фичи.
Увеличение количества регистров, вообще говоря, напротив, сильно усложняет генерацию (да и предсказуемость выполнения) кода.
«Архитектура ввода/вывода с прямым доступом к памяти и очередями команд» — это некий странный конгломерат. «Архитектура» и «очереди команд» на самом деле существует в виде SCSI с ~1981-1982 года. Если речь про DMA — то поддержка DMA существует с ISA шины оригинального IBM PC (1981 год). ATA-4 и UltraDMA, вообще говоря, не были чем-то суперноваторским с технической точки зрения — DMA был и до них, новизна по сути только в новом аппаратном решении с 80-жильным кабелем, дававшим в разы большую помехоустойчивость, что позволило задрать частоты и уплотнить передачи.
В общем, инженеров IBM PC есть, за что ругать — но отнюдь не за то, что они, дескать, тупые и не скопировали с «большого брата» всякие полезные фичи.
1. Я специально отметил, что аппаратная поддержка страничной памяти появилась раньше ее поддержки в OS (на PC). Но, во-первых, она появилась на IBM/370 на 15 лет раньше, чем на PC. Чтобы понять масштаб времени в выражении “на 15 лет раньше” попытаемся вспомнить, как выглядел, например, Интернет в 1998 году. И сравним с современными сайтами. Это наглядно показывает сколько всего в мире меняется за 15 лет. Во-вторых, Xenix в 1987 году был так же широко известен и распространен, как, наверное, и сейчас. :) То есть, и тогда, и сейчас эту OS “живьем” видели и использовали отдельные люди.
2. Большое количество регистров и их равноценность позволяют использовать давно известные и крайне эффективные алгоритмы их распределения, такие, как graph coloring аллокатор, которые в GCC были поддержаны только в 2005 году, спустя ~25 лет после их внедрения в компиляторы для мейнфреймов IBM. Кстати SSA (Static Single Assignment form) которая полностью видоизменила в лучшую сторону оптимизацию в GCC (тоже в районе 2005 года) была разработана в лабораториях IBM для mainframes во второй половине 80-х.
3. На IBM PC был DMA, но ирония судьбы состоит в том, что он использовался для обмена данными с floppy-диском, но не с HDD :) (начиная с IBM PC AT). Из-за этого любой обмен данными с HDD грузил центральный процессор, и все сильнее по мере ускорения дисков в ходе их прогресса. Что было достаточно хорошо видно на графиках загрузки CPU вплоть до появления DMA в ATA.
4. Очереди команд и out-of-order выполнение операций при работе с HDD сильно ускоряют конкурентную работу с диском на серверах и снижают время отклика. Эти возможности действительно были доступны в SCSI, но даже там они появилась не сразу. Коммерчески доступной эта технология стала в середине 90-х и использовалась в основном отдельными фанатами-энтузиастами, как раз-таки узнавшими о ее преимуществах по своему опыту работы с “большим железом”. В середине 90-х диск SCSI + топовый контроллер Adaptec или BusLogic с поддержкой очереди команд стоили порядка $750 (личный опыт), что по тем временам равнялось двум средним зарплатам программиста (в России), поэтому такие технологии были мало кому известны и понятны.
5. Ни в коем случае я не намекаю, что инженеры PC “тупые”. Тем более, что частично люди разрабатывающие архитектуру PC, ОС для PC/серверов на базе PC, компиляторы для PC и т.п. это одни и те же люди с теми, кто разрабатывал в свое время архитектуру софта или железа для мейнфреймов. Речь совсем о другом – о том, что технологии зачастую появляются в узких секторах или на особых машинах лет на 20-30 (!) раньше, чем на массовом рынке. Причем это относится к технологиям софта в том числе, а не только к машиностроению или к hardware, связанным с физическим миром.
2. Большое количество регистров и их равноценность позволяют использовать давно известные и крайне эффективные алгоритмы их распределения, такие, как graph coloring аллокатор, которые в GCC были поддержаны только в 2005 году, спустя ~25 лет после их внедрения в компиляторы для мейнфреймов IBM. Кстати SSA (Static Single Assignment form) которая полностью видоизменила в лучшую сторону оптимизацию в GCC (тоже в районе 2005 года) была разработана в лабораториях IBM для mainframes во второй половине 80-х.
3. На IBM PC был DMA, но ирония судьбы состоит в том, что он использовался для обмена данными с floppy-диском, но не с HDD :) (начиная с IBM PC AT). Из-за этого любой обмен данными с HDD грузил центральный процессор, и все сильнее по мере ускорения дисков в ходе их прогресса. Что было достаточно хорошо видно на графиках загрузки CPU вплоть до появления DMA в ATA.
4. Очереди команд и out-of-order выполнение операций при работе с HDD сильно ускоряют конкурентную работу с диском на серверах и снижают время отклика. Эти возможности действительно были доступны в SCSI, но даже там они появилась не сразу. Коммерчески доступной эта технология стала в середине 90-х и использовалась в основном отдельными фанатами-энтузиастами, как раз-таки узнавшими о ее преимуществах по своему опыту работы с “большим железом”. В середине 90-х диск SCSI + топовый контроллер Adaptec или BusLogic с поддержкой очереди команд стоили порядка $750 (личный опыт), что по тем временам равнялось двум средним зарплатам программиста (в России), поэтому такие технологии были мало кому известны и понятны.
5. Ни в коем случае я не намекаю, что инженеры PC “тупые”. Тем более, что частично люди разрабатывающие архитектуру PC, ОС для PC/серверов на базе PC, компиляторы для PC и т.п. это одни и те же люди с теми, кто разрабатывал в свое время архитектуру софта или железа для мейнфреймов. Речь совсем о другом – о том, что технологии зачастую появляются в узких секторах или на особых машинах лет на 20-30 (!) раньше, чем на массовом рынке. Причем это относится к технологиям софта в том числе, а не только к машиностроению или к hardware, связанным с физическим миром.
Xenix в 1987 году был так же широко известен и распространен, как, наверное, и сейчас. :) То есть, и тогда, и сейчас эту OS “живьем” видели и использовали отдельные люди
А IBM/370 не отдельные люди видели и использовали?
Спасибо за развернутый ответ!
Я еще немножко попридираюсь, если позволите:
Вы говорите о PIO в ATA (и, возможно, ESDI); масса других дисковых интерфейсов использовали DMA и даже имели в то время память, понятие очереди команды, кэши и буферы — например, ST-506 (1980 год), тот же SASI/SCSI (1981-1982) и т.д. Да, это все стоило как самолет, было немассовым (хотя вообще странно говорить о массовости жестких дисков где-то до конца 80-х).
Первый вид DMA (WDMA) в ATA появился в ATA-1, драфты публиковались где-то с 1991, контроллеры и материнские платы выпускались где-то со осени-зимы 1991, официально финализирован он в 1994.
«Топовые» дисковые контроллеры и сейчас стоят порядка 1K$ — так что радикально на самом деле ничего не изменилось, разве что SCSI-диски стали пропорционально больше/быстрее и раза в 2-3 доступнее.
А если по существу — то в целом с посылом «некоторые технологии появляются в узких секторах на N лет раньше, чем на массовом рынке» вы абсолютно правы, разве что с оценками этих самых N лет можно иногда поспорить.
Если отвлечься от компьютерной тематики — вон, гражданских перелетов через космос сколько ждут уже — 52 года прошло, и все ни? Когда-нибудь будет — и тогда будем считать эту N даже не порядка 20-30 лет, а под 60-70-80, а может и больше.
Я еще немножко попридираюсь, если позволите:
Вы говорите о PIO в ATA (и, возможно, ESDI); масса других дисковых интерфейсов использовали DMA и даже имели в то время память, понятие очереди команды, кэши и буферы — например, ST-506 (1980 год), тот же SASI/SCSI (1981-1982) и т.д. Да, это все стоило как самолет, было немассовым (хотя вообще странно говорить о массовости жестких дисков где-то до конца 80-х).
Первый вид DMA (WDMA) в ATA появился в ATA-1, драфты публиковались где-то с 1991, контроллеры и материнские платы выпускались где-то со осени-зимы 1991, официально финализирован он в 1994.
«Топовые» дисковые контроллеры и сейчас стоят порядка 1K$ — так что радикально на самом деле ничего не изменилось, разве что SCSI-диски стали пропорционально больше/быстрее и раза в 2-3 доступнее.
А если по существу — то в целом с посылом «некоторые технологии появляются в узких секторах на N лет раньше, чем на массовом рынке» вы абсолютно правы, разве что с оценками этих самых N лет можно иногда поспорить.
Если отвлечься от компьютерной тематики — вон, гражданских перелетов через космос сколько ждут уже — 52 года прошло, и все ни? Когда-нибудь будет — и тогда будем считать эту N даже не порядка 20-30 лет, а под 60-70-80, а может и больше.
Аппаратную 128-битную арифметику с плавающей точкой и BCD-арифметику. На PC их нет и сейчас. :)
Поправьте меня если ошибаюсь, но разве в SSE & AVX расширениях нет инструкций для обработки чисел с плавающей точкой?
Насколько я знаю они оперериют 64bit float.
Ну это появилось совсем недавно — архитектура Kepler
Разговор о процессорах, а не о видеокартах.
Вообще, x87 поддерживает 80-битные числа. Только их почти никто не использует.
Ну и двоично-десятичные числа в x86 тоже поддерживаются. Однако в x86-64 от них отказались, ибо НИНУЖНО.
Вообще, x87 поддерживает 80-битные числа. Только их почти никто не использует.
Ну и двоично-десятичные числа в x86 тоже поддерживаются. Однако в x86-64 от них отказались, ибо НИНУЖНО.
Фактически они (двоично-десятичные числа) никогда не поддерживались. Для работы с ними существовали четыре унаследованные и фактически бесполезные команды, применимость которых была ограничена двухзначными (!) числами. Именно поэтому на практике они практически никогда не использовались и их убрали в современной архитектуре. Поддержка BCD актуальна для SQL и для работы с финансовыми данными, но из-за отсутствия поддержки в железе ее реализуют софтверно.
применимость которых была ограничена двухзначными (!) числамиКто вам такое сказал? Да, в один байт влезало 2 разряда. Но вызовы этих команд точно также можно было делать по цепочке или в цикле, как и команд обычной арифметики.
по цепочке не прокатывает, поскольку для каждого разряда после суммы или вычитания необходимо было делать десятичную коррекцию — это собственно и была команда поддержки BCD, все это неймоверно усложняло алгоритмы и делало их медленными.
Вот была бы команда, которая 50-значные числа друг с другом хлоп-хлоп за какой-то десяток тактов, это было бы дело… а так и правда, проще реализовать на двоичной арифметике а потом преобразовать в нужный вид.
Вот была бы команда, которая 50-значные числа друг с другом хлоп-хлоп за какой-то десяток тактов, это было бы дело… а так и правда, проще реализовать на двоичной арифметике а потом преобразовать в нужный вид.
… а после десятичной коррекции можно было приступать в вычислению следующего разряда, не так ли?
PS у меня лабораторная работы была — сложение длинных чисел в двоично-десятичном коде, и я бы не сказал, что алгоритм получился сильно запутаннее или медленнее двоичного.
PS у меня лабораторная работы была — сложение длинных чисел в двоично-десятичном коде, и я бы не сказал, что алгоритм получился сильно запутаннее или медленнее двоичного.
Медленнее. Инфа 100%.
Сложите 10000 и 13000 в двоичном виде и в BCD. В двочном виде 1 команда — один такт. В BDC одних переносов туева хуча.
Сложите 10000 и 13000 в двоичном виде и в BCD. В двочном виде 1 команда — один такт. В BDC одних переносов туева хуча.
Безусловно Вы правы если говорить о чистых вычислениях. Но давайте сравним что будет быстрее — прочитать число из текстовой строки (условно — из каких-нибудь XML-данных) перекодируя его в binary, прибавить к нему единицу и перекодировать обратно в текст — или же сделать все тоже самое в BCD, заморачиваясь только (опционально) паковкой и распаковкой.
Это верно только для сложения и вычитания, но так же нужно заметить, что организация цикла по байтам была уже менее эффективной, чем софтверная реализация без процессорных команд.
Да, действительно, софтверная реализация выгоднее из-за большего основания СС. Но я бы не назвал это «никогда не поддерживались» — до тех пор, пока регистры данных оставались 16ти-битными, двоично-десятичные команды были вполне конкурентоспособными. Вот с появлением 32х-разрядных операций, позволивших уместить 9 разрядов в 4 байта, они актуальность окончательно потеряли.
Да, но регистры уже почти 20 лет 32-битные даже под Windows. Поэтому эти команды утеряли актуальность примерно два десятилетия назад. И их выполнение всегда занимало несколько тактов, а данные нужно было грузить в AL, поэтому я не уверен, что даже на 8086 они были выгоднее своей software эмуляции.
Для сравнения на IBM/370 можно было сложить, вычесть, умножить или поделить (!) два десятичных 31-разрядных (16-байтовых, речь идет о десятичных разрядах) числа одной машинной командой.
Для сравнения на IBM/370 можно было сложить, вычесть, умножить или поделить (!) два десятичных 31-разрядных (16-байтовых, речь идет о десятичных разрядах) числа одной машинной командой.
Еще смешнее, что сейчас из браузера делают ОС, повторяя тоже самое что давно есть на десктопах OS, как пример Native Client. Многое идет по кругу.
а 128 ядер по моему уже было в спарках, но скоро будет и у нас.
BCD умер в тот самый момент когда научились писать быстрые алгоритмы используя FFT, и реализовывать быстрый сопроцессор ALU для арифметики с FP
BCD имеют преимущество перед FP на действительно больших числах без потери точности вычислений. Это массовому пользователю не нужны такие вычисления, а попробуй организовать расчет на FP с разрядностью хотябы в 50 десятичных разрядов?
Ну да, ну да… не каждому простому смертному…
Ну да, ну да… не каждому простому смертному…
Кто мешает считать в двоичном виде, переводя в десятичный вид результат?
Скорее всего теоретическое обоснование встраивания BCD в процессор было из-за деления, которое нужно для перевода и которое намного медленнее остальных операций (по крайней мере в старых процессорах).
А при выполнении операций непосредственно в BCD деление для перевода не нужно.
А потом на практике оказалось что десятичная арифметика нужна в тех областях где скорость вычислений не важна, поскольку узкое место не расчеты, а система хранения данных, которая на порядки медленнее расчетов:)
Хотя возможно, что основной причиной игнорирования BCD стало отсутствие соответствующей поддержки в мейнстримных языках.
А при выполнении операций непосредственно в BCD деление для перевода не нужно.
А потом на практике оказалось что десятичная арифметика нужна в тех областях где скорость вычислений не важна, поскольку узкое место не расчеты, а система хранения данных, которая на порядки медленнее расчетов:)
Хотя возможно, что основной причиной игнорирования BCD стало отсутствие соответствующей поддержки в мейнстримных языках.
BCD-числа по-прежнему актуальны в SQL (стандартные типы данных CURRENCY и DECIMAL это BCD, INTEGER с заданным числом цифр часто тоже реализуют через BCD, если заданная разрядность превышает разрядность платформы).
Это костыль из-за маломощности процессора, аналогичный текстовому режиму.
Разумеется, намного эффективнее считать в двоичном виде, но вывод результата человеку был медленнее, и придумали, чтобы эти BCD-разрядики с минимальными преобразованиями кидать в текстовую видеопамять.
Сейчас же одна лишь печать результата OpenType-шрифтом с его глифами и сплайнами в тысячи раз тяжелее, чем двоично-десятичное преобразование того, что печатаем. Но никто не заморачивается — мощностей с избытком.
Разумеется, намного эффективнее считать в двоичном виде, но вывод результата человеку был медленнее, и придумали, чтобы эти BCD-разрядики с минимальными преобразованиями кидать в текстовую видеопамять.
Сейчас же одна лишь печать результата OpenType-шрифтом с его глифами и сплайнами в тысячи раз тяжелее, чем двоично-десятичное преобразование того, что печатаем. Но никто не заморачивается — мощностей с избытком.
Это при отображении пользователю. Но на сервере преобразование чисел в тексты, например, перед отправкой HTML или (особенно) XML занимает настолько большое время, что эту процедуру специально оптимизируют, в частности, давно разработаны и используются алгоритмы для преобразования binary -> decimal не содержащие во внутреннем цикле даже команды умножения.
Если речь об XML, то это трёхзвенка, из базы обычно выгребаются бинарники.
И я не поверю, что преобразование в dec является бутылочным горлом, когда есть приём данных из базы (по сети) и отправка далее клиенту (тоже сеть).
32-битные умножения ещё со времён Pentium не страшны, очень быстро выполняются.
Деление на константу компиляторы сейчас автоматом заменяют на умножение.
Если попытаться вычислить таблицу умножения, узкое место — запись в память.
Определённо, сейчас BCD выглядит как костыль из 70-х
И я не поверю, что преобразование в dec является бутылочным горлом, когда есть приём данных из базы (по сети) и отправка далее клиенту (тоже сеть).
32-битные умножения ещё со времён Pentium не страшны, очень быстро выполняются.
Деление на константу компиляторы сейчас автоматом заменяют на умножение.
Если попытаться вычислить таблицу умножения, узкое место — запись в память.
Определённо, сейчас BCD выглядит как костыль из 70-х
Это смотря у кого – у самых требовательных к быстродействию систем данные лежат в оперативной памяти (и даже не в кэшах, а прямо доступны по указателям). А драйверы сетевой карты так написаны, что берут данные непосредственно с пользовательских страниц без промежуточного буфера. Так вот оказывается, что при формировании буферов с данными для отсылки генерация тысяч вставок содержащих очередные счетчики чего-либо, денежные суммы и т.п. занимает достаточно большое время и есть смысл оптимизировать процедуры конверсии – можно выиграть процентов 5-10 времени. А если бы в машине была бы встроенная BCD-арифметика, то можно было бы не перекодировать эти числа вообще. Потому, что в подавляющем большинстве случаев в реальном времени с этими данными не делается никакой содержательной работы, кроме прибавления/вычитания единицы (или денежной суммы взятой из очередной транзакции) и конверсий туда-сюда.
Операции над BCD в x86 поддерживали двухзначные числа — поэтому на практике были бесполезными, и работу с нормальными BCD-числами приходилось делать используя длинный (и крайне нетривиальный для понимания другими людьми) код.
Все это, конечно, здорово, но судьба мэйнфреймов и то, где они оказались, хорошо показывает то, что на самом деле нужно пользователю.
И это совсем не абстрактные биты и фичи.
А еще не стоит забывать, а то тут наблюдается некая эйфория в тексте, про то, что софт был закрытый, что он был жестко привязан к железу, что он был монопольно разрабатываемым производителем железа и фактически не существовало никакой движущей силы конкуренции ("- слушай свои Валенки"). Думаю, разбалованные свободой Линукса, вы бы взвыли на мэйнфрейме с его «фичами» минут через 15 использования.
И это совсем не абстрактные биты и фичи.
А еще не стоит забывать, а то тут наблюдается некая эйфория в тексте, про то, что софт был закрытый, что он был жестко привязан к железу, что он был монопольно разрабатываемым производителем железа и фактически не существовало никакой движущей силы конкуренции ("- слушай свои Валенки"). Думаю, разбалованные свободой Линукса, вы бы взвыли на мэйнфрейме с его «фичами» минут через 15 использования.
Они оказались у меня на столе тогда, когда в них возникла потребность массового рынка, а не когда отдел разработки компании IBM решил, что мне это нужно.
С подобным подходом компании пролетают раз за разом, посмотрите историю процессоров, например.
С подобным подходом компании пролетают раз за разом, посмотрите историю процессоров, например.
Правда состоит в том, что они оказались у Вас на столе как раз именно потому, что отдел маркетинга в IBM так решил. :) Уже давно компании типа IBM, MS и т.п. создают новые, а не обслуживают имеющиеся потребности людей. Хотя вторым они тоже занимаются, но уже во вторую очередь или как косвенный результат основной инновационной деятельности. Именно эта магия — умение создавать новые потребности — позволяет компании заработать миллиарды (а не миллионы).
А книга говорит что обслуживали потребности еще до появления мейнфреймов. Незнаю насколько это правда, но судя по всему корпорациям не чуждо сотрудничать с правительствами не только по прослушке и слежки за населением…
Мне почему-то кажется, что развитие IT-индустрии хорошо показывает, что о том, чего пользователь хочет, пользователь узнает из пресс-релизов.
И что? Это что-то говорит об используемых технологиях? А что касается Linux и всего СПО… Ну, GNU/Hurd никак не могут закончить уже лет, наверно, 10, если не больше. Проект Singularity, по сути, реализующий ту же архитектуру, был успешно реализован за 5 лет. Так что, в закрытости разработки есть свои плюсы.
PS Не думаю, что многие из хабражителей работали бы непосредственно с мейнфреймом — скорее, с одной из гостевых ОС. Которая может быть любой.
что софт был закрытый, что он был жестко привязан к железу, что он был монопольно разрабатываемым производителем железа и фактически не существовало никакой движущей силы конкуренции
И что? Это что-то говорит об используемых технологиях? А что касается Linux и всего СПО… Ну, GNU/Hurd никак не могут закончить уже лет, наверно, 10, если не больше. Проект Singularity, по сути, реализующий ту же архитектуру, был успешно реализован за 5 лет. Так что, в закрытости разработки есть свои плюсы.
PS Не думаю, что многие из хабражителей работали бы непосредственно с мейнфреймом — скорее, с одной из гостевых ОС. Которая может быть любой.
Неверно. Пользователь за все это еще и платит, свои, между прочим, деньги.
Что именно неверно? Что производители consumer-устройств занимаются исключительно тем, что разводят пользователя на деньги? :)
Может, у вас тогда есть объяснение, почему планшет от MS не взлетел, а вот тоже самое от Apple — летает до сих пор? Из рациональных объяснений — только разница во времени (что, потребности пользователей сильно изменились?) и маркетинг. Маркетинг мне кажется более вероятным.
PS Может, вы тогда можете объяснить, какую такую потребность удовлетворяет Google Glass, которую не может удовлетворить обычный смартфон? Только, как обычно, с пруфлинками :)
Может, у вас тогда есть объяснение, почему планшет от MS не взлетел, а вот тоже самое от Apple — летает до сих пор? Из рациональных объяснений — только разница во времени (что, потребности пользователей сильно изменились?) и маркетинг. Маркетинг мне кажется более вероятным.
PS Может, вы тогда можете объяснить, какую такую потребность удовлетворяет Google Glass, которую не может удовлетворить обычный смартфон? Только, как обычно, с пруфлинками :)
с одной из гостевых ОС. Которая может быть любой.
«Автомобиль может быть любого цвета, если этот цвет — черный» (с) Генри Форд
Просто в отличие от людей, которые про мэйнфреймы узнали из постов на Хабре, мне в свое время приходилось иметь с ними дело непосредственно. Иллюзии это хорошо разрушает, поверьте. Никому из присутствующих не пожелаю переходить на мэйнфреймы по своей воле.
«Автомобиль может быть любого цвета, если этот цвет — черный» (с) Генри Форд
Не понял, к чему это? Или технологии виртуализации накладывают ограничения на то, какая ОС может использоваться в качестве гостевой?
Просто в отличие от людей, которые про мэйнфреймы узнали из постов на Хабре, мне в свое время приходилось иметь с ними дело непосредственно. Иллюзии это хорошо разрушает, поверьте. Никому из присутствующих не пожелаю переходить на мэйнфреймы по своей воле.
Мейнфреймы — понятие крайне растяжимое. Если вам есть, что рассказать про работу с ними — пишите, думаю, читатели Хабра будут вам благодарны :)
мне с этими «уникальными разработками, обогнавшими время» не нравится ещё вот что: люди работают, вкладывают своё время в то, что бы сделать крутую штуку, а потом её выбрасывают.
Из-за естественных капиталистических причин (бабло) все эти разработки замораживаются и ложатся мертвым грузом, а потом другие люди должны заново это всё переизобретать.
Из-за естественных капиталистических причин (бабло) все эти разработки замораживаются и ложатся мертвым грузом, а потом другие люди должны заново это всё переизобретать.
Мейнфреймы оказались именно там, куда их направляли, для чего разрабатывали. Больше 90% финансовых транзакций в мире происходят на них
… По крайней мере, по мере утверждениям самих производителей мэйнфреймов ;)
:) Вообщем, да :)
Но вряд ли они уж совсем нагло врут. А потом, у меня приятель работает в одной глобально--страховой компании в Штатах. Подтверждает, что у них то так.
Но вряд ли они уж совсем нагло врут. А потом, у меня приятель работает в одной глобально--страховой компании в Штатах. Подтверждает, что у них то так.
Ну они могут не «врать», а недоговаривать. Например считать AS/400 за мэйнфреймы, хотя это не совсем так, по существу. Или лукавить с тем, что считается «транзакциями». Или опускать, что транзакция транзакции рознь. И бывает операция снятия в банкомате, а бывает операции на NASDAQ.
В общем тут фильтровать и фильтровать.
В общем тут фильтровать и фильтровать.
Это ж сколько вам лапши на уши навесили? Да, софт разрабатывал прозводитель — ну так и сейчас софт разрабатывает производитель: Microsoft выпускает приставки и планшеты, Google — телефоны. А в те времена совместимые компьютеры выпускали IBM, Amdahl, Hitachi, UNIVAC. И это если проигнорировать ЕС ЭВМ!
Закрытый, «жёсто привязанный к железу софт» — это как раз-таки изобретение персоналок! Который, правда, перекочевал со временем и на мэйнфреймы…
Закрытый, «жёсто привязанный к железу софт» — это как раз-таки изобретение персоналок! Который, правда, перекочевал со временем и на мэйнфреймы…
Закрытый, «жёсто привязанный к железу софт» — это как раз-таки изобретение персоналок!
Да что вы говорите! ;)
Да, к хорошему быстро првыкаешь :)
Подозреваю, что я старше вас примерно этак вдвое, и мне, в отличие от вас не надо узнавать о мэйнфреймах и их «чудесах» по рассказам на Хабре, я с ними имел дело непосредственно. А сейчас у вас, похоже, немножко «про СССР» такое, восприятие. Все же знают, как счастливо жилось при СССР, особенно твердо это знают люди, 1985 и позже годов рождения ;)
На бумаге все хорошо, но после ЕС 1045 (аналог IBM 360), Искра 1030 турбо (аналог IBM PC) — казалась даром небес.
Посмотрев как-то описание БЭСМ-6 в старой книжке был удивлён наличием виртуальной страничной адресации, с поддержкой подкачки с магнитного барабана, разделения прав доступа чтения/записи страниц и уровни выполнения (по типу ring0/3 в IA), наличия кеш-памяти, конвеерной обработки команд, асинхронной работы с памятью, системных вызовов.
И все забыли DEC. Как насчет PDP-8 и PDP-11, на которых исходно был разработан Unix (с) в 1971? Лично мне DEC'овская архитектура всегда казалась существенно удобнее и логичнее. Середина 197х — 32-битная VAX VMS. РОН и аппаратная арифметика…
так то все верно, но эти железяки больше похоже на современные ibm system z. сколько вы таких видели? я пока только две. там и сейчас много чего интересного еще есть.
это все закрытые аппаратные технологии, закрытые программные среды. проприетарное царство ранее почти полностью принадлежавшее ibm. микрософт и интел добились впечатляющих успехов как раз на эти 20-30 лет позже.
поймите правильно, дело не в технологиях, а в их доступности на рынке. управляемый термоядерный синтез — тоже очень круто. но реактора у вас дома пока почему-то нет.
это все закрытые аппаратные технологии, закрытые программные среды. проприетарное царство ранее почти полностью принадлежавшее ibm. микрософт и интел добились впечатляющих успехов как раз на эти 20-30 лет позже.
поймите правильно, дело не в технологиях, а в их доступности на рынке. управляемый термоядерный синтез — тоже очень круто. но реактора у вас дома пока почему-то нет.
хм, 20 лет. А не связано ли это с патентами?
В основном — не связано. Просто новые технологии, как в железе (что всем понятно), так и в софте (что менее очевидно и не всегда это так) сначала, сразу после изобретения, стоят очень дорого. Но постепенно затраты на их изначальную разработку окупаются, а уровень развития технологий в целом делает более дешевым массовое производство или возникает необходимость в массовом использовании (если мы говорим о софте) и технологии находят применение на массовом рынке уже по приемлемой цене. Хотя бывает, конечно, что технология сразу отлично подходит и для массового рынка.
Вообще говоря, железо персоналок во многом повторяет путь развития мини, а мини повторили мейнфреймы:
TX-0 -> PDP-8 -> MOS-6502
S/360 -> PDP-11 -> Motorola 68K
S/360 -> VAX -> i386
При том, что реального влияния между ними мало: теория процессоров сильно продвинулась между шестьдесят четвертым и семьдесят девятым, а архитектуры все равно похожи.
TX-0 -> PDP-8 -> MOS-6502
S/360 -> PDP-11 -> Motorola 68K
S/360 -> VAX -> i386
При том, что реального влияния между ними мало: теория процессоров сильно продвинулась между шестьдесят четвертым и семьдесят девятым, а архитектуры все равно похожи.
Вспоминая универ и лекции по ОС, база современных ЭВМ: виртуальная память, вытесняющая многозадачность в планировщике, DMA ввода-вывода были с 70х.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опережая массовый рынок на 20-30 лет