Комментарии 92
Хорошая статья и замечательно иллюстрирует, в чём именно проявляется негибкость больших компаний и как бабло побеждает зло.
Выпуск процессора 8080 как бы намекает, что внутренне 16-битный процессор вполне имеет смысл делать с 8-битной шиной. Позже этот же трюк повторил 386SX.
Выбор процессора 8086 не был бы такой уж сильной ошибкой, если бы Intel и IBM не пошли по пути совместимости при выпуске процессора 80286, усугубляя все сделанные ранее ошибки. Вот тогда и надо было перейти на Motorola 68x или вообще разрабатывать RISC-процессор типа ARM.
Да собственно, когда в IBM PC стали ставить 256 килобайт памяти — уже было понятно, что 16-битная архитектура (я о разрядности регистров) тормозит сильнее всего — ибо для адресации больших массивов требовались лишние вычисления.
Вот тогда и надо было перейти на Motorola 68x или вообще разрабатывать RISC-процессор типа ARM.
И как вы себе это представляете? Выкинуть нафиг всё уже наработанное ПО? Или лепить эмуляцию? Даже на 64-битнои Интеле выполнять 32-битные программы не так просто, а тут совершенно другая архитектура.
Мне очень странно, что Вы этого себе не представляете. В компьютер ставятся два процессора: главный 32-битный и совместимый *86-й.
Реально OS (в т.ч. драйверы оборудования) выполняется на главном процессоре. Желательно сделать там нормальную OS с вытесняющей многозадачностью — благо Unix был разработан для PDP-11, а значит, мог жить в очень малой памяти.
На *86-м процессоре запускается "заглушка" (можно — загружать; а можно запускать прямо из ПЗУ), которая перенаправляет вызовы (INT-прерывания) DOS и BIOS на главный процессор. А тот уже выполняет нужные функции.
Остаётся проблема с прямым обращением к аппаратуре. Реально надо эмулировать только видеопамять — ну так поддержку этого можно встроить в чипсет, контролирующий обращение *86-го процессора к оперативной памяти.
Ну, ещё хорошо бы эмулировать COM/LPT-порты. Это тоже реально сделать; я даже могу расписать, как именно, но лень, ибо неактуально.
Кстати, при разработке AMD-64 надо было сделать аналогично, а не впихивать поддержку обоих наборов команд в один процессор. Ну или сделать два ядра (два набора ядер) для 32-юитных программ и для 64-битных программ.
Но как обычно — разработчики идут по пути с максимальным количеством грабель. Ведь если они выберут другой путь, то работодатель не станет платить им за преодоление предусмотрительно созданных заранее трудностей.
PS: Программную эмуляцию процессора сделать не слишком сложно — при условии, что эмулирующий процессор имеет намного больше регистров, чем эмулируемый.
Интересно, как процессоры будут общаться друг с другом? Необходимость синхронизации между процессорами убъёт всю идею. Да и контролировать обращение процессора к памяти, да ещё аппаратно тянет на ещё один чипсет… плодить сущности на ровном месте?
Процессоры будут общаться через общую память. В системе предполагается от одного до трёх пулов/банков памяти. При трёх пулах — пропадает возможность динамического распределения памяти (т.е. память распределяется на этапе проектирования/сборки компьютера); зато в этой схеме доступ к памяти будет быстрее. При едином пуле — в нём логически создаются три пула, размер которых можно менять.
Первый и второй пулы — это собственная память главного процессора и *86-го процессора соответственно. Каждый процессор не имеет никакого доступа к памяти второго процессора.
Третий пул — это буферная память, куда имеют доступ оба процессора. Эту память они оба не кэшируют, зато эта память имеет свой собственный кэш — типа внешнего кэша процессора.
Ну или процессоры могут кэшировать память третьего пула — в то время, когда кладут или забирают данные. После работы надо "убрать за собой" — приказать своему кэшу перестать кэшировать эту память. Никакой аппаратной синхронизации кэшей не нужно.
О какой "синхронизации между процессорами" Вы говорите? Почему Вы не протестуете против синхронизации между CPU и GPU? Или там это не убивает идею?
На данный момент контроллер памяти (адресного пространства) уже давно (с 386-го процессора; а недоделки были и а 286-м) встроен в процессор (сравнительно недавно в процессор перенесли и контроллер модулей памяти, распределяющий запросы процессора к физической памяти между банками памяти).
Если Вас задел контроль над обращением к видеопамяти — то Вы сильно опоздали: этот контроль был в чипсете 8086-го процессора изначально, а начиная с EGA появился второй чипсет — на видеокарте.
Что же касается сущностей, то Вы, видимо, не интересовались подробностями архитектуры *86-х процессоров. Вот Вам кратенький список сущностей, построенных одна над другой:
- Сегментная адресация памяти на 8086 и 186 из-за того, что в системе предполагалось больше памяти, чем можно было адресовать одним регистром.
- Сегментная защита памяти в 286-м — жуткое уродство. И это вместо того, чтобы переходить на 32-битную архитектуру (закон Мура уже известен).
- Страничная защита памяти в 386-м — ну, нормально; но при этом — добавление ещё двух сегментных регистров.
- Четыре кольца защиты. При этом никто не способен объяснить мне, чего нельзя сделать в двух кольцах — ядро и приложения. Да и вообще, можно без колец защиты: ядерные команды реализовать через порты ввода/вывода, доступ к портам ввода/вывода сделать через обращение к памяти, память защитить страничной защитой; в адресном пространстве ядра есть страницы с портами, а приложениям их не дают.
- Четырёх колец мало — добавляют "минус первое кольцо защиты".
- Этого тоже мало — добавляют ещё одно кольцо защиты, "минус первое" переименовывают в "минус второе", а новое становится "минус первым".
- Если я правильно понял — сейчас навешивают ещё одно кольцо защиты.
- Это я ещё не стал писать про расширения набора команд процессора: MMX, SSE, SSE2 и ещё более дюжины.
У меня уже нет сил изучать весь этот зоопарк с вивисекцией. Сообщите кто-нибудь в антинаркотический контроль, пусть они проверят Intel на сверхтяжёлые наркотики.
А Вы тут решили запретить мне ковыряться в носу! (Если кто-то не понял — это намёк на анекдот: "Ребёнок увидел, как родители занимаются любовью, и сказал/подумал: "Эти люди запрещают мне ковыряться в носу."")
Сущности, видите ли, плодить не надо! Расскажите это в Санта-Кларе! И в Редмонде заодно — они тоже к этому руку приложили.
Почему Вы не протестуете против синхронизации между CPU и GPU? Или там это не убивает идею?
GPU это довольно специализированный векторный вычислитель там такое поведение оправдано и накладными расходами на передачу данных можно пренебречь. Кроме того, GPU настолько специфичен что результаты вычислений не возвращаются в CPU а идут сразу в видеопамять. А у вас получается два процессора трудятся над одной по сути задаче, дял каждого из них нужна собственная прошивка-программа написанная на двух разных(или одном?) языках и скомпилированная на двух разных компиляторах… для одной-то вычислительной системы? Система просто обречена на забвение… ибо кто будет заморачиваться двумя компиляторами для поддержки одной аппаратной платформы когда есть решения проще и масштабируемей?
доступ к портам ввода/вывода сделать через обращение к памятиТогда это будут уже не порты ввода-вывода а просто отображение адресного пространства. Такое тоже часто практикуется, но… проблема в том что порты ввода-вывода по своей сути весьма медленные по меркам процессора и даже памяти. Их никак не получится отразить на адресное пространство памяти не замедлив работу с памятью.
GPU настолько специфичен что результаты вычислений не возвращаются в CPU а идут сразу в видеопамятьМайнеры криптовалют от изумления теряют дар речи. Некоторые научные работники, занимающиеся вычислениями, тоже очень удивляются.
А у вас получается два процессора трудятся над одной по сути задачеНасколько я знаю, в любой операционке — над ядром трудятся одни программисты, а над user-space программами совсем другие. В данном случае ядро и user-space программы выполняются на разных процессорах, что по большому счёту ничего не меняет.
дял каждого из них нужна собственная прошивка-программа написанная на двух разных(или одном?) языках и скомпилированная на двух разных компиляторах…Про языки — будем считать, что я ничего не слышал. Потому что это настолько ничтожное возражение, что отвечать на него просто смешно — на фоне разнообразия используемых языков.
Компиляторы — очевидно разные. Ну и что?
Для *86- процессоров есть компиляторы для разных режимов работы: 16-битного, 32-битного и 64-битного; а для 16-битного режима были варианты с разными моделями памяти: Tiny, Small, Medium, Compact, Large и Huge. И после этого Вы запрещаете мне ковыряться в носу!
ибо кто будет заморачиваться двумя компиляторами для поддержки одной аппаратной платформы когда есть решения проще и масштабируемей?В привычном нам компьютере есть масса процессоров — на сетевой карте, на HDD, а на видеокарте их вообще много. И для всех написаны компиляторы. И все поддерживаются.
Мы точно на одной планете живём?
Тогда это будут уже не порты ввода-вывода а просто отображение адресного пространства.Это будут именно порты ввода-вывода. Изучите систему команд процессоров 6502 или ARM — там нет команд для работы с портами ввода-вывода, всё делается через отображение этих портов в адресное пространство процессора.
проблема в том что порты ввода-вывода по своей сути весьма медленные по меркам процессора и даже памятиЭто не порты медленные, это тормозят устройства, с которыми процессор работает через порты.
А часто ли надо делать системные команды? Они и на *86 небыстрые — ибо ломают конвейер.
Их никак не получится отразить на адресное пространство памяти не замедлив работу с памятью.А ничего, что в *86 обращение к портам ввода-вывода делается (ну или делалось до того, как контроллер памяти перенесли с сев.моста в процессор) через ту же шину, что и к памяти? Разница — только в том, что в адресной шине есть ещё одна линия, отвечающая за выбор между портами и памятью.
А глупые почему-то используют ASIC и специализированные математические модули… ведь есть GPU.
Я хочу сказать что для системы придётся использовать ОДНОВРЕМЕННО два разных компилятора а не каких-то произвольных т.к. нам одновременно надо будет менять и то и другое. Причем из-за кардинального различия в процессорах это будут совершенно разные компиляторы, если их сводить к одному знаменателю это чревато тем что ни один из них не будет работать оптимально.
Хотите ещё сильнее усложнить жизнь обновляя софт отдельно для каждого из процессоров и при этом умножив количество проблем совместимости между версиями? Такая схема будет не очень жизнеспособной.
Нет, это таки порты медленные. Устройства при всём желании не смогут работать быстрее чем работает шина, а скорость у неё ограничена. И за каждый такт на шине PCI процессор успевает сделать сотню тактов.
Отражение портов в адресное пространство памяти проблему не решит НИКАК. И если надо по алгоритму организовать сотню обращений к устройству для передачи данных то процессор вынужден будет ждать. По этой причине многие устройства имеют прямой доступ к памяти и общение с ними происходит через ПАМЯТЬ, и это не отражение адресного пространства.
До тех пор пока память не стала быстрее и эта линия тормозила всю систему при обращении к устройствам ввода-вывода. Вы ведь не забывайте что помимо этой линии для устройств отводился такой важный сигнал как HOLD позволяющий удерживать шину медленному устройству пока оно не примет данные. Именно из-за этого шины разделили. Теперь медленные устройства отделены от быстрой шины мостом и не мешают. Но это решило только часть проблемы — медленные устройства всё так же остались медленными, и если организовать интенсивное обращение к УВВ это может затормозить всю систему: вспомните как ведёт себя система при переключении IDE интерфейса в PIO-режим, а там каких-то 30-40Мб/сек и уже проблемы независимо от скорости процессора и шины памяти. То же касается и GPU — если данные вытаскивать исключительно через порты его потенциал не будет раскрыт полностью.
Я хочу сказать что для системы придётся использовать ОДНОВРЕМЕННО два разных компилятора а не каких-то произвольных т.к. нам одновременно надо будет менять и то и другое. Причем из-за кардинального различия в процессорах это будут совершенно разные компиляторы, если их сводить к одному знаменателю это чревато тем что ни один из них не будет работать оптимально.
В привычном нам компьютере есть масса процессоров — на сетевой карте, на HDD, а на видеокарте их вообще много.
Хотите ещё сильнее усложнить жизнь обновляя софт отдельно для каждого из процессоров и при этом умножив количество проблем совместимости между версиями? Такая схема будет не очень жизнеспособной.
Это не порты медленные, это тормозят устройства, с которыми процессор работает через порты.
Нет, это таки порты медленные. Устройства при всём желании не смогут работать быстрее чем работает шина, а скорость у неё ограничена. И за каждый такт на шине PCI процессор успевает сделать сотню тактов.
Отражение портов в адресное пространство памяти проблему не решит НИКАК. И если надо по алгоритму организовать сотню обращений к устройству для передачи данных то процессор вынужден будет ждать. По этой причине многие устройства имеют прямой доступ к памяти и общение с ними происходит через ПАМЯТЬ, и это не отражение адресного пространства.
в *86 обращение к портам ввода-вывода делается (ну или делалось до того, как контроллер памяти перенесли с сев.моста в процессор) через ту же шину, что и к памяти
До тех пор пока память не стала быстрее и эта линия тормозила всю систему при обращении к устройствам ввода-вывода. Вы ведь не забывайте что помимо этой линии для устройств отводился такой важный сигнал как HOLD позволяющий удерживать шину медленному устройству пока оно не примет данные. Именно из-за этого шины разделили. Теперь медленные устройства отделены от быстрой шины мостом и не мешают. Но это решило только часть проблемы — медленные устройства всё так же остались медленными, и если организовать интенсивное обращение к УВВ это может затормозить всю систему: вспомните как ведёт себя система при переключении IDE интерфейса в PIO-режим, а там каких-то 30-40Мб/сек и уже проблемы независимо от скорости процессора и шины памяти. То же касается и GPU — если данные вытаскивать исключительно через порты его потенциал не будет раскрыт полностью.
А глупые почему-то используют ASIC и специализированные математические модули… ведь есть GPU.Я не очень понял, при чём тут ASIC. Многие любители вычислений используют GPU — и получают результат обратно. Что мешает построить аналогичную систему по предложенной мной схеме?
Я хочу сказать что для системы придётся использовать ОДНОВРЕМЕННО два разных компилятораПочему одновременно???
На главном процессоре исполняется ядро (и некоторые приложения, написанные для этого процессора — предполагается постепенная миграция на этот процессор; но тут мы рассматриваем поддержку унаследованных программ, написанных/откомпилированных для *86). На *86 выполняются унаследованные давно откомпилированные программы. Зачем использовать компиляторы одновременно — я не понимаю.
Ну хорошо, рассмотрим Web-сервер и браузер (на Ваш выбор). Уж не хотите ли Вы сказать, что Web-сервер и браузер д.б. написаны на одном языке и компилироваться одновременно?
Ну или если это Вам ближе — файловый сервер Novell NetWare и DOS-клиент.
Хотите ещё сильнее усложнить жизнь обновляя софт отдельно для каждого из процессоров и при этом умножив количество проблем совместимости между версиями?Кажется, Вы не поняли: в современном компьютере уже есть много процессоров — и все проблемы совместимости решаются через соблюдение протоколов.
Нет, это таки порты медленные. Устройства при всём желании не смогут работать быстрее чем работает шинаНу так не обязательно выводить порт на шину! Порт может обрабатываться и чипсетом, и даже внутри процессора (в современных процессорах контроллер памяти — в процессоре).
И если надо по алгоритму организовать сотню обращений к устройству для передачи данных то процессор вынужден будет ждать. По этой причине многие устройства имеют прямой доступ к памяти и общение с ними происходит через ПАМЯТЬ, и это не отражение адресного пространства.Когда устройства имеют прямой доступ к памяти — они сами залезают в память. В реальную память. Это совершенно другое — протокол общения на другом уровне.
Однако, тут Вы опять не понимаете, зачем это сделано. Это для того, чтобы не дёргать процессор IRQ-прерываниями, которые занимают куда больше времени, чем обращение к портам.
для устройств отводился такой важный сигнал как HOLD позволяющий удерживать шину медленному устройству пока оно не примет данныеВы про какую шину? В современных процессорах их две: PCI и PCI-X.
вспомните как ведёт себя система при переключении IDE интерфейса в PIO-режимНу так это — как раз обработка IRQ, см.выше!
При том что GPU вещь специфичная и не все задачи решает оптимально. И даже вычислительные. Он заточен на работу с графикой, а то что используют для другого это побочная функция.
Результат обработки получить обратно можно, но это узкое место вычислителя. GPU заточен на то чтобы получить сравнительно небольшой объём данных, обработать его и оставить в памяти прямо на карте, а там память даже быстрее чем системная, но возвращать результат обратно в системную память довольно накладно поэтому используют GPU в вычислениях когда назад приходит относительно мало данных. Причем в майнинге криптовалюты видеокарты находятся в районе нулевого баланса.
Результат обработки получить обратно можно, но это узкое место вычислителя. GPU заточен на то чтобы получить сравнительно небольшой объём данных, обработать его и оставить в памяти прямо на карте, а там память даже быстрее чем системная, но возвращать результат обратно в системную память довольно накладно поэтому используют GPU в вычислениях когда назад приходит относительно мало данных. Причем в майнинге криптовалюты видеокарты находятся в районе нулевого баланса.
в современном компьютере уже есть много процессоровЭти процессоры — черные ящики и могут быть в любой момент заменены на другие без изменения функциональности. И как правило пользователю не надо ставить для них какой-либо софт. Но что касается основного(-ых) процессоров то софт под них надо считать переменным. И то что в идеале мы будем отказываться от x86 софта не означает что его не надо поддерживать и вносить изменения, особенно касающиеся безопасности и уязвимостей. Так или иначе нам надо будет работать как с новым так и со старым процессором на время перехода, которое может затянуться лет на 20, не меньше.
GPU вещь специфичная и не все задачи решает оптимальноЕсли Вы можете объяснить, в чём специфичность GPU — объясните. Если не можете — не говорите этого слова.
Неоптимально работают все системы. И что дальше?
Он заточен на работу с графикойНу и в чём заключается эта заточка?
Я читал про компьютер, высчитывающий движение космических тел в Солнечной системе. Там у процессора была команда, для которой аргументами были координаты и массы двух тел, а результатом — то ли сила взаимодействия, то ли сразу же два ускорения. Вот это я понимаю — специфичность, нигде более не нужная.
А в чём заключается заточенность на графику? Синусы, нужные в графике, и обычный процессор неплохо считает; вроде, у всех процессоров это уже есть в виде одной команды.
Результат обработки получить обратно можно, но это узкое место вычислителя.Ой, а что там узкого-то? GPU умеет брать достаточно объёмные данные из памяти — текстуры. А значит, может и класть данные обратно.
Эти процессоры — черные ящики и могут быть в любой момент заменены на другие без изменения функциональности.Вы меня поражаете. Вы так говорите. как будто яро Windows — не чёрный ящик и не было неоднократно заменено с сохранением совместимости и прежней функциональности. Наиболее значимое изменение — это замена W'95/98/ME на W'NT/2000/XP/etc.
И как правило пользователю не надо ставить для них какой-либо софт.Ой! (Падаю под стол.)
Я так понимаю, про установку драйверов Вы не слышали. И про проблемы, связанные с этим — тоже.
Но что касается основного(-ых) процессоров то софт под них надо считать переменным.Ой, это как?
И то что в идеале мы будем отказываться от x86 софта не означает что его не надо поддерживать и вносить изменения, особенно касающиеся безопасности и уязвимостей.От поддержки 16-битного софта отказались уже давно, в т.ч. и от исправления уязвимостей. От поддержки W'XP отказались недавно; а от поддержки W'2000 (последней из Windows, не имевшей 64-битной версии) отказались достаточно давно.
(Я не уверен, можно ли считать W'XP'32 и W'XP'64 одной системой — там свои сложности.)
Т.е. отказ от поддержки старого софта — это вполне нормальная практика.
Но тут (я опять напоминаю) мы обсуждаем такую гипотетическую (в смысле — альтернативная история) ситуацию:
«Были компьютеры на процессорах 8086. Вместо создания процессора 286 принято решение сделать компьютер с друмя процессорами. На главном 32-битном процессоре выполняется ядро операционки. На процессоре 8086 выполняются старые унаследованные программы.»
Т.е. в нашем случае предполагается, что все те, кто собираются поддерживать свои программы — выпускают новые версии, написанные на ассемблере или откомпилированные для главного процессора. А старые программы — уже не меняются или меняются незначительно (пока не у всех программистов есть новые процессоры).
Так или иначе нам надо будет работать как с новым так и со старым процессором на время перехода, которое может затянуться лет на 20, не меньше.Выше я несколько раз написал, что работа с несколькими процессорами — это нормальная практика современных компьютеров. Здесь нет проблемы; точнее, проблемы есть — но они меньше, чем если бы в компьютере был только один процессор.
Да-да, реально меньше. Чисто потому, что разнесение работы на несколько процессоров — это аппаратная реализация идеи «слоёв абстракции».
Например, мы знаем. что FDD и CD/DVD/BlueRay практически умерли. Тогда как HDD и Flash — живут и развиваются. А почему так? Обратите внимание: в первой группе мы имеем пассивные накопители (не имеющие входа электропитания); а во второй группе — интеллектуальные накопители, в каждом из которых есть собственный процессор.
Ну а теперь подумайте, можно ли возложить работу тех процессоров, которые сейчас находятся внутри HDD и Flash, на CPU. И когда Вы осмыслите этот вопрос, можно будет плавно перейти к вопросу о целесообразности зашивания OS в ПЗУ.
Специфичность GPU заключается в распарралеливании задачи.
Вычислительное ядро у GPU простенькое, зато их МНОГО.
Но не все задачи могут быть эффективно распарралелены, ибо многие задачи требуют последовательности действий, чтобы для дальнейших вычислений использовать полученные ранее результаты.
Например архивация плохо поддается распарралеливанию, ибо вам нужно проанализировать весь участок данных, чтобы вычислить закономерности на как можно бОльшем участке, иначе степень архивации у вас будет невелика.
Именно по этому принципу Solid архивы, где все файлы сжимаются одним куском (используя в алгоритме данные из предыдущих файлов), гораздо лучше сжимаются, чем если каждый файл независимо.
В видеообработке, где экран можно поделить на участки, и каждый обрабатывать независимо — GPU оказались мегаэффективны.
Где нужно перебрать несколько десятков/сотен вариантов и затем уже по результатам выбрать из них один самый удачный — тоже.
Но опять таки, в большинстве популярных алгоритмов, сложно придумать даже как их разложить на уже доступные 4-8 ядер, не говоря уж о GPU.
Вычислительное ядро у GPU простенькое, зато их МНОГО.
Но не все задачи могут быть эффективно распарралелены, ибо многие задачи требуют последовательности действий, чтобы для дальнейших вычислений использовать полученные ранее результаты.
Например архивация плохо поддается распарралеливанию, ибо вам нужно проанализировать весь участок данных, чтобы вычислить закономерности на как можно бОльшем участке, иначе степень архивации у вас будет невелика.
Именно по этому принципу Solid архивы, где все файлы сжимаются одним куском (используя в алгоритме данные из предыдущих файлов), гораздо лучше сжимаются, чем если каждый файл независимо.
В видеообработке, где экран можно поделить на участки, и каждый обрабатывать независимо — GPU оказались мегаэффективны.
Где нужно перебрать несколько десятков/сотен вариантов и затем уже по результатам выбрать из них один самый удачный — тоже.
Но опять таки, в большинстве популярных алгоритмов, сложно придумать даже как их разложить на уже доступные 4-8 ядер, не говоря уж о GPU.
Специфичность GPU заключается в распарралеливании задачи.Это никак не тянет на специфичность. Попробуйте ещё раз.
Вычислительное ядро у GPU простенькое, зато их МНОГО.
Например архивация плохо поддается распарралеливанию, ибо вам нужно проанализировать весь участок данных, чтобы вычислить закономерности на как можно бОльшем участке, иначе степень архивации у вас будет невелика.Что мешает мне анализировать разные куски, а потом объединить таблицы?
В видеообработке, где экран можно поделить на участки, и каждый обрабатывать независимоНе получится — для этого надо устранить узкое место в виде «все процессоры постоянно читают трёхмерную модель». Или надо ставить столько памяти (причём отдельные микросхемы с независимым доступом), сколько у нас ядер — каждому ядру свою копию трёхмерной модели.
Ладно, вернёмся к моей модели. У меня всего два процессора, оба одноядерные. Как знания о GPU помогут анализировать схему из двух процессоров???
То, что анализируя разные куски, вы теряете возможность анализировать их целиком, например если закономерность встречается на стыке ваших кусков.
Лучше проанализировать 1 мб, найдя в нем все закономерности, чем разделить 1 мегабайт на 512 ядер, анализируя куски по 2 килобайта.
Лучше проанализировать 1 мб, найдя в нем все закономерности, чем разделить 1 мегабайт на 512 ядер, анализируя куски по 2 килобайта.
Ну, заставим процессоры дважды анализировать участки, примыкающие к границам. Т.е. каждый процессор будет анализировать по 2.2 килобайта.
Этого недостаточно. всеравно каждому ядру нужен доступ ко всему содержимому, или как минимум к общему словарю который наполняется по мере анализа данных т.е. последовательно по мере чтения данных и является узким местом.
Этого недостаточно. Если ядра будут пользоваться одним общим словарем, парралельность анализа будет не очень, ибо нужно будет результаты каждой обработки куда-то записывать в общую память. Как это сделать, чтобы не мешать друг другу? Ждать результата выполнения и в очередь, иначе каша. Тут можно даже того, кто будет этот алгоритм кодить пожалеть.
Найдя небольшую закономерность, можно тут же найти закономерность побольше. Найдя закономерность в участке 2.2 кб, вы не сможете определить, существует ли такая в 102 фрагменте и можно ли ее использовать.
В общем подобные вопросы давно рассматривались в темах и идеях для «вечного архиватора», поэтому просто нет смысла повторять все базовые истины.
Найдя небольшую закономерность, можно тут же найти закономерность побольше. Найдя закономерность в участке 2.2 кб, вы не сможете определить, существует ли такая в 102 фрагменте и можно ли ее использовать.
В общем подобные вопросы давно рассматривались в темах и идеях для «вечного архиватора», поэтому просто нет смысла повторять все базовые истины.
Разные процессы/потоки (выполняющиеся на разных ядрах) ведут свои словари и не конфликтуют. А по окончании работы они сливают свои словари (или точнее — словари сливает один главный процесс/поток).
Нельзя найти закономерность побольше сразу. Её находят постепенно.
Если закономерность есть в двух фрагментах — её заметят и там, и там. А потом при слиянии словарей выяснится, насколько эта закономерность сильная.
Только на момент слияния словарей данные должны быть уже сжаты с учетом общего словаря… иначе будут проблемы с распаковкой.
А зачем сжимать словари перед слиянием?
Сначала по исходному тексту строятся словари (параллелится). Затем словари сливаются, получаем общий словарь (практически не параллелится). Потом по этому словарю строим кодировочную таблицу, и этой таблицей кодируем исходный текст (параллелится) — собственно, это и есть компрессия.
Выглядит конечно великолепно но за исключением одного ньюанса — исходные данные надо будет прочитать два раза. Представьте какие накладные расходы при необходимости сжать файл в десяток гигабайт?
Откуда читаем данные — из памяти или с диска? Вроде, в современном мире никто не требует от компрессоров-архиваторов однопроходности.
Так что читаем данные в память — сколько уместится. Разделяем работу по процессорам — они ищут закономерности, потом сливают свои результаты и сжимают данные. Затем данные пишутся на диск, в память читается следующая порция данных, и повторяем.
Простите. Напишите простенький алгоритм сжатия по словарям для обычного процессора и GPU и проведите эксперимент, что будет работать быстрее.
Просто мы вам объясняем не теорию, а то, что уже опробовано многими людьми. Или вы считаете, что автора 7z, rar, arj и др. идиотами, что они до сих пор поддержку gpu не встроили?
Просто мы вам объясняем не теорию, а то, что уже опробовано многими людьми. Или вы считаете, что автора 7z, rar, arj и др. идиотами, что они до сих пор поддержку gpu не встроили?
Созданием больших архивов с высокой компрессией занимается не так уж много людей, и они имеют довольно приличные компьютеры. Поэтому труда понадобится много (теория распараллеливания находится в зачаточном состоянии), а результат получится небольшой.
А ещё нас ждут сложности при запуске нескольких программ, каждая из которых пытается использовать GPU. Делить между задачами CPU — задача давно решённая. А вот с GPU всё немного сложнее, туда вытесняющую многозадачность ещё не прикрутили.
Да ладно вам, если вы напишете архиватор, который будет использовать GPU (он есть в каждом домашнем компе сейчас), то скорость по идее возрастет в десятки раз.
На каждом производстве есть бэкапы. Увеличить скорость создания бэкапа в несколько раз — станете знаменитым на весь мир.
Вы очень много «теоретически» рассуждаете, как все должно хорошо работать, но похоже что вы даже не пытались никогда написать архиватор, который пользуется словарем, и как работает этот алгоритм представляете себе очень плохо. Отсюда эти идеи про «потом словари объединяются».
Напишите, докажите что вы правы.
Я, например пробовал, у меня не вышло, о чем я и пытаюсь пояснить. И многие другие пробовали, пока получить серьезное преимущество от GPU получилось только для проверки/хеширования файлов и блоков.
На каждом производстве есть бэкапы. Увеличить скорость создания бэкапа в несколько раз — станете знаменитым на весь мир.
Вы очень много «теоретически» рассуждаете, как все должно хорошо работать, но похоже что вы даже не пытались никогда написать архиватор, который пользуется словарем, и как работает этот алгоритм представляете себе очень плохо. Отсюда эти идеи про «потом словари объединяются».
Напишите, докажите что вы правы.
Я, например пробовал, у меня не вышло, о чем я и пытаюсь пояснить. И многие другие пробовали, пока получить серьезное преимущество от GPU получилось только для проверки/хеширования файлов и блоков.
Где-то читал, что подглючивание отдельных процессоров в GPU дефектом не считается — подумаешь, пиксель не той цветности получится.
А вот для архивации такое не годится.
А вот для архивации такое не годится.
Как мне недавно объяснили — видеокарта крута не большим количеством независимых процессоров/ядер, а векторными операциями. Т.е. GPU хорошо выполняет операции типа "сложить два массива и положить результат в третий массив (все три массива — одного размера)". А вот выполнять ветвления, каждое из которых зависит от элемента массива — не получается.
В этой парадигме распараллелить анализ текста — не получается. Нужны обычные процессоры с независимыми ядрами.
И что дальше?
железобетонный тролльский аргумент. Всё с вами понятно. Путаете процессоры с контроллерами.
Специфичность GPU это заточенность его ядер под расчеты связанные с графикой, математику на таких ядрах считать можно но не эффективно. Объезжает CPU только за счет количества ядер и более быстрой памяти. Если бы их было не 256 то ещё неизвестно кто был бы быстрее в произвольной математике обычный процессор или GPU.
Ещё раз повторяюсь, для двухпроцессорной системы надо будет поддерживать оба процессора, особенно если они слишком разные. А это и компиляторы и софт… причем на совершенно другом уровне нежели поддержка контроллеров для периферии, где производители делают то что сами хотят ни с кем не согласовывая.
Внутри HDD и Flash находятся МИКРОКОНТРОЛЛЕРЫ, заменить их можно в любой момент только соблюсти внешний интерфейс и для этого всего лишь надо будет переписать прошивку, а не тонну софта.
про установку драйверов Вы не слышали.Драйвера — это проблема операционки а не периферии. Вы когда нибудь слышали про пользовательский софт выполняющийся на сетевой карте?
Не вижу тут никакого троллинга. Вы выкатили аргумент «эта система работает неоптимально». Я ответил «неоптимально работают все системы» и попросил развить тему. А Вы вместо того, чтобы ответить подробнее — перешли на обсуждение личности оппонента.И что дальше?железобетонный тролльский аргумент.
Кстати, троллинг такой фразой не ведётся.
Путаете процессоры с контроллерами.Нет, не путаю. Процессор м.б. частью контроллера. А бывают контроллеры без процессоров.
Специфичность GPU это заточенность его ядер под расчеты связанные с графикой, математику на таких ядрах считать можно но не эффективно.Я уже просил Вас объяснить, в чём специфичность. Чем «расчеты связанные с графикой» — не математика?
Кстати, многие математические задачи делают почему-то на GPU. Дураки, наверно…
Объезжает CPU только за счет количества ядер и более быстрой памяти.Ну и что же мешает сделать CPU с тем же количеством ядер и с такой же памятью?
Хотя зачем быстрая память, если есть кэш?
Ещё раз повторяюсь, для двухпроцессорной системы надо будет поддерживать оба процессора, особенно если они слишком разные.Вы опять забыли, что в обычном компьютере процессоров гораздо больше двух? Что их поддерживают (включая компиляторы)? И что программы для этих процессоров модифицируют независимо?
Внутри HDD и Flash находятся МИКРОКОНТРОЛЛЕРЫА на микрокотнроллерах (или внутри них, если они однокристалльные) находятся МИКРОПРОЦЕССОРЫ (ну или НАНОПРОЦЕССОРЫ).
заменить их можно в любой момент только соблюсти внешний интерфейсО! Наконец-то!
Итак, возвращаемся к моей исходной схеме с двумя процессорами. Почему Вы считаете, что там невозможно соблюсти интерфейс?
Драйвера — это проблема операционки а не периферии.Странно — драйверы обычно пишут производители именно периферии.
А проблемы бывают никак не у устройств, а только у людей.
Вы когда нибудь слышали про пользовательский софт выполняющийся на сетевой карте?Я давно уже не видел пользовательский софт. Мне всё больше попадается софт разработчиков, которые делает не то, что нужно пользователям, а то, что нужно разработчикам — например, шпионит за пользователем.
«расчеты связанные с графикой» — не математика?Я бы сказал что это не математика а арифметика, причем преимущественно в целых числах. А по-настоящему математические расчеты — это как минимум безразмерные числа, которые гарантированно не поместятся в любой фиксированный размер. Например, числа с 10000 значащими разрядами.
Ну и что же мешает сделать CPU с тем же количеством ядер и с такой же памятью?
Хотя зачем быстрая память, если есть кэш?
Накладные расходы на синхронизацию между процессорами и общей шиной. Чем больше ядер тем больше конфликтов на общей шине и тем меньше эффективность многоядерности. Современные процессоры имеют большое количество инноваций, позволяющих уменьшить эту проблему — гипертрединг, отдельные кеши для каждого ядра/процессора и т.д. Но всеравно идеала достичь не удаётся. GPU же имеют заточенную под многопоточность архитектуру, в основном за счет простоты ядер, которым легко даются векторные расчеты но очень тяжело обычные для CPU вещи вроде условных переходов, циклов…
В целом GPU для расчетов используют там где CPU недостаточно быстр(рендеринг видео, видео кодеки, и т.д.) а математический модуль слишком дорог или необоснован. В конце концов, GPU более распространён и уже есть в системе условно бесплатно.
А насчет быстрой памяти… кеш хорош пока алгоритм и объем данных очень мал и полностью укладывается в кеш — нынче это считанные десятки килобайт и коэффициент повторного использования данных больше единицы, а дальше начинается фигня и начинает играть роль скорость работы основной памяти.
Вы опять забыли, что в обычном компьютере процессоров гораздо больше двух? Что их поддерживают (включая компиляторы)?
Вот только цикл поддержки у этих процессоров очень разный. В сетевой карте, как правило, прошивка заливается один раз и до её смерти. Поэтому и поддержка компилятора совсем другая, в другой ревизии той же сетевой карты вообще может применяться совсем другой компилятор не совместимый с предыдущим и команда разработки может быть другой. Для ваших же процессоров для обоих сразу нужно будет поддерживать два разных компилятора в актуальном состоянии и обеспечивать совместимость с предыдущими версиями иначе попоболь и проблемы гарантированы. А это как минимум в 2 раза больше ресурсов на разработку!
возвращаемся к моей исходной схеме с двумя процессорами. Почему Вы считаете, что там невозможно соблюсти интерфейс?Где я говорил что невозможно соблюсти? Очень даже возможно, но в два раза затратней по ресурсам разработки чем в системе с однотипными процессорами. Проще накинуть одинаковых ядер чем использовать два разных процессора. А в перспективе это покроет накладные расходы на эмуляцию старого процессора. Поэтому жизнь гибридной системы не имеет перспектив и не стоит затраченных усилий.
Странно — драйверы обычно пишут производители именно периферии.Давно уже не так… очень нужна эта морока производителям писать драйвера под все существующие системы и с десяток специфических систем для эмбеддеров. Даже за деньги. Как правило, от производителя железа это драйвера на 1-2 популярных систем и не более. Обычно это проблема производителя операционной системы заинтересованного в работе железа на его системе.
Я бы сказал что {расчеты связанные с графикой} не математика а арифметика, причем преимущественно в целых числах.Арифметикой занимается процессор. Причём при выполнении любой работы. Это у него механизм такой.
А вот программист занимается математикой, алгоритмами.
Про целые числа — сообщите скорее авторам OpenGL, что они неправильно работают.
И тут (на Хаббре или на GT) на днях пробегала статья о том, как можно быстро приближённо вычислить функцию 1/sqrt(x) для плавающих чисел — там что-то было про магическое число. И обсуждалось это именно в связи с графикой.
А по-настоящему математические расчеты — это как минимум безразмерные числа, которые гарантированно не поместятся в любой фиксированный размер. Например, числа с 10000 значащими разрядами.Доказать или обосновать можете? Пруфы есть?
Накладные расходы на синхронизацию между процессорами и общей шиной.«Общая шина» — это что такое? Какие устройства она объединяет?
Чем больше ядер тем больше конфликтов на общей шине и тем меньше эффективность многоядерности.Допустим, в процессоре есть четыре ядра и общий кэш для всех ядер. Этот кэш разделён на два слоя — первый слой кэширует чётные адреса памяти, второй — нечётные (адрес — это номер сточки памяти, а не байта; строчка памяти по размеру равна строчке кэша).
Теперь у нас нет общей шины, а есть две шины. Процессор при обращении знает, в какой из слоёв кэша надо обращаться. Если обращения распределены равномерно — то количество конфликтов падает в два раза.
А теперь сделаем в кэше 16 слоёв — и конфликты становятся совсем редкими.
Современные процессоры имеют большое количество инноваций, позволяющих уменьшить эту проблему — гипертредингА гипертрединг тут чем помогает? Он скорее увеличивает число коллизий.
отдельные кеши для каждого ядра/процессораА вот отдельные кэши как раз надо синхронизировать.
кеш хорош пока алгоритм и объем данных очень мал и полностью укладывается в кешВы бы теорию кэширования почитали, что ли. Про локальность в пространстве и во времени. Про периоды высокого hit rate и периоды активной замены содержимого кэша.
Для примера можете оценить размер кода и данных у Word/Excel. Затем сравнить это с размером кэша. Получается, кэш вообще неэффективен.
А теперь отключите кэш и проверьте скорость работы.
нынче это считанные десятки килобайтА я читал — что размер L2-кэша уже десятки мегабайт.
Вот только цикл поддержки у этих процессоров очень разный.Вы так говорите, как будто я настаивал на том, чтобы цикл поддержки был одинаковый.
В сетевой карте, как правило, прошивка заливается один раз и до её смерти. Поэтому и поддержка компилятора совсем другая, в другой ревизии той же сетевой карты вообще может применяться совсем другой компилятор не совместимый с предыдущим и команда разработки может быть другой.Ну так при выпуске нового ядра операционки (типа перехода от W'XP к W'Vista; или при смене мажорной цифры в версии FreeBSD) и при выпуске новой версии прикладной программы — точно так же можно сменить компилятор. Не вижу разницы.
Для ваших же процессоров для обоих сразу нужно будет поддерживать два разных компилятора в актуальном состоянииУ меня такое ощущение, что Вы опять забыли, о чём разговор.
А разговор был о том, чтобы осуществить переход от DOS-8086 к нормальному процессору, сохраняя совместимость УЖЕ НАПИСАННЫХ и ОТКОМПИЛИРОВАННЫХ ПРОГРАММ. Т.е. для устаревающего DOS-8086 все компиляторы уже есть, но развивать их уже нет смысла. И создавать новые программы (а значит, компилировать их) уже никто не будет.
Очень даже возможно {соблюсти интерфейс}, но в два раза затратней по ресурсам разработки чем в системе с однотипными процессорами.Разделение работы компьютера на два процессора означает разделение по уровням абстракции и надёжную изоляцию этих уровней абстракции. Затраты на разработку если и вырастут — то незначительно.
А вот затраты на отладку (на обеспечение надёжности и секурности) — резко снизятся.
Проще накинуть одинаковых ядер чем использовать два разных процессора.Создатели модемов, HDD, видеоускорителей, сетевых карт, RAID-контроллеров и много чего ещё — смотрят на Вас с недоумением. Расскажите им скорее, какие они придурки — что начали совать в свои изделия процессоры ещё до того, как CPU стали многоядерными. (Кстати — заодно мы имеем достоверный ответ на вопрос о том, что проще.)
Как правило, от производителя железа это драйвера на 1-2 популярных систем и не более. Обычно это проблема производителя операционной системы заинтересованного в работе железа на его системе.Ок. Я вернусь к Вашему утверждению «как правило пользователю не надо ставить для {периферийных устройств} какой-либо софт». Оказывается, его надо не только ставить, но ещё и писать отдельно под каждую операционку!
В PIO-режиме как раз нет никаких IRQ, это полностью программный режим работы исключительно через порты ввода-вывода.
Прямой доступ в память как раз реализовали для разгрузки центрального процессора, чтобы он не оказался узким местом в процессе передачи данных. И более того, скорость общения устройствами с памятью тоже ограничена скоростью шины PCI и PCI-E, которая в разы меньше пропускной способности шины памяти.
Прямой доступ в память как раз реализовали для разгрузки центрального процессора, чтобы он не оказался узким местом в процессе передачи данных. И более того, скорость общения устройствами с памятью тоже ограничена скоростью шины PCI и PCI-E, которая в разы меньше пропускной способности шины памяти.
В PIO-режиме как раз нет никаких IRQ, это полностью программный режим работы исключительно через порты ввода-вывода.А вот что врёт на эту тему Википедия: В этом режиме контроллер требовал исполнения драйвером или же BIOSом команды процессора REP INSW/OUTSW для передачи всех данных, обычно команда исполняется в обработчике прерывания контроллера в статусе «готов к передаче данных».
(Термин «прерывание контроллера», очевидно, как раз обозначает IRQ.)
Давайте подумаем, что здесь может сильнее тормозить: прерывание или же каманда «REP INSW/OUTSW».
Прерывание, особенно в защищённом режиме, особенно на современных процессорах — штука дико дорогая, ибо ломает конвейер (а у современных процессоров он весьма длинный), переключает процессор в режим ядра (т.е. заставляет изменить многие параметры — а это требует времени), перегружает кэш. Кроме того, процессор должен программно сохранить регистры и по завершении работы восстановить их значения, а также дать команду возвращения в режим задачи (или что там было прервано), и возврат тоже требует немало времени.
С др.стороны, неясно, сколько времени будет выполняться каждая команда «INSW/OUTSW» в цикле «REP». И это зависит от массы параметров, начиная с наличия буфера на контроллере диска (что-то мне подсказывает — начиная где-то с 386, он там должен быть обязательно; но я могу и ошибаться).
Прямой доступ в память как раз реализовали для разгрузки центрального процессора, чтобы он не оказался узким местом в процессе передачи данных.Я в курсе.
скорость общения устройствами с памятью тоже ограничена скоростью шины PCI и PCI-E, которая в разы меньше пропускной способности шины памяти.Если мы говорим про работу с HDD, то эти ограничения ничтожны на фоне тормознутости механической системы. Да и Flash-память тоже небыстрая.
Основная экономия получается от того, что прихода данных ожидает не дорогой CPU (или в многоядерном CPU — одно его ядро, что тоже недёшево), а дешёвенький DMA-контроллер, который простой (например, потому что не содержит FPU) способен обходиться без кэш-памяти.
Обычно она выполняется в прерывании, да, но в PIO-режиме не используются прерывания от привода или по крайней мере само прерывание выполняется лишь один раз на запрос — например как сигнал о том что с привода можно считать запрошенные 32 сектора каждый по 512байт. Проблема в другом — если DMA ложит данные прямо в указанный буфер без участия процессора, то в PIO-режиме процессор самостоятельно извлекает данные через регистры привода, а это обращения к портам ввода-вывода которые исполняются в лучшем случае по 100 тактов процессора на каждые 2 считанных байта. Вроде мелочь, но загружает процессор под завязку на высоких скоростях который практически не может в течении этих 100 тактов ничего другого делать. А поскольку все операции настолько низкоуровневого ввода-вывода осуществляются в ядре и с высоким приоритетом то остальным задачам сильно не достаёт ресурсов и даже парализуется работа аудиоподсистемы которая хоть и с использованием DMA работает, но буфер кому-то надо пополнять а процесс этот из менее приоритетных.
Хм-м-м… А разве привод может давать прерывания? Разве он имеет доступ на шину ISA/PCI, где проходят линии прерывания?
Я всегда думал, что это делает не привод, а контроллер, устанавливаемый в слот шины. А этот контроллер может иметь собственную буферную память.
Откуда у Вас сведения о том, что "обращения к портам ввода-вывода которые исполняются в лучшем случае по 100 тактов процессора на каждые 2 считанных байта"? Для какого процессора и какой шины это выведено?
PS: Я привык подвергать сомнению каждое услышанное мной слово. И особенно — число.
Какой там контроллер… обычная логика на совпадение адреса(обычно двух — для master и slave), буффер для трёх адресных линий, сигнала CS(выбор master/slave) и двунаправленный регистр-защёлка для изоляции от шины. А сам «контроллер» находится в приводе и имеет отдельный выход запроса прерывания, который потом со слота PCI напрямую заводится на контроллер прерываний. Да, если сделать небольшой генератор(NE555) на IDE-шину можно запросто повесить систему завалив её запросами прерывания от несуществующего привода.
На самом деле всё что делает «драйвер IDE» в винде — это резервирует адресное пространство — два участка по 8 адресов чтобы их не заняли другие драйвера как и для большинства системных устройств.
Дальше — шина 16-битная(в случае IDE), поэтому за одно обращение к порту передаётся 2 байта, а одно обращение к порту, инструкция заставляет ожидать выполнения транзакции на шине — а PCI хоть и внутри чипсета но работает на частоте порядка 30Мгц… сколько тактов процессора пройдёт за один цикл работы шины? Порядка сотни… и это в случае если арбитр шины СРАЗУ ЖЕ даст доступ запрашиваемому устройству, ведь в этот момент шина может использоваться более приоритетным обменом. По этой причине, ещё со времен первых пентиумов стараются уйти от интенсивного обмена через порты используя окна в RAM но и это не сильно помогает — всеравно обмен с УВВ идёт гораздо медленней чем может работать RAM — узкое место это скорость работы шины и она никогда не сможет работать быстрее пока не перейдут на последовательную передачу данных чем собственно и является PCI-E, но… память тоже не стоит на месте там тоже хотят вводить последовательный интерфейс который будет ещё быстрее.
Да, насчет тактов для команды чтения-записи в порты я когда-то читал в справочнике по ассемблеру. Там была написана цифра примерно от 100 и до бесконечности. А замерить реальное время исполнения чего-то идея в голову не пришла… я ж тогда чуть было не сделал свой PCI-девайс вроде 16-битного регистра на свободном адресе, но нехватка времени и идея была похоронена а сейчас что-то уже не хочется в такие мелочи, хотя уверен что смог бы — там больше возни с драйвером на современных операционках.
На самом деле всё что делает «драйвер IDE» в винде — это резервирует адресное пространство — два участка по 8 адресов чтобы их не заняли другие драйвера как и для большинства системных устройств.
Дальше — шина 16-битная(в случае IDE), поэтому за одно обращение к порту передаётся 2 байта, а одно обращение к порту, инструкция заставляет ожидать выполнения транзакции на шине — а PCI хоть и внутри чипсета но работает на частоте порядка 30Мгц… сколько тактов процессора пройдёт за один цикл работы шины? Порядка сотни… и это в случае если арбитр шины СРАЗУ ЖЕ даст доступ запрашиваемому устройству, ведь в этот момент шина может использоваться более приоритетным обменом. По этой причине, ещё со времен первых пентиумов стараются уйти от интенсивного обмена через порты используя окна в RAM но и это не сильно помогает — всеравно обмен с УВВ идёт гораздо медленней чем может работать RAM — узкое место это скорость работы шины и она никогда не сможет работать быстрее пока не перейдут на последовательную передачу данных чем собственно и является PCI-E, но… память тоже не стоит на месте там тоже хотят вводить последовательный интерфейс который будет ещё быстрее.
Да, насчет тактов для команды чтения-записи в порты я когда-то читал в справочнике по ассемблеру. Там была написана цифра примерно от 100 и до бесконечности. А замерить реальное время исполнения чего-то идея в голову не пришла… я ж тогда чуть было не сделал свой PCI-девайс вроде 16-битного регистра на свободном адресе, но нехватка времени и идея была похоронена а сейчас что-то уже не хочется в такие мелочи, хотя уверен что смог бы — там больше возни с драйвером на современных операционках.
Что-то мне кажется, что Вы пишете сведения, относящиеся к IDE-контроллерам/устройствам на шине ISA. Потому что IDE как раз проектировался так, чтобы IDE-контроллер был как можно проще; правда, для этого на брюхо HDD пришлось ставить собственный процессор, особенно когда сообщаемая компьютеру геометрия перестала соответствовать реальной.
Интересно, что это был за справочник? В хорошем справочнике д.б. указано, для какой архитектуры эти цифры. А то ведь даже внутри одной архитектуры есть довольно широкий диапазон значений — например, P'I (без MMX) мог иметь частоту от 66 до 200 мегагерц. На том же P'I обыычо были две шины — ISA и PCI, у которых скорость различалась примерно в восемь раз. И скорость диска тоже может различаться очень сильно.
Если Вам хочется баловаться с собственным устройством — есть FreeDOS. И вроде, под современные операционки есть особый драйвер, позволяющий дёргать порты ввода-выводв и получать сообщения о прерываниях из user-space программ.
От шины работа контроллера IDE никак не зависит. Работа с ним как велась так и ведётся через 8 портов ввода-вывода.
От архитектуры скорость выполнения операций ввода-вывода зависит слабо, хотя да для Z80 работа с портами была столь же быстра как и с памятью. Даже на модных STM32 операции ввода-вывода очень медленны по сравнению с ядром. Может не 100 тактов, а допустим 30 в лучшем случае, это сильно дело не меняет. В худшем случае окончания операции можно и не дождаться из-за того что шину захватит агрессивное устройство вроде TV-тюнера которое будет гнать поток на полной скорости шины и не даст никому голову поднять(зависит, конечно, от настроек арбитра шины но это настраивается где-то глубоко в чипсете, и возможно концы выведены в БИОСе вроде опции spread spectrum).
Справочник был по ассемблеру процессоров серии Pentium.
От архитектуры скорость выполнения операций ввода-вывода зависит слабо, хотя да для Z80 работа с портами была столь же быстра как и с памятью. Даже на модных STM32 операции ввода-вывода очень медленны по сравнению с ядром. Может не 100 тактов, а допустим 30 в лучшем случае, это сильно дело не меняет. В худшем случае окончания операции можно и не дождаться из-за того что шину захватит агрессивное устройство вроде TV-тюнера которое будет гнать поток на полной скорости шины и не даст никому голову поднять(зависит, конечно, от настроек арбитра шины но это настраивается где-то глубоко в чипсете, и возможно концы выведены в БИОСе вроде опции spread spectrum).
Справочник был по ассемблеру процессоров серии Pentium.
особый драйвер, позволяющий дёргать порты ввода-выводаДрайвер то есть, но на 10-ке он не идёт насколько я знаю т.к. не имеет цифровой подписи и врятли её когда-либо получит. Да и в любом случае наличие такого драйвера в системе это огромная брешь в безопасности. FreeDos это конечно хорошо, но опять же — только для поиграться и не более. Использовать-то устройство захочется в современных операционках!
От шины работа контроллера IDE никак не зависит. Работа с ним как велась так и ведётся через 8 портов ввода-вывода.«8 портов ввода-вывода» — это внешний интерфейс контроллера. А внутри м.б. что угодно — например, вместо классического HDD можно распаять Flash прямо на плате.
В данном случае на контроллере м.б. буферная память, в которую контроллер примет данные от диска и будет отдавать со скоростью шины.
А ещё бывают вирт.машины, в которых PIO-mode эмулируется программно (ну, если система эмулируется достаточно тщательно). И там скорость ответа немного совсем другая.
От архитектуры скорость выполнения операций ввода-вывода зависит слабоЗато длительность такта процессора зависит очень и очень сильно.
Впрочем, от архитектуры тоже зависит достаточно много — например, ISA, EISA, VESA/VLB, PCI и PCI-X имеют очеь разную скорость. А ещё я знаю про MCA и PCI-64.
хотя да для Z80 работа с портами была столь же быстра как и с памятьюНу так на первых писюках (8086; а возможно, и 286) память сидела на той же шине, что и порты.
Драйвер то есть, но на 10-ке он не идёт насколько я знаю т.к. не имеет цифровой подписи и врятли её когда-либо получит.Ну а кто мешает внедрить в систему свою собственную корневую подпись (которая удостоверяет подпись производителей драйверов)?
Да и в любом случае наличие такого драйвера в системе это огромная брешь в безопасности.Вы так говорите, как будто Ваши эксперименты хоть немного соответствуют той модели безопасности, которую обеспечивают подпись на драйверах.
Использовать-то устройство захочется в современных операционках!Linux, *BSD — к Вашим услугам. Там ещё и исходный код открыт.
Так это и есть контроллер на плате HDD. Он и обеспечивает тот самый интерфейс, а то что на материнке — просто жесткая(но конфигурируемая в некоторых пределах) логика изолирующая контроллер от шины и обеспечивающая работу по конкретному адресу.
А, да… эмуляция команд ввода-вывода в виртуалке ещё более накладна чем в железе поскольку обрабатывается особым образом.
Ну а кто мешает внедрить в систему свою собственную корневую подпись (которая удостоверяет подпись производителей драйверов)?Куда втыкнуть? Насколько я знаю, 10-я винда этому сопротивляется. Они стараются быть монополистами в подписи драйверов, особенно системных. Иначе утечка сертификата и разгул вирусов. не все дрйверописатели, например, держат свои подписи достаточно надёжно. Ну да, сертификат могут отозвать но… это потребует времени.
Вы так говорите, как будто Ваши эксперименты хоть немного соответствуют той модели безопасности, которую обеспечивают подпись на драйверах.Если не ошибаюсь, тот драйвер может безпрепятственно дать доступ к CMOS-памяти, или портам IDE и напрямую в обход системы общаться с железом — так что потенциальному взломщику/трояну любые антивирусы побоку. Поэтому, микрософт так зажимает гайки с подписью драйверов. На 8-ке вроде ещё был доступен режим отключения проверки подписи, но на 10-ке безальтернативно. Если хочешь свой драйвер — через специальную приблуду пиши, которая работает с пониженными привилегиями и не имеет доступа к ядру.
Linux, *BSD — к Вашим услугам. Там ещё и исходный код открыт.А толку-то? Что я с линуксом делать буду? Тоже поиграться и выбросить за ненадобностью… держать и постоянно перезагружаться в него только для драйвера на собственную железку?
А, да… эмуляция команд ввода-вывода в виртуалке ещё более накладна чем в железе поскольку обрабатывается особым образом.
Если очень хочется подписать драйвер бесплатно, то выход есть.
то что на материнке — просто жесткая(но конфигурируемая в некоторых пределах) логика изолирующая контроллер от шины и обеспечивающая работу по конкретному адресу.Когда-то давно COM-порт представлял собой простейшую логику, преобразующую один байт от процессора в последовательность битов по одной линии (и наоборот). Но позже туда впихнули буферную память, благо интерфейс общения процессора с COM_портом позволял это сделать вполне прозрачно.
Я думаю, что IDE-контроллеры (на самом деле — ATA, а не IDE, но это не важно) давно уже обзавелись собственной буферной памятью — чтобы отдавать данные процессору (и принимать их от процессора) со скоростью шины, а не интерфейса диска.
При этом у меня есть все основания полагать, что дисковый интерфейс медленне шины — хотя бы потому, что у него меньше разрядность, а кабедь длиннее и при этом гибкий. Шина же имеет больше разрядов, короткая и жёсткая.
Куда втыкнуть?Хороший вопрос. Очевидно, что M$ не станет раскрывать подробности устройства хранилища подписей. Так что нао чистать хакерские форумы.
Я полагаю, что M$ не может сама написать все драйверы — и предоставляет такую возможность производителям устройств. При этом вряд ли производители устройств имеют способ оперативно подписывать свои драйверы подписью, которая хранится в M$ — слишком опасно.
Поэтому я полагаю, что система электронных подписей слизана с системы удостоверения подписей в Интернете: подписи авторизованных драйверописателей удостоверены подписью от M$, а дальше драйверописатели сами подписывают своей подписью что хотят. А в Windows хранится корневая подпись; причём с возможностью замены при компрометации.
Хуже всего — если корневая подпись интегрирована прямо в исполняемый файл в виде константы.
Если не ошибаюсь, тот драйвер может безпрепятственно дать доступ к CMOS-памяти, или портам IDE и напрямую в обход системы общаться с железом — так что потенциальному взломщику/трояну любые антивирусы побоку.Если Вы устанавливаете себе в систему свои самодельные устройства — то глупо плакать о софтверной безопасности.
Что я с линуксом делать буду?Да то же самое, что и с Виндой. Большинство программ имеют аналоги в Linux; что не имеет — можно запускать в WINE или в вирт.машине с Windows.
эмуляция команд ввода-вывода в виртуалке ещё более накладна чем в железе поскольку обрабатывается особым образомЗато это подобный образ не обращается к шине!
Я думаю, что IDE-контроллеры (на самом деле — ATA, а не IDE, но это не важно) давно уже обзавелись собственной буферной памятью — чтобы отдавать данные процессору (и принимать их от процессора) со скоростью шины, а не интерфейса диска.Буферная память есть, но на самом диске.
Сначала головка читает с диска, где-то на скорости 800 Мb/с. Предварительно потратив сколько-то там времени на позиционирование головки. А потом сливает данные по SATA на 3/6 Gb/s. Только вот если читать с внутреннего конца процессором — то оно побайтно получается, а специальный чип dma умеет лить в память потоком.
Я видел SATA-контроллеры на шину PCI. А на современных мат.платах SATA-контроллеры интегрированные; и, очевидно, там безслотовая шина PCI.
Как будет лить данные HDD? Должен ли он знать, на какой шине контроллер? Не логичнее ли сделать буферную память ещё и на контроллере (не на диске, а с другого конца SATA-кабеля)?
(Есть такой принцип: "сочетание каналов с разной скоростью — требует буферной памяти". SATA и PCI — это явно каналы с разной скоростью. Правда, буфером может работать память на брюхе диска.)
А ещё есть RAID-контроллеры. И про них пишут, что там есть собственная память — чуть ли не в виде стандартных модулей памяти. Неужто брешут?
Ну вот сейчас посмотрел — в контроллере в самом деле есть немножко памяти, 8К, 2К и 256 байт.
А в RAID там не только память мегабайтами, но и собственный процессор.
А в RAID там не только память мегабайтами, но и собственный процессор.
Память в «контроллере» нужна только чтобы обеспечить BURST-режим(накапливает с накопителя на скорости 100мб/сек и отдаёт пачкой в шину как та освободится на скорости 2гб/сек) для шины, поэтому её там килобайты… и используется она только в режиме DMA, когда идет программный обмен данные читаются «по одному» и пакетный режим просто не применим. А RAID-контроллеры это совсем другой вопрос, это как аппаратный ускоритель дисковых массивов и задачи у него совсем другие — например собрать информацию с 10 накопителей, посчитать контрольную сумму, отработать алгоритмами коррекции ошибок и передать в систему, понятное дело для таких операций нужны объёмы памяти для хранения перед передачей.
" Если бы IBM, а не Microsoft, контролировала бы MS-DOS, Windows и прочих, мир компьютеров был бы совершенно другим."
и скорее всего намного менее удобным.
и скорее всего намного менее удобным.
Ну, как сказать… Если бы победил, скажем, 68000, то в архитектуре большинства современных компьютеров было бы два стека и было бы меньше роблем с безопасностью из-за переполнения стека.
не, я про UI/UX — у межделмаша вполне могла пойти отговорка «не понимаете как этим пользоваться? пройдите наши курсы всего за $199,95/занятие»
Вообще-то у x86 (ia32 и x64) уже несколько десятилетий существует возможность использовать свой стек для каждого уровня привилегий, автоматически переключаемый при переключении задач. Иначе пользовательское приложение получило бы возможность испортить стек привилегированных процедур ОС, а это абсолютно недопустимо.
А стек данных можно отдельно сделать от стека адресов возвращения?
Хороший вопрос, но обычно стек данных в x86 архитектуре в Форт системах делают через использование BP регистра.
P.S. Любители, кстати, запускают Forth на процессоре из статьи turboforth.net
и снимают видео.
P.S. Любители, кстати, запускают Forth на процессоре из статьи turboforth.net
и снимают видео.
Аппаратной поддержки для такого разделения стеков в x86 нет.
Да, есть опасность потери управления вследствие несоответствия количества инструкций PUSH при входе в процедуру и POP при выходе из процедуры. Разработчики x86 посчитали что важнее изолировать стеки между уровнями привилегий, защищая ОС от ошибок в приложениях, чем защищать приложения от самих себя.
Да, есть опасность потери управления вследствие несоответствия количества инструкций PUSH при входе в процедуру и POP при выходе из процедуры. Разработчики x86 посчитали что важнее изолировать стеки между уровнями привилегий, защищая ОС от ошибок в приложениях, чем защищать приложения от самих себя.
Они вообще ничего не считали, в первых x86 ничего ни от кого защищать не требовалось, просто не хотели копировать конкурентов. А потом уже пошло «а зачем второй стек, если все равно весь софт использует только один». Вот теперь и сидим с тем что есть в мире, где с переполнением буферов борятся уже лет 30.
30-летняя борьба с переполнением буферов, сравнительно недавно завершилась успехом. Технология MPX предусматривает отдельную защиту от несанкционированной модификации данных на уровне привилегий пользователя.
Каким образом это защитит от переполнения буфера? В четыре регистра никак не влезет весь список локальных переменных на стеке. Или перед каждой операцией загружать в эти регистры адреса используемых массивов? :)
От переполнения не защитит, но защитит от последствий — приложение сможет навредить только себе и не позволит выполнить код с более высокими привилегиями, для чего собственно и эксплуатируют переполнение.
Дополнительно вводится понятие «таблиц границ», которые хранят описания диапазонов памяти, в случае нехватки регистров границ.
Если стек общий (без разделения на стек адресов возврата и стек данных), то серия записей в память по PUSH на входе или POP на выходе из подпрограммы, попадет в ту же самую строку (или группу последовательных строк) кэш-памяти, что и ранее сохраненный адрес возврата. Это кэш-попадание в сравнении с обращением к ОЗУ при кэш-промахе может сэкономить сотни процессорных тактов.
Учитывая что в мейнфреймах IBM стека и прерываний ЕМНИП вообще не было — могло быть и в обратную сторону…
и скорее всего намного менее удобным.
Спорный вопрос. Та-же os/2 в плане юзабельности интерфейса была неплоха.
возможно, сильно попользоваться ей не получилось. но и чисто мдмовской разработкой оно тоже небыло.
OS/2 без MS/DOS просто не было бы, а IBM разрабатывала бы вместо этого версии своих OS, адаптированных с мэйнфреймов, выпуская минорные апгрейды раз в 10 лет, стоимостью в пятизначные суммы в долларах.
В общем, нынешний Oracle на этом фоне выглядел бы невинным ягненком.
В общем, нынешний Oracle на этом фоне выглядел бы невинным ягненком.
История, как говорится, не знает сослагательного наклонения, поэтому не буду спорить что-бы представляла из себя полуось, но я говорил именно про UI. А он был основан на, скажем так, методологии CDE. В принципе, по той же методологии делали UI и SUN в своей соляре. Речь, естественно, идет о полуоси версий 3 и выше.
Ну и если бы не было MS (компания) полуось бы не была так коряво спроектирована в части ядра. UNIX был в этом отношении более зрелым.
Ну и если бы не было MS (компания) полуось бы не была так коряво спроектирована в части ядра. UNIX был в этом отношении более зрелым.
В данном случае вполне знает, так как хорошо известно, какой была IBM в 80-х (ну и 30 предшествующих лет), что заставило ее измениться, откуда вообще возникла идея создавать OS/2 как таковую, кто первоначальную версию писал, и так далее.
И, кстати, какое отношение UI имеет к OS? Настолько ли важное, чтобы говорить о нем, в отрыве от OS? Это какое-то «не для хабра» представление о компьютерах.
И, кстати, какое отношение UI имеет к OS? Настолько ли важное, чтобы говорить о нем, в отрыве от OS? Это какое-то «не для хабра» представление о компьютерах.
настолько — типичному пользователю достаточно пофиг, что там под капотом; ему надо чтоб удобно было и обои нескучные.
(ну и вспоминаем количество разных гуев в линухах и срачей вокруг них)
(ну и вспоминаем количество разных гуев в линухах и срачей вокруг них)
Мне казалось, что на Хабре и ГТ все же собираются люде НЕ называющие системный блок «процессором».
и-и-и, ваша идея? посадить всех на идеально стройное железо и систему с интерфейсом, кривая обучения у которой будет а-дя Dwarf Fortress?
кажется, мы это уже проходили где-то в 60е, когда программист и оператор эвм были двумя разными людьми.
кажется, мы это уже проходили где-то в 60е, когда программист и оператор эвм были двумя разными людьми.
Моя идея — оставить все как есть ;) (кстати откуда у вас взялась мысль, о том, что я предлагаю какой-то другой вариант?)
Мне как раз кажется, что получившийся результат — умеренно лучший, и уж точно лучший чем «будущее по версии IBM образца 1985-го».
Я лишь обратил внимание, что стенать «ах этот мелкософт, если бы не он, ИБМ построило бы счастье с полуосью и презентеэйшн менеджер!» не очень разумно, и совершенно неисторично. Без MS мы бы в MVS программировали на PL/1 и прочих скулосворачивающих от тоски штуках.
Мне как раз кажется, что получившийся результат — умеренно лучший, и уж точно лучший чем «будущее по версии IBM образца 1985-го».
Я лишь обратил внимание, что стенать «ах этот мелкософт, если бы не он, ИБМ построило бы счастье с полуосью и презентеэйшн менеджер!» не очень разумно, и совершенно неисторично. Без MS мы бы в MVS программировали на PL/1 и прочих скулосворачивающих от тоски штуках.
Основное отличие OS/2 от Win в тот момент было, что пока OS/2 шлифовала UI, MS штамповала драйвера и совместимость под все, что было.
В результате юзер мог поставить Win, и поругиваясь на глюки работать.
А чтобы поставить OS/2, надо было долго трахаться с драйверами, чтобы завелись все нужные устройства. А потом уже да, можно было радоваться.
Например для фидошной ноды, где нужен был только рабочий модем и tmail, OS/2 была хорошей заменой винды в плане стабильности работы.
Но для себя, каждый апгрейд — головная боль. Прикладного ПО и игрушки — под Вин появлялись как грибы.
В результате юзер мог поставить Win, и поругиваясь на глюки работать.
А чтобы поставить OS/2, надо было долго трахаться с драйверами, чтобы завелись все нужные устройства. А потом уже да, можно было радоваться.
Например для фидошной ноды, где нужен был только рабочий модем и tmail, OS/2 была хорошей заменой винды в плане стабильности работы.
Но для себя, каждый апгрейд — головная боль. Прикладного ПО и игрушки — под Вин появлялись как грибы.
Microsoft контролирует часть мира компьютеров.
Есть ещё Apple, которые легко поменяли процессор в своих ПК на x86 от Intel.
Есть ещё Apple, которые легко поменяли процессор в своих ПК на x86 от Intel.
Да не сказать что на ходу поменяли. Скорее реинкарнация после смерти. С созданием новой ОС.
Ну если капнуть глубже то Apple несколько раз меняла процы — первый раз с, уже упомянутой в статье, Motorola на PowerPC и второй раз с PowerPC на Intel
производитель предоставил тысячи примеров выпущенного продукта
Образцы наверное?
Наверное, уместным будет здесь клип Мэка Дэйвиса «It's Hard To Be Humble»
Спасибо.
Вы выбрали очень интересную статью для перевода.
Вы выбрали очень интересную статью для перевода.
Семейство 320 DSP и его производные начали приносить почти половину всей прибыли TI
Оказывается его копии — микросхемы 1867ВМ7Т, 1967ВЦ1Т, 1910ВМ1Т, 1901ВЦ1Т.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Внутренняя история крупнейшей ошибки Texas Instruments, микропроцессора TMS9900