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

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

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

Угу, но сам JIT — точно так же перед этим проджитить или скомпилить по-месту (смотря на чем он там будет к тому моменту).

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

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

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

Не вся ОС. Я говорил о первичном распределении выч-ресурсов. Да, без аппаратной поддержки управления пулами процессоров эффективно распаралелливать код не получится. Но все не так тупо было даже на Крее. Эти аппаратные "шедуллеры" неплохо управляются и настраиваются программно. Тут можно привести аналогию с технологией DMA.

VD>Но пока этого всего нет. Крэев у нас тоже нет. Да и слабы они уже на сегодня.

Это те Креи слабы на сегодня, которые на T3E были. Зато Крей уже прямо сейчас лепит серийно кластеры на процессорах Alpha, PowerG4 и даже на обычных пнях. Ноу-хау тут уже скорее в общей архитектуре подобных систем и принципах построения программ для них. Примерно то же самое делает IBM, SUN, HP и с некоторых пор Intel и AMD.

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


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

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



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

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

А распараллеливать алгоритмы не так уж сложно, если язык поддерживает. Например, можно ввести расширения типа fork, join. Вот гипотетический пример расчета определителя матрицы на модифицированном C#:

double[,] matrix = GetMatrix(M, N);
double[] partialSums = new double[N]; // массив для частичных сумм определителя

join {
    for (int i = 0; i < N; i++) 
        fork {
            // запускаем расчеты в параллель
            partialSums[i] = Matrix.CalcPartialDeterminant(matrix, i);
        }
}

// после завершения всех тредов складываем частичные результаты
return Vector.Sum(partialSums);

Курилка wrote:

> depracated и
> Throws:
> NoSuchMethodError — always

> ты игнорируешь?
Потому и был поставлен смайлик и слово "реализовано" взято в кавычки.

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

V>Угу, но сам JIT — точно так же перед этим проджитить или скомпилить по-месту (смотря на чем он там будет к тому моменту).

Это уже не обязательно, хотя и разумно.

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

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

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

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



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

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

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

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

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


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

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


M>Голова не опухнет у абстрактного программиста в вакууме? Так что Влад прав — для 80-ядерников кровь из носу как будут нужны средства автоматического распараллеливания задачи. В уме такие задачки нормальные люди не должны решать.

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

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

V>Тут Андрей подсказал наличие проекта PLinQ (Parallel LinQ), как раз автоматически должен будет обрабатывать массивы данных, не привлекая явно программиста.

Глянул. Улыбнуло. Функциональные вставки в императивный язык. Осталось всех научить свободно писать на ФЯ и уметь ХОРОШО использовать приемы работы на нем. А иначе это будет просто синтаксический сахар. Да, нового в этом Линке ничего нет.

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

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

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

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

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

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

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

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

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

M>Глянул. Улыбнуло. Функциональные вставки в императивный язык. Осталось всех научить свободно писать на ФЯ и уметь ХОРОШО использовать приемы работы на нем. А иначе это будет просто синтаксический сахар. Да, нового в этом Линке ничего нет

Там все прощею. С языком будет идти библиотека позволяющая использовать функции в очень высокоуровневом виде, так что изучать ФП не потребуется. Более того придуман синтаксис очень похожий на SQL, а SQL по сути функциональный язык хорошо известный болшинству прикладников. Так что рассчет верный.

Здравствуйте, 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К процессов является штатной ситуацией, и они не работают с общей памятью. Что исключает потери на блокировках — Эрланг-программы асинхронны и параллельны по своей природе, и великолепно масштабируются. Таким образом, существующие приложения на Эрланге уже готовы к такому масштабированию лучше, чем какие-либо другие.

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

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

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

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

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

VD>Те же что повышение частоты процессора, только не автоматически и не линейно.

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

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

c-smile wrote:
> Т.е. ты хоть обложись камнями но "первый же залетевший GC разрушит
> цивилизацию"
Кстати да, пока что единственный разумно быстрый распределенный GC — это
взвешенный счетчик ссылок

Так что все срочно вспоминаем ручное управление памятью.

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

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

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

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

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

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

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

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

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

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

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

Ну, у меня не такая уж и наивность... я же сказал, если будет работать нормально ОС. Я на одних сообщениях вручную вам эти 1500 потоков смогу организовать. Если, конечно, объектов ядра хватит... Но только в данной задаче, не в какой другой.

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

Может, но только в очень узких задачах: тут совершенно верно.

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

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

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

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

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

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

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

Ага, и далеко не люьой интернет ускорит Intel Pentium III. Только впаривать SSE как нечто, жизненно необходимое, этоне помешало.

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

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

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