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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0xDEADBEEF wrote:

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

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

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

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

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

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.

Взято здесь

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

kan wrote:

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

Здравствуйте, 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 вселяет надежду.

Здравствуйте, 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 и всех делов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

M>Да. Вспомнил что в ДП была новость о поддержке SMP в Erlang.
M>Собственно
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>Ну что я могу сказать по этому поводу ...

Там еще одна фишка есть. Можно запустить несколько виртуальных машин на одном компе, под разными процессорами. Так как Эрлангу все равно, где остальные машины наодятся, на том же компе или в соседнем здании то таким образом опять получаем возможность использовать многопроцессорность даже в однопроцессорном Эрланге Собственно, именно так и предлагалось использовать версии до R11

IT>Но здесь, есть одно НО. WinForms не является дружественной средой для многопоточных приложений, и доступ к элементам формы из другого потока закончится исключением.

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

Enhanced thread support, with signal-slot connections across threads and per-thread event loops.

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

kan>kan wrote:

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

depracated и
Throws:
NoSuchMethodError — always

ты игнорируешь?

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



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

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

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