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

[Telserg]

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

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

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

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

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

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

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

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

 

[Нкоро_]

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

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

[prostak_1982]

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

[Нкоро_]

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

 

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

 

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

[prostak_1982]

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

[MGouchkov]

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

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

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

Изменено 15 Ноя 2015 пользователем MGouchkov

[Вандал]

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

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

[Marlagram]

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

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

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

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

[dragon.nur]

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

[Лин]

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

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

[Вандал]

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

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

 

[Marlagram]

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

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

 

 

[Marlagram]

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

Главная проблема виртуализации в 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)

[Marlagram]

Не понял. Страничная организация памяти, насколько помню, в 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.

Изменено 17 Ноя 2015 пользователем Вандал

[Вандал]

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

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

[Нкоро_]

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

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

[Вандал]

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

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

[Нкоро_]

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

 

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

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

[Вандал]

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

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

DESQview же работала

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

[Нкоро_]

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

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

[Вандал]

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

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

[MGouchkov]

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

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

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

 

 

[Pvl_1]

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

Чем?

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

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

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

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

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

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

 

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

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

Изменено 20 Ноя 2015 пользователем Pvl_1