AidarM> Почти как у интеловских многоядерных процессоров, у каждого ядра есть свой персональный очень быстрый кэш на сотни килобайт. Может, уже на мегабайты.
Ирония, правда?
Иерархия памяти у них сдвинулась: роль ОЗУ играет кэш, а ОЗУ играет роль медленного накопителя.
AidarM> По сути у вас общая задача идеально распараллелена, вот и все.
Нет там ничего общего. Нельзя притягивать параллельность туда, где она целенаправленно исключена. PHP-движок авиабазы и драйвер дисплея в вашем компе — это тоже идеально распараллеленная общая задача?
AidarM> Раз вы упихали их все в один корпус, значит, вы как-то будете ими всеми управлять, задавать задачи и т.п.->минимум, однодольный граф точно будет. Более того, если на самом деле задача общая, то для контроля за обеспечением "реального времени" нужно управляющее ядро - та самая вершина в однодольном графе.
Конечно, нужно управлять: загружать задачи, собирать топологию каналов связи между машинками. На это надо выделить одну или несколько машинок из сотни, например. Так по-моему у какого-то из Крэев было — отдельный проц управлял молотилками. Так у Селла — риск-ядро и несколько ядер-молотилок. Но этот код также будет в собственной среде, и потому ничто ему не помешает делать своё дело. Машинки можно на ходу обслуживать, никогда-никогда-никогда не понадобится полная перезагрузка, всегда можно подключить резервную машинку вместо сбойной.
AidarM> Ваш вариант упрощает требуемую ось, ей остается только давать процам/ядрам задачи и собирать решения.
Да это не ось уже — оно живёт в своей изолированной среде, а не в одной с программами. Никаких переключений — только загрузка кода, настройка каналов связи машинки, запуск кода, остановка, повторить снова когда надо.
AidarM> А в Вики пишут, что когда вопрос упирается в быстродействие, то из-за узких связей между процами в машине, построенной по вашей идеологии, большой команде приходится извращаться с программированием, чтобы разрезать типовые задачи на ядра и получить быстродействие, сравнимое с арифм. суммой производительности всех ядер/процов. Собс-но, пример Татарина про эппловскую машину - это оно. В графических процессорах на самом деле те же траблы, хотя там общая память есть.
Не согласен. Во-первых большой команде надо извращаться чтобы сделать хоть что-то хоть как-то. Кажется IBM проводил исследования по производительности труда программистов — с ростом размера проекта она падала до трагического уровня, и особо стоит выделить что асы-программисты в больших командах работают не лучше молодёжи. Только когда асы работают сами или более-менее сами, они работают как асы и стоят своих денег. То что я описываю — самые лучшие условия для их работы, и потому они стоят своих денег.
Задачи надо резать (partitioning) на стадии проектирования, и не так, чтобы что-то упиралось в пределы производительности. Если скорости не хватает, так чтобы не резать по живому, нужно поднимать скорость. Опять же, это на стадии проектирования, а не когда уже железо спаяно.
AidarM> Они сделаны недоступными оттого, что узкозаточены, отчего нехило оптимизированы (и поэтому дешевы) и ни на что другое не годятся. Очаровавшая вас мощь графических карт должна сильно вас разочаровать, когда вы ознакомитесь с набором инструкций их процессоров, и на какие ужимки и прыжки приходится идти, чтобы эту самую мощь задействовать.
Мощь графических карт "очаровала" меня лишь тем что это конкурент старперской архитектуре, который бегает вокруг неё кругами, а не просто опережает. Была (и есть) тема применения GPU во всяких неграфических задачах — у неё много энтузиастов, но я не один из них. Сегодня, повторю слова того херра, у инженера есть доступ к архитектуре — он её может создать сам, какую надо, а не уживаться с тем что ему прислали из интела или нвидии. Он сам может создать архитектуру памяти, выбрать любую архитектуру проца и изменять её, и уж точно сам строить архитектуру маспара. Использование GPU — это протест и надежда, а не продуманный шаг от клонирования архитектуры мейнфрейма ad infinitum в каком-то определённом направлении.
AidarM> Просто по сути случайно так вышло, что возможности, заложенные в графические процессоры для эффективного решения сугубо графических задач, оказалось полезны и при других типах вычислений.
Вот точно — случайно так вышло
AidarM> Если задачи конкретного типа, то наверняка существует, а вот запихать полноценные универсальные вычислители с вашей идеологией помногу пока не получается - гигабайты памяти для каждого процессора/ядра не лезут.
Как тут уже случайно выяснили, универсальных вычислителей не бывает
Так что в массиве машинок — разнородном! — могут быть машинки и под быстрыее компактные задачи, и под медленные гигабайтные. Заранее это не нужно выбирать, но даже на этапе концепции проекта уже известно что там в принципе понадобится — скорость, размеры, или и то и другое. К тому же, в массив можно добавить машинку и позже, как легко добавляют комп в локальную сетку. Если с точки зрения авторов гигабайтной задачи там есть 1 машинка с 1ГБ, 4 машинки по 64МБ, и 100 по 64кБ, то в сумме памяти всё равно лишь чуть больше обычной машины с 1ГБ — о чём речь тогда, в чём предмет спора о ресурсах?
Будет чуть дороже железо, намного дешевле код, и всё в целом несравненно лучше по качеству при прочих равных (уровень разработчиков).
AidarM> Посадить за такие машины всех вам не удастся, людям в массе нужны универсальные вычислители, максимально быстрые за ~1000-2000долл.
Да не о писюках же речь, сразу сказал. Задачи управления, анализа сигналов, автопилот подводной лодки херра DBS..