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

M>Что интересно, Qt4 позволило обращаться к UI из других потоков. (Если быть точным, позволило соединять сигналы/слоты через потоки).

Это не одно и то же. В WinForms 2 тоже можно синхронизацию с UI сделать прозрачной, если использовать AsyncOperation. Но сами контролы от этого многопоточность поддерживать не стали. Просто стало возможно писать асинхронные алгоритмы, не задумываясь о том, какая синхронизация нужна в каждом конкретном случае.

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

M>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?

Эх, а я бы не отказался. 80, не 80, но штук 8 точно не помешало бы. Вот запускаю сейчас дефрагментацию сразу на 3 vmwares, и эти сволочи сожрали все 100% на моих dual core. А было бы 8 процов, я бы ещё пару vmwares запустил

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

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

M>>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?

IT>Эх, а я бы не отказался. 80, не 80, но штук 8 точно не помешало бы. Вот запускаю сейчас дефрагментацию сразу на 3 vmwares, и эти сволочи сожрали все 100% на моих dual core. А было бы 8 процов, я бы ещё пару vmwares запустил

А вот у Sun уже есть 8 ядерные процессоры Сервер UltraSPARC T1000 всего за 3000 долларов

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

CS>Ясно. Типа девять теток родят мальцов в девять раз быстрее. ... Ну не в девять а нелинейно скажем в восемь.

Аналогия совершенно неуместная.

CS>Далеко не все задачи можно параллелить короче.

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

CS>Распаралелливание это проблема не количества процессоров а проблема алгоритмов.

Ага. Но не прикладных, а алгоритмов компилторов и рантаймов. Распараллеливание — это автоматизируемая задача. А лично я считаю глупым перекладывать на мозг человека то что можно сделать автоматически.

CS> Которые еще предстоит разработать.
CS>Т.е. ты хоть обложись камнями но "первый же залетевший GC разрушит цивилизацию"

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

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

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

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

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

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

Вопрос только — где этот итаниум? Интел с ХП в этом году 16 миллиардов планировали втюхать в продвижение его, но вот есть ощущение, что от х86-х процов прибыль больше и у тех и у других будет

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

К>Вопрос только — где этот итаниум?

Интел говорит, что раскупают его хорошо и продажи растут. Просто, при его цене, очевидно, что это продукт не для массового рынка. Ровно как и Ниагара.

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

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

К>>Вопрос только — где этот итаниум?

AVK>Интел говорит, что раскупают его хорошо и продажи растут. Просто, при его цене, очевидно, что это продукт не для массового рынка. Ровно как и Ниагара.

Задумывалось как раз для массового (замена х86), насколько я помню, (в отличии от Ниагары) но вот реалии, видимо, выглядят иначе...
А конкретных линок с цифрами под рукой нет?

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

К>Задумывалось как раз для массового (замена х86), насколько я помню

Не знаю кто и что там задумывал, но за цены, годящиеся для массового рынка, он никогда не продавался.

К>А конкретных линок с цифрами под рукой нет?

С какими цифрами?

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

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

К>>А конкретных линок с цифрами под рукой нет?

AVK>С какими цифрами?

Где бы был виден реально рост продаж, про который ты говоришь.
Хотя это не важно — забей

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

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

ОК, будем ждать.

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

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

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

M>>>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?

_>>В настоящее время подовляющее число компьютеров используется в качестве замены бумаге, ручке и калькулятору. Между тем есть такой класс задач, как моделирование. Моделировать можно всё — материалы, машины, погоду, поведение живых существ, фондовый рынок, не говоря о таких мелочах, как размещение мебели на кухне. Чем детальнее модель, чем ближе она к оригиналу, тем точнее прогноз свойств и поведения реальных объектов. Если добавить к моделированию генетические алгоритмы, то можно проектировать новые машины, отдельные их узлы не усилиями инженеров, а запустив соответствующую программу. В общем, очень перспективно.

FDS>Ничего перспективного. Задачи моделирования могут быть как хорошо распараллеливаемыми, так и плохо распараллеливаемыми. На суперкомпьютерах, например, обычно ставят много задач на небольшое количество процессоров каждой, а не одну — но распараллеленную на много процессоров: так получается эффективней. А что делать с 80 потоками на обычном компе — никому не известно, ведь задачами моделирования не каждый занимается.

Прямо, как Билл Гейтс: "Народу интернет не нужен, народу интернет не нужен..." Начнём с того что моделирование физической реальности сейчас самое модное направление развития игровой индустрии. Но теоритически можно моделировать и то, сколько проедет ваш личный автомобиль при вашем стиле вождения, и сколько протянете вы сами с учётом текущего состояния организма, режима физических нагрузок, питания и всего остального. Кроме того можно попробовать что-то виртуально изменить и посмотреть, как это скажется через десятки лет. Конечно, для этого нужны достаточно подробные модели, а результат всё равно будет не точен. Но это лучше чем жить вслепую.

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

M>

M>In the SMP version of the Erlang virtual machine, there can be many process schedulers running in separate OS threads. As default there will be as many schedulers as there are processors or processor cores on the system.

M>Взято здесь

M>Ну что я могу сказать по этому поводу ...

Ключевое слово здесь "in separate OS threads". То есть Эрланг точно так же помрет на 20-ом процессоре как Ява или С++ если приложение поднимается на Виндовс или Линукс. Так что у Эрлэнга есть чисто гипотетическое приемущество — модель. Но это уже не мало.

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

К>Вопрос только — где этот итаниум? Интел с ХП в этом году 16 миллиардов планировали втюхать в продвижение его, но вот есть ощущение, что от х86-х процов прибыль больше и у тех и у других будет

Если быть спроведливым, то UltraSPARC T1 примерно втом же месте. Как говорится "все говорят что мы в месте, но не многие знают в каком...".

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

VD>Ключевое слово здесь "in separate OS threads". То есть Эрланг точно так же помрет на 20-ом процессоре как Ява или С++ если приложение поднимается на Виндовс или Линукс. Так что у Эрлэнга есть чисто гипотетическое приемущество — модель. Но это уже не мало.
Причем эта модель также хорошо ложится на С++, .НЕТ и жабу... причем с прозрачным интеропом между ними.
Я сейчас неспешно работаю над таким велосипедом (благо где покататься есть...). Нужно много продумать но никаких принципиальных затыков я пока не вижу.

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

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

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

VD>Ты путашь игры и их движки. Игры действительно живут как феерверк. А движки эволюционируют годами. Тот же Q4 эволюционировал с Дума. Уж точно с Q1. В бетах Doom 3 были нехилые куски из Q3.

Очень большой процент игр пишется на своем движке. Да и то что есть куски кода из старых движков ничего ни показывает. Тот же думовский движок принципиально отличается от q2 — q3.

FR>>Сейчас практически все большие игры пишутся с учетом распаралеливания, так как у нового поколения игровых приставок процессоры многоядерные.

VD>Языком они пишутся. Да и твои представления о консольных системах очень поверхносные. Там не процессоров много. Тот же Целл это скорее один процессор с кучей сопроцессорв.

Пишутся и не языком, притом давно, сразу как появился гипертретрединг на P4.
Про консольные системы не надо, повторно грубить не буду, но поинтерисуйся какие процессоры используются в xbob360 да и в Nintendo Wii тоже вроде есть гипертрединг. Cell конечно особняком, но даже для него стиль OpenMP вполне работает.

VD>В общем, факт в том что нет ни одной игрушки получающей реальное приемущество от второго камня. Хотя, сам понимаешь, по уму обязаны получать. Вопли о параллелизме были еще во времена Q2. Но воз и ныне там.

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

FR>>Да ничего там сильно менять не надо, в играх полно вещей которые естественно паралелить.

VD>Кон надо менять. Ладно мне надоело. Все равно ты будешь из приципа спорить с каждым моим словом. Спорь дальше.

Да нет у меня такого принципа, просто у нас уровень упертости близкий

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

M>Что, собственно, приводит к следующему вопросу: А что у нас, собственно, способно прямо сейчас, убудчи запущенным на таком монстре, воспользоваться такой мощью? И что сможет в ближайшие пять лет?

Думаю, если я запущу (даже без перекомпиляции) весь тот софт, что я делал для кластеров, то он сразу всю мощщю и заэксплуатирует. Тем более что мой вариант message passing сам умеет решать, когда общую память использовать, а когда сериализовать сообщения.

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

K> Думаю, если я запущу (даже без перекомпиляции) весь тот софт, что я делал для кластеров, то он сразу всю мощщю и заэксплуатирует. Тем более что мой вариант message passing сам умеет решать, когда общую память использовать, а когда сериализовать сообщения.

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

Здесь же речь идет скорее о повседневном софте вроде тексовых редакторв, игрушек, ОС...

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

VD>Это очень редкий пример софта специально разрабатывавшегося в рассчете на параллельное вычисления.

Ну да. Специально. А кто мешает сейчас всем разрабатывать специально?

VD> Да и уверен, что класс задачь там особый.

Вовсе не особый. Всего лишь нереляционная СУБД с некоторыми хитрыми технологиями поиска. Никаких вычислений...

VD>Здесь же речь идет скорее о повседневном софте вроде тексовых редакторв, игрушек, ОС...

Текстовым редакторам вообще никакой производительности не нужно. Прошло то время, когда emacs расшифровывался как "eight megabytes, constantly swapping". Игрушки разпараллеливаются довольно легко — у них обычно модульность на высоте, достаточно разпараллелить графический движок, и вот уже ощутимый прирост в скорости готов. ОС — сто лет как есть такие ОС, которым любое количество процессоров не проблема. Недавно даже такое убожество, как Linux к ним присоединилось, что уж говорить о серьёзных системах. Я сам видел IRIX на системе с сотней процессоров (NUMA, конечно же, не чистый SMP). Linux с O(1) scheduler и даже SMP потянет (только вот толку от SMP на таких масштабах не будет — память, зараза, узким местом станет). Solaris тоже без проблем потянет весьма немалое количество процессоров.

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

VD>Ключевое слово здесь "in separate OS threads". То есть Эрланг точно так же помрет на 20-ом процессоре как Ява или С++ если приложение поднимается на Виндовс или Линукс. Так что у Эрлэнга есть чисто гипотетическое приемущество — модель. Но это уже не мало.
Это означает всего лишь то, что Ерлангу нужно по 1-му системному процессу на ядро, чтобы использовать всю мощу многоядерности. А свои процессы будут уже распределяться ерланговским шедулером внутри этих 20-ти системных процессов. И винда, и линукс вытянут 20 процессов без натуги. А сотни тысяч ерланговских процессов будут исключительно внутри, и ОС ничего о них не знает, отчего и не напрягается.

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

FR>Про консольные системы не надо, повторно грубить не буду, но поинтерисуйся какие процессоры используются в xbob360 да и в Nintendo Wii тоже вроде есть гипертрединг. Cell конечно особняком, но даже для него стиль OpenMP вполне работает.

Я последнее время за событиями не слежу, но еще совсем недавно читал, что процессор Wii — это Pentium 3 (как и у первого Xbox), у которого никакого гипертрединга, по вполне понятным причинам, быть не может.