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

FM>С небольшими доработками — игрушки

Я бы сказал с микроскопическими. Их нужно переписать на 100% на новых языках и компилторах.

Курилка wrote:
> Чтот ты такое хитрое загнул, ну не покатит эрланг для числодробилок
> И про один поток (процесс?) — это тоже "трудно", на Эрланге изначально
> декомпозиция будет иначе выглядеть, хотя в принципе тебе нельзя
> запретить создать всего 1 поток который всё будет делать, но это,
> знаешь, будет примерно также как ООП программа написанная в рамках 1 класса.
Не надо недооценивать изобретательность индусов

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

M>Ну мы работаем над авт. распараллеливанием в нашем ФЯ. Благо модель языка для этого правильная. Правда, язык на данный момент под вычисления заточен, а не под GUI. Могу, если интересно, черкануть немного об этом.

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

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

В общем, с удовольствием поможем в написании и публикации подобного материала.

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

M>Коротко говоря: в течение пяти лет Интел предлагает интегрировать невероятное количество процессоров на одном чипе (80 в прототипе) и объединить каждый с собственной памятью.

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

Виста

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

G>>Он в настоящий момент проходит государственные испытания,

VD>"Он" называется не Е2К, а Эльбрус <b>Е3М</b>.

VD>Ничего, ничего. Мне простительно. Я все же не работаю в конторе разнабатывающей чипы. А вот то что ты не знаешь название чипа о котором говоришь — это немного странно.

Ты перепутал вычислительный комплекс для военных, который делает МЦСТ, с микропроцессором. Ничего, это простительно — ты ведь и в самом деле не работаешь в конторе, разрабатывающей чипы. Многие "процессором" системый блок называют, это нормально.

Для тех, кто эту ветку читает, я дам ссылки на сайт производителя. Может кому интересно будет. Ты тоже взгляни.

Вот на этой странице
http://www.mcst.ru/develop.shtml

Ищи свой E3M в секции "вычислительные колмплексы", и смотри на него даташыт.
http://www.mcst.ru/doc/8-9.zip

А так же процессор "Эльбрус", который в среде инженеров известен как E2K.
http://www.mcst.ru/doc/2-3.zip

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

kan>Ограничение лишь из-за того, что в С++ нет поддержки ф-ций с переменным числом аргументов (я сказал, что нет! ).
...а я сказал, что нас-рать. Ибо есть overloading. И никто не мешает поределить функцию с одним параметром, затем — с двумя, затем — с тремя. Далее — насколько позволяют ресурсы, терпение и чувство меры.
Впрочем, нашшот операторов "||" и "&&" чегой-то-там Мейерс против имел. Как ни странно, я с ним вполне согласен. Ибо, если я скажу "if( future1 && future2 && non_future )" случится черт-те что с весьма неожиданными эффектами.

kan>Правда с while непонятно что сделать. Правда я и не понимаю что ты там хочешь делать...
"пока есть хотя бы одна 'живая' футура", вертимся.

kan>Видимо, тебе хочется что-то типа timed_wait но чтобы таймаут был распределён на всех... но вроде можно обёртку написать,
Да-а-а. Именно такое мне и хочется. Но pthread-ы (по образу и подобию которых смоделирован boost::thread) это не поддерживает. Делать сие "на коленке" тоже не выход ибо поимеешь busy-wait.

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

А мораль такова, что boost::thread не предусматривает никакого (Никакого. НИКАКОГО!) способа убиения задачи. Ни синхронного ни асинхронного. So is только-что-предложенный std::thread. Следовательно, прибить асинхронную таску НЕ-ВОЗ-МОЖ-НО. С чем я имею вас и поздравить.

kan>future не панацея для сабжа, а вполне чёткая концепция, удобная в определённых ситуациях.
О! "Сей Меч позволит вам без труда победить трусливого и безоружного противника". Побежаль покупать. Вы за мной!

>> Марал, до тех пор пока в C++ не будет юзабельной лямбды, futures уготовано место рядом с
>> std::for_each, которым все советуют пользоваться, но никто не хочет
kan>Мелочи реализации...
"Дьявол — в мелочах" (с) Молот ведьм.

>> Про требования к памяти скромно помолчим
kan>Фигня какая, замени на auto_ptr
Пасиб за дельный совет. А вы купите пистолет. Когда будете его испытывать, не забудьте посмотреть в ствол — может пуля и не собирается вылетать?

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

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

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

VD>Нет в природе никакого E2K.

Он в настоящий момент проходит государственные испытания, и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал. Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .

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

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

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

Здравствуйте, 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-ом процессоре как Ява или С++ если приложение поднимается на Виндовс или Линукс. Так что у Эрлэнга есть чисто гипотетическое приемущество — модель. Но это уже не мало.

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

AA>>>В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков.
IT>>А сейчас сходу сможешь быстро разобраться что делается в твоих же собственных исходниках?
AA>Запросто, Но только не в том шедулере — во первых он пропал во вторых асма спекки я уже почти не помню.

Жалко, конечно, что исходничков не осталось, а так бы запросто. Гы-гы.

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

AA>а 30000 строчек функционального кода зачастую легко превращаются в 20000 грамотным рефакторингом.

При чём тут вообще рефакторинг? Мы разве о нём говорим? Или главное о чём-нибудь спорить лишь бы спорить? Бывало приходилось 20000 строк ужимать в 100 и что с того? Мы сейчас многозадачность обсуждаем или кривой дизайн?

AA>Но вообще говоря не в кол-ве строчек сложность кода выражается.

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

AA>Хм... Три раза прочитал эту вашу фразу и так и не понял зарытого смысла

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

AA>А вот интересно как вы будете прямолинейно обрабатывать запросты в БД от одновременно 1000 юзеров?

Я их вообще никак не буду обрабатывать. БД для меня чёрный ящик, который специально обученные ребята вылизывают годами.

И вообще, я говорю совсем о другом. Давай вернёмся назад. Начал я вот с чего:

AA>А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.

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

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

Вот сам длительный процесс:

string LongProcess(string text)
{
    Thread.Sleep(1000);
    return text;
}

А это обработчик кнопки:

void button1_Click1(object sender, EventArgs e)
{
    try
    {
        textBox2.Text = LongProcess(textBox1.Text);
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message);
    }
}

У этого примера есть один существенный изъян. При действительно длительном процессе UI приложения перестанет подавать признаки жизни и приложение будет выглядеть подвисшим. Для того, чтобы этого не происходило длительный процесс необходимо запускать в отдельном потоке. Но здесь, есть одно НО. WinForms не является дружественной средой для многопоточных приложений, и доступ к элементам формы из другого потока закончится исключением. Чтобы этого не происходило придётся переписать наш линейный алгоритм следующим образом (вариант с асинхронными делегатами я даже приводить не буду):

string    _text;
string    _result;
Exception _exception;
WaitForm  _waitForm;

void button1_Click2(object sender, EventArgs e)
{
    _text     = textBox1.Text;
    _waitForm = new WaitForm();

    new Thread(LongProcessThread).Start();

    _waitForm.ShowDialog();
}

void LongProcessThread()
{
    try
    {
        _exception = null;
        _result    = LongProcess(_text);
    }
    catch (Exception ex)
    {
        _exception = ex;
    }

    Invoke(AfterLongProcess);
}

void AfterLongProcess()
{
    _waitForm.Close();

    if (_exception == null)
        textBox2.Text = _result;
    else
        MessageBox.Show(_exception.Message);
}

Итак, от нашего линейного алгоритма не осталось и следа. И это пока что очень примитивный вариант синхронизации доступа к UI.

Но ещё не всё потеряно. Если взять немного более продвинутый инструмент, то вернуть линейность алгоритма вполне возможно. Вариант с замыканиями может выглядеть примерно так:

void button1_Click(object sender, EventArgs e)
{
    string   text     = textBox1.Text;
    WaitForm waitForm = new WaitForm();

    new Thread(delegate()
    {
        Exception exception = null;
        string    result    = null;

        try
        {
            result = LongProcess(text);
        }
        catch (Exception ex)
        {
            exception = ex;
        }

        Invoke(delegate()
        {
            waitForm.Close();

            if (exception == null)
                textBox2.Text = result;
            else
                MessageBox.Show(exception.Message);
        });
    }).Start();

    waitForm.ShowDialog();
}

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

А теперь пофантазируем, что мог быть сделать катарпиллер. Допустим, у нас имелась бы возможность сказать компилятору, например, с помощью атрибутов, что доступ к объектам наследникам класса Control может осуществлятся только из потока UI. Предположим также, что у нас есть некая языковая конструкция, которая указывает компилятору, что определённая часть кода должна выполняться в новом потоке. Вот как мог бы выглядеть гипотетический код:

void button1_Click1(object sender, EventArgs e)
{
    WaitForm waitForm = new WaitForm();

    newthread
    {
        try
        {
            textBox2.Text = LongProcess(textBox1.Text);
            waitForm.Close();
        }
        catch (Exception ex)
        {
            waitForm.Close();
            MessageBox.Show(ex.Message);
        }
    }

    waitForm.ShowDialog();
}

Т.е. если бы нам не надо было открывать/закрывать WaitForm, то этот код практически не отличался бы от первоначального. Компилятор мог бы сам позаботится о вызове Invoke и чтении/записи данных в правильном потоке и в нем же вызвать MessageBox.Show.

Возможно ли сделать такой инструмент? Не знаю. Фактически от ответа на этот вопрос зависит ответ на вопрос будет ли толк от 80 процессоров на одном компьютере. В автоматическое распаралеливание пока верится с трудом. А вот вариант с подсказками компилятору где именно надо паралелить и что именно синхронизировать может оказаться вполне рабочим. Остальную рутину он должен выполнить сам. Думаю, это вполне возможно. По крайней мере, сообразительность компиляторов в случае с замыканиями и yield return вселяет надежду.

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

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

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

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

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

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

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

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

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

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

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

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

Ну если бы все сервисы что работают сейчас в Windows "в заду" ушли на свои собственные ядра никому плохо бы не было.

Тако ж apache явно просится на такую модель. Нет?

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

A>Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода.
A>Могу сказать, что есть для C++. Futures обсуждаются для включения в стандарт C++. У Herb Sutter'а есть проект Concur.

С++ в многопоточном мире точено вымрет. Большего бреда чем битые указатили при 80 камнях придумать очень тяжело.

AA>> Больше процессоров — быстрее будут исполняться всяческая CGI хренотень, которой запускается много потоков
VD>Это наивное мнение. Займись этим по плотнее и ты увидишь, что масштабирование SMP-систем совершенно не линейное.
Линейное или нет другой вопрос. Тут скорее сказывается ограничения аппаратной архитектуры SMP, но они преодолимы. см NUMA.

AA>> (по потоку на клиента) и каждому из которых надо много CPU. Будет одновременно обрабатываться 80 клиентов скриптами на каком нить перле — будут загружены все 80 процессоров. Будет одновреенно 1000 клиентов сидеть (довольно скромная цифра для веб сервера кстати) — тем лучше.

VD>Без специальных язык, специальных библиотек и специальных СУБД клиенты выстроятся в очередь, а процессоры будут заняты обработкой дэдлоков и синхронизацией.
СУБД крутится в одтельном процессе а то и на другом сервере что еще дает доп преимущество.
а процессоры будут заняты обработкой дэдлоков
Спасибо. Посмеялся

AA>> В "быту" это мультимедиа, архивация, меньше это нужно играм (которые вобщето в последнее время на 3D нагрузку только дают в основном).

VD>3D, к сведению, при хорошем исполнении вообще не должно грузить ЦП. Оно должно грузить движок физики и видиокарту. Вот там параллелизм уже есть и сейчас. Только делается от совсем по другому.
угу шейдеры всякие и тп. Но сдается мне что делается оно далеко не только _там_.

AA>> Еще можно вспомнить терминальные решения — это когда сидят 50 юзеров через терминалы на одной винде и работают в вордах/ехелях. Там вообще рай для многопроцессорных систем.

VD>Ты много видел то терминал-сервисов с 50 одновременно вкалывающими товарищами?
Достаточно. Для 1С это например рекомендуемое решение всех проблем

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

M>Intel pledges 80 cores in five years

M>Processor, memory may marry in future computers

M>Коротко говоря: в течение пяти лет Интел предлагает интегрировать невероятное количество процессоров на одном чипе (80 в прототипе) и объединить каждый с собственной памятью.

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

Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода.
Могу сказать, что есть для C++. Futures обсуждаются для включения в стандарт C++. У Herb Sutter'а есть проект Concur.

Здравствуйте, 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. Именно так, кстати, будут выглядеть выдеокарты следующего поколения — выйдут анонсы, увидите.

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

AA>В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков.

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

AA>А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.

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

Это прекрасно видно на примере FP. Пока "научившиеся ещё в 10м классе" занимались измерениями размеров своего головного мозга, толку было мало. А стоило появится нормальному инструменту с человеческим лицом и вдруг оказалось, что ничего такого волшебного в FP нет.

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

Здравствуйте, Дьяченко Александр, Вы писали:

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

VD>>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
ДА>В какой? (Просто сильно интересно)

Алгоритмической. Например научатся бесконечные циклы оптимизировать и выполнять за один такт. А еще появится набор инструкций "Office Now!", в котором будут инструкции типа RunWindows, RunNotepad, RestartWordExcelOrAccess, RunKDE и т.д. (все они будут выполняться за 1 такт, как вы понимаете). Кэши будут безразмерные, поэтому память ставить не потребуется, ибо все уже в кэше. Итдитп.

Вай, только не надо начинать священную войну.

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

AA>>>Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1
VD>>Слыхали, слыхали. А вы слыхали о трудностях заката солнца вручную?
AA>А вы я вижу слыхали про широко используемый в рекламе прием логической привязки независимых явлений. Типа выпил СуперКолу и все бабы твои

Нет, а что хочется его применить?

OpenMP — то не автоматическое распараллеливание, а полуавтоматческое. Это конечно проще чем полный ручник, но до полноценной автоматики ему как до пикина раком. При этмо код засоряется хинтами компилятору. Что тоже не фантан.

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

AA>Знаю. Потому так я балуюсь исключительно для себя Зачастую это кстати дает помимо замедления еще и значительное упрощение архитектуры.

Ой сомневаюсь я на счет уерощения. Скорее усложнение. Все же не рассчитаны современные языки на параллелизм. По крайней мере "зачастую" — это явная натяжка.

VD>>Да и что в этом интересного?
AA>хз. наверно тем что такой стиль более приближен к нашей повседневной реальной жизни

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

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

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

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

CS>>Кому нужно?

VD>Тем кто хочет чтобы их приложения реально использовали мощь множества процессоров.

Т.е. автору приложения?

А если пользователю то как раз изначальный вопрос и был: какие пользовательские задачи эта мегапроцессорность решает?

Сервера — да, понятно. У Гугла вон их много. И ясно для чего.

Попробуй продать идею "Вам надо купить 80-ти ядерный ноутбук вместо старого" моей жене например...
Или еще кому. Это и будет ответ на вопрос.

В играх наверное будет нужно.

А нейронные сети и пр. нужно делать ... на нейронах, а не на процессорах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VD>Сложноть. Ее бы без заморочек на распараллеливание осилить.

Так не бывает. Халявы для ПТУшников в IT больше не будет.

VD> А распараллеливание возводитэ сложность в квадрат.

Нет. Всего лишь умножает на константу. Это если message passing. Для традиционной модели, с общей памятью, блокировками и прочим кошмаром — то да, даже не в квадрат а порой в степень до 10 и выше.

K>> Текстовым редакторам вообще никакой производительности не нужно.

VD>Глубоко ошибашся. Там как раз все вылизывается до нельзя. Да и фунциональностью жертвуют ради этой самой скорости.

Примеры можно? Не видал я в коде текстовых редакторов следов сумасшедшей оптимизации. Ни в vim, ни в emacs. Других текстовых редакторов вроде бы и не существует.

K>> Прошло то время, когда emacs расшифровывался как "eight megabytes, constantly swapping".

VD>Времена всегда одинаковые. На повышение вычислительных ресурсов индустрия всегда отвечает повышением сложности решений, что порождает как объективное повышение выч. потребностей, так и вызванные повышеннием абстракции.

Ну да, сейчас у меня emacs в среднем до 30-40Mb жрёт. Не серьёзно.

VD>Когда-то ООП считалось жудким оверхэдом. Сегодня постоить модель АСТ или модель контента редактируемого документа — это совершенно нормальное явление. В будущем все будет только усугубляться. Абстрация будет становиться все более высокой, что соотвественно неминуемо будет приводить к накладным расходам. Единственный способ боросться с такими рсходами — это повышать интеллектуальность средств разработки.

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

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

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

И не побежит, пока четырёхголовые железки не станут популярнее.

VD> "Легко" — это на словах. А в реальной жизни все не так просто. Да ивыигрышь от одного каманя обычно компенсируется затратами на синхронизацию (коих раньше просто не было).

Именно. 4 — это уже игра стоит свеч, а на две головы графику разпараллеливать смысла нет.

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

http://www.sgi.com/products/servers/altix/4000/

SGI Altix 4700 incorporates the shared-memory NUMAflex™ architecture,
which simplifies software development, workload management and system
administration. It supports up to 512 processors under one instance
of Linux and as much as 128TB of globally shared memory. Supporting
these powerful capabilities is the NUMAlink™ interconnect, which leads
the industry in bandwidth and latency for superior performance on
cluster applications. The SGI Altix 4700 represents a versatile solution
for shared or distributed memory applications of any scale.

Sun Niagara вполне себе неплохо живет с 32 ядрами.

VladD2 wrote:
> C>Слив засчитан.
> Как дети право. Страна не пуганых идиотов... (с)
Ну так а что еще в этом форуме делать?

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

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

здесь

Автор: Guard
Дата: 29.09.06

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

...

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

Ответ типа должен сам напрашиваться?
Кстати у Гая Стила были интересные работы по поводу многоядровых процессоров (хотя это было ещё в 80-х), там он использовал вариант лиспа с расширениями для параллельных вычислений типа того, что делают APL/J/K — вариант совсем иного по отношению к эрлангу подхода.

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

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

M>>Ну мы работаем над авт. распараллеливанием в нашем ФЯ. Благо модель языка для этого правильная. Правда, язык на данный момент под вычисления заточен, а не под GUI. Могу, если интересно, черкануть немного об этом.

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

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

VD>В общем, с удовольствием поможем в написании и публикации подобного материала.

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

Здравствуйте, Дьяченко Александр, Вы писали:

VD>>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
ДА>В какой? (Просто сильно интересно)

Я не гадалка. Я просто допускаю такую возможность. Темболее что подбное уже не раз случалось.

0xDEADBEEF wrote:
> А мораль такова, что boost::thread не предусматривает никакого
> (Никакого. НИКАКОГО!) способа убиения задачи. Ни синхронного ни
> асинхронного. So is только-что-предложенный std::thread. Следовательно,
> прибить асинхронную таску НЕ-ВОЗ-МОЖ-НО. С чем я имею вас и поздравить.
Так ведь нет НИКАКОГО общего способа нормально прибить поток.

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

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

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

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

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

M>Коротко говоря: в течение пяти лет Интел предлагает интегрировать невероятное количество процессоров на одном чипе (80 в прототипе) и объединить каждый с собственной памятью.

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

Не очень понял: речь идёт о способностях ОС или об используемых алгоритмах? Ну, если ОС — то пока нет аппаратуры о ней и говорить не надо: всё-таки они аппаратно зависимые.

Что касается алгоритмов, то если .NET и пул потоков там нормально будут работать, то я готов дать хоть сейчас код, который сработает нормально (в сложной задаче) на 1500 потоках. Конечно, до пиковой производительности там будет далековато, потому что есть операции, которые исполняются в основном последовательно. Тут видимо уже речь о встраивании в обычные компьютеры векторного подхода и т.п.
И вообще, я не понимаю, (ссылок не читал), почему они будут с собственной памятью? Это неэффективно, строить ccNUMA на одном кристале, когда это явно SMP.

0xDEADBEEF wrote:

> Но у них есть проблема — futures никак не абстрагируют конкурентный
> доступ. Также, на данный момент нет никакой возможности (в рамках
> std::thread, который есть "причесанный" boost::thread) дождаться
> завершения N futures.
А чем

std::vector<int> v1 = f1();  // ждём окончания исполнения f1 и возвращаем его результат
std::vector<int> v2 = f2();  // ждём окончания исполнения f2 и возвращаем его результат
std::vector<int> v3 = f3();  // ждём окончания исполнения f3 и возвращаем его результат
// или даже
mergeResults(f1(), f2(), f3());

плохо?

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

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

VD>>>Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.
AA>>Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1
VD>Слыхали, слыхали. А вы слыхали о трудностях заката солнца вручную?
А вы я вижу слыхали про широко используемый в рекламе прием логической привязки независимых явлений. Типа выпил СуперКолу и все бабы твои

AA>>Ах да.. для .Net еще нету аналогичного лисапеда

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

AA>>Кстати я например вообще всю жизнь чисто для себя старался распараллеливать все что можно. Просто например потому что так интереснее

VD>Весьма странное поведение. Ведь на однопроцессорном железе это даст замедление.
Знаю. Потому так я балуюсь исключительно для себя Зачастую это кстати дает помимо замедления еще и значительное упрощение архитектуры.

VD>Да и что в этом интересного?
хз. наверно тем что такой стиль более приближен к нашей повседневной реальной жизни

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


FDS>>Влад, что смешного? Может объяснишь...

VD>Улыбнула наивность. Уверяю тебя, что даже на 16 процессоров эффективное распараллеливание на сегодны — это очень солжная задача. А уж на 1500 просто фантастика.


Прикольно то, что на позавчера это было обыденным делом (Cray-процессоры). Грид процов, встроенная команда асемблера типа fork и всех делов. Первичным распределением ресурсов занимается аппаратура. Надо бы этот fork вводить в платформы, он гораздо удобнее и понятнее, чем объекты-треды. Ибо тред — это поток исполнения. ИМХО, потоку должен соответствовать путь исполнения кода, а не объект.


А в дотнете практически нет средств поддержки массового параллелизма (как и в Виндовс/Линукс в целом).

VD>Так что появление 80-процессорых камней неизбежно приведет к революции в средствах разрабокти. И забавно, что бывшие аутсайдеры — функциональные языки — могут оказаться очень даже в фаворе, так как неизменяемость позволяет автоматизировать распараллеливание на уровне алгоритмов. Вот только для этого еже нужно тонну работы сделать. Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.

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


VD>Человек же на таких объемах уже совсем справиться не сможет. Отдельные алгоритмы конечно можно будет распараллелить, но в целом сложность будет такая, что никто за это не возьмется.

Уже давно берутся и всю жизнь брались, но подходят немного с другого конца. Действительно, нет смысла заставлять одну операционную систему управлять всеми 1500 процессоров. Эти процы надо группировать в кластеры. У каждой ячейки кластера пусть будет несколько (немного) процессоров и собственная аппаратная память. И пусть будут мощные каналы связи (не расшаренная память, а именно каналы связи) м/у кластерами. В каждом кластере исполняется своя копия ядра ОС, а с другими кластерами общение происходит через pipes. Именно так сейчас строятся кластеры с сотнями и тысячами процессоров.

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

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

M>>О ! Зет"с как говорится то, что надо
M>>
К>Всегда пжалста
К>А вот и линка

Читал. Много думал..

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

В Erlang процессы создаются легко и просто. ок. Они не зависят от ОС. ок. Все это прекрасно. Но ведь erl запускается ОС ? и этот самый erl запустится в одном единственном потоке ОС. (если я все правильно понимаю).
И каким тогда образом он сможет воспользоваться указанной выше мощью сейчас ?

Вопрос имеет смысл, если я правильно понял твой намек
здесь

Автор: Курилка
Дата: 29.09.06

0xDEADBEEF wrote:

> (еще живыми) футурами которые оказались вдруг не нужны? Способа
> корректно придушить этих "сирот рязанских" нету. Что бум делать? Душить
По поводу убиения сирот рязанских... Смотри как это "реализовано" в безопасной
java.
Так что убийство — смертный грех, читайте Библию.

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

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

К>Это было до R11 вроде как сейчас многопроцессорность поддерживается платформой,

Да. Вспомнил что в ДП была новость о поддержке SMP в Erlang.
Собственно

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.

Взято здесь

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

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

M>>Не обязательно, ой не обязательно. Есть и другие идеи, кроме компиляции под конкретную машину...

V>Например? Для универсальной программной реализации того же самого потребуется много if-ов на ровном месте.

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



M>>Вам писали про то, что охренительно трудно бывает ЭФФЕКТИВНО ВРУЧНУЮ распараллелить сложный алгоритм. А не о том, что охренительно трудно управлять вагоном процов.

V>Влад имел ввиду и трудности совместной работы вагона процов.

V>А распараллеливать алгоритмы не так уж сложно, если язык поддерживает. Например, можно ввести расширения типа fork, join.

Да как определитель параллелить — это и ежику понятно. А если алгоритм будет посложнее на порядок? А если нужно будет стремиться к крупно-зернистому параллелизму, а не к мелко-зернистому, пример которого Вы привели (он имеет смысл только на относительно больших размерностях матрицы). Голова не опухнет у абстрактного программиста в вакууме? Так что Влад прав — для 80-ядерников кровь из носу как будут нужны средства автоматического распараллеливания задачи. В уме такие задачки нормальные люди не должны решать.

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

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



M>> Можно запустить несколько виртуальных машин на одном компе, под разными процессорами. Собственно, именно так и предлагалось использовать версии до R11

M>Ну у меня была такая идея, только показалась несколько корявой. Но на безрыбье как говорится..

Идея эта вполне нормальная, более того, так все до последнего времени и делали. К примеру, в стандартной либе Эрланга есть модуль, реализующий так называемый пул процессов. По сути, он дает следующее — заменаете spawn на определенный там pspawn, и (бинго) у вас процессы запускаются на группе виртуальных машин с автоматической балансировкой нагрузки.

M>А вот подумал и возник еще вопрос. Пока в ОС не будет поддержки новых многоядерных процессоров, то и Erlang их мощу использовать не сможет.
В "ОС" она есть. К примеру, Эрланг замечательно себя чувствует на 8-ядерном 32-х поточном UltraSPARC T1 (виден оперсистеме как 32-х ядерный SMP) — смотрите тесты в release notes к последнему релизу.

M>Но когда в ОС будет поддержка, тогда и все программы, использующие ОС процессы(потоки) будут тоже использовать 80-core параллелизацию. Ну, что они будут валиться на большом количестве процессов, до тех пор, пока они не будут реализованы настолько же lightweight как и в Erlang это понятно

Здесь все не совсем так. В многоядерной ОС существует по одной копии шедулера процессов на ядро, так что процессы останутся такими, какие есть, и все будет нормально. Так что особой проблемы с поддержкой ОС тут нет.

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

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

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

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

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

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

FR>А про 386 на сказки похоже, NASA недавно вроде не смогла найти для ремонта.

Насе нужен процессор в mil исполнении, а не любой 386. Аналоги 386 по сю пору выпускаются в большом кол-ве для промышленной автоматики.

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

FR>>>И как ты представляешь выпуск новой игровой приставки на процессоре давно снятом с производства?
K>>Никак не представляю. Вот только P3 не снят с производства. С производства даже кажется i386 не снят.

FR>По моему снят, вроде писали пару лет назад.

Только не говорите, что первый XBox уже два года не производиться. Вот это новость так новость.
Но даже если и так, то можно говорить только об отсутствии массового, крупносерийного производства, но никак не производства вообще.

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

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

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

VD>>Сложноть. Ее бы без заморочек на распараллеливание осилить.

K> Так не бывает. Халявы для ПТУшников в IT больше не будет.

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

K> Нет. Всего лишь умножает на константу.

Спорный вопрос. Но даже если это и так, то рдости это не прибавляет.

K> Это если message passing. Для традиционной модели, с общей памятью, блокировками и прочим кошмаром — то да, даже не в квадрат а порой в степень до 10 и выше.

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

K> Примеры можно?

Я как бы сам парочку написал. И долго в свое время рассматривал как Ворд работает. Там вообще труба. Они ведь даже кренирг вручную отрабатвавают.

K>Не видал я в коде текстовых редакторов следов сумасшедшей оптимизации. Ни в vim, ни в emacs. Других текстовых редакторов вроде бы и не существует.

А как ты себе видишь эти следы? Вот например, тот же Ворд данные хранит специальными инкрементальными потоками. Из-за это глюков в нем "мама дорогая".

K> Ну да, сейчас у меня emacs в среднем до 30-40Mb жрёт. Не серьёзно.

Емакс это прмитивный редактор плоского текста. А бывают еще WUSIUG-редаткоры. В общем-то даже любой броузер уже вылизан по самое нехачу.

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

Что-то не вижу я подобного на практике.

K> И не побежит, пока четырёхголовые железки не станут популярнее.

Они уже есть у народа. Некторые платят бешенные бабки за супер карты и 10% частоты процессора. А тем временем второй камень мог бы серьезно ускорить большинство процессов в играх. Но никто не рвется в бой.

Конечно когда двухголовые будут на каждом столе, то наорд банально вложит деньги и в конце концов создадут новые вдижки которые будут утилизировать все процессоры. Но пока этого нет. Значит это не так то просто на практике.

K> Именно. 4 — это уже игра стоит свеч, а на две головы графику разпараллеливать смысла нет.

Ну, и два не так плохо, но согласен 4 это намного больший стимул.

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

VD>Конечно когда двухголовые будут на каждом столе, то наорд банально вложит деньги и в конце концов создадут новые вдижки которые будут утилизировать все процессоры. Но пока этого нет. Значит это не так то просто на практике.

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

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

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

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

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

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

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

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

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

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

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

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

M>А в последнем "гипотетичеком" варианте этот самый UI вызывается вовсе не в UI'шном потоке.

Так почитай внимательно первый же абзац после этого примера. А то создаётся впечатление, что ты только картинки посмотрел.

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

M> Если уж фантазировать, до давайте делать это пореалистичнее. А то пример совсем неубедительный получился.

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

IT>>Не вижу связи между функциональщиной и непрямолинейщиной с отсутствием состояния. Возможно она если и есть, то только в головах оголтелых поборников ФП, для которых принцип и догмы важнее здравого смысла. Для меня же ФП — это ещё один набор очень удобных паттернов и инструментов.

M>Я имел ввиду вот это:
M>

M>В функциональном программировании переменные – это просто псевдонимы для выражений (так что нам необязательно записывать всё в одну строчку). Они (переменные) не могут быть изменены. Все переменные могут принимать значения только один раз.

(это из статьи "Функциональное программирование для всех")

Это и есть догмы.

M>,а Влад выше писал:
M>

M>Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.

И что здесь не так?

IT>>Мьютексы то тут причём?

M>При том, что ими можно проблемы, которые в гипотетическом коде предлагалось решать с помощью атрибутов.

В гипотетическом коде предлагается совсем другое. А именно — приведение многопоточного алгоритма к линейному виду.

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

G>Он в настоящий момент проходит государственные испытания,

"Он" называется не Е2К, а Эльбрус <b>Е3М</b>.

G> и в ближайшее время будет принят на вооружение. Дизайн в собственности МО РФ (которое и финансировало разработку), на открытый рынок продаваться не будет. Твои соображения по поводу чип-дизайна конечно очень любопытны, особенно где ты со знанием дела пишешь про проблемы с производственной и инженерной базой, но извини, я их поскипал.

Ничего, ничего. Мне простительно. Я все же не работаю в конторе разнабатывающей чипы. А вот то что ты не знаешь название чипа о котором говоришь — это немного странно.

G> Исключительно из скромности. Где мне в такой мощной философской дискуссии участвовать, когда такие зубры чипостроения в бой пошли .

Начал в себе скромность воспитывать? Это похвально.

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

G>Ты перепутал вычислительный комплекс для военных, который делает МЦСТ, с микропроцессором.

И все же я тебя огорчу, так как я как раз ничего не перепутал. Просто в среде инженеров недостаточно информации и переизбыток желания задеть собеседника.
Вот и на этом сайте нашел один документик:
http://www.mcst.ru/doc/1_grabezhnoy.doc

Почитай его. Он несколько интереснее чем те рекламные листки на которые ты давал ссылки.

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

Словом E2K процессор назывался много лет назад когда он был на бумаге и когда его разработкой занимался Бабаян. Я тогда лично присутсвовал на презентации бумажного процессора и даже в общем-то купился на обещания. Мы даже опубликовали статейку по этому поводу. Теперь Бабаян срыл в Интел, а разработку ведут без него. За это время они умудрились сделать чип (правда не сами, а где-то в Корее). То что заработало как раз и называется E3М. А Е2К так и остался бумажным процессором. А теперь они называют Е2К общей архитектурой.

G> Ничего, это простительно — ты ведь и в самом деле не работаешь в конторе, разрабатывающей чипы. Многие "процессором" системый блок называют, это нормально.

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

G>Ищи свой E3M в секции "вычислительные колмплексы", и смотри на него даташыт.
G>http://www.mcst.ru/doc/8-9.zip

Ты почитал бы то на что ссылки даешь. Там говорится о «Эльбрус-3М1».
Ну, да продолжайте Инженер. Все равно вывернетесь, скажете, что апельины приносили.

G>А так же процессор "Эльбрус", который в среде инженеров известен как E2K.
G>http://www.mcst.ru/doc/2-3.zip

Это вообще рекламный листок для инженеров... МО РФ.

ЗЫ

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

Intel pledges 80 cores in five years

Processor, memory may marry in future computers

Коротко говоря: в течение пяти лет Интел предлагает интегрировать невероятное количество процессоров на одном чипе (80 в прототипе) и объединить каждый с собственной памятью.

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

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


К>Кстати у Гая Стила были интересные работы по поводу многоядровых процессоров (хотя это было ещё в 80-х), там он использовал вариант лиспа с расширениями для параллельных вычислений типа того, что делают APL/J/K — вариант совсем иного по отношению к эрлангу подхода.

А ссылочку можно ? Особенно по поводу того, как делают это в APL family, а то поиск что-то не помогает ...

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

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

С небольшими доработками — игрушки

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

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

FM>>С небольшими доработками — игрушки

VD>...Их нужно переписать на 100% на новых языках и компилторах. ...

Кому нужно?

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

FM>>С небольшими доработками — игрушки

VD>Я бы сказал с микроскопическими. Их нужно переписать на 100% на новых языках и компилторах.

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

Microsoft <OS Name>, причем даже этих ресурсов ей врядли хватит

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

FM>С небольшими доработками — игрушки

С каими небольшими?

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

M>Здравствуйте, Курилка, Вы писали:
К>>Кстати у Гая Стила были интересные работы по поводу многоядровых процессоров (хотя это было ещё в 80-х), там он использовал вариант лиспа с расширениями для параллельных вычислений типа того, что делают APL/J/K — вариант совсем иного по отношению к эрлангу подхода.

M>А ссылочку можно ? Особенно по поводу того, как делают это в APL family, а то поиск что-то не помогает ...

По поводу этой семейки посмотри J, там по сути SIMD на уровне языка получается, поэтому параллелить — это самое логичное.
А по поводу статей Стила вот здесь вроде бы, посмотри там по порталу — там ещё есть интересные его вещи.

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

К>А по поводу статей Стила вот здесь вроде бы, посмотри там по порталу — там ещё есть интересные его вещи.

Блин, извиняюсь, там по ходу это дело за бабки, но статьи те (точно не помню откуда качал).

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

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

FM>>>С небольшими доработками — игрушки

VD>>Я бы сказал с микроскопическими. Их нужно переписать на 100% на новых языках и компилторах.

FR>Учитывая их время жизни, это непрерывный процесс
FR>Так что преимуществами скорее всего первыми они и воспользуются.

Только вот примеров особо пока не видно
Хотя Тим Свини вроде напирал на concurrency.

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

CS>Кому нужно?

Тем кто хочет чтобы их приложения реально использовали мощь множества процессоров.

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

FR>Учитывая их время жизни, это непрерывный процесс

Непрерывный процесс — это эволюция. Тут же им прийдется попотеть. Я пока что не видел ни одной игрушки действительно ускоряющейся от наличия второго камня. А вот револющии — это всегда прерывание и надолго.

Уверен, что под такую революцию пролезут новые игроки. Старые как всегда ее проспят.
Так было уже не раз. Тот же ФарКрай, например. Но там революция была мизерная. А тут... надо менять архитектуру всего приложения.

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

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

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

К>Хотя Тим Свини вроде напирал на concurrency.

Извини, что за Свин и накого он написал?

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

CS>Ну если бы все сервисы что работают сейчас в Windows "в заду" ушли на свои собственные ядра никому плохо бы не было.

Они в основном спят. А те что не спять становятся в очередь к ресурсам вроде кэша, памяти, дестких дисков, каналов вода/вывода...

CS>Тако ж apache явно просится на такую модель. Нет?

Ага. Только на 80 камнях он будет работать не лучше чем на 8. Пока что даже Виндовс в штатном варианте не держит более 8. Так что тут прийдется очень многое переписать.

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

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

Сейчас ровным счетом ничего. Даже серверные продукты теряют эффективность при куда меньшем количестве камней.

Причем чтобы изменить ситуацию программы нужно будет писать просто по другому. Они должны быть рассчитаны на массовый параллелизм. И параллелизм для 8 камней не тоже самое что для 80. Но исследований море. Так что к тмому времени когда у всех (специально для любителей придраться к словам... у всех означает "у большинства") будут на столе такие камни. А это будет не скоро.

А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.

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

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

FR>>Учитывая их время жизни, это непрерывный процесс

VD>Непрерывный процесс — это эволюция. Тут же им прийдется попотеть. Я пока что не видел ни одной игрушки действительно ускоряющейся от наличия второго камня. А вот револющии — это всегда прерывание и надолго.

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

VD>Уверен, что под такую революцию пролезут новые игроки. Старые как всегда ее проспят.
VD>Так было уже не раз. Тот же ФарКрай, например. Но там революция была мизерная. А тут... надо менять архитектуру всего приложения.

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

VD>Но тут куча проблем. Ведь код должен одинаково хорошо работать и на 1 и на 80 процессорах. А это без автоматизации невозможно. Тут нужны специальные языки и компиляторы (рантаймы). Нужны новые подходы. Новые алгоритмы. Те работающие догмы что были в однопроцессорном мире будут выброшены на помойку и народ будет по новому изобретать велосипед.

С 80 процессорами да придется делать по другому, да и то не все игры, например те же серверные онлайн игры хоть завтра можно переводить хоть на 1000 ядерный камень. А для 4 — 8 ядер (максимум по моему что угрожает в ближайшие пять лет) у любой игры есть что распаралелить и без новых языков и технологий.

VD>Но уверен, что бабок в индустрии на это хватит. Так что тут скорее надо Интелу стараться чтобы заставить нас купить эти 80-тикамневые процессор. А я лично пока вижу мало толку даже в двух камнях. Так что им прийдется продовать 80х по ценам таким же или ниже чем 1х.

Так если не найдут способ увеличить частоту (хотя и это временная отсрочка, скорость света никто ни отменял ) распаралеливание неизбежно.

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

FR>>Учитывая их время жизни, это непрерывный процесс
FR>>Так что преимуществами скорее всего первыми они и воспользуются.

К>Только вот примеров особо пока не видно
К>Хотя Тим Свини вроде напирал на concurrency.

Это он впереди паровоза бежит
Для 2 — 8 ядер никаких новых языков и технологий не нужно.

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

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

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

G>здесь

Автор: Guard
Дата: 29.09.06

Кто ж такие вопросы в "О жизни" обсуждает?

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

FDS>Что касается алгоритмов, то если .NET и пул потоков там нормально будут работать, то я готов дать хоть сейчас код, который сработает нормально (в сложной задаче) на 1500 потоках. Конечно, до пиковой производительности там будет далековато, потому что есть операции, которые исполняются в основном последовательно.

Забыл сказать, что за задача: расчёт стержневой конструкции на прочность (одна из трудоёмких частей заключает в себе расчёт каждого стержня, который можно проводить отдельно для каждого стержня, при этом сам этот расчёт довольно хорошо параллелится на 13 потоков). В принципе, думаю МКЭ то же неплохо распараллеливается, хотя уже на векторном, а не на скалярном.

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

VD>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
В какой? (Просто сильно интересно)

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

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

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

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

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

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

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

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

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

A>Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода.
A>Могу сказать, что есть для C++.
STFI OpenMP — существует уже давно. Поддерживается компилерами от интела, мелкософта и GNU (gcc 4.1+)

A>Futures обсуждаются для включения в стандарт C++.
Пфе, "жалкое подобие левой руки". По крайней мере, по сравнению с OpenMP

Влад, что смешного? Может объяснишь...

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

FDS>Влад, что смешного? Может объяснишь...

Улыбнула наивность. Уверяю тебя, что даже на 16 процессоров эффективное распараллеливание на сегодны — это очень солжная задача. А уж на 1500 просто фантастика. А в дотнете практически нет средств поддержки массового параллелизма (как и в Виндовс/Линукс в целом). Так что появление 80-процессорых камней неизбежно приведет к революции в средствах разрабокти. И забавно, что бывшие аутсайдеры — функциональные языки — могут оказаться очень даже в фаворе, так как неизменяемость позволяет автоматизировать распараллеливание на уровне алгоритмов. Вот только для этого еже нужно тонну работы сделать. Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.

Человек же на таких объемах уже совсем справиться не сможет. Отдельные алгоритмы конечно можно будет распараллелить, но в целом сложность будет такая, что никто за это не возьмется.

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

A>>Futures обсуждаются для включения в стандарт C++.
DEA>Пфе, "жалкое подобие левой руки". По крайней мере, по сравнению с OpenMP

Собственно, сравнение futures с OpenMP неправомерно. У них разное предназначение. Futures задумывались для облегчения написания асинхронного кода. С помощью такой абстракции как futures, асинхронное выполнение сводится к небольшому количеству телодвижений:

    std::thread_pool launch_in_pool;

    std::future<std::vector<int>> f3 = launch_in_pool(std::bind(h, 100));  // асинхронный вызов h(100)

    // ... делаем другие вещи, пока f3 выполняется

    std::vector<int> v = f3();  // ждём окончания исполнения f3 и возвращаем его результат

Пример взят от сюда.

CS>>Тако ж apache явно просится на такую модель. Нет?

VD>Ага. Только на 80 камнях он будет работать не лучше чем на 8.
Гхм. А аргументы какие? Апач активно юзает многопоточность. Те он на ней построен. Больше процессоров — быстрее будут исполняться всяческая CGI хренотень, которой запускается много потоков (по потоку на клиента) и каждому из которых надо много CPU. Будет одновременно обрабатываться 80 клиентов скриптами на каком нить перле — будут загружены все 80 процессоров. Будет одновреенно 1000 клиентов сидеть (довольно скромная цифра для веб сервера кстати) — тем лучше.

VD>Пока что даже Виндовс в штатном варианте не держит более 8. Так что тут прийдется очень многое переписать.
w2k3 Datacenter держит 32. Так что 4 CPU или скока там для какой нить ХР — ограничение скорее маркетинговое.

Много процессоров надо тем кому надо много процессорного времени. В "быту" это мультимедиа, архивация, меньше это нужно играм (которые вобщето в последнее время на 3D нагрузку только дают в основном). Первые два варианта давно затачиваются под многопроцессорность — многие видео кодеки и архиваторы умеют распараллеливаться. Игры — хз. Разве что каждого NPC и самого игрока будут обсчитывать разные потоки. Еще можно вспомнить всякие технологии типа распознавания текста/речи — так тут параллелизм — это их родное. Еще можно вспомнить терминальные решения — это когда сидят 50 юзеров через терминалы на одной винде и работают в вордах/ехелях. Там вообще рай для многопроцессорных систем.

VD>Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.
Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1


D:\Program Files\Far>icl.exe /?
Intel(R) C++ Compiler Help
==========================
...blablabla...
/Qtcheck generate instrumentation to drive the Intel Thread
Checker to detect multi-threading bugs in programs
written using Windows or POSIX Threads
/Qopenmp enable the compiler to generate multi-threaded code
based on the OpenMP directives
/Qopenmp_profile link with instrumented OpenMP runtime library to
generate OpenMP profiling information for use with the
OpenMP component of the VTune(TM) Performance Analyzer
/Qopenmp_stubs enables the user to compile OpenMP programs in
sequential mode. The openmp directives are ignored and
a stub OpenMP library is linked (sequential)
/Qopenmp_report{0|1|2} control the OpenMP parallelizer diagnostic level

/Qparallel enable the auto-parallelizer to generate multi-threaded
code for loops that can be safely executed in parallel
code for loops that can be safely executed in parallel
...blablabla...

Ах да.. для .Net еще нету аналогичного лисапеда

Кстати я например вообще всю жизнь чисто для себя старался распараллеливать все что можно. Просто например потому что так интереснее

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

К>По поводу этой семейки посмотри J, там по сути SIMD на уровне языка получается, поэтому параллелить — это самое логичное.

Хм, а вот чисто гипотетисски интересно ...

Имеем простой код.

*: 1 2 3 4

1 2 9 16

Имеем процессор Pentium. Самый первый в котором появились два целочисленных конвеера.
Использует ли J эти два конвеера или нет ? Насколько я помню, для того чтобы использовались оба конвеера, необходимо специфическая последовательность ассемблерных команд. J же вроде интерпретатор ?

Имеем Dual Core. Распараллелится ли ?
Иммем Intel 80-Core Super-puper Processor. Тот же вопрос.

Или допустим большая числодробилка на Erlang, но написана студентами в одном потоке. Как поведут себя вычисления в этом случае ?

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

К>Блин, извиняюсь, там по ходу это дело за бабки, но статьи те (точно не помню откуда качал).

Ну это не страшно, главное что ключевые слова есть

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

A>Собственно, сравнение futures с OpenMP неправомерно.
Согласен. Futures никак нельзя применить для того чтобы распараллелить код написанный "непараллельным" способом. А вот OpenMP — можно.

A>У них разное предназначение.
A>Futures задумывались для облегчения написания асинхронного кода.
Я поглядываю с достаточно большим интересом на futures еще со времени когда про них начал говорить Саттер (где-то с год назад). В первую очередь потому, что при помощи их можно абстрагировать задачи предполагающие асинхронность — не только вычисления, но и ввод-вывод. Например, можно выразить сокетный select() как future.

Но у них есть проблема — futures никак не абстрагируют конкурентный доступ. Также, на данный момент нет никакой возможности (в рамках std::thread, который есть "причесанный" boost::thread) дождаться завершения N futures.

Мне кажется, что когда настанет время большого количества ядер (от 32-х), появится чип — "параллелизатор", который будет искать подходящие паттерны в однопоточном коде и распараллеливать их автоматически... То есть, делать примерно то же самое, что делает OpenMP в "ручном" режиме.

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

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

К>>Хотя Тим Свини вроде напирал на concurrency.

VD>Извини, что за Свин и накого он написал?

Посмотри здесь

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

M>Использует ли J эти два конвеера или нет ? Насколько я помню, для того чтобы использовались оба конвеера, необходимо специфическая последовательность ассемблерных команд. J же вроде интерпретатор ?

Вот уж не знаю — к разработчикам J вопрос, а оптимизирующий интерпретатор разве не бывает? Java тоже по сути интерпретатор

M>Или допустим большая числодробилка на Erlang, но написана студентами в одном потоке. Как поведут себя вычисления в этом случае ?

Чтот ты такое хитрое загнул, ну не покатит эрланг для числодробилок
И про один поток (процесс?) — это тоже "трудно", на Эрланге изначально декомпозиция будет иначе выглядеть, хотя в принципе тебе нельзя запретить создать всего 1 поток который всё будет делать, но это, знаешь, будет примерно также как ООП программа написанная в рамках 1 класса.
Всё, конечно, ИМХО

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

C>Не надо недооценивать изобретательность индусов

Согласен, только тут никакой язык не поможет, только ампутация

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

К> а оптимизирующий интерпретатор разве не бывает? Java тоже по сути интерпретатор
Твоя правда, кстати.. Вполне может быть..

К>Чтот ты такое хитрое загнул, ну не покатит эрланг для числодробилок
Ну почему же.. Операции над матрицами допустим замечательно распараллелятся.. Правда даст тут Erlang большой прирост в производительности по сравнению скажем с .net —
Матрицы хорошо параллелятся на любом языке

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

Просто подумал, может рантайм Erlang умеет делать что-то типа такого
Re[4]: Влад, что смешного?

Автор: apple-antonovka
Дата: 02.10.06

/Qparallel enable the auto-parallelizer to generate multi-threaded
code for loops that can be safely executed in parallel

Хотя с другой стороны я слабо себе представляю, как можно автоматически параллелить даже на уровне ОС для 80-ти ядреного проца. Допустим для 10-ти ядер можно создать еще полносвязную систему.. Оно упростит планирование. Но для 80-ти .. Линейка ? Кольцо ? Гиперкуб ? Тогда ОС придется иметь отдельный планировщик под каждую архитектуру проца...

В общем вопросов как обычно больше, чем ответов.

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

К>>Чтот ты такое хитрое загнул, ну не покатит эрланг для числодробилок
M>Ну почему же.. Операции над матрицами допустим замечательно распараллелятся.. Правда даст тут Erlang большой прирост в производительности по сравнению скажем с .net —
M>Матрицы хорошо параллелятся на любом языке

Ну не все же операции к матрицам сводятся

M>Просто подумал, может рантайм Erlang умеет делать что-то типа такого
M>Re[4]: Влад, что смешного?

Автор: apple-antonovka
Дата: 02.10.06

M>

M>/Qparallel enable the auto-parallelizer to generate multi-threaded
M>code for loops that can be safely executed in parallel

Нет, там подход другой — там параллельность на уровень языка вынесена, т.е. программист мыслит в терминах процессов. А не как тут, что компилятор путём каких-то своих правил какие-то части оптимизирует.
И планировщик (супервайзор) есть именнно на уровне платформы Erlang/OTP
И почитай хотябы вводный учебник, если интересно, там всё просто и понятно (по меньшей мере мне было )

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


К>Ну не все же операции к матрицам сводятся

гхм.. шизофреническая мысль.. А не сделать ли язык...
Но это так, шутка юмора.

К>Нет, там подход другой — там параллельность на уровень языка вынесена, т.е. программист мыслит в терминах процессов.
На самом деле я представляю подход к разработке приложений на Erlang . Просто подумал о том, что может рантайм помимо этого умеет на уровне машкодов что-то параллелить.
Просто не смог найти нормального описания что есть внутрях Erlang/OTP помимо создания, убития и планирования процессов. Чем-то задним чувствую, что в погоне за максимальной легковесностью и производительностью по-другому быть не может... Но мало ли..

К>И планировщик (супервайзор) есть именнно на уровне платформы Erlang/OTP
К>И почитай хотябы вводный учебник, если интересно, там всё просто и понятно
Да там все просто и понятно, просто надеялся увидеть какое-нибудь более менее подробное описание внутренней архитектуры. В документации в разделе Erlang/OTP /System Principles
пишут о том, как запускать\останавливать систему. В учебнике вообще по архитектуре ничего не нашел, только общие слова..
Хотя, может мы о разных учебниках говорим

З.Ы. В свое время был действительно поражен, насколько простой язык Erlang..

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

M>Да там все просто и понятно, просто надеялся увидеть какое-нибудь более менее подробное описание внутренней архитектуры. В документации в разделе Erlang/OTP /System Principles
M>пишут о том, как запускать\останавливать систему. В учебнике вообще по архитектуре ничего не нашел, только общие слова..
M>Хотя, может мы о разных учебниках говорим

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

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


К>Почитай докторскую Джо Армстронга, там как раз он описывает исходя из чего принимались решения при построении системы и т.п.
К>Правда там три сотни страниц, но тыж подробнее хотел
О ! Зет"с как говорится то, что надо

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

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

К>>Почитай докторскую Джо Армстронга, там как раз он описывает исходя из чего принимались решения при построении системы и т.п.
К>>Правда там три сотни страниц, но тыж подробнее хотел
M>О ! Зет"с как говорится то, что надо
M>
Всегда пжалста
А вот и линка

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

kan>0xDEADBEEF wrote:

>> Но у них есть проблема — futures никак не абстрагируют конкурентный доступ. Также, на данный момент нет никакой возможности (в рамках std::thread, который есть "причесанный" boost::thread) дождаться завершения N futures.
kan>А чем

kan>// или даже
kan>mergeResults(f1(), f2(), f3());

kan>плохо?

Плохо. Если какая-нить из них futures "зависнет" на неопределенное время, то зависнет все. Куда лучше было бы:

while(???)
   if( future& ready = is_ready(f1,f2,f3,...,fN) )
   {
       process(ready);
   } else {
       show_spinning_clock();
   }

И еще, вы тут все показываете как красяво futures вызываются, но не показываете как некрасяво они конструируются. Марал, до тех пор пока в C++ не будет юзабельной лямбды, futures уготовано место рядом с std::for_each, которым все советуют пользоваться, но никто не хочет

И еще, вы так легко передаете вектор по значению, как будто это маа-а-аленький такой int Из этого еще одна марал, до тех пор пока в C++ не будет реализован move-constructor, вам и 100 процессоров будет мало. Про требования к памяти скромно помолчим

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

CS>>>Тако ж apache явно просится на такую модель. Нет?

VD>>Ага. Только на 80 камнях он будет работать не лучше чем на 8.
AA>Гхм. А аргументы какие? Апач активно юзает многопоточность. Те он на ней построен.

Апач не может "юзать" многопоточность активнее ОС на которой он работает. А современные Видовс и Линукс 80 просто не тянут. Так что Апач даже не тисировался на подобных задачах.
К тому же Апач это просто средство отформатировать текст и отдать по ХТТП. А вот данные что он отдает еще где-то взять нужно. И тут то и случится узкое местечко. Все клиенты ломанутся к одной СУБД и 72 процессора.

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

Это наивное мнение. Займись этим по плотнее и ты увидишь, что масштабирование SMP-систем совершенно не линейное.

AA> (по потоку на клиента) и каждому из которых надо много CPU. Будет одновременно обрабатываться 80 клиентов скриптами на каком нить перле — будут загружены все 80 процессоров. Будет одновреенно 1000 клиентов сидеть (довольно скромная цифра для веб сервера кстати) — тем лучше.

Без специальных язык, специальных библиотек и специальных СУБД клиенты выстроятся в очередь, а процессоры будут заняты обработкой дэдлоков и синхронизацией.

AA>w2k3 Datacenter держит 32. Так что 4 CPU или скока там для какой нить ХР — ограничение скорее маркетинговое.

2 для ХРюши ограничение. Но это дейсатвительно маркетинг. Реальная цияра 4-8. А вот ДатаЦентр — это утучный продукт не продающийся в коробке. Он специально адаптируется для каждой железки на которой работает и без оной не продается. Это опять же наивное представление. Стоят такие решения мегобаксы и софт по них тоже очень специфичен.

AA>Много процессоров надо тем кому надо много процессорного времени.

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

AA> В "быту" это мультимедиа, архивация, меньше это нужно играм (которые вобщето в последнее время на 3D нагрузку только дают в основном).

3D, к сведению, при хорошем исполнении вообще не должно грузить ЦП. Оно должно грузить движок физики и видиокарту. Вот там параллелизм уже есть и сейчас. Только делается от совсем по другому.

AA> Еще можно вспомнить терминальные решения — это когда сидят 50 юзеров через терминалы на одной винде и работают в вордах/ехелях. Там вообще рай для многопроцессорных систем.

Ты много видел то терминал-сервисов с 50 одновременно вкалывающими товарищами?

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

VD>>Извини, что за Свин и накого он написал?

К>Посмотри здесь

Игрушечник значит? Ну, им сам бог вилел об этом думать. Это только лихие бравые парни с РСДН полагают что в играх все раз плюнуть чтобы перевести в режим массового параллелизма.

А где он это говорил? И что конкретно?

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

VD>>Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.
AA>Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1

Слыхали, слыхали. А вы слыхали о трудностях заката солнца вручную?

AA>Ах да.. для .Net еще нету аналогичного лисапеда

Думаю они там будут несколько более высокоуровневыми.

AA>Кстати я например вообще всю жизнь чисто для себя старался распараллеливать все что можно. Просто например потому что так интереснее

Весьма странное поведение. Ведь на однопроцессорном железе это даст замедление. Да и что в этом интересного?

0xDEADBEEF wrote:

> Плохо. Если какая-нить из них futures "зависнет" на неопределенное
> время, то зависнет все. Куда лучше было бы:
У class future есть методы ready/wait/timed_wait, что не удивительно.
Так что твой код будет выглядеть чуть по-другому, но делать тоже самое. Ограничение лишь из-за того, что в С++ нет
поддержки ф-ций с переменным числом аргументов (я сказал, что нет! ).

if(f1.ready() && f2.ready() && f3.ready())

Правда с while непонятно что сделать. Правда я и не понимаю что ты там хочешь делать...
Видимо, тебе хочется что-то типа timed_wait но чтобы таймаут был распределён на всех... но вроде можно обёртку написать,
если вдруг понадобится...

Потом, можно соглашение сделать, что "зависать" не будет, а будет по таймауту отваливаться с ошибкой. Будет удобно в
ситуации, когда тебе нужно собрать несколько ресурсов, некоторые из сети, например, некоторые "тяжело" вычисляются и
т.п. и как-то соорудить результат.
future не панацея для сабжа, а вполне чёткая концепция, удобная в определённых ситуациях. Можно предложить событийную
модель как альтернативу.

> И еще, вы тут все показываете как красяво futures вызываются, но не
> показываете как некрасяво они конструируются. Марал, до тех пор пока в
> C++ не будет юзабельной лямбды, futures уготовано место рядом с
> std::for_each, которым все советуют пользоваться, но никто не хочет
Мелочи реализации...

> И еще, вы так легко передаете вектор по значению, как будто это
> маа-а-аленький такой int Из этого еще одна марал, до тех пор пока в C++
> не будет реализован move-constructor, вам и 100 процессоров будет мало.
> Про требования к памяти скромно помолчим
Фигня какая, замени на auto_ptr
Просто теоретически vector<int> из 5 примитивных элементов может быть быстрее...
Кстати, move-constructors таки.

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

DEA>Но у них есть проблема — futures никак не абстрагируют конкурентный доступ.

Что ты имеешь ввиду под конкретным доступом?

> Также, на данный момент нет никакой возможности (в рамках std::thread, который есть "причесанный" boost::thread) дождаться завершения N futures.

Для этого есть future_group. Грубо говоря:

future<int> f1 = ...;
future<double> f2 = ...;
future_group<...> fg = f1 && f2;
fg();  // waits for both f1 & f2 and returns something (what?  maybe tuple<future<int>, future<double>>)

И это можно сделать в рамках boost::thread. У меня есть идея как такую штуку провернуть через boost::condition.

VD>OpenMP — то не автоматическое распараллеливание, а полуавтоматческое. Это конечно проще чем полный ручник, но до полноценной автоматики ему как до пикина раком. При этмо код засоряется хинтами компилятору. Что тоже не фантан.
Ну OpenMP это раз. Два — это ключик /Qparallel для icl которому openmp директивы не нужны
А автоматически... полностью автоматически это пожалуй только в каком нить смоллтолке сделать можно.

VD>Меж тем побочные эффекы и особенно фокусы с указателями могут привести к такому, что потом не расхлебаешь. Идея Эрлэнговских лайт-процессов и активных объектов — это полный автомат. Хотя и не лишенный недостатков.
аналогично.

AA>>Знаю. Потому так я балуюсь исключительно для себя Зачастую это кстати дает помимо замедления еще и значительное упрощение архитектуры.
VD>Ой сомневаюсь я на счет уерощения. Скорее усложнение. Все же не рассчитаны современные языки на параллелизм. По крайней мере "зачастую" — это явная натяжка.
Очень зачастую. Просто пользоваться надо уметь
Но соглашусь что в таком стиле написанный мной код оказывается обычно проще только для меня. Причина ИМХО — не учат пока в школах/вузах многопоточному программированию толком. Рассказывают про бегинтред какой нить и мутексы в конце обучения и все. Мое мнение — программера идее параллельного исполнения взаимодействующих алгоритмов учить надо с самого начала. Тогда же когда про Чертежника/Робота там рассказывают, или что там ща в школах. В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков. А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.


VD>>>Да и что в этом интересного?
AA>>хз. наверно тем что такой стиль более приближен к нашей повседневной реальной жизни

VD>Серьезно. Ты способен одновременно делать несколько дел? Попробуй ради хохмы вертеть левой рукой по часовой стрелке, а правой ногой по часовой. Когда привыкнешь к этому попробуй на ходу поменять направление вращения. Уверяю тебя эффект будет потрясающий.
<Офтоп конечно..>
Я вижу у вас даже печатать наоборот не получилось
Между тем ногами и руками я кручу без особых проблем в разные стороны и меняюнаправление. Просто я с детства тренировался делать ассиметричные вещи левыми и правыми частями тела — тоже из интереса. От этих кручений до "перебирания" пальцами левой и правой рук в разные стороны что гораздо сложнее, но тоже получается после определенного кол-ва тренировок
</Офтоп конечно..>


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

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

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

AA>>В моем случае я этому научился еще в 10м классе кода на асме под спекки написал этакий шедулер потоков.

IT>А сейчас сходу сможешь быстро разобраться что делается в твоих же собственных исходниках?
Запросто, Но только не в том шедулере — во первых он пропал во вторых асма спекки я уже почти не помню.


AA>>А так народ и выходит из ВУЗов с плоско-функциональным мышлением в области программирования. И хорошо еще если он потом поймет хотябы как правильно юзать ООП.

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


IT>Это прекрасно видно на примере FP. Пока "научившиеся ещё в 10м классе" занимались измерениями размеров своего головного мозга, толку было мало. А стоило появится нормальному инструменту с человеческим лицом и вдруг оказалось, что ничего такого волшебного в FP нет.
Хм... Три раза прочитал эту вашу фразу и так и не понял зарытого смысла

IT>Тоже самое касается и многопоточности. Проблема не в понимании как таковом. Проблема в понимании увеличивающейся на порядок сложности кода, выполняющего задачу многопоточно, по сравнению с тем же кодом, но делающем тоже самое прямолинейно.
Это отлично работает когда прямолинейно делается
printf ("hello world!");

А вот интересно как вы будете прямолинейно обрабатывать запросты в БД от одновременно 1000 юзеров? Наверное складывать в очередь и потом по очереди обрабатывывать да? Т.е. по сути самому реализовывать многопоточность, но в более понятном для вас функциональном стиле — когда все последовательно вот так сразу и работает. Переключением контекстов будет в этом случае последовательное доставание запросов из очереди вами. Данная реализация будет просто частным случаем многопоточной обработки, но синхронизированной "на корню", вместо реально нужных узких мест + вы реализуете функционал уже имеющийся в ОС. Да сейчас это по производительности выгодее, если работать на одном процессоре, но если в самом деле будут десятки ядер...

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


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


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

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


VD>Кон надо менять.

(Код?)
Ну да, разумеется. Скорости передачи данных внутри проца в разы больше, чем наружу через самые быстрые AGP. Если будут дополнительные процессоры, то даже последнюю стадию — сглаживание эффективней будет сделать внутри, чем гнать на какой-то внешний чип.

----------------------
Пофантазирую

Представим например, что мы взяли "крутой" монитор, который может отобразить 3.2k x 2.4k, возьмем 48 бит цвета, получим 46MB готовой информации на один кадр. А для работы конвеера нужны еще пара буферов для промежуточных данных, но уже с плавающей точкой, т.е. 12 байт на точку. При частоте в 100 Герц и двух паралельных конвеерах получим примерно 7.5GB вычисляемых по сложным алгоритмам данных в секунду на конвеер. Хрена себе...

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


> И что сможет в ближайшие пять лет?

Для .Net 7.0 ИМХО маловато будет

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

В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

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

A>Нужны языки программирования и библиотеки, облегчающие написание многопоточного кода.
A>Могу сказать, что есть для C++. Futures обсуждаются для включения в стандарт C++. У Herb Sutter'а есть проект Concur.

Фьючерсы — это реально очень-очень крутая штука, наверно, одно из самых интересных обобщений в области ЯП. Тока ИМХО для полного счастья они должны непосредственно языком поддерживаться. Например, вот так:
http://www.ps.uni-sb.de/alice/manual/futures.html

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

V>В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

На кластере какой архитектуры ? в том смысле как соединяются элементы кластера ? Полносвязно ? Еще как-то ?

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

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


VD>А где он это говорил? И что конкретно?

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

CS>>>>Тако ж apache явно просится на такую модель. Нет?

VD>>>Ага. Только на 80 камнях он будет работать не лучше чем на 8.
AA>>Гхм. А аргументы какие? Апач активно юзает многопоточность. Те он на ней построен.

VD>Апач не может "юзать" многопоточность активнее ОС на которой он работает. А современные Видовс и Линукс 80 просто не тянут. Так что Апач даже не тисировался на подобных задачах.

Это хорошо видно здесь: Apache vs. Yaws

Apache dies at about 4,000 parallel sessions. Yaws is still functioning at over 80,000 parallel connections.

...

The problem with Apache is not related to the Apache code per se but is due to the manner in which the underlying operating system (Linux) implements concurrency. We believe that any system implemented using operating system threads and processes would exhibit similar performance. Erlang does not make use of the underlying OS's threads and processes for managing its own process pool and thus does not suffer from these limitations.

Что, конечно, не убирает проблемы:

VD> К тому же Апач это просто средство отформатировать текст и отдать по ХТТП. А вот данные что он отдает еще где-то взять нужно. И тут то и случится узкое местечко. Все клиенты ломанутся к одной СУБД и 72 процессора.

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

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

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

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


V>>В догонку. Unix-подобная Plan9 способна работать в кластере произвольного размера, представляя кластер как единую систему с т.з. пользователя.

M>На кластере какой архитектуры ? в том смысле как соединяются элементы кластера ? Полносвязно ? Еще как-то ?

Кластер для Plan9 не обязан быть однородным. Да и сложновато и неэффективно все несколько тысяч ядер связать однородной связью. Могу пофантазировать: как вариант разбить на "очаги" в которых будет полносвязные соединения, а "очаги" в свою очередь — в какю-нибудь архитектуру верхнего уровня, например в звезду.

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

Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.

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

V> Да и сложновато и неэффективно все несколько тысяч ядер связать однородной связью.
+1 Собственно в связи с этим вопрос и возник.

V> Могу пофантазировать: как вариант разбить на "очаги" в которых будет полносвязные соединения, а "очаги" в свою очередь — в какю-нибудь архитектуру верхнего уровня, например в звезду.
Динамически???
Или руками(полуавтоматом) с перестройкой под каждую систему ?

V>Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.
Просто Plan9 тогда должен разработать какой-то алгортим маршрутизации для передачи данными между процессами, через промежуточные.

Неужели он сам найдет оптимальный маршрут ?

Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

Просто не может ли получиться так, что основное время система будет заниматься пересылкой данных, а не собственно задачей ?

Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

З.Ы. И что он будет делать если кусок кластера отвалится ? (Злая уборщица передавит канал связи у кольца )

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

VD>>Это наивное мнение. Займись этим по плотнее и ты увидишь, что масштабирование SMP-систем совершенно не линейное.
AA>Линейное или нет другой вопрос. Тут скорее сказывается ограничения аппаратной архитектуры SMP, но они преодолимы. см NUMA.

Да фиг с ней, с архитектурой. А вот что делать с формулой Амдала?

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


M>Или руками(полуавтоматом) с перестройкой под каждую систему ?

имеется ввиду некая аппаратная связь, конечно же. Насчет динамической перестройки архитектуры соединений — а смысл? В иерархической модели IP-доменов хорошо живут unix-подбные системы, и Plan9 в т.ч. Да и весь сетевой софт на это заточен.

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


V>>Будет. Если м/у 2-мя процессами есть "канал", то процессы запросто работают совместно.
M>Просто Plan9 тогда должен разработать какой-то алгортим маршрутизации для передачи данными между процессами, через промежуточные.

M>Неужели он сам найдет оптимальный маршрут ?

Конечно
Статически прописать метрику на подсетки (очаги) проще простого.


M>Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

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


M>Просто не может ли получиться так, что основное время система будет заниматься пересылкой данных, а не собственно задачей ?

Нет не будет. Внутри "очага" можно проложить оптические свичи м/у ядрами со скоростями в несколько MB/s. Какие основные задачи решают кластера? Моделирование погоды, расчет диффуров и моделей поведения земной коры, ядерный синтез и т.д. и т.д. Размер самих моделей обычно невелик. Велики вычисления по оной (ради чего все и затевается). Я же не думаю, что вычисления организованы так, что требуют в процессе вычисления постоянно гонять кучу данных. На примере взлома ключа шифра: каждому "очагу" был бы выделен диапазон и шифрованный текст. Обратно получилибы уже готовые данные. В общем, ничего нового. Клиент-серверные системы, а затем многоуровневые для того и появились, чтобы оптимизировать передачу данных.


M>Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

Протоколы маршрутизации весьма успешно справляются в случае множественных путей к адресату. Кстати, откуда взялась характеристика "однонаправленный"?


Да, еще замечание. Если когда-нить пойдет речь о том, что все несколько тысяч обсуждаемы ядер будут физически находится на одном устроцстве (или даже на одном чипе ... а что? эдакий многомерный полимерный электронный пирожок ), то, ясное дело, сетевую систему придумают максимально эффективную для организации внутренних pipes. Не уверен, что речь пойдет об IP, ибо в протоколе IP невообразимый оверхед, совершенно ненужный в случае внутричипового канала.

M>З.Ы. И что он будет делать если кусок кластера отвалится ? (Злая уборщица передавит канал связи у кольца )

Погибнут процессы, которые на нем исполнялись. А чего ты ожидал? Если речь о данных, то Oracle вполне умеет жить на кластерах. Если часть кластера отвалится и конфигурация подразумевает полное дублирование, то продолжит работу вторая половина.

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


M>>Неужели он сам найдет оптимальный маршрут ?

V>Конечно
V>Статически прописать метрику на подсетки (очаги) проще простого.

Но все равно без настройки руками не обойтись, насколько я понимаю.

M>>Только что подумал, что в принципе можно по графу найти кратчайшие пути между всеми парами процессоров.

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

Ну то есть для получения оптимального результата подкручивать что-то будет надо.
Это как раз то, что меня смущало..

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

V> Клиент-серверные системы, а затем многоуровневые для того и появились, чтобы оптимизировать передачу данных.
+1

M>>Допустим в случае однонаправленного кольца передача данных между процессами может стать реальной проблемой..

V> Кстати, откуда взялась характеристика "однонаправленный"?
Из сфероконического вакуума


V>... то, ясное дело, сетевую систему придумают максимально эффективную для организации внутренних pipes. Не уверен, что речь пойдет об IP, ибо в протоколе IP невообразимый оверхед, совершенно ненужный в случае внутричипового канала.
+1

0xDEADBEEF wrote:

> kan>Ограничение лишь из-за того, что в С++ нет поддержки ф-ций с
> переменным числом аргументов (я сказал, что нет! ).
> ...а я сказал, что нас-рать. Ибо есть overloading. И никто не мешает
> поределить функцию с одним параметром, затем — с двумя, затем — с тремя.
> Далее — насколько позволяют ресурсы, терпение и чувство меры.
> Впрочем, нашшот операторов "||" и "&&" чегой-то-там Мейерс против имел.
> Как ни странно, я с ним вполне согласен. Ибо, если я скажу "if( future1
> && future2 && non_future )" случится черт-те что с весьма неожиданными
> эффектами.
Ну вот и сделай функции
bool ready(future f1){return f1.ready();}
bool ready(future f1, future f2){return f1.ready() && f2.ready();}
и т.п.
В общем мне несовсем понятно в чём возражение (если это возражение ).

> kan>Правда с while непонятно что сделать. Правда я и не понимаю что ты
> там хочешь делать...
> "пока есть хотя бы одна 'живая' футура", вертимся.
Это практически и означает "f1.wait(); f2.wait();...". Т.е. дождаться завершения всех футур. Зачем это делать через
while/ready? Если надо что-то периодически что-то делать во время ожидания — запусти ещё один тред или timed_wait
используй. В простом случае f[n].timed_wait(timeout / totalNumberOfFutures), при необходимости более "умного" ожидания,
написано ниже.

> kan>Видимо, тебе хочется что-то типа timed_wait но чтобы таймаут был
> распределён на всех... но вроде можно обёртку написать,
> Да-а-а. Именно такое мне и хочется. Но pthread-ы (по образу и подобию
> которых смоделирован boost::thread) это не поддерживает. Делать сие "на
> коленке" тоже не выход ибо поимеешь busy-wait.
Всё просто. Имеем таймаут 10 сек и 3 футуры.
Засекаем момент времени. Ждём первую 10 секунд, когда завершается проверяем сколько времени прошло, скажем 3 секунды.
Ждём вторую 10-3=7 секунд, опять проверяем, она завершилась раньше первой, а значит ожидание затратит 0 секунд, на
третью у нас снова 7 сек есть. Третью ждём 7 сек. Т.е. просто из общего таймаута вычитать потраченное время ожидания на
каждую футуру. Если очередная футура превысит остаток таймаута — значит не дождались.
Ещё как вариант — создать ещё одну футуру, которая будет содержать "f1.wait();f2.wait();..." и вызывать timed_wait на
этой футуре.

> kan>Потом, можно соглашение сделать, что "зависать" не будет, а будет по
> таймауту отваливаться с ошибкой.
> Оки. Теперь смотрим что получается. Одна футура сдохла по исключению.
> Началась раскрутка стека "материнской" нитки. А что делать с остальными
> (еще живыми) футурами которые оказались вдруг не нужны? Способа
> корректно придушить этих "сирот рязанских" нету. Что бум делать? Душить
Один выход. Убивать себя об стену.

> их силой, рискуя уничтожить всю программу или ждать их "естественной"
> смерти (неизвестно когда), рискуя тем, что пул потоков (в конце концов)
> окажется весь оккупирован этими "сиротами" и приложение выродится
> обратно в однопоточное? Или начнем увеличивать пул и с риском
> использовать все адресное пространство и угробить всю программу куда
> более странным способом?
>
> А мораль такова, что boost::thread не предусматривает никакого
> (Никакого. НИКАКОГО!) способа убиения задачи. Ни синхронного ни
> асинхронного. So is только-что-предложенный std::thread. Следовательно,
> прибить асинхронную таску НЕ-ВОЗ-МОЖ-НО. С чем я имею вас и поздравить.
Невозможно теоретически в общем случае! И от boost/std это не зависит. Это сущность понятия thread. Иногда можно
прибивать процессы, если известно, что они не оставят какие-нибудь общие ресурсы типа файлов/базы данных/удалённого
сервиса в "неправильном" состоянии.

> kan>future не панацея для сабжа, а вполне чёткая концепция, удобная в
> определённых ситуациях.
> О! "Сей Меч позволит вам без труда победить трусливого и безоружного
> противника". Побежаль покупать. Вы за мной!
И трусливого сложно победить иногда, он может быстро бегать.

>> > Марал, до тех пор пока в C++ не будет юзабельной лямбды, futures
> уготовано место рядом с
>> > std::for_each, которым все советуют пользоваться, но никто не хочет
> kan>Мелочи реализации...
> "Дьявол — в мелочах" (с) Молот ведьм.
Тёмные века?

>> > Про требования к памяти скромно помолчим
> kan>Фигня какая, замени на auto_ptr
> Пасиб за дельный совет. А вы купите пистолет. Когда будете его
А что не устраивает-то? Или тоже задаёшься вопросом "есть ли жизнь без gc"?

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

V>Прикольно то, что на позавчера это было обыденным делом (Cray-процессоры).

Не было это обыденным делом. Во-первых Cray сами по себе никогда не были обыденным делом, а во-вторых та экзотика, что считалась на креях, сейчас точно так же спокойно живет на кластерах и никого это не удивляет. Собственно всякие XxxMP оттуда и идут. Только речь в этом топике немножко о другом ИМХО.

V>А в дотнете практически нет средств поддержки массового параллелизма (как и в Виндовс/Линукс в целом).

Работы на этут тему ведутся, причем не одной командой. Из самых известных слышал, наверное, про PLInQ?

V>Ну да, автоматическое распарралеливание — это сложная задача, и она практически не решается в общем случае.

А вот это фик его знает. Насколько мне известно, каких то выводов о решаемости и NP-полноте этой задачи пока никто сделать не смог.

V>Выражаясь современным языком, программы и фреймворки надо будет распространять в исходниках и компилить на конкретной платформе.

Или использовать JIT.

V>Уже давно берутся и всю жизнь брались, но подходят немного с другого конца. Действительно, нет смысла заставлять одну операционную систему управлять всеми 1500 процессоров. Эти процы надо группировать в кластеры. У каждой ячейки кластера пусть будет несколько (немного) процессоров и собственная аппаратная память. И пусть будут мощные каналы связи (не расшаренная память, а именно каналы связи) м/у кластерами. В каждом кластере исполняется своя копия ядра ОС, а с другими кластерами общение происходит через pipes. Именно так сейчас строятся кластеры с сотнями и тысячами процессоров.

Проблема не в архитектуре, проблема в алгоритмах и программах, которые на всем этом будут работать. Пока речь идет о всяких моделированиях, OpenMP сотоварищи хватает. Как только речь заходит о чем то другом, возникает куча проблем.

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

M>В Erlang процессы создаются легко и просто. ок. Они не зависят от ОС. ок. Все это прекрасно. Но ведь erl запускается ОС ? и этот самый erl запустится в одном единственном потоке ОС. (если я все правильно понимаю).
M>И каким тогда образом он сможет воспользоваться указанной выше мощью сейчас ?

Это было до R11 вроде как сейчас многопроцессорность поддерживается платформой, примерно об этом сегодня в erlangquestions обсуждение было, точнее ещё продолжается — почитай, может что ясней станет.

kan wrote:

> Так что убийство — смертный грех
А что не так, Курилка?

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

DEA>Мне кажется, что когда настанет время большого количества ядер (от 32-х), появится чип — "параллелизатор", который будет искать подходящие паттерны в однопоточном коде и распараллеливать их автоматически... То есть, делать примерно то же самое, что делает OpenMP в "ручном" режиме.

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

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

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

VD>>Лично я незнаю ни одного ЯП с автоматическим распараллеливанием вычислений. Тут пока одна теория.
AA>Про OpenMP слыхали? http://www.openmp.org/drupal/node/view/11#Q1

Фортран параллелят полностью автоматически с 80-х годов. Первые работы по автоматическому распараллеливанию были выполнены Куком, с тех пор все достаточно сильно продвинулось вперед.

http://parallel.ru/tech/tech_dev/auto_par.html

Кстати, Intel Fortran умеет автоматически параллелить программу.

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

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

V>> Да и сложновато и неэффективно все несколько тысяч ядер связать однородной связью.
M>+1 Собственно в связи с этим вопрос и возник.

Как это ни странно, на самом деле, в современных суперкомпьютерных кластерах с несколькими тысячами ядер именно так и делают. Применяют специальные коммутируемые бесконфликтные сети с небольшим размером пакета. Например, часто используются myrinet и infiniband (wikipedia или google).

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

V>У современных игрушек скорее видюха является бутылочным горлышком, чем процессор.

Только вчера читал статью про разгод Pentium D 805. Он дал 17 кадров в секунду. А разницы не было только на разрешениях 2000+ * что-то там. Так что процессор тоже важен. И это были шутеры с малым количеством мозгов.

V>Первым делом что произойдет при увеличении ядер до N-го количества — это ликвидация отдельных графических и музыкальных чипов, ибо ненужны станут. Разумеется и движки будут существенно переработаны под новую организацию выч-конвеера.

Уверен что этого не произоцдет. В графических чипах уже по 45 микрокамней заточненных для специальных задач.

V>Ну да, разумеется. Скорости передачи данных внутри проца в разы больше, чем наружу через самые быстрые AGP.

Да, но это все фигня. Тут код будет меняться идеологически. Для распаралеливания важны совсем другие факторы нежели для вытягивания жил из одного камня.

V> Если будут дополнительные процессоры, то даже последнюю стадию — сглаживание эффективней будет сделать внутри, чем гнать на какой-то внешний чип.

Пойми, топавая вюдюха стоит более 500 баксов. За эти деньги на нее можно поставить такой же 80-процессорный монстр. А можно и 1000-процессорный специализированый девайс. И мне кажется, что именно последнее и произойдет. Но ЦП всегда работа останется. Ведь чтобы даже монстры выглядили умными для них нужны вычислительные ресурсы. Сейчас они все живут на одном каме. А при 80 процах для них спокойно можно будет выделить 40 процессоров .

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

AA>Два — это ключик /Qparallel для icl которому openmp директивы не нужны

Здорово. То есть Оракул и т.п. осталось только перекомпилировать свой код? Интересно почему они этого до сих пор не сделали?

AA>А автоматически... полностью автоматически это пожалуй только в каком нить смоллтолке сделать можно.

С чего же это? Как раз МТ мягко говоря виховый кандидат.

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

V>Прикольно то, что на позавчера это было обыденным делом (Cray-процессоры).

Крэи, говоришь, обыйденное дело? Ты их в живую то видел? А цены их знаешь?

V> Грид процов, встроенная

К твоему сведению Грид — это как раз тенология использующая кучу относительно простых машин.

V>команда асемблера типа fork и всех делов.

То есть ОС у нас аппоратная? Прелесно. Это было бы конечно забавно и примерно об этом (только не так тупо) речь и идет. Но пока этого всего нет. Крэев у нас тоже нет. Да и слабы они уже на сегодня.