Возможна ли такая комбинация памяти?

Татарин> Интересным топичным свойством её было то, что любой ключ и вентиль там были по своей природе ячейкой памяти.)

Читали? Теперь оно в МРАМ Причём делать будут в РФ, причём на более тонких нормах, чем заграницей. Постил в новостях технологии.

Magnetic-Logic-Unit (MLU) architecture ... permits practical implementation of advanced logic and memory capabilities, a first for the industry

Татарин> Только я не понимаю, каким боком он относится к топику или мечтам о транспьютерах?
Татарин> Это классическая процессорная архитектура, всего лишь - чуть более разумная, чем х86. Всего лишь.

Тем боком, что с 86 ситуация была такая: шаг вправо или влево считается побегом (клоны AMD, NEXTGEN,..), прыжок на месте — попытка улететь (всё революционное). Побег состоялся, теперь можно и улететь

tarasv>>> Так это будет очередной числогрызер, в каждом ноуте в виде видеоконтроллера уже такой стоит, но операционку на нем както никто не спешит запускать.
au>> А операционка ему и не нужна, т.к. каждый процесс получает персональную машинку. К тому же машинка не обязательно числогрыз, но и контроллер i/o.
Татарин> Этот путь исповедует ту же идеологию, что "тотальный х86" и унаследует ВСЕ его грабли плюс кучу новых, своих. tarasv абсолютно прав: такая машина потеряет универсальность (не все алгоритмы параллелятся), простоту программирования, дешевизну (в угоду идеологии держим запас неработающих транзисторов и не можем гибко перераспределять мощность на лету), функциональность... ну и кучу всего.

Вы не поняли, не нашли знакомого в тексте Повторяю: каждая машинка работает независимо, в ней работает одна программа. Программы не разделены на нескольких машинках, их не надо параллелить. Одна программа — одна машинка. Потому никаких ОСей не нужно, вся машинка — в распоряжении программы. Проще программирования не бывает в принципе. Дешевизна сегодня не определяется неработающими транзисторами, всё изменилось. Все "гибкие перераспределения мощности на лету" имеют неисправимые побочные эффекты для надёжности, потребляемой энергии, нагреву, сложности и стоимости разработки программ, и той самой гибкости.

Татарин> Это в корне неправильный подход - придавать архитектуре и технологии несвойственные ей роли. Причём, в случае х86 это хотя бы оправдывалось рынком, мылыми затратами на разработку, внедрение и дешевизной конечных решений.

Вот это уже идеология А нечто похожее на то что я описываю, работает в автомобилях — сеть контроллеров, причём некоторые из них по мощи равны большим компам нашей молодости В целом они решают задачу управления системами автомобиля (в т.ч. тормоза и прочее ..-by-wire), которая не решается на "более гибких", т.к. надёжность их неприемлемая. Только микроядерная ось вроде нейтрино подойдёт, но там уже другие факторы мешают. Голая машина и знающий её программист — это страшная сила.

Татарин> Во-первых, как известно из теории вычислений, память разменивается на быстродействие и наоборот. Если требуется экономить память, машине придётся больше вычислять. А зачем? Память нынче дешева. И потребляет немного.

Это в теории она разменивается. А на практике разменяйте мне гиг памяти на быстродействие, если у вас в системе всего мег памяти в сумме (1 чип МРАМ по ТЗ, например). Или разменяйте сколько угодно памяти на быстродействие, если нужно анализировать поток данных, который быстрее чем ваша память, не говоря уже о каких-то операциях проца. Вот был у меня поток 10Гб/с с камеры, его нужно пропускать через алгоритм и выдавать несколько байт "выводов" на кадр. Записывать в память нельзя — нет времени. Считать надо синхронно с поступлением по каналу, никаких прерываний, прерывающих переключений, ничего — это для случая теоретического проца с тактовой в десятки ГГц. А уж потреблял бы тот проц... А всё на батарейке, с естественным охлаждением. Такая вот разница между теорией и практикой вычислений — в количестве переменных и их взаимозависимостях.

Татарин> Во-вторых, некоторые задачи принципиально требуют для решения некоего объёма памяти (хотя бы начальные данные требуется уместить), если этой памяти не хватает, начинаются игры с кешами с катастрофическими последствиями для быстродействия.

Назовите, а кто всё "какие-то" да "некоторые". Вот в примере выше тоже можно было бы требовать память на несколько кадров, "иначе никак" (как это обычно). А вот сделано было без этого, иначе как раз и было никак.

Татарин> В-третьих, "годные" программисты есть, но они знают себе цену. И их цена велика.

Значит это их цена.

Татарин> И более того: их число в мире ограничено, а софта требуется все больше и больше.

+10% к зарплате и освобождение от налогов — уговорю?

au> Вы не поняли, не нашли знакомого в тексте
Всё мы поняли, дружище. Поняли даже лучше, чем ты думаешь.
Микроядра с памятью не позволяют этоя памятью делиться с соседями. Всё. Тупик.
На некоторых задачах ещё поканает, но на большинстве - нет. Придётся прикручивать "обычную" память. Посмотри на нонешние видеокарты - именно так и сделано. И это несмотря на то, что задачи по видео параллелятся наиболее распрекрасно.
Поясняю ещё раз. Все эти подходы уже, минимум как 20 лет, изучены, смоделированы и опробованы.
Единственное, что ещё не очень опробовано - это атомарные ядра. Которые, собственно, ведут к "проклятым" нейронным сетям.

pokos> Микроядра с памятью не позволяют этоя памятью делиться с соседями. Всё. Тупик.

Тупик — для тех, кто неинтересен в контексте — code monkeys. А для embedded software engineers если написано что есть Х памяти, значит это всё что есть, а не "тупик".

pokos> На некоторых задачах ещё поканает, но на большинстве - нет.

Список пожалуйста, на выбор три штуки из "большинства", и требуемые для них ресурсы. Рассмотрим что им нужно и что с ними будет

pokos> Поясняю ещё раз. Все эти подходы уже, минимум как 20 лет, изучены, смоделированы и опробованы.

И забыты, ибо не хочется отвыкать от привычных языков и осей.
Я выше показал пример вычислителей и с кучей процев, и на FPGA — народ делал как лучше, из того что лучше, а не как привыкли и из того что привыкли. К тому же заявления "изучены, смоделированы и опробованы" относительно синтетического предмета, как компьютерная архитектура, годны лишь на коротких промежутках времени, т.к. всё меняется. Когда-то нас учили что CMOS по определению медленнее TTL, а верх совершенства — это ECL. И всё это было изучено, смоделировано и опробовано. А потом было откровение, TTL вымерла, ECL забыта, а CMOS стала нашим всем. Так в этом хоть физика участвует, в отличие от нематериальных вещей вроде компьютерной архитектуры.

au> Я уже написал, так что отвечу в чём ваша проблема (не обижайтесь). Вы похоже не знаете зачем нужна ОС, и потому не понимаете слов "ОС не нужна". А что "для некоторых классов задач" что-то не подходит — ну и что? Так можно сказать о любом компе без исключения, поэтому те некоторые классы задач либо должны решаться иначе, либо не должны решаться.

Ну вот и прекрасненько, тут никто с вами не спорит что сеть из мелких, возможно специализированных, вычислителей с локальной памятью на многих классах задач, например на жестком RT, на голову лучше чем универсальный процессор с обычной ОС. Но вы пытаетесь утверждать что она лучше на всех классах задач. Получается правда плохо - вы уже объявили что базы данных вам не не интересны. А почему? Может потому что ваша идеальная архитектура не такая уж и идеальная и подходит исключительно для сферы ваших профессиональных интересов а для других задач выглядит очень сомнительной.

au> "Надо" — это результат работы автора алгоритма, или автора программы, реализующей алгоритм. Я с болшим удовольствием (в прошлом, увы) переделал и реализовал один из "класса алгоритмов", на который все забили, хотя он очень и очень хорош, но не хватало ресурсов. Так вот, ресурсов не только хватило, но и уложилось в одну FPGA.

Поздравляю но за n*log(n) обычно платят памятью или получают премию Гёделя.

au> Нет ничего фундаментального в полностью синтетических проблемах. Переформулируйте задачу и признайте физические ограничения, и поместитесь. Программист, если он инженер, всегда при чём. Другие в таких делах и не нужны.

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

tarasv> Но вы пытаетесь утверждать что она лучше на всех классах задач.

Не было такого. Как минимум потому, что "все" классы задач мне неинтересны, да и неизвестны. Я пишу о задачах управления, обработки данных сенсоров (в т.ч. камер) и т.п. Индексация терабайтных корпоративных баз данных меня не касается и потому не волнует.

> вы уже объявили что базы данных вам не не интересны. А почему? Может потому что ваша идеальная архитектура не такая уж и идеальная и подходит исключительно для сферы ваших профессиональных интересов а для других задач выглядит очень сомнительной.

Просто неинтересны.

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

А вы читали что я тут пишу? В отдельной машинке программе доступно абсолютно всё что у неё есть. Ну и снова замечу что "универсальное" бывает только в теории, а на практике неучтённые в теории переменные резко ограничивают возможности. При тактовой проца 1ГГц он ничего не может сделать с сигналом с тактовой даже 500МГц. Даже записать в память не может, т.к. память ещё медленнее. Но теория до таких пустяков не опускается наверно, так что давайте теорию оставим для какой-то другой темы.

tarasv> Поздравляю но за n*log(n) обычно платят памятью или получают премию Гёделя.

Гёделя пришлось гуглить. Нет, куда уж нам до такого. Целых пять тысяч баксов А платить не пришлось вообще ничем, одни плюсы — нужно было лишь взглянуть по-другому на задачу, и не делать дурной работы. И памяти нужно было меньше — в FPGA память далеко не дармовая. За это именных премий не полагается.

au> Не было такого. Как минимум потому, что "все" классы задач мне неинтересны, да и неизвестны. Я пишу о задачах управления, обработки данных сенсоров (в т.ч. камер) и т.п. Индексация терабайтных корпоративных баз данных меня не касается и потому не волнует.

Ну так в такой интерпретации никто я думаю и спорить не будет, если функциональность устройства фиксирована от производства до списания то простор для оптимизации ограничен только бюджетом. Но это согласитесь далеко не тоже самое что: "И памяти там много не надо, т.к. одна задача на одно ядро — самый лучший и единственный безупречный метод многозадачности." Безупречный он только тогда когда заранее известно что на таком процессоре будет работать, не более того.

au> А вы читали что я тут пишу? В отдельной машинке программе доступно абсолютно всё что у неё есть.

Конечно читаю и вижу что суммарная производительность на тяжелых нераспараллеливаемых (а они обычно память любят) задачах сознательно ограничивается производительностью одного ядра и перегружает IO в отличии от систем с разделяемой памятью.

au> При тактовой проца 1ГГц он ничего не может сделать с сигналом с тактовой даже 500МГц. Даже записать в память не может, т.к. память ещё медленнее. Но теория до таких пустяков не опускается наверно, так что давайте теорию оставим для какой-то другой темы.

А осцилограф не может отиндексировать террабайт за приемлемое время, хотя и может прожевать 500МГц но об этом никто не плачет и не говорит что архитектура DSP осцилографа "неправильная".

tarasv> "И памяти там много не надо, т.к. одна задача на одно ядро — самый лучший и единственный безупречный метод многозадачности." Безупречный он только тогда когда заранее известно что на таком процессоре будет работать, не более того.

Я допускаю что некоторым задачам нужен терабайт памяти, и непременно оперативной. Но что вас не устраивает в тезисе о безупречности многозадачности по принципу "вся машина — одной задаче"? Аргументы против есть? У меня есть аргументы за, много разных.

tarasv> Конечно читаю и вижу что суммарная производительность на тяжелых нераспараллеливаемых (а они обычно память любят) задачах сознательно ограничивается производительностью одного ядра и перегружает IO в отличии от систем с разделяемой памятью.

Ну где же примеры этих "тяжёлых нераспараллеливаемых"? И повторяю, что распараллеливаемость тут неважна абсолютно, т.к. вся машина в распоряжении одной программы.

tarasv> А осцилограф не может отиндексировать террабайт за приемлемое время, хотя и может прожевать 500МГц но об этом никто не плачет и не говорит что архитектура DSP осцилографа "неправильная".

Ну, она и есть неправильная, что делать. Но работает с костылями. И эта тема актуальна. А индексирование терабайта — неактуально, хотя кому-то это важно. В этой теме разговор идёт о чём угодно, но только не об индексации терабайтов. МРАМ, ПРАМ — это всё не из мира терабайтов. Зачем же сюда это тащить, будто оно актуальное, и представлять как аргумент против несравнимых во всех аспектах вещей?

au> Вы не поняли, не нашли знакомого в тексте Повторяю: каждая машинка работает независимо, в ней работает одна программа.
Тогда эта каждая машинка называется (в текущих терминах) hardware по отношению к CPU и ничего нового в таком подходе нет. В конце-то концов, в каждом настольном компутере (оплоте х86) у нас есть мышка со своим процессором внутрях, клавиатура - со своим, монитор - со своим, винчестер - со своим, часто его контроллер по другую сторону шины имеет свой процессор, видеокарта имеет свой архимногоядерный процессор, часто и не один (чуть реже - и не два), звук обрабатывается отдельным процом, на приличной сетевой карте стоит свой проц, материнская и даже корпус с блоком питания (из тех что подороже) часто имеют по процу со своей микропрограммой. Ма-аленькие такие, незаметные снаружи, тихо выполняющие свою скромную роль. И это если даже избежать перечисления всяких более узкоспециализированных приспособ-помошников - от шифрования до расчёта физики в компутерных играх.
Причём, во многих из перечисленных случаях эти процы особо создавались под выполняемую в писюке роль и имеют производительность, команды и железо под эту роль заточеные. Что ж тут нового?

И то как есть - это хорошо.

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

Совершенно очевидное и правильное решение - вынести все такие задачи на ОДИН вычислитель, который мог бы гибко распределять свои ресурсы между такими программами. Более того - имеются примеры (успешные примеры!) радикализации такого подхода: сервер приложений + тонкий клиент.

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

au> Дешевизна сегодня не определяется неработающими транзисторами, всё изменилось.
Ещё как определяется!
Количество транзисторов на чип определяет его площадь и процент брака - важнейшие исходные для его себестоимости.

au> Все "гибкие перераспределения мощности на лету" имеют неисправимые побочные эффекты для надёжности, потребляемой энергии, нагреву, сложности и стоимости разработки программ, и той самой гибкости.
Как и альтернативный подход. У которого таких побочных больше.

Да, сейчас индустрия вынуждена делать много ядер: просто уткнулись в некоторый момент в физические пределы. Но не надо выдавать нужду за добродетель. Пока индустрия могла повышать производительность отдельного ядра - она должна была этим заниматься, ибо это тупо выгодно. Всем. И, разумеется, повышала.

au> Вот это уже идеология
Подбор архитектуры под задачу - это идеология?
Если так, то я её адепт и фанат.

au> А нечто похожее на то что я описываю, работает в автомобилях — сеть контроллеров, причём некоторые из них по мощи равны большим компам нашей молодости В целом они решают задачу управления системами автомобиля (в т.ч. тормоза и прочее ..-by-wire),
Другие приоритеты - другие решения.

au> Это в теории она разменивается.
И на практике.

au> А на практике разменяйте мне гиг памяти на быстродействие, если у вас в системе всего мег памяти в сумме (1 чип МРАМ по ТЗ, например).
Если памяти нет, разменивать нечего.

au> ничего — это для случая теоретического проца с тактовой в десятки ГГц. А уж потреблял бы тот проц... А всё на батарейке, с естественным охлаждением. Такая вот разница между теорией и практикой вычислений — в количестве переменных и их взаимозависимостях.
На практике такие задачи не решаются универсальными вычислителями.

au> Назовите, а кто всё "какие-то" да "некоторые".
Да элементарное распознавание образов. Или игрушка типа "стрелялка". Или моделирование Максвелла в неоднородной и сложной среде. Или спелл-чекинг в большом документе. Или...

Татарин>> И более того: их число в мире ограничено, а софта требуется все больше и больше.
au> +10% к зарплате и освобождение от налогов — уговорю?
Там не о процентах идёт речь, а о разах.
Хорошего мало, и спрос на него велик.

При этом мы же ради чего все это затеивали? Чтобы повысить эффективность и производительность системы и снять ограничения с программиста. А тут выясняется, что вместо этого, мы ограничиваем того программиста так, что не все справляются. Ну и зачем?

Татарин> Что ж тут нового?
Татарин> И то как есть - это хорошо.

Это очень хорошо. Но у пользователя компа такого нет. И это плохо. И это не новое — примерно так был устроен Intel Paragon - Wikipedia, the free encyclopedia

Татарин> - потребная им производительность и память неизвестны и меняются во времени;
Татарин> - число таких программ, которые желательно исполнять одновременно, заранее неизвестно;

Вы думаете эти "универсальные" вычисления ничем не ограничены? Проверьте:
- проиндексируйте терабайтную базу данных на своём компе. У вас её нет, правда? А если бы была, всё равно не получилось бы.
- думаете количество одновременно исполняемых программ бесконечно? На чужом, вражеском компе зайдите в поиск по диску, найдите все ехе, выделите их и запустите одновременно. Посмотрите как там с многозадачностью будет
- зайдите в диспетчер задач и посмотрите сколько там процессов. У меня вот порядка 60, из них большая часть — всякий хлам винды, частный случай bloatware, результат концепции "бесконечной памяти". Умельцы вытряхивают это из неё, не теряя работоспособности системы.

Татарин> - программы реагируют на действия пользователя и внешние события, абсолютное большинство времени код "простаивает", не исполняется.

А вот тут у вас неозвученное предубеждение. Вы думаете что простаивающий проц — это зло, а может (слышал живьём однажды) даже что проц должен быть загружен постоянно, иначе зло Это тоже было правдой лишь 20~30 лет назад, а нынче у вас в компе мощных процев сотни, а не один, и их простой — это экономия энергии, а не зло. Только когда нужна полная мощь, тогда они должны быть загружены. А так большой проц — большое потребление, и критерием "добра" уже не первый день является производительность на ватт, а не просто производительность. И вот куча всякого мелкого кода работает не хуже на мелких и крошечных процах, потребляющих милливатты или ватты, и то редко. А на большом, гоняющим большую память, её шину, и триллиард своих транзисторов, он палит ватты просто чтобы быть готовым что-то делать, даже когда ничего не делается. Это ещё не касаясь аспекта переключения задач со всеми последствиями — наличие оси, конфликты и зависимости между прогами, невозможность быстрой реакции, What is preemptive multitasking? - Definition from Whatis.com и т.д. В результате прога работает в непредсказуемой среде с непредсказуемым и ненадёжным таймингом, ось может её в любой момент отключить, чтобы какой-то там говнодрайвер забытого устройства проверил свой буфер. Это реально злая гадость, в отличие от выключенного проца. На одном небольшом чипе можно иметь сотню мелких процев под всякие мелкие задачки, каждый со своей памятью, и они будут надёжно исполнять их, и не мешать ни друг другу, ни пользователю — и всё в реальном времени. А когда не будут исполнять, их можно выключать вместе с их памятью, и они не будут потреблять ничего. И почему эта тема возникла: если они на МРАМе, то они статичны.

Татарин> Совершенно очевидное и правильное решение - вынести все такие задачи на ОДИН вычислитель

По какому параметру правильное? Вы одним махом усложняете задачу разработчика с тривиальной до как сегодня; закрываете ему доступ к железу, потому что там уже нужна ось и она будет рулить, а не вы; вносите взаимозависимости с другими прогами (ось далека от идеала) и тем усложняете разработку и отладку. Вы наверно деньги сэкономить хотели? Так вот вы их потеряли, т.к. все эти сложности стоят денег — зарплата кучи программистов, которые будут бороться со всем этим, чего может не быть. Именно с учётом этого эти самые программисты (инженеры) считают что лучшая многозадачность — это одна задача на проц, и много процев. Именно так они сделали ту штуковину за год — на 29 процах, и в тот год вошло их программирование. Такая вот неочевидная но проверяемая правильность решения.

Татарин> Умножение маленьких ядер для универсальной машины - абсолютно и полностью контрпродуктивно.

По какому параметру?

au>> Дешевизна сегодня не определяется неработающими транзисторами, всё изменилось.
Татарин> Ещё как определяется!
Татарин> Количество транзисторов на чип определяет его площадь и процент брака - важнейшие исходные для его себестоимости.

И по этой логике большой чип — лучше, потому что даже один битый транзистор на миллиард отправляет в брак весь чип? Проверяйте логику. Другие уже проверили на машинах, способных работать с дефектными ядрами, исключая их. Те же GPU, Cell могут отключать битые ядра, а до них была ещё машина на FPGA у HP, которая была работоспособна с кучей дефектов. Но вы наверно не об этом? Вас беспокоит выключенный, но работоспособный проц? Так он уже оплачен, как оплачена вся мощь вашего автомобиля, но вы не ездите на максимальной скорости, т.к. топливо ещё не оплачено. Проверяйте логику на чётких критериях, а не на интуиции.

Татарин> Как и альтернативный подход. У которого таких побочных больше.

Какие из них вас беспокоят? Простой проца?

Татарин> Да, сейчас индустрия вынуждена делать много ядер

Ну так делать надо с умом, а не тупо. Связали кучу ядер в одном чипе, потому что это удобно производителую чипа. Связали кучу памяти в других чипах, потому что это удобно производителю памяти. А мостиком между ними осталась шина, через которую всё должно пропихиваться. И поскольку единой архитектуры нет, процы в разы быстрее памяти, хотя это идиотизм, и его приходится компенсировать кэшами и извратами в проце. Эта же самая индустрия с алчными дебилами у руля не смогла договориться о едином стандарте DVD, и прочего такого натворила много. А когда архитектура проца и компа создаётся отделом маркетинга, спорить просто не о чем — она не может по определению быть хорошей.

au>> А на практике разменяйте мне гиг памяти на быстродействие, если у вас в системе всего ег памяти в сумме (1 чип МРАМ по ТЗ, например).
Татарин> Если памяти нет, разменивать нечего.

Вот то-то же. А как на это смотрит теория? Она не в курсе таких ограничений, рассуждая об универсальных вычислителях.

Татарин> На практике такие задачи не решаются универсальными вычислителями.

Значит они не универсальные! Ограниченно-специфические для каких-то задач.

Татарин> Да элементарное распознавание образов.

Ничего элементарного в этом нет. К тому же это зависит от алгоритма, а не от его применения. И эти алгоритмы работают в весьма ограниченных по ресурсам машинах — хорошо работают.

> Или игрушка типа "стрелялка".

Работает со времён амиги и синклера до сего дня. И такие проги всегда лучше делать в машине, где доступно всё.

> Или моделирование Максвелла в неоднородной и сложной среде.

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

> Или спелл-чекинг в большом документе.

Если даже пунктуацию проверять хотите. Нету предложений длинной в тыщу слов. Туман напускаете

Татарин> Татарин>> И более того: их число в мире ограничено, а софта требуется все больше и больше.
au>> +10% к зарплате и освобождение от налогов — уговорю?
Татарин> Там не о процентах идёт речь, а о разах.

О разах ли? Если он получает 200к в год, платит налогов 80к, и ему остаётся 120к, то предложение 220к без налогов ему неинтересно? Давайте спросим у наших программеров, как они отнеслись бы к такому предложению?

Татарин> При этом мы же ради чего все это затеивали? Чтобы повысить эффективность и производительность системы и снять ограничения с программиста. А тут выясняется, что вместо этого, мы ограничиваем того программиста так, что не все справляются. Ну и зачем?

Затем, чтобы сделать надёжный комплекс с малым потреблением и большими возможностями — то что невозможно сделать иначе. Вам нравится качество кода, где один дефект на несколько десятков строчек? Некоторых оно не устраивает, и вас оно тоже не устроит, если этот код будет управлять самолётом, в котором вы летите. Вы сразу захотите программистов, мастерски владеющих Ravenscar profile - Wikipedia, the free encyclopedia — их весьма мало, они живут с ограничениями, и их код работает во всевозможных ограничениях. И позаботившись обо всём этом, вы не подсунете им говнокомп — вы захотите правильный, надёжный и неубиваемый комп. Так вот, это не тот комп, к которому вы привыкли, где даже одна частица легко убивает его наповал и он "перезагружается", пока вы пикируете.
И ещё забавный эпизод: лодка Deep Blue Sea, где авторы сознательно и решительно отказались от всякой автоматизации, потому что она абсолютно ненадёжна и они не хотят булькнуть из-за "универсального вычислителя" и "неограниченного программирования". Что-то не так с приоритетами, не находите?

au> Читали?

Вот тоже неплохая новость: IBM develops 'instantaneous' memory, 100x faster than flash — Engadget
IBM выпустила "моментальную" память в 100 раз быстрее флеша с 10 миллионами циклов записи и достаточно дешевую, чтобы использовать везде, где только можно на phase change memory (PCM). Память с изменением фазового состояния — Википедия

Вот такой подарок преподнесла IBM себе и всем на свой 100-летний юбилей.

au>> Читали?
Naturalist> Вот тоже неплохая новость

Дык это PRAM. Смущает только предел по количеству записей — миллион или несколько. Вроде раньше говорили что на много порядков выше, иначе она не была бы кандидатом на универсальную память. Но есть MRAM — там без ограничений. Вот особо радует: Crocus developed NAND-like MRAM based technology called Magnetic Logic Unit (MLU)

au> Тупик — для тех, кто неинтересен в контексте — code monkeys.
Бред полный. Всегда найдётся задача, которая превысит возможности машины. А если ты машине не можешь подкинуть ещё ресурсов - бери другую машину.
Вскорости без порток пойдёшь по миру с таким подходом.
au> А для embedded software engineers если написано что есть Х памяти, значит это всё что есть, а не "тупик".
С чего вдруг эта область стала определять стратегию развития вычислительной техники?
Чрезвычайно узкая область ВТ. Собственно, к ВТ имеет даже маловато отношения.
au> Список пожалуйста, на выбор три штуки из "большинства",
Одной достаточно: распараллель мне хэш-функцию.
au> И забыты, ибо не хочется отвыкать от привычных языков и осей.
"для embedded software engineers ", определённо. Это наиболее костная часть из программистов, по моему наблюдению. А уж железные новшества этими людьми порой и вовсе принимаются в штыки, по типу "мы тут на старом ядре 500 лет сидим, все библиотеки уже написаны и отлажены, ваше новое говно - нам лишний гемор, сделали лучше бы старое побыстрее и памяти побольше".
au> Я выше показал пример вычислителей и с кучей процев, и на FPGA — народ делал как лучше, из того что лучше, а не как привыкли и из того что привыкли.
А получилось говно, которое никому в физической реальности особо не нужно. Даже странно.
Можть потому, что то же самое на нормальном кристалле работает в 5 раз быстрее и жрёт в 10 раз меньше?
au> Так в этом хоть физика участвует, в отличие от нематериальных вещей вроде компьютерной архитектуры.
Да, в этой нематериальной области рулит нематериальная наука - математика. Для которой, заметим, физика - только подмножество.
Не читал ты толком ничего по этой теме, так и скажи.

Если ты не видишь классов задач, которые не распараллеливаются, это значит не то, что их нет, а то, что ты их не знаешь.
Поэтому твои выводы о вселенской пользе микроядер с микропамятью, по крайней мере, смешны.
Ты меня извини, дружище, но ты мне напоминаешь пионера, только что прочитавшего про ядерную энергию и предлагающего сделать ядерный утюг и ядерный пылесос как решение проблем с электроэнергией.

pokos> Ты меня извини, дружище, но ты мне напоминаешь пионера

Вы хотите поговорить о чём-то своём — поговорите. То что вы написали выше не стоило потраченного на чтение времени, и коментариев на ваши выпады не будет.

au> Ну где же примеры этих "тяжёлых нераспараллеливаемых"? И повторяю, что распараллеливаемость тут неважна абсолютно, т.к. вся машина в распоряжении одной программы.

Вообще, любая задача, в которой некоторое выражение вычисляется только рекуррентно ч-з его же значения в некоторые предыдущие итерации.

Дубовый пример - однородное векторное уравнение в символьном виде:

dY(t)/dt=F(t)Y(t), при условии, что матрица оператора F(t) не коммутирует сама с собой в разные моменты t. Y(0)=Y0

Формальное решение - хронологическая экспонента. Вычислять её в общем виде - повеситесь, гарантирую.

А вот вам нелинейный вариант:

dY(t)/dt=F(t)Y(t)+Tr2(P(t)*Y(t)xY(t)).

Значит, первое слагаемое уже написано выше. Во втором Y(t)xY(t) - прямое, т.н. кронекеровское произведение вектора на себя. То бишь, если Y(t) был размерности N, то Y(t)xY(t) имеет размерность N^2. Оператор P(t) имеет размерность N²xN², Tr2 Означает свертку полученного выражения по переменным одного из Y(t), то есть, такой вот возврат обратно в пространство векторов размерности N.

Дерзайте, распараллеливайте. Максимум, что можно сделать - распараллелить процесс умножения матрицы на вектор в конкретный момент времени. И все.

Пример Татарина тоже хорош. Даже задача 3х тел в общем случае не имеет аналитического решения, люди считают на компах и ручками, пошагово подставляя конкретные текущие для каждого момента времени координаты и импульсы, хотя уравнения Ньютона все со школы знают. А задача многих тел и подавно.

au>> Ну где же примеры этих "тяжёлых нераспараллеливаемых"? И повторяю, что распараллеливаемость тут неважна абсолютно, т.к. вся машина в распоряжении одной программы.

AidarM> Дубовый пример - однородное векторное уравнение в символьном виде
AidarM> Дерзайте.

Понятно, пусть так. Ну и дерзнул бы: выделил бы машинку под этот код, и пусть себе считает. В чём же проблема? Как уже надцать раз повторил, параллелить ничего и не надо в такой архитектуре: ядро и его память целиком в распоряжении этого кода, в отличие от компов с осями и т.п. переключаемой многозадачностью.

au> Понятно, пусть так. Ну и дерзнул бы: выделил бы машинку под этот код, и пусть себе считает. В чём же проблема?

Так вы же запросили примеры нераспараллеливаемых задач.

>Как уже надцать раз повторил, параллелить ничего и не надо в такой архитектуре: ядро и его память целиком в распоряжении этого кода, в отличие от компов с осями и т.п. переключаемой многозадачностью.

Ну, так оно и происходит в компах с осями и т.п. Т.е. берем комп, и даем ему это дело считать. Мой I5 на задаче типа 2й тупо грызет её в одно ядро. Потому что остальные 3 ядра ему ничем помочь не могут. И толк от них только тогда, когда мне надо порешать эту же задачу для нескольких начальных условий.

А в задаче о многих взаимодействующих телах у ядра может своей памяти не хватить, там на каждом шаге вычислений для последующего положения одной частицы необходимо иметь конкретные текущие значения величин взаимодействия со всей оравой остальных частиц. Орава может исчисляться десятками-сотнями миллионов. Каждому по 6 величин типа extended/long double - это 60 байт (в лучшем случае) только на кинематику. И вот уже гигабайты нужны.

Решение этой задачи распараллелить можно, но только при условии, что все ядра лезут в общую память и могут читать везде. И все выполняют свои вычисления максимально одновременно, чтобы потом они смогли в нее параллельно писать (не везде, а каждое в свою выделенную область) в уверенности, что все ядра сейчас именно пишут промежуточные результаты, и никто не пытается прочесть.

Уверенность в последнем может дать только ОС, с помощью которой одно супервайзорное ядро следит за остальными, вычислительными ядрами. Раздает каждому адреса для записи, дает всем прочесть данные отовсюду, и обязательно командует парадом.

По пунктам, ОС на ЦЯ.

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

1. Ждет, когда все закончат чтение данных (стало быть, начали считать), после чего
2. Запретит читать и ждет, пока от всех ядер не придет запрос на запись (все досчитали), после чего
3. Разрешит писать и ждет, пока ото всех не придет запрос на чтение(все дописали). Проверит, не закончено ли вычисление. Если закончено, то выход, а если нет, то запретит писать, разрешит читать и сделает переход к п.1.

Под такие игрища всегда выделяли суперкомпы, из-за их многопроцессорности, из-за дурных объемов требуемой памяти и из-за того, что ядра/процессоры сами по себе были самыми быстрыми на данный момент и были оснащены параллельным доступом к памяти (управляемым) - оч. дорогое удовольствие.

upd: А когда тел, скажем, всего 10, а ядер 100, то задача на 100 ядер уже не распараллеливается, а вся необходимость общего управления счетом и доступом к общей памяти для 10 вычислительных остается. Совсем как у меня на 4хядернике. Работать будут 11 ядер под одной осью, 89 будут курить бамбук.

Татарин>> Что ж тут нового?
Татарин>> И то как есть - это хорошо.
au> Это очень хорошо. Но у пользователя компа такого нет. И это плохо.
Как это нет?! А что же у меня (да и у всех) на столе-то стоИт?
Именно так и обстоят дела СЕЙЧАС.

Чего сейчас нет - так это массового параллелизма для пользовательских программ. То есть, процессорщики бы с радостью - им забот меньше, да только реальная функциональность такого компа резко падает.

Я вот напомню одно интереснейшую (в контексте) историю недавних дней, про то, как IBM со своим PowerPC раньше, чем Intel в сторону многоядерности рванула. Масштабнейший эксперимент по проверки Вашей концепции на прочность... и таки да, весна показала, кто где срал. Была такая фирма Apple со своим независимым от мира ПЦ софтом, железом, подходом, архитектурой и очень большими возможностями по давлению на производителей софта. Так вот она в своих настольных компах начала первой использовать многопроцессорные системы и многоядерные процессоры (не по доброй воле, а из-за IBM, которая этой архитектурой свои задачи решала).
После невероятных усилий по доводке софта чтобы он использовал многозадачность (а задачи там были благодарные - мультимедия, обработка графики и видео) двуголовый "Эппл" кое-как дотягивал лишь до старших моделей тогдашних "пентиумов", безнадёжно проигрывая во всех остальных задачах. И это - при формальной разнице в производительности в разы в пользу PowerPC (ну, если сравнивать теоретические МФлопы и МИПСы).
Лишь чудовищным насилием над правдой маркетологи держали этот фронт несколько лет (и за это время "Эппл" завоевал себе... гм... неоднозначную репутацию и начал быстро терять даже свою долю рынка - рынка фанатов).
Чем закончилось всё это дело, помните?
Уже через пару лет инженерам была дана задача перестать ссать против ветра и развернуть технологическую платформу конторы в сторону x86. Результаты чего через ещё через год и продемонстрировали в натуре, и сейчас "Эппл" работает не на супер-многоядерных PPC (среди которых есть и 16-ти ядерные), а на Интелах, которые лишь сейчас до 4-х ядер добираются.

О чем это должно говорить зрячему, думающему инженеру? О том, что типичные пользовательские задачи, которые тот жаждет пускать на своем универсальном вычислителе, не любят мноогопроцессорности даже в её самом зачаточном варианте. Тут же нам предлагается перестроить в эту сторону всю индустрию и напихать кучу ядер не по нужде, а запросто так, за здорово живёшь. За чей счёт экспериментируем, Михал-Сергеич?
И главное, а какие причины ожидать иного результата на этот раз?

au> Вы думаете эти "универсальные" вычисления ничем не ограничены? Проверьте:
Разумеется, ограничены. Любую универсальную железку на конкретной задаче можно побить специализированной - по скорости, по снижению потребления, по цене. Это аксиоматично.

Но миру нужен некий стандартный универсальный вычислитель.

И вот моё утверждение состоит в том, что быстрый единичный процессор куда более подходит на эту роль, чем много процессорв (или ядер) с той же (или чуть бОльшей) суммарной производительностью.
Почему? Потому что всё, что можно выполнять на N ядрах, можно выполнять на одном с производительностью xN. Обратное строго неверно. Очень просто сделать из одного проца "как бы много", практически нельзя сделать из многих "как бы один".

au> - думаете количество одновременно исполняемых программ бесконечно? На чужом, вражеском компе зайдите в поиск по диску, найдите все ехе, выделите их и запустите одновременно. Посмотрите как там с многозадачностью будет
Я не думаю, что оно "бесконечно". Я думаю, что текущая система позволит запускать куда бОльшее количество процессов, чем та, которую предлагаете Вы. А поскольку большинство задач на типичном пользовательском компе жрут ничтожно мало процессорного времени и лишь некоторое количество дешевой памяти, пользователь в выигрыше.

Татарин>> - программы реагируют на действия пользователя и внешние события, абсолютное большинство времени код "простаивает", не исполняется.
au> А вот тут у вас неозвученное предубеждение. Вы думаете что простаивающий проц — это зло, а может (слышал живьём однажды) даже что проц должен быть загружен постоянно, иначе зло
Нет. Это Ваше предубеждение, которое Вы приписываете мне.
У меня лишь некоторое практическое наблюдение: пользователю в каждый момент времени нужна лишь программа, с которой он непосредственно работает, которая откликается на его, пользователя, действия.
Если пользователю нужно делать нечто с постоянной нагрузкой, без его вмешательства, в фоновом режиме, то пользователю легче поставить спец-железо под это дело. Вот как у меня сейчас: я пишу это на ноутбуке, а отдельный рутер - роутит и качает торренты.

Найдите какую-нибудь мощную вычислительную задачу, которая необходима типичному пользователю в фоновом режиме на его личном персональном вычислителе? и чтобы таковая не выполнялась бы уже отдельным процом?

Про чистые числогрызы я вообще буду молчать: недаром для строительства "универсальных" и дешёвых выбирают самые мощные на текущий момент процы (хотя, очевидно, что отношение производительность/цена куда лучше у "середнячков", причём, часто лучше в РАЗЫ!).
Казалось бы, вот уж где должна работать Ваша философия и подход к архитектуре - ведь за ту же цену можно было бы получить на десятки процентов (а то и в разы) более высокую производительность на ровном месте. Ни за что.

Однако же...

au> На одном небольшом чипе можно иметь сотню мелких процев под всякие мелкие задачки, каждый со своей памятью, и они будут надёжно исполнять их, и не мешать ни друг другу, ни пользователю — и всё в реальном времени. А когда не будут исполнять, их можно выключать вместе с их памятью, и они не будут потреблять ничего. И почему эта тема возникла: если они на МРАМе, то они статичны.
А есть такие чипы - то ли от TI, то ли от AD, не помню... с кучей мелких процов. Вот как по-вашему, почему никто даже не пытается сделать телефон на таком чипе?

У меня есть тому простое и понятное объяснение: типичная пользовательская задача проще реализуется на одном мощном ядре. Что угодно - от текстового процессора до игрушки проще программировать "линейно".

Татарин>> Совершенно очевидное и правильное решение - вынести все такие задачи на ОДИН вычислитель
au> По какому параметру правильное? Вы одним махом усложняете задачу разработчика с тривиальной до как сегодня; закрываете ему доступ к железу, потому что там уже нужна ось и она будет рулить, а не вы;
Разработчику сегодня не нужен доступ к железу. Напротив, разработчики сегодня прилагают огромные усилия чтобы от железа по возможности отгородиться и не знать чужих проблем (причины этого опустим, я просто напоминаю, что они существуют и очень разумны). Вот у Ромы спросите - нужен ему доступ к железу, когда он программирует свой сайт на Яве? ну или у меня спросите: нужно ли мне доступ к железу на телефоне чтобы записать во флеш или я всё-таки предпочту API, единый для всех моделей?
Некоторые встроенные применения, где софт и железо делаются однажды и составляют единое целое раз и навсегда - лишь малая доля того, что нужно людям от софта и железа.

Татарин>> Умножение маленьких ядер для универсальной машины - абсолютно и полностью контрпродуктивно.
au> По какому параметру?
- по конечной производительности системы на типичных реальных задачах;
- по простоте программирования.

au> И по этой логике большой чип — лучше, потому что даже один битый транзистор на миллиард отправляет в брак весь чип?
Нет. По этой логике не нужно множить транзисторы на чипе, они не бесплатны. У этого умножения есть свой более-менее разумный компромисс по экономике, и он хорошо виден: при текущих технологиях это что-то типа миллиарда транзисторов на чип. Ну, или что-то около того.

au> Ну так делать надо с умом, а не тупо. Связали кучу ядер в одном чипе, потому что это удобно производителую чипа. Связали кучу памяти в других чипах, потому что это удобно производителю памяти.
DRAM и процессоры не очень хорошо совмещаются по технологии. Было же уже - "умная память", вполне вписывалось в наличные архитектуры, давало серьезные преимущества в скорости для серверов (а там деньги крутятся достаточные, чтобы можно было позволить себе поэкспериментировать). Как думаете - почему не пошлО-то?

au> Ничего элементарного в этом нет. К тому же это зависит от алгоритма, а не от его применения. И эти алгоритмы работают в весьма ограниченных по ресурсам машинах — хорошо работают.
Блин. Что значит "в весьма ограниченых", что значит "хорошо работают"?
"- Петька, приборы?! - 15!!! - Что 15? - А что приборы?"
Как только исходные данные для распознавания могут поместиться в память машины - да, все работает. Но я же про это и говорю - не надо ограничивать машину в доступе к памяти. Это сужает круг возможных решаемых задач.

>> Или игрушка типа "стрелялка".
au> Работает со времён амиги и синклера до сего дня. И такие проги всегда лучше делать в машине, где доступно всё.
Синлер - однопроцессорная машина классической архитектуры. Которой была доступна вся память.

>> Или моделирование Максвелла в неоднородной и сложной среде.
au> Не могу проверить, но думаю и тут вы неправы.
Думайте, но факт остаётся фактом: если последующие вычисления зависят от результата предыдущих, то выгоднее иметь один мощный проц с производительностью Ы, чем N по Ы/N. Выгоднее ровно в N раз, и это очевидно, обсуждениям даже не подлежит.

au> Сложность вычислений не упрощается сложностью архитектуры, а очень наоборот.
А почему? У меня вот есть куча контрпримеров... но я сначала хочу послушать обоснования этому странному тезису.

>> Или спелл-чекинг в большом документе.
au> Если даже пунктуацию проверять хотите. Нету предложений длинной в тыщу слов. Туман напускаете
Зато есть словари в 250000 слов с морфологией и формами. Какой уж тут туман...

au> О разах ли? Если он получает 200к в год, платит налогов 80к, и ему остаётся 120к, то предложение 220к без налогов ему неинтересно? Давайте спросим у наших программеров, как они отнеслись бы к такому предложению?
Речь не о том, согласится ли Вася на зарплату в +10%. Речь о том, сможет ли этот Вася, даже после этой доплаты, выполнять более сложную работу в сроки. Количество таких Вась ограничено.

au> Затем, чтобы сделать надёжный комплекс с малым потреблением и большими возможностями — то что невозможно сделать иначе. Вам нравится качество кода, где один дефект на несколько десятков строчек? Некоторых оно не устраивает, и вас оно тоже не устроит, если этот код будет управлять самолётом, в котором вы летите. Вы сразу захотите программистов, мастерски владеющих
Да. И такие программисты есть, и такие системы делаются.
Знаете, сколько они, эти системы, стОят?
Они много стОят.
Очень много.
Игрушка, сделаная по таким правилам, Вам будет просто не по карману. И вот тут ребром встаёт вопрос: вам нужно так или никак? И миллионы фанатов игр орут: да! нам нужно так и СЕЙЧАС! а фикс даже известных багов потом, через полгода выпустите!
И индустрия покорно выполняет запрос. В сроки и по ценам, которые всех удовлетворяют. И с качеством, которое в целом всех более-менее устраивает, ибо любой незашоренный человек видит, что тут налицо простой компромисс.
А не проблемы архитектуры.

au> И ещё забавный эпизод: лодка Deep Blue Sea, где авторы сознательно и решительно отказались от всякой автоматизации, потому что она абсолютно ненадёжна и они не хотят булькнуть из-за "универсального вычислителя" и "неограниченного программирования". Что-то не так с приоритетами, не находите?
По-моему, всё так.
Замечу, их-то никто в выборе архитектуры системы и стиля программирования не ограничивал. Если люди трезво оценивают свои возможности и возможности доступного им железа, это следует только приветствовать.
Гораздо хуже, если бы они взялись делать и проволындались бы полгода с автоматизацией вместо того, чтобы делать лодку. И ещё хуже, если бы они взялись, сделали, но лодка бы после этого "булькнула". С экипажем.

Мы живем в реальном, неидеальном мире. И обязаны учитывать это.

Татарин> Чего сейчас нет - так это массового параллелизма для пользовательских программ. То есть, процессорщики бы с радостью - им забот меньше, да только реальная функциональность такого компа резко падает.

Программить те же параллельные вычисления бывает тяжко, обычно под конкретное количество процессоров с конкретным размером индивидуального кэша (вокруг юзания CUDA ужимки и прыжки те еще), слишком мало задач легко параллелятся, и так, что накладные расходы на синхронизацию оправдываются. Не всякая, даже в принципе распараллеливаемая задача, оправдывает написание параллельной версии программы, т.к. управление потоками и собирание насчитанного тоже требуют ресурсов.

Татарин>...а на Интелах, которые лишь сейчас до 4-х ядер добираются.

Чистый придиразм от зануды: 6ядерники i7 в РФ можно купить прямо сейчас.

Но смысл оптимальной идеологии сохраняется: сначала добиваемся максимального быстродействия одного ядра, а когда на пути к этому становится физические/технологические барьеры, навешиваем еще ядра. Кому надо, тот купит. 2 ядра нужны ИМХО почти всем, т.к. комфорт реально скачет вверх (под соотв. осью, разумеется). А вот остальные ядра - уже для пока еще редкого софта, который умеет ими пользоваться во всю мощь.

AidarM> Программить те же параллельные вычисления бывает тяжко, обычно под конкретное количество процессоров с конкретным размером индивидуального кэша (вокруг юзания CUDA ужимки и прыжки те еще), слишком мало задач легко параллелятся, и так, что накладные расходы на синхронизацию оправдываются.
Я знаю человека из лабы сверху (вместе на айкидо ходили), который занимался распараллеливанием задачи как раз обратного Максвелла (есть распределение полей, нужно получить тензор проводимости - диагностика сердца). Они построили устройство, а потом 7 лет пытались сделать некую систему, которая бы в разумное время (меньше нескольких лет, как у них получалось по прогнозам в матлабе на одном проце) давала бы с этих данных диагностику... Строили кластеры, учились программировать под распределенку, писали софт всей лабой... чел варился в этом с самого начала, не зная на старте даже С++. Идея, НЯП, была в том, что данные с достаточно удаленных датчиков можно считать независимыми.

Короче, конец у этой истории поучительный.

После пяти лет чел уехал в CERN и сейчас там уже руководит отделом облачных вычислений (неплохая карьера для человека из безвестного эстонского универа). Задача так и не была решена.

AidarM> Чистый придиразм от зануды: 6ядерники i7 в РФ можно купить прямо сейчас.
Факт. Я зарвался.

AidarM> Решение этой задачи распараллелить можно, но только при условии, что все ядра лезут в общую память и могут читать везде.

Классический MIMD или в нонешней реализации самой распространённой — SMP. Из других реализаций и архитектур — матричные процессоры. Кстати, прогноз погоды на таком и делается.

AidarM> Уверенность в последнем может дать только ОС, с помощью которой одно супервайзорное ядро следит за остальными, вычислительными ядрами. Раздает каждому адреса для записи, дает всем прочесть данные отовсюду, и обязательно командует парадом.
Не совсем. Способов синхронизации много. А так стандартная промблема писателей-читателей (производители-потребители).

Ответ я сейчас напишу. Только большая просьба: раз уж полетели простыни, давайте не только писать, но и читать, т.к. повторять простой тезис в надцать+1 раз, из-за игнорирования которого написана половина простыни, уже невыносимо Я его повторю ещё раз, прочитайте пожалуйста: распараллеливаемость тут неважна абсолютно, т.к. вся машина в распоряжении одной программы.

Медленно и пошагово описываю что имеется ввиду. Есть "машинка" — вычислительное ядро и его личная, персональная, недоступная снаружи никому память. Ядро может быть мелкоскопическим, может быть гигагерцным векторным, но оно одно в машинке, и память одна — его собственная память. Любая прога, которая скормлена этой машинке, работает там в полнейшем нераздельном одиночестве. Никто и ничто не прервёт её выполнение, не нарушит доступ к памяти, не создаст конфликтов. Весь обмен с внешними устройствами, в т.ч. такими же машинками, идёт через отдельный канал/память/буфер, которая используется сугубо для обмена между машинками. Надеюсь после этого ясно что вопрос "распараллеливания" закрыт окончательно из-за отсутствия такового?

Дальше, таких машинок много, они разные по мощи и ресурсам, а в целом весь этот массив собран под общую задачу — много мелких, или много больших, или в каком-то соотношении — например, для управления сложным объектом с многими физическими процессами в реальном времени. Каждый алгоритм, каждый контур управления, работает на своей машинке. Если алгоритм затратный, там машинка мощная. Если алгоритм лёгкий, машинка мелкая. Все машинки соединяЕМЫ, но соединеНЫ только те, которые должны передавать между собой что-то. Это как сеть, но без чёткой топологии. А смысл этого в том, что легче реализовать алгоритм на одной машинке, чем несколько алгоритмов на одной более мощной и потом вылавливать блох из-за явного и неявного взаимодействия между ними самими и осью. Это вылавливание стоит денег, т.к. занимает время, которое ничего продуктивного не даёт — решается проблема, которая создана в процессе решения задачи из-за выбранного метода решения (всё упихать в один комп). Если вы думаете что сэкономите на железках сто баксов, то месяц ловли блох командой из десятка человек — это уже сотня тысяч баксов на одной лишь зарплате им. И за этот месяц они не создадут ничего — только будут ликвидировать последствия процесса создания.

Насчёт "такое уже существует". Оно не существует в компе. Те контроллеры, которые в нём использованы — это закрытые и недоступные вещи. Есть они или нет — ничего не меняет для вас. А не существует такого вот массива машинок, по которому можно распихать задачи, оставив основную мощную для той самой "главной", с которой пользователь занимается. Но писюковые дела меня мало интересуют — я сказал уже что интересны задачи управления и анализа/синтеза сигналов. Много сигналов — много алгоритмов, и если между ними нет прямой зависимости, нет никакой выгоды если они будут сидеть в одной памяти и считаться на одном ядре, да ещё под какой-то осью. Всё это — наследованное, некогда вынужденное, но нынче абсолютно необязательное решение. Примеры приводил уже тут. Транзисторы небесплатны, но и программисты небесплатны, мягко выражаясь, а хорошие — так вообще. И я не стремлюсь сделать программирование лёгким и простым, мне не интересны плоды труда code monkeys для таких задач. Лучше пусть программирование будет нелёгким и непростым, так что только знающие и способные могли бы делать эту работу, и за неё не жалко платить. Поэтому лучше пусть пишут на том ravenscar, т.к. для этого нужно быть асом, чем на яве, на которой может писать кто только захочет. А то что таких мало — повторяю — абсолютно неважно, потому что если они стоят своих денег, их можно вытащить из других проектов (без обид) баблом, и они будут работать на вас. И такие асы оправданы только когда они работают сами, а в группе они разбодяживаются и не оправдывают своих денег. А сами они могут работать только если они будут заниматься только своим делом — вся машинка в их распоряжении, ни с кем не надо делиться, ни за кем не надо хвост заносить, и ни с кем не надо совещаться. Так что то что я описал, учитывает роль всех аспектов дела, а не "лёгкость программирования". А критерием годности и успеха было бы применение в такой вот лодке, чтобы народ не шарахался от автоматики, как от чумы, а дрых спокойно, пока автоматика — надёжная, годная — рулит объектом. На сегодня такой уровень сертифицируется каким-то там авиастандартом — именно из-за него в самолёте можно дрыхнуть, а не готовиться к неминуемой и внезапной смерти из-за ненадёжной автоматики. Ладно, простыню пора отрезать. На что не ответил, отвечу позже, когда замечу.

au> Медленно и пошагово описываю что имеется ввиду. Есть "машинка" — вычислительное ядро и его личная, персональная, недоступная снаружи никому память. Ядро может быть мелкоскопическим, может быть гигагерцным векторным, но оно одно в машинке, и память одна — его собственная память. Любая прога, которая скормлена этой машинке, работает там в полнейшем нераздельном одиночестве. Никто и ничто не прервёт её выполнение, не нарушит доступ к памяти, не создаст конфликтов.

Почти как у интеловских многоядерных процессоров, у каждого ядра есть свой персональный очень быстрый кэш на сотни килобайт. Может, уже на мегабайты.

>Весь обмен с внешними устройствами, в т.ч. такими же машинками, идёт через отдельный канал/память/буфер, которая используется сугубо для обмена между машинками. Надеюсь после этого ясно что вопрос "распараллеливания" закрыт окончательно из-за отсутствия такового?

По сути у вас общая задача идеально распараллелена, вот и все.

au> Дальше, таких машинок много, они разные по мощи и ресурсам, а в целом весь этот массив собран под общую задачу — много мелких, или много больших, или в каком-то соотношении — например, для управления сложным объектом с многими физическими процессами в реальном времени. Каждый алгоритм, каждый контур управления, работает на своей машинке. Если алгоритм затратный, там машинка мощная. Если алгоритм лёгкий, машинка мелкая. Все машинки соединяЕМЫ, но соединеНЫ только те, которые должны передавать между собой что-то. Это как сеть, но без чёткой топологии.

Раз вы упихали их все в один корпус, значит, вы как-то будете ими всеми управлять, задавать задачи и т.п.->минимум, однодольный граф точно будет. Более того, если на самом деле задача общая, то для контроля за обеспечением "реального времени" нужно управляющее ядро - та самая вершина в однодольном графе.

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

Если ось очень плохая, то да. Блохи ИМХО сохранились от другой многозадачности. Когда есть много процессоров, то там честная многозадачность. А тараканы по большей части возникают от другой, т.н. вытесняющей многозадачности. Когда попытались сделать быстрое переключение существенно однопроцессорной машины между уймой задачек, каждая из которой не требует 100% мощи проца. Или требует, но не получит, т.к. остальные задачи тоже важны. Ваш вариант упрощает требуемую ось, ей остается только давать процам/ядрам задачи и собирать решения.

> Это вылавливание стоит денег, т.к. занимает время, которое ничего продуктивного не даёт — решается проблема, которая создана в процессе решения задачи из-за выбранного метода решения (всё упихать в один комп). Если вы думаете что сэкономите на железках сто баксов, то месяц ловли блох командой из десятка человек — это уже сотня тысяч баксов на одной лишь зарплате им.

А в Вики пишут, что когда вопрос упирается в быстродействие, то из-за узких связей между процами в машине, построенной по вашей идеологии, большой команде приходится извращаться с программированием, чтобы разрезать типовые задачи на ядра и получить быстродействие, сравнимое с арифм. суммой производительности всех ядер/процов. Собс-но, пример Татарина про эппловскую машину - это оно. В графических процессорах на самом деле те же траблы, хотя там общая память есть.

au> Насчёт "такое уже существует". Оно не существует в компе. Те контроллеры, которые в нём использованы — это закрытые и недоступные вещи. Есть они или нет — ничего не меняет для вас.

Они сделаны недоступными оттого, что узкозаточены, отчего нехило оптимизированы (и поэтому дешевы) и ни на что другое не годятся. Очаровавшая вас мощь графических карт должна сильно вас разочаровать, когда вы ознакомитесь с набором инструкций их процессоров, и на какие ужимки и прыжки приходится идти, чтобы эту самую мощь задействовать. Как там память организована, на блоках данных каких размеров эта самая мощь реализуется. И сколько там ситуевин со штрафными тактами. До смешного доходит: две разные карточки одной модели имеют разное число мультипроцессоров -> для оптимальности нужно ручками распараллеливать задачу на разное число потоков. А иначе штрафные такты за лишние обращения в общую, весьма тормозную память видеокарты.

Просто по сути случайно так вышло, что возможности, заложенные в графические процессоры для эффективного решения сугубо графических задач, оказалось полезны и при других типах вычислений. Потому-то осознавший это пипл в NVidia открыл доступ и сделал CUDA-компиляторы. Удастся ли эффективно использовать эту вычислительную мощь - проблема сугубо юзера, NVidia обещала графическую карту, а не универсальный вычислитель. Например, хватит ли вам одинарной точности, или нет - сугубо ваши проблемы, для видеозадач хватает - и ладно. Двойная там тоже есть, но медленнее. Бывало, до 100 раз медленнее.

>А не существует такого вот массива машинок, по которому можно распихать задачи, оставив основную мощную для той самой "главной", с которой пользователь занимается.

Если задачи конкретного типа, то наверняка существует, а вот запихать полноценные универсальные вычислители с вашей идеологией помногу пока не получается - гигабайты памяти для каждого процессора/ядра не лезут.

>Но писюковые дела меня мало интересуют — я сказал уже что интересны задачи управления и анализа/синтеза сигналов. Много сигналов — много алгоритмов, и если между ними нет прямой зависимости, нет никакой выгоды если они будут сидеть в одной памяти и считаться на одном ядре, да ещё под какой-то осью. Всё это — наследованное, некогда вынужденное, но нынче абсолютно необязательное решение. Примеры приводил уже тут. Транзисторы небесплатны, но и программисты небесплатны, мягко выражаясь, а хорошие — так вообще.

Если вы можете твердо сказать, что вам нужно столько-то процессоров и столько-то памяти для таких-то конкретных задач, и все это влезает в один корпус, ИМХО вам персонально производители сделают такой комп. То, что нужно вам, это специализированная машина, которые тоже делают для промышленных установок, для военных. Оси, софт вообще, и соотв. программеры для таких компов наверняка должны водиться в природе, в отдельных заповедных местах.

Посадить за такие машины всех вам не удастся, людям в массе нужны универсальные вычислители, максимально быстрые за ~1000-2000долл. На сегодня это компы с относительно небольшим числом ядер с кэшами, а большая память - общая.