Здравствуйте, VladD2, Вы писали:

VD>Это означает, что на 80-процессорном сервере Элранг будет точно так же бессмысленнен как С с ручным управлением многопоточностью, так как бутылочным голрышком станет шедулер ОС.
Разве у меня есть хоть слово про шедулер ОС ? У меня написано — "сотни тысяч ерланговских процессов будут исключительно внутри, и ОС ничего о них не знает,"
На Ниагаре это себя хорошо зарекомендовало

Здравствуйте, FR, Вы писали:

VD>>Какие еще кластеры? Кроме процессоров, ну, и возможно шины все остальное общее — разделяемые ресурсы. 80 процессоров ведь в одном камне!

FR>Так уже в современных процессорах есть средства виртуализации, например можно на каждом ядре по OS запустить, думаю не будет проблемой для 80 ядерного процессора запуск 10 OS с выделением каждому 8 ядер.

И пользователь — бог Шива — работает 20 руками в 10 операционках, наблюдая за ними в 10 мониторах 20 глазами....

Здравствуйте, mik1, Вы писали:

M>Здравствуйте, FR, Вы писали:

VD>>>Какие еще кластеры? Кроме процессоров, ну, и возможно шины все остальное общее — разделяемые ресурсы. 80 процессоров ведь в одном камне!

FR>>Так уже в современных процессорах есть средства виртуализации, например можно на каждом ядре по OS запустить, думаю не будет проблемой для 80 ядерного процессора запуск 10 OS с выделением каждому 8 ядер.

M>И пользователь — бог Шива — работает 20 руками в 10 операционках, наблюдая за ними в 10 мониторах 20 глазами....

Нет будут выпускать специальные клавиатуры на 1000 клавиш и сегментированные мониторы.

Здравствуйте, Cyberax, Вы писали:

>> параллельны по своей природе, и великолепно масштабируются. Таким
>> образом, существующие приложения на Эрланге уже готовы к такому
>> масштабированию лучше, чем какие-либо другие.
C>Не совсем. Остается еще вопрос передачи сообщений и пропускной
C>способности каналов — это достаточно дорогие операции, если сообщение
C>пересекает пределы локальной памяти ядра. Так что нужен еще Erlang 2 в
C>котором будет понятие "близости" процессов.

Совсем, совсем . И так все нормально. Рантайм R11 умеет работать на SMP — а именно так видны многоядерные конфигурации. Несколько рантаймов умеют объединятся в кластер. Ничего больше на практике не нужно.

C>Еще как вариант, нужен очень умный scheduler, который мог бы мигрировать
C>процессы между ядрами и обеспечивать автоматический multicast между
C>локальными копиями памяти.

Да все нормально, умные пацаны обо всем уже позаботились. Никакого "Эрланг 2" не нужно. "Умный шедулер" уже реализован в R11 и умеет балансировать нагрузку на ядрах, которые видны как SMP независимо от того, локальная у них память или общая. Потому, что "автоматический мультикаст" на самом деле давно реализован в железе на уровне протоколов типа Hypertransport и RapidIO — они выражают общую память через посылки сообщений. Именно так работают сейчас многоядерные оптероны — у каждого из них своя память и они лезут друг к другу в память и кэш через гипертранспорт. При этом, вся система видна как система с общей памятью (архитектура ccNUMA, google)

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Gaperton, Вы писали:

G>>Во вторых — сейчас становится модно исключать этот блок из дизайна процов, заменяя его аппаратной многопоточностью. Так устроен, например, UltraSPARC T1 ("Niagara"). Так что готовьтесь к явному многопоточному программированию.

AVK>Ну, Intel (в случае Itanium) полагается все же на компилятор.

Эта мода (VLIW, в случае Itanium) — уже в прошлом. У такой архитектуры есть ряд недостатков, один из которых связан, например, с тем, что широкий VLIW плохо кладется на кристалл — у него широкие шины. Это раздувает кристалл, делая его дороже, и снижает тактовые частоты из-за длинных связей. Например, пресловутый E2K, о котором много говорили, работает на практике (а не на бумаге) на частоте 300 МГц. По критерию "производительность с квадратного миллиметра" он далеко не блещет. А это — основное в нашем деле. То же самое можно сказать о Трансмете — это тоже довольно прямолинейный VLIW, у которого были проблемы с разгоном по той же причине. С Itanium поступили умнее — там не совсем обычный VLIW, там инструкции бьются на короткие бандлы (штуки по три) которые объединяются в большие бандлы — короче, там люди реально думали о производительности. Вероятно, Itanium — максимум из того, что можно выжать из VLIW.

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

Короче, сейчас народ в массе своей решил делать не так. Нужно делать много сравнительно простых процов — это понятно сейчас всем, и в AMD, и в Intel, и в Sun, и в NVidia, и в ATI. Именно так, кстати, будут выглядеть выдеокарты следующего поколения — выйдут анонсы, увидите.

Gaperton wrote:
> C>Не совсем. Остается еще вопрос передачи сообщений и пропускной
> C>способности каналов — это достаточно дорогие операции, если сообщение
> C>пересекает пределы локальной памяти ядра. Так что нужен еще Erlang 2 в
> C>котором будет понятие "близости" процессов.
> Совсем, совсем . И так все нормально. Рантайм R11 умеет работать на SMP
> — а именно так видны многоядерные конфигурации. Несколько рантаймов
> умеют объединятся в кластер. Ничего больше на практике не нужно.
SMP для 80 ядер вряд ли будет возможен — так как доступ к памяти станет
больным местом. Значит как-то надо эти ядра делить на кластеры, которые
будут взаимодействовать только через каналы связи.

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

> C>Еще как вариант, нужен очень умный scheduler, который мог бы мигрировать
> C>процессы между ядрами и обеспечивать автоматический multicast между
> C>локальными копиями памяти.
> Да все нормально, умные пацаны обо всем уже позаботились. Никакого
> "Эрланг 2" не нужно. "Умный шедулер" уже реализован в R11 и умеет
> балансировать нагрузку на ядрах, которые видны как SMP независимо от
> того, локальная у них память или общая.
Это-то понятно, а вот как сделать мультикастовые сообщения, например?
Чтобы сообщение от одного потока к 10 другим нужно было отослать только
1 раз, а не 10.

Здравствуйте, Cyberax, Вы писали:

C>Gaperton wrote:
>> C>Не совсем. Остается еще вопрос передачи сообщений и пропускной
>> C>способности каналов — это достаточно дорогие операции, если сообщение
>> C>пересекает пределы локальной памяти ядра. Так что нужен еще Erlang 2 в
>> C>котором будет понятие "близости" процессов.
>> Совсем, совсем . И так все нормально. Рантайм R11 умеет работать на SMP
>> — а именно так видны многоядерные конфигурации. Несколько рантаймов
>> умеют объединятся в кластер. Ничего больше на практике не нужно.
C>SMP для 80 ядер вряд ли будет возможен — так как доступ к памяти станет
C>больным местом. Значит как-то надо эти ядра делить на кластеры, которые
C>будут взаимодействовать только через каналы связи.
Ну, внутри все будет так, как ты говоришь. А снаружи, с точки зрения софта, это скорее всего будет выглядеть как SMP.
Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут через HyperThreading. И ничего — все равно это выглядит для софта как SMP, потому как это проще программить. И ничего.

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

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

>> C>Еще как вариант, нужен очень умный scheduler, который мог бы мигрировать
>> C>процессы между ядрами и обеспечивать автоматический multicast между
>> C>локальными копиями памяти.
>> Да все нормально, умные пацаны обо всем уже позаботились. Никакого
>> "Эрланг 2" не нужно. "Умный шедулер" уже реализован в R11 и умеет
>> балансировать нагрузку на ядрах, которые видны как SMP независимо от
>> того, локальная у них память или общая.
C>Это-то понятно, а вот как сделать мультикастовые сообщения, например?
C>Чтобы сообщение от одного потока к 10 другим нужно было отослать только
C>1 раз, а не 10.

В Эрланге нет мультикастовых сообщений.

Здравствуйте, Cyberax, Вы писали:

C>VladD2 wrote:
>> Это означает, что на 80-процессорном сервере Элранг будет точно так же
>> бессмысленнен как С с ручным управлением многопоточностью, так как
>> бутылочным голрышком станет шедулер ОС.
C>С чего бы? Разбиваем 80 процессоров на 8 кластеров и вперед с песней.


В 80-ядерном проце будет 80 копий шедулера оперсистемы, на каждом из которых будет крутится по одному потоку процесса Erlang Runtime. В чем проблема? Какие кластеры?

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Cyberax, Вы писали:

G>Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут через HyperThreading. И ничего — все равно это выглядит для софта как SMP, потому как это проще программить. И ничего.
А там разве гипертридинг ?

G>В Эрланге нет мультикастовых сообщений.
А будет : Армстронг хочет оператор bang-bang, он же !!

Здравствуйте, gandalfgrey, Вы писали:

G>Здравствуйте, Gaperton, Вы писали:

G>>Здравствуйте, Cyberax, Вы писали:

G>>Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут через HyperThreading. И ничего — все равно это выглядит для софта как SMP, потому как это проще программить. И ничего.
G>А там разве гипертридинг ?
Имелся в виду гипертранспорт, конечно. Апичатка.

G>>В Эрланге нет мультикастовых сообщений.
G>А будет : Армстронг хочет оператор bang-bang, он же !!
Читал я про bang-bang. Зря он это затеял, имхо. вери имхо, бред это редкостный.

Gaperton wrote:
>> > Это означает, что на 80-процессорном сервере Элранг будет точно так же
>> > бессмысленнен как С с ручным управлением многопоточностью, так как
>> > бутылочным голрышком станет шедулер ОС.
> C>С чего бы? Разбиваем 80 процессоров на 8 кластеров и вперед с песней.
> В 80-ядерном проце будет 80 копий *шедулера оперсистемы*, на каждом из
> которых будет крутится *по одному потоку* процесса Erlang Runtime. В чем
> проблема? Какие кластеры?
Оверхед больше Ну да ладно, это детали.

Gaperton wrote:
> C>SMP для 80 ядер вряд ли будет возможен — так как доступ к памяти станет
> C>больным местом. Значит как-то надо эти ядра делить на кластеры, которые
> C>будут взаимодействовать только через каналы связи.
> Ну, внутри все будет так, как ты говоришь. А снаружи, с точки зрения
> софта, это скорее всего будет выглядеть как SMP.
> Пример — два двухъядерных процессора Opteron. Ядра не равноправны — в
> рамках одного кристалла они разделяют кэш. К соседнему кристаллу лезут
> через HyperThreading. И ничего — все равно это выглядит для софта как
> SMP, потому как это проще программить. И ничего.
Понимаешь, для двух процессоров это прокатит — так как достаточно редкие
обращения к общей памяти не будут делать погоды. А вот для 80
процессоров — уже не уверен, нужно уже что-то другое. Я не сомневаюсь в
способности использовать 80 ядер для запуска 80 параллельных копий
Erlang'а.

Мне больше интересно как будет организовано управление каналами связи
между ними. Один центральный контроллер уже не прокатит — так как его
полоса пропускания должна расти квадратично с числом ядер. Значит нужна
сетевая структура с маршрутизацией сообщений, а значит появятся
интересные проблемы — чем дальше идет сообщение, тем это будет
медленнее. А значит язык должен это как-то учесть

Причем если в современных кластерах обычно сообщения между узлами
передаются все же достаточно редко и их стараются делать coarse-grained,
то при использовании кластерного подхода для создания одного компьютера,
относительный overhead нужно сделать НАМНОГО меньшим. Кому нужен будет
Erlang с 100000 процессов, если переключение на другой процесс будет
занимать миллисекунду (утрировано)?

> C>Это-то понятно, а вот как сделать мультикастовые сообщения, например?
> C>Чтобы сообщение от одного потока к 10 другим нужно было отослать только
> C>1 раз, а не 10.
> В Эрланге нет мультикастовых сообщений.
Это-то и плохо.

Здравствуйте, gandalfgrey, Вы писали:

G>Разве у меня есть хоть слово про шедулер ОС ? У меня написано — "сотни тысяч ерланговских процессов будут исключительно внутри, и ОС ничего о них не знает,"

"Процессы" Эрланга это большая фикция. Сами по себе они не позволят использовать те самые 80 процессоров.

Здравствуйте, Sergey, Вы писали:


>> Факты говорят об обратном. Поака что ни один шутер не побежал быстрее на двух или четырех камнях.

S>Вообще-то некоторое ускорение от многоядерности в некоторых шутерах есть.
S>http://www.elitebastards.com/page.php?pageid=13241

Ага. Иногда +3%, а иногда -3%.


S>Но оно пока слишком незначительное, чтобы его воспринимать всерьез

А иногда отрицательны.

S>Кстати, ATI'ные дрова теперь тоже многопоточные.

А толк то с этого есть? И вообще, если дрова занимают значительное процессрное время, то это означет, что крта дермо, так как вместо аппратной реализации используется эмуляция.

VladD2 wrote:
> G>Разве у меня есть хоть слово про шедулер ОС ? У меня написано — "сотни
> тысяч ерланговских процессов будут исключительно внутри, и ОС ничего о
> них не знает,"
> "Процессы" Эрланга это большая фикция. Сами по себе они не позволят
> использовать те самые 80 процессоров.
Причины?

Здравствуйте, Cyberax, Вы писали:

>> "Процессы" Эрланга это большая фикция. Сами по себе они не позволят
>> использовать те самые 80 процессоров.
C>Причины?

Эрланг использует потоки ОС для распараллеливания вычислений на нескольких процессорах. Сам же он парллелит вычисления на одном потоке. Что естественно никак не может дать ускорения от таличия еще одного процессора.

Ну, а так как за распределение времени между процессорами отвечает ОС, то она неменуемо станет узким местом. Современные версии Виндовс и Линукса резко деградируют после 8 процессоров, а то и вооще не поддерживают большого их количества.

Здравствуйте, Gaperton, Вы писали:

G>Эта мода (VLIW, в случае Itanium) — уже в прошлом. У такой архитектуры есть ряд недостатков, один из которых связан, например, с тем, что широкий VLIW плохо кладется на кристалл — у него широкие шины. Это раздувает кристалл, делая его дороже, и снижает тактовые частоты из-за длинных связей. Например, пресловутый E2K, о котором много говорили, работает на практике (а не на бумаге) на частоте 300 МГц.

Нет в природе никакого E2K. А то что работает работает на 300 мегагерцаях явно из-за проблем с производственной и инженерной базой. Но даже на 300 мегагерцах показывает очень не хилые результаты. Сравнимые с гигогерцовыми процессорами.

G> По критерию "производительность с квадратного миллиметра" он далеко не блещет. А это — основное в нашем деле.

За то по критерию "производительность на ват" очень даже блещет. Насколько я помню у него 5 ват.

VladD2 wrote:
> Эрланг использует потоки ОС для распараллеливания вычислений на
> нескольких процессорах. Сам же он парллелит вычисления на одном потоке.
> Что естественно никак не может дать ускорения от таличия еще одного
> процессора.
Во-первых, никто не мешает запустить ДВЕ копии интерпретатора Эрланга,
на разных процессорах и связать их как угодно (в том числе копии могут
быть на других машинах). Это УЖЕ работает.

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

Так что организуем 10 кластеров по 8 процессоров в каждом, а в каждом
кластере вешаем автономный scheduler. Это хоть сейчас можно сделать
(Xen/OpenVZ в зубы — и вперед).

> Ну, а так как за распределение времени между процессорами отвечает ОС,
> то она неменуемо станет узким местом. Современные версии Виндовс и
> Линукса резко деградируют после 8 процессоров, а то и вооще не
> поддерживают большого их количества.
Вообще-то, Линукс масштабируется до 128 процессоров.

Здравствуйте, VladD2, Вы писали:

VD>За то по критерию "производительность на ват" очень даже блещет. Насколько я помню у него 5 ват.

Да, кстати. Практика показала, что в формфакторе UMPC интел со свистом слил банальному C7-M, несмотря на то, что поначалу производители начали пользовать ULV версии Core. Особо характерен пример Q1 — вышедший в оригинале на интеле, сейчас он переделывается под C7, бо аккумуляторы нынешние далеки от совершенства.

Здравствуйте, Cyberax, Вы писали:

C>Во-первых, никто не мешает запустить ДВЕ копии интерпретатора Эрланга,
C>на разных процессорах и связать их как угодно (в том числе копии могут
C>быть на других машинах). Это УЖЕ работает.

Толку то? Еще раз, последний, сама ОС не повзволят использовать 80 процессоров одновременно. Больше я на подобные вопрсы не отвечаю.