Moderator: Shaos
И задача действительно распараллеливалась?MC68k wrote:ща полезу в коробку, достану аркаду на двух Z80 сделанную и запощу фотоLavr wrote:А хотя бы с двумя (или с четырьмя) процессорами К580 (или пусть Z80) реальное
железо где-либо существовало? Ну, естественно, не так, как в ZX_NEXT, а чтобы
задача действительно распараллеливалась.
хз, в аркадах часто такое встречается. один проц занимается звуком а второй разруливает все остальное. спрайты аппаратно делаются. схемы нет, ибо досталась голая плата даже без описания, только таблица, что на слот выводится. подозреваю, что подобие ОСи там есть ибо некоторые ПЗУшки маркированы иначе. в сеге подобно сделано,но там процессоры разные. ну и более близкий к задаче "тяни-толкай" в SNES/SFC - там дополнительный процессор на карике может дергать основной и наоборот.Lavr wrote:И задача действительно распараллеливалась?MC68k wrote:ща полезу в коробку, достану аркаду на двух Z80 сделанную и запощу фотоLavr wrote:А хотя бы с двумя (или с четырьмя) процессорами К580 (или пусть Z80) реальное
железо где-либо существовало? Ну, естественно, не так, как в ZX_NEXT, а чтобы
задача действительно распараллеливалась.
Если "да", то с удовольствием ознакомился бы как со схемой, так и с ОСью.
Ну ты красиво подытожил всё, что мы в топике уже выяснили...ntil wrote:Распараллеливание задая на треды - это не прерогатива ОС. ОС только обеспечивает механизм управления многими задачами - многозадачность, многотредовость.
Параллелизм растет из:
а) программиста, который явно паралелит задачи (pthreads там всякие). ведь не даром в период подготовки к выпуску многоядерных процессоров интел замутил гипертридинг - чтобы сломить инертность и лень прикладных программеров (серверно-системные вещи как правило пишутся более адекватными людьми, в отличие от большинства прикладушников - вспомните как весело работает 1цэ семерка на многоядернике, укладывая в полку только одно ядро)
б) оптимизирующего компилятора, который сам параллелит все, что можно. ...
Впрочем... теории мы здесь понаписали аж 17 страниц, и выяснили, что в теорииntil wrote:Поддержка распарралеливания в ОС "на лету" - не оптимально - выгоднее это
сделать один раз компилятором, чем делать при каждом запуске приложения.
Многопроцессорная система ещё не означает "многозадачная", а тем более автоматически не подразумевает распараллеливание процессов. Мне кажется, цели наши неясны, и с ними нужно конкретно определиться. Если многопроцессорность нужна именно для распараллеливания процессов, то "есть мнение"cr0acker wrote:Задумали мы тут с тов. Шаосом, многопроцессурную систем на NedoPC-580-M.
, что это зло. К примеру, при создании X-Window предпринимались попытки распараллеливания, но ничего хорошего из этого не вышло, и разработчики вернулись к традиционным методам. Лично я воспринимаю обсуждаемую многопроцессорную систему не более чем как совокупность процессоров, каждый из которых может выполнять свою задачу, имея своё изолированное адресное пространство. Общая память при программировании приведёт к полному хаосу и невозможности вести отладку. Есть и другие серьёзные трудности. Не зря в современном программировании и "железе" распараллеливание процессов приживается с большим трудом и лишь серьёзными усилиями людей, которые видят в этом деле перспективу, для иных весьма туманную. А мне кажется за 17 страниц цели наши определились, просто каждый хочет немного своего...VituZz wrote:Многопроцессорная система ещё не означает "многозадачная", а тем более автоматически не подразумевает распараллеливание процессов. Мне кажется, цели наши неясны, и с ними нужно конкретно определиться.
А ты в окно выгляни - год 2012!Shaos wrote:> да пусть она хоть двухпроцессорная будет, только задачу пусть "распараллелит" сама...
может система ещё и кодить сама за тебя должна?
Почему бы системе немножко не покодить за меня? 
А я не гордый - я готов её неоптимальную многопроцессорную и невыгоднуюntil wrote:Поддержка распарралеливания в ОС "на лету" - не оптимально - выгоднее это
сделать один раз компилятором, чем делать при каждом запуске приложения.
динамический рекомпилинг при старте - довольно ресурсоемкая задача. и сложная в добавку.я не гордый - я готов её неоптимальную многопроцессорную и невыгодную
подождать всякий раз при каждом запуске приложения.
Но пусть - явит чудо!
Я как-то отвлёкся от этого эльбруса, когда понял, что чуда в сжатые сроки бабаянцы не явят...ntil wrote:эльбрус он вообще с явным паралеллизмом - там или очень толковый программер или очень толстый компилер.
эт уже ближе к акселерации аппаратеойLavr wrote:Я как-то отвлёкся от этого эльбруса, когда понял, что чуда в сжатые сроки бабаянцы не явят...ntil wrote:эльбрус он вообще с явным паралеллизмом - там или очень толковый программер или очень толстый компилер.
Но насколько я помню, он делал аппаратную перекомпиляцию чужого кода в нативный,
умудряясь сделать код эффективнее оригинала при прочих равных условиях...
Что-то в таком ракурсе...
А насчет распараллеливания на 2 процессора - я уже тут много раз говорил,
ну хочется, чтобы один проц расчет делал, а второй - перехватывал операции
с графикой у него... не более...
Ничего супер-нового мы не сконструируем - потому как некогда всем в жизни...
А вот попробовать реализовать мою идею из двух "Орионов" или двух "Спецтрумов"
(у кого что есть) может полегче будет?...
и все эти десятки конвееров относятся к риск ядру.. Насколько я помню, он ничего не эмулирует, а перекомпилирует "на лету".ntil wrote:еще о эльбрусе - так он эмулирует Х86 для совместимости или выполняет свой нативный но явно прооптимизированный...
угу, сама кодит, сама деньги получает.Shaos wrote:> да пусть она хоть двухпроцессорная будет, только задачу пусть "распараллелит" сама...
может система ещё и кодить сама за тебя должна?
обычно программист кодит алгоритм и программист же его распараллеливает
P.S. распараллеливать сами могут только относительно новые версии больших компиляторов для современных процессоров (т.е. не Z80 и тем более не 8080) и то как правило самостоятельно они это делают плохо и им надо показывать пальцем где желательно параллелить и как (гугли OpenMP - не путать с OpenMPI)
