1-Way vs n-Way (Зачем многопроцессорность и что предпочесть)
Модераторы: Trinity admin`s, Free-lance moderator`s
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
1-Way vs n-Way (Зачем многопроцессорность и что предпочесть)
В смысле однопроцессорные против n-процессорных
Назрела, вроде тема ? В разных форумах уже неоднократно поднималась, даже для домашних компьютерах. В связи с тем, что все более популярными становятся решения типа HyperThreading(два "виртуальных" процессора в одном физическом), нескольких процессорных ядер на одном кристалле (Power G4). Кроме того, по новостям пробегало - об "асимметричном" компьютере на базе AMD (ClawHammer в качестве процессора для системных нужд и SledgeHammer для foreground задач).
Предлагаю обсудить:
1. Где, что эффективнее применять, где вообще применима упомянутая экзотика типа "асимметричного" компьютера ?
2. Куда, как предполагается, пойдет индустрия дальше - распараллеливание задач для n-Way или наращивание "мощи" однопроцессорных десктопов ? Или и туда, и туда - разом ?
3. Ну и так далее.
Назрела, вроде тема ? В разных форумах уже неоднократно поднималась, даже для домашних компьютерах. В связи с тем, что все более популярными становятся решения типа HyperThreading(два "виртуальных" процессора в одном физическом), нескольких процессорных ядер на одном кристалле (Power G4). Кроме того, по новостям пробегало - об "асимметричном" компьютере на базе AMD (ClawHammer в качестве процессора для системных нужд и SledgeHammer для foreground задач).
Предлагаю обсудить:
1. Где, что эффективнее применять, где вообще применима упомянутая экзотика типа "асимметричного" компьютера ?
2. Куда, как предполагается, пойдет индустрия дальше - распараллеливание задач для n-Way или наращивание "мощи" однопроцессорных десктопов ? Или и туда, и туда - разом ?
3. Ну и так далее.
Re: 1-Way vs n-Way
Моё мнение такое : мы уже их во всю применяем - вспомните о графических ускорителях и картах звуковой обработки, карты видеозахвата ... В каждой штуковине под определённую задачу уже стоит специализированный процесор.1. Где, что эффективнее применять, где вообще применима упомянутая экзотика типа "асимметричного" компьютера ?
2. Куда, как предполагается, пойдет индустрия дальше - распараллеливание задач для n-Way или наращивание "мощи" однопроцессорных десктопов ? Или и туда, и туда - разом ?

Я думаю будет так - каждая задача получит по спец процессору: например hardware ускоритель БД и т.д.
Вообще очень удобно - один процессор координирует и раздаёт задачи, которые в свою очередь решаются специализированными процессорами.
Ну, и конечно, интеграция в чипы нейросетей, возможно на органической основе (такие разработки уже давно ведутся) - то есть переход с жесткой логики на совмещение её с адаптивной.
Безусловно революционным шагом в развитии производительности компьютеров, станет переход на оптику, если конечно разработчики не пойдут по пути принудительного приведения оптических процессов к 0 и 1

- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Хм. Куда-то мы несколько не туда, куда предполагалось...
Любой революционный метод очень туго приемлем рынком - из-за несовместимости с уже отработанными решениями и инерции. Потому, имхо, пока что революций не предвидится - будут наращивать гигагерцы и/или количество ядер на чипе/исполнительных устройств.
И потом - n-Way даже в SOHO вовсе уже и не фантазия (видел раз переходник Slot1->2xSocket370, в котором стояла пара 466 Целеронов
, и работало ведь, что характерно! Правда, сервером
). HyperThreading, опять же, не за горами. PowerG4 - пожалуйста (два ядра на одном чипе).
По поводу асинхронности: меня сильно удивило выделение целого ClawHammer (aka Атлон64) под системные нужды. Чего это такого ОС делает (если весь foreground выбросить на могучий Оптерон), чтобы ей было нужно нечто с частотой, скажем, более полгигагерца ? И потом: в приведенном Вами примере - узкоспециализированные, а не универсальные процессоры, каковым Атлон64 является. Тогда уж более логичным решением был бы спец. процессор с архитектурой не выше 386, минимумом исп. устройств, частотой порядка 200-500 МГц, с пассивным охлаждением и способностью что-нибудь из нужд ОС аппаратно ускорять (Интернет
). Плюс - ОС должна подобный изврат поддерживать и не пускать приложения на свой процессор (типа принудительной affinity).
А hardware акселератор БД - это ж вообще кошмар будет: основное отличие всех SQL-движков как раз и состоит в механизмах отработки запросов, стало быть, под каждую БД нужен будет свой акселератор (из стандартного в БД только SQL, да и то - не всегда полностью стандартный
). Т.е. под каждую БД нужен будет проприетарный железный акселератор.
Что касательно принуждения к дискретности и двоичной логике - дык, на аналоговых вещах тоже ведь - где сел, там и слез (нет чтобы точно 0 или 1
, а с заданной точностью).
Нет. Я про то начал, что весь софт ныне становится многонитевым. Что эффективнее для десктопов/серверов: "виртуальная" многонитевость или реальная (т.е. на нескольких реальных процессорах) ?

Любой революционный метод очень туго приемлем рынком - из-за несовместимости с уже отработанными решениями и инерции. Потому, имхо, пока что революций не предвидится - будут наращивать гигагерцы и/или количество ядер на чипе/исполнительных устройств.
И потом - n-Way даже в SOHO вовсе уже и не фантазия (видел раз переходник Slot1->2xSocket370, в котором стояла пара 466 Целеронов


По поводу асинхронности: меня сильно удивило выделение целого ClawHammer (aka Атлон64) под системные нужды. Чего это такого ОС делает (если весь foreground выбросить на могучий Оптерон), чтобы ей было нужно нечто с частотой, скажем, более полгигагерца ? И потом: в приведенном Вами примере - узкоспециализированные, а не универсальные процессоры, каковым Атлон64 является. Тогда уж более логичным решением был бы спец. процессор с архитектурой не выше 386, минимумом исп. устройств, частотой порядка 200-500 МГц, с пассивным охлаждением и способностью что-нибудь из нужд ОС аппаратно ускорять (Интернет

А hardware акселератор БД - это ж вообще кошмар будет: основное отличие всех SQL-движков как раз и состоит в механизмах отработки запросов, стало быть, под каждую БД нужен будет свой акселератор (из стандартного в БД только SQL, да и то - не всегда полностью стандартный

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

Нет. Я про то начал, что весь софт ныне становится многонитевым. Что эффективнее для десктопов/серверов: "виртуальная" многонитевость или реальная (т.е. на нескольких реальных процессорах) ?
- Anton Kovalev
- Power member
- Сообщения: 38
- Зарегистрирован: 04 дек 2002, 16:48
- Откуда: Санкт-Петербург
- Контактная информация:
Re: 1-Way vs n-Way
Эта тема назрела в 1958 году, когда неизвестный программист вытащил из колоды перфокарт одну ресурсоемкую процедуру и скормил ее ЭВМ, стоящей в соседней комнатеa_shats писал(а):В смысле однопроцессорные против n-процессорных
Назрела, вроде тема ?

И совершенно напрасно поднималась. Говорю как человек у которого более трех лет дома стояла двухпроцессорная система.В разных форумах уже неоднократно поднималась, даже для домашних компьютерах.
Нужно хорошо представлять - что это ПОЛУмера. Болезнь роста. Таких технологий быть не должно в принципе.В связи с тем, что все более популярными становятся решения типа HyperThreading(два "виртуальных" процессора в одном физическом)...
Погоня за тактовой частотой породила гиперконвеерные архитектуры, работающие во многих случаях неэффективно. Теперь появлется такой костыль как HyperThreading. Выигрышь от нее во многих аспектах исключительно маркетинговый. Ты платишь теже деньги и получаешь ДВА процессора.
К концу года появится улучшенная версия этой технологии. Появится возможность синхронизировать и приоретизировать трэды. Но и тогда - это будет лишь дерюжка, прекрывающая безобразную родовую травму всего конструктива.
Вот это уже намного интересней. Хотя предпосылки появления данного решения также маркетинговые. Здесь IBM решила ударить по больному месту всех корпоративных IT отделов - а именно по стоимости лицензирования программного обеспечения в зависимости от количество процессоров в системе.нескольких процессорных ядер на одном кристалле (Power G4).
Процессоров два, а платишь как за один (маркетинговый антипод HyperThreading

В любом случае - по мере совершенствования технологий за такими решениями будущее. Именно за ними, а не за поделками аля гипертрэдинга.
Опять же решение подсмотрено в далеком 58-омКроме того, по новостям пробегало - об "асимметричном" компьютере на базе AMD (ClawHammer в качестве процессора для системных нужд и SledgeHammer для foreground задач).

Даю цинк - процессоры ввода-вывода при главных процессорах на мэйнфреймах.
AMD я прекрасно понимаю - чем больше таких решений - тем больше можно продать процессоров.
Да это уже есть. Вглядитесь в микроархитектуру любого современного процессора - схема превыборки в кэш-память, преобразователь команд в микрокод и т.д.Предлагаю обсудить:
1. Где, что эффективнее применять, где вообще применима упомянутая экзотика типа "асимметричного" компьютера ?
Еще раз повторюсь. Работа 95% пользователей ОДНОЗАДАЧНА. Что дома, что в офисе.2. Куда, как предполагается, пойдет индустрия дальше - распараллеливание задач для n-Way или наращивание "мощи" однопроцессорных десктопов ? Или и туда, и туда - разом ?
Для офисного использования на мой взгляд самый перспективный путь развития - беспроводные терминалы. Само-собой индустрии это не сильно выгодно. Интелу-то все равно - она свои процы куда хочешь продвинет. А вот остальным имеет смысл задуматься.
Дома нужен один очень быстрый процессор. Исключительно для одной задачи - нагружать очень быстрый 3Дакселератор.
Для всех остальных задач даже один процессор такой мощности ИЗЛИШЕН.
А вот корпоративный рынок... Мне лично очень импонирует проект от маленькой компании IBM под кодовым названием Ice Cube.
Беруться кубики с определенной маркировкой (например производительность полтерафлопса и памятью сколько-то гигабайт), ставятся друг на друга. При нехватки производительности ставится еще нужное количество кубиков. Система умеет самодиагностироваться и отключать вышедшие из строя узлы.
Какие процессоры внутри, сколько их, что там происходит - никому это неинтерсно. Администрирует это хозяйство бабушка уборщица на полставки

- Андрей Куренков
- free-lance moderator
- Сообщения: 220
- Зарегистрирован: 09 окт 2002, 20:11
- Откуда: Foray ltd. СПб
- Контактная информация:
Re: 1-Way vs n-Way
Создайте решение, которым сможет воспользоваться любой дурак, и только полный идиот захочет это сделать:)Anton Kovalev писал(а): Какие процессоры внутри, сколько их, что там происходит - никому это неинтерсно. Администрирует это хозяйство бабушка уборщица на полставки
А что касается Ice Cube, это очередной пример того, что ничто не ново под луной... Достаточно вспомнить умерший под Compaq'ом проект Tandem...
- Dmitry
- Сотрудник Тринити
- Сообщения: 867
- Зарегистрирован: 22 авг 2002, 16:12
- Откуда: St.Petersburg
- Контактная информация:
Если такое решение создать, то найдется много людей которые захотят этим воспользоваться, причем количество (дураков) резко перерастет в качество и станет стандартом де-факто. Помнится кто-то из великих сказал: истина проходит три этапа - сначала над ней усмехаются и атакуют, затем задумываются и частично допускают и наконец, принимают как очевидное, причем, кто ругал ранее оспаривают честь ее открытия.Создайте решение, которым сможет воспользоваться любой дурак, и только полный идиот захочет это сделать:)

- Anton Kovalev
- Power member
- Сообщения: 38
- Зарегистрирован: 04 дек 2002, 16:48
- Откуда: Санкт-Петербург
- Контактная информация:
Re: 1-Way vs n-Way
И еще пару десятков подобных.Андрей Куренков писал(а): А что касается Ice Cube, это очередной пример того, что ничто не ново под луной... Достаточно вспомнить умерший под Compaq'ом проект Tandem...
Но мне все-таки кажется, что в конфигурациях железа мы рано или поздно придем именно к подобной самодиагностирующейся распределенной системе. Потому как стоимость железа всегда интересует корпорацию меньше нежели стоимость его обслуживания.
- CyberDrake
- free-lance moderator
- Сообщения: 338
- Зарегистрирован: 23 авг 2002, 10:39
- Откуда: Санкт-Петербург
- Контактная информация:
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Anton Kovalev
НТ, имхо, не полумера все-таки. В десктопах - может так выглядеть. Но - не везде. Что касается стоимости - дык, 5% площади кристалла, да к тому же - с ядра Willamette еще было
А что касается двух ядер на одном кристалле - дык, FSB ж не резиновая - ажно 2 ядра данными прокормить. Даже (?) у G4. Кстати: причина падения производительности P4 на некоторых задачах - тоже, как я понял из всего того, что читал - недостаток пропускной способности шины между ЦП и ОЗУ. Разрыв в производительности подсистем ОЗУ и потребности в оной ЦП ныне чудовищен, так что многоядерность тоже может стать нехилым тормозом
. И нужда в объеме кэша многоядерных ЦП может быть куда более, чем у одноядерных (даже с НТ
).
А для появления вещей калибра Ice Cube нужно, имхо, как минимум, несколько открытых с точки зрения стандартов, патентов и софта проектовна эту тему. Тогда пойдет. А так - дороговато выйдет...
CyberDrake
Да нет, не слухи - Монтесито, вроде, самый что ни на есть двуядерный Итаниум
all
Ну хорошо, в пользу "все-на-чипе" доводы есть. А SMP и иже с ним ? Или считаете, что все пойдет в стороны SoC и кластеров ?
НТ, имхо, не полумера все-таки. В десктопах - может так выглядеть. Но - не везде. Что касается стоимости - дык, 5% площади кристалла, да к тому же - с ядра Willamette еще было



А для появления вещей калибра Ice Cube нужно, имхо, как минимум, несколько открытых с точки зрения стандартов, патентов и софта проектовна эту тему. Тогда пойдет. А так - дороговато выйдет...
CyberDrake
Да нет, не слухи - Монтесито, вроде, самый что ни на есть двуядерный Итаниум

all
Ну хорошо, в пользу "все-на-чипе" доводы есть. А SMP и иже с ним ? Или считаете, что все пойдет в стороны SoC и кластеров ?
- Anton Kovalev
- Power member
- Сообщения: 38
- Зарегистрирован: 04 дек 2002, 16:48
- Откуда: Санкт-Петербург
- Контактная информация:
Что-то в VLIW архетиктурах такой мегапрогрессивной технологии не видатьa_shats писал(а):НТ, имхо, не полумера все-таки.

Но расстянуть-то немного можноА что касается двух ядер на одном кристалле - дык, FSB ж не резиновая - ажно 2 ядра данными прокормить.

Например Opteron с интегрированным контроллером памяти. Вот и устранили основного потребителя SB.
Через квартал FSB на десктопе достигнет 800МГц.Даже (?) у G4. Кстати: причина падения производительности P4 на некоторых задачах - тоже, как я понял из всего того, что читал - недостаток пропускной способности шины между ЦП и ОЗУ.
Он существенно сокращается мощным кэшированием. Причем как количественно так качественно.Разрыв в производительности подсистем ОЗУ и потребности в оной ЦП ныне чудовищен,
Дык когда речь идет о SMP там проблемы возникают куда как глобальней - синхронизация и актуальность. Многоядерные конфигурации на данном этапе справляются с подобными проблемами намного легче.так что многоядерность тоже может стать нехилым тормозом. И нужда в объеме кэша многоядерных ЦП может быть куда более, чем у одноядерных (даже с НТ
).
А софт вообще не должен знать на каком железе он работает. Конфигурационный софт поставляется вместе с железом. Единственно возможная связка в критически важных задачах.А для появления вещей калибра Ice Cube нужно, имхо, как минимум, несколько открытых с точки зрения стандартов, патентов и софта проектовна эту тему. Тогда пойдет. А так - дороговато выйдет...
Itanium 2Да нет, не слухи - Монтесито, вроде, самый что ни на есть двуядерный Итаниум![]()

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

- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
По VLIW: там оптимальная загрузка исполнительных устройств достигается программными методами (компилятором), и при оптимальном коде простаивающих блоков быть попросту не должно - значит, и возможности применить НТ просто нет
Кстати - мега-прогрессивность VLIW -тоже совсем не факт. Просто очередное "хорошо забытое старое", насколько мне известно. 
Насчет 800 МГц - ых, большие сомнения есть у меня. Недаром Интел объявил, отозвал и опять объявил 3 ГГц с этой шиной. Как бы не вышло повторения истории с Коппермайном.
Насчет кэширования: ага, а если еще вспомнить, что полночастотный кэш на кристалле становится источником огромной кучи проблем (греется, сильно увеличивает площадь кристалла и т.п.)... Не так все однозначно, имхо. Что касается "качества" - поведение Р4 при кэш-миссах уже давно притча во языцех, вроде бы как...
У многоядерных конфигураций, имхо, две основных проблемы: пропускная к памяти и большая площадь кристалла.
И еще: ныне модны n-way из 4-процессорных блоков, что у Интел (Xeon MP), что у АМД (Opteron - чего-то моделей 8хх не слышно и не видно).
Про софт: ох. Вы это сами представляете себе ? Это ж,в первую очередь, всеми проклятая совместимость
. И вообще: без тонкой настройки к железу тяжелый софт будет иметь сильно завышенные требования к производительности оного, имхо. А как раз в time-critical задачах используется софт, жесточайше привязанный к конкретной железке, пример - embedded контроллеры.
"Soc в SMP" - Неа. Принципиально. Скорее, все функции, хоть как-то связанные с пользовательским интерфейсом, будут выноситься на тонких клиентов - с SoC. А вся основная работа будет выполняться могучими, многоядерными и многоблочными числогрызами
.


Насчет 800 МГц - ых, большие сомнения есть у меня. Недаром Интел объявил, отозвал и опять объявил 3 ГГц с этой шиной. Как бы не вышло повторения истории с Коппермайном.
Насчет кэширования: ага, а если еще вспомнить, что полночастотный кэш на кристалле становится источником огромной кучи проблем (греется, сильно увеличивает площадь кристалла и т.п.)... Не так все однозначно, имхо. Что касается "качества" - поведение Р4 при кэш-миссах уже давно притча во языцех, вроде бы как...
У многоядерных конфигураций, имхо, две основных проблемы: пропускная к памяти и большая площадь кристалла.
И еще: ныне модны n-way из 4-процессорных блоков, что у Интел (Xeon MP), что у АМД (Opteron - чего-то моделей 8хх не слышно и не видно).
Про софт: ох. Вы это сами представляете себе ? Это ж,в первую очередь, всеми проклятая совместимость

"Soc в SMP" - Неа. Принципиально. Скорее, все функции, хоть как-то связанные с пользовательским интерфейсом, будут выноситься на тонких клиентов - с SoC. А вся основная работа будет выполняться могучими, многоядерными и многоблочными числогрызами

Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя