Ещё - к возможным недавним АИ в компьютерах

195 сообщений в этой теме

Опубликовано:

Не взлетит ибо АРМ проигрывает нормальным х86 даже сейчас.

Фокус в том, что мак соревнуется прежде всего с маком, так что им достаточно быть не медленней старых powerPC.

А полноценная виртуалка имеет слишком большие накладные расходы.

Я бы не сказал, на примере того же x86, если процессор поддерживает виртуализацию, то потерями можно пренебречь.

В современных ОС для каждого приложения создается изолированная "песочница".

"Песочница" - это все-же не совсем то, думаю Вы в курсе различий.

Вын10... ;) Теоретически.

Да, где-то так, главное  - магазин приложений и проверка на совместимость. Для маков, благодаря отсутствию зоопарка систем выигрыш максимален. А реальная виндоус должна работать везде и в результате нигде без багов не выходит :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

И кстати, есть работы над 128-битовыми программами?

А зачем? Для наивной арифметики и 32 часто хватало, а 64х битов и подавно хватит. Для адресации тоже, столько физической памяти просто не бывает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

По идее, тем самым можно увеличить точность передачи информации. И при шифровании удобно использовать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

По идее, тем самым можно увеличить точность передачи информации.

 

Чтобы ее передавать, надо сначала ее получить. Датчики, способные различить 340282366920938463463374607431768211456 уровней входящего сигнала встречаются не часто :)

 

Я вообще не уверен, что физические законы нашего мира позволяют вот так просто взять и создать нечто подобное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

))) ГлАвное нАчать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено)

В треде в "авиации" :) выложили линк на это

http://forum.bandits-clan.ru/index.php?showtopic=6226

Авиалинии UNIX
Все пассажиры приезжают в аэропорт с собственными деталями от самолета, затем собираются на взлетной полосе и начинают его строить, ни на секунду не переставая спорить о том, какого же именно типа самолет они строят.

Изменено пользователем MGouchkov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Помнится, в 70-е - 80-е в советских тогдашних сервер-терминальных системах использовали ОС - СВМ (система виртуальных машин), которая была творчески скопирована с IBM z/VM, и позволяла запускать самые разные тогдашние ОС в качестве сессий. Ну, я так это дело понял из статей. Так что, прецедент использования и опыт создания оболочки для мультиОС тогда уже были.

Всё Вы правильно поняли (единственный момент, запускать можно было только ОС, которые могли идти на IBM System/360 и /370, и, разумеется, это были ОС от IBM, зато можно было запустить саму ОС-СВМ), только нужно понимать, какой тогда был уровень операционных систем. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Но ближе к теме АИ-программ, почему бы не продолжить цепочку: однозначный DOS->псевдомногозначный Win9x->многозначный WinNT->виртуальные машины для каждого приложения.

На мой взгляд, тут есть некий дефицит фантазии.

  1. DOS - он ведь может быть очень разным. Даже мелкомягкий..Многозадачный MS-DOS, разрабатывавшийся параллельно с однозадачным 3.3 - это факт истории.
  2. Win9x - это лишнее звено, изрядно запоздавшее по времени создания, но выстрелившее за счёт высокой стартовой базы и относительной неприхотливости. В качестве графической оболочки в духе win 3.11 мог быть и GEM - хотя конечно с сетевыми возможностями там надо отдельную тему поднимать.
  3. А вот между многозадачностью и виртуализацией есть отдельная, сложная и неудобная стадия. Многозадачность с реально используемым механизмом привилегий и изоляцией приложений.

Отдельно нужно выделить проблему исполнения части задач в жёстком реальном времени и использовании гетерогенных вычислительных систем. Эпопею с аудиосистемой в виндах, особенно при переходе XP - семёрка, стоит помнить... А проблемы интерфейсов ввода-вывода, когда пошевелить контактами с гарантированным временем отклика современная машина общего назначения не может в принципе, и приходится вставлять прокладку из малинки...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

"С гарантированным временем отклика" на современную машину ставится ОСРВ. Просто это пальба из пушки по воробьям получается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Я бы не сказал, на примере того же x86, если процессор поддерживает виртуализацию, то потерями можно пренебречь.

До 30% - это пренебречь? И потом НЯП в тесте виртуалка была одна. Если же виртуалку создавать под каждую программу, начиная с Блокнота... А ведь еще есть потери памяти..

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

DOS - он ведь может быть очень разным. Даже мелкомягкий..Многозадачный MS-DOS, разрабатывавшийся параллельно с однозадачным 3.3 - это факт истории.

А это что за чудо-юдо? Можно поподробнее? Не догоняю что-то, о чем Вы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

А это что за чудо-юдо? Можно поподробнее? Не догоняю что-то, о чем Вы.

Тут речь о двух (как минимум) проектах MS середины 80-х. Первый - MS DOS 4.00M,  а второй - создание ОС по заказу Sharp для их линии X68000. Оба проекта в многозадачном виде за пределы фирмы практически не вышли, про второй за пределами Японии вообще почти нет данных.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

И да. По поводу виртуализации.

Главная проблема виртуализации в PC - это слишком стандартное и дешёвое железо, которое клепали все кому не лень и софт к которому лез напрямую, прямо по адресам и без всяких там обращений к ОС и даже в BIOS. Ну и слишком простой MMU с полным отсутствием I/O MMU на 386 машинах с ISA шиной.

Правильно с архитектурной точки зрения построенная система, с нормальной механикой многоуровневой трансляции адресов и поддержкой I/O MMU всеми производителями карт расширений... Эх. С другой стороны, спаять чуть ли не на макетке, дискретных компонентах, рассыпухе и стандартных чипах какую-нибудь плату, делающую что-то полезное - можно было на Apple II, на IBM PC, но уже PDP-11 и PS/2 с MCA требовали совсем другого уровня проектирования и уровня доступности компонентов.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Ну и слишком простой MMU с полным отсутствием I/O MMU на 386 машинах с ISA шиной.

Не понял. Страничная организация памяти, насколько помню, в 386-м организована. И на ISA всё работало (те же OS/2 или Windows NT)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Не понял. Страничная организация памяти, насколько помню, в 386-м организована. И на ISA всё работало (те же OS/2 или Windows NT)

Дело в нюансах. Шина (включая DMA-фабрику, прерывания и таймеры), видеопамять и каналы ввода-вывода не имели (полноценного) MMU (в отличии от мейнфреймов и полноформатных *nix-машин), разделение доступа к ним было софтверным и очень затратным с точки зрения времени на формирования запросов и количество переключений контекстов и колец защиты. А стандарты COM и LPT портов были очень жёсткими по наследству, и не давали вводить умных контроллеров с большими буферами без пляски с бубном и коллекции режимов совместимости.

Зато платформа была дешёвой. MMU только в процессоре - это...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено)

Дело в нюансах. Шина (включая DMA-фабрику, прерывания и таймеры), видеопамять и каналы ввода-вывода не имели (полноценного) MMU (в отличии от мейнфреймов и полноформатных *nix-машин), разделение доступа к ним было софтверным и очень затратным с точки зрения времени на формирования запросов и количество переключений контекстов и колец защиты. А стандарты COM и LPT портов были очень жёсткими по наследству, и не давали вводить умных контроллеров с большими буферами без пляски с бубном и коллекции режимов совместимости. Зато платформа была дешёвой. MMU только в процессоре - это...

Теперь понял. А что Вы хотели? Полноценная аппаратная реализация была бы Вам не по карману. Это, по тем временам, уровень графстанций, уже немного другой ценовой сегмент.

Вообще-то, для простого пользователя и софтверной реализации переключения контекста было достаточно. У меня, что под Desqview/386, что под OS/2 frontdoor/t-mail в фоновом окне исправно крутился и байтов из COM-порта не терял. А я в это время мог DOOM погонять или Aces of the Pacific.

Изменено пользователем Вандал

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Тут речь о двух (как минимум) проектах MS середины 80-х. Первый - MS DOS 4.00M,  а второй - создание ОС по заказу Sharp для их линии X68000. Оба проекта в многозадачном виде за пределы фирмы практически не вышли, про второй за пределами Японии вообще почти нет данных.

Никогда не слышал ни про тот, ни про другой. Большой вопрос, смогло бы это удовлетворительно работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Большой вопрос, смогло бы это удовлетворительно работать.

Смогло бы, но подняло бы цену железа и требования к написанию программ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Смогло бы, но подняло бы цену железа и требования к написанию программ.

Ну, собственно, в реале её отозвали из-за обилия глюков, как выясняется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено)

Ну, собственно, в реале её отозвали из-за обилия глюков, как выясняется.

 

Там не было ничего что в итоге нельзя было исправить - DESQview же работала, даже был вариант с Х-сервером. Но смысла не было.

Изменено пользователем Нкоро_

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Там не было ничего что в итоге нельзя было исправить

Ага, даже Малтикс в конце концов заработал. Только кому это интересно? У каждого продукта есть окно возможностей. Не влез - в пролете.

DESQview же работала

Так Desqview - это не DOS 4.0.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Так Desqview - это не DOS 4.0.

C точки зрения общего подхода и пользователя - те же колокольчики, вид сбоку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

C точки зрения общего подхода и пользователя - те же колокольчики, вид сбоку.

Только руки прямые. Вот сколько их было разных, а до полуоси DesqView делал всех. Так что, если они смогли, не факт, что Microsoft сможет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано:

Немного теплой ламповой Америки

На фото сборочная линия компании Apple по производству первых компьютеров с графическим интерфейсом Macintosh 128K. 

http://samsebeskazal.livejournal.com/357436.html#cutid1

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опубликовано: (изменено)

Не взлетит ибо АРМ проигрывает нормальным х86 даже сейчас.

Чем?

ИМХО, он проигрывает только возрастом, так как:

1) Его разрабатывали, учитывая костыльность архитектуры х86.

2) Он получился безопаснее за счёт наличия отдельного специального регистра с адресом вершины стека.

3) ЕМНИП, он ещё и меньше энергии расходует.

4) Длина команды одна и та же для всех, и время выполнения каждой сделано более-менее константным (деление вынесено куда-то в другое место). То есть конвейеру обработки команд несколько проще.

5) Но к моменту разработки ARM была уже куча специфичных для х86 прог, которые переписывать никто не собирается.

 

Скажем в начале 2000х Джобс принял решение не переходить на x86, а разработать собственный arm-процессор (понятно многоядерный и 64битный, возможно с доп.инструкциями для ускорения работы VM) и добавить в OSX менеджер виртуальных машин с возможностью обмена данными между приложениями.

Так что считаю это альтпозитивой для Apple.

Изменено пользователем Pvl_1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте учётную запись или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать учётную запись

Зарегистрируйтесь для создания учётной записи. Это просто!


Зарегистрировать учётную запись

Войти

Уже зарегистрированы? Войдите здесь.


Войти сейчас