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

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

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

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

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

Курилка wrote:
> Чтот ты такое хитрое загнул, ну не покатит эрланг для числодробилок
> И про один поток (процесс?) — это тоже "трудно", на Эрланге изначально
> декомпозиция будет иначе выглядеть, хотя в принципе тебе нельзя
> запретить создать всего 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-ти .. Линейка ? Кольцо ? Гиперкуб ? Тогда ОС придется иметь отдельный планировщик под каждую архитектуру проца...

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

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());

плохо?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>>А возможно через года 3 будет прорыв в некой области и про многоядерность снова забудут на много лет.
ДА>В какой? (Просто сильно интересно)

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

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

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