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

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

автоматический map/reduce?

E>Поэтому параллелизм будет проникать к программистам в виде каких-нибудь фишечек или рюшечек. .NET-овский LINQ здесь является примером. Т.е. рядовые программисты получат выгоду от многоядерности не прикладывая к этому никаких усилий (так же, как сейчас это происходило с тактовой частотой). Только вот развиваться эти средства будут, скорее, всего не для C++

Сейчас подумалось, что добавление в языки программирования средств распараллеливания (вроде LINQ) может очень серьезно разделить мейнстримовые и немейнстримовые языки. Так, Sun и MS могут (да и вынуждены) вкладывать серьезные средства в реализацию таких средств для JVM и .NET. А вот какой-нибудь Eiffel Software или AdaCore -- еще вопрос.

С С++ так же не однозначно. С одной стороны, у C++ нет богатых хозяев (как себя MS в отношении VC++ поведет еще вопрос). Зато большое количество разработчиков. Так что появление версии STL с какими-нибудь parallel_for_each, parallel_accumulate, parallel_transform и пр. вполне возможно.

Но вот у тех же Eiffel или Ada пользователей значительно меньше, посему и меньше перспективы на развитие инструментов для распараллеливания программ на этих языках (созданных силами community).

Вот и получится, что в скором времени выбор быстрого языка для разработки можно будет делать между Java, C# и C++, а всякие Eiffel/Ada/Modula/Objective-C/OCaml и пр. не брать в расчет. Хотя открытым останется вопрос о других .NET-овских и JVM-овских языках -- F# и Scala.

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

E>Сейчас подумалось, что добавление в языки программирования средств распараллеливания (вроде LINQ)

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

E> Так, Sun и MS могут (да и вынуждены) вкладывать серьезные средства в реализацию таких средств для JVM и .NET.

А можно ссылочку на аналог LINQ для джава? Можно на JSR, который не умер.

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

E>>Сейчас подумалось, что добавление в языки программирования средств распараллеливания (вроде LINQ)

AVK> LINQ это не средство распараллеливания. Просто параллелить функциональные выражения проще, чем императивный код, потому что последний содержит меньше информации, отражающей семантику того, что хочет программист.

По-моему это ты рассказывал про какую-то презентацию, на которой демонстрировался код, использующий LINQ: сначала показали его скорость в обычной реализации, затем подставили ему другую реализацию LINQ и на двухядерной машине тот же самый код (без переписывания) заработал раза в два быстрее. Поскольку я не .NET программист, то мне проще считать, что есть LINQ, за которым могут скрываться разные PLINQ, LINQ to SQL и пр.

E>> Так, Sun и MS могут (да и вынуждены) вкладывать серьезные средства в реализацию таких средств для JVM и .NET.

AVK>А можно ссылочку на аналог LINQ для джава? Можно на JSR, который не умер.

А что, для Java пока ничего не планируется? Тем хуже для Java. Видимо, дела у санок действительно идут неважно. В прежние времена саночники могли себе позволить вкладывать десятки мегабаксов в разработку JVM и JDK.

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

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

Не я, но я там был.

E> Поскольку я не .NET программист, то мне проще считать, что есть LINQ, за которым могут скрываться разные PLINQ, LINQ to SQL и пр.

То, что LINQ можно использовать для автоматического распараллеливания еще не означает, что LINQ является средством распараллеливания. Чувствуешь разницу?

AVK>>А можно ссылочку на аналог LINQ для джава? Можно на JSR, который не умер.

E>А что, для Java пока ничего не планируется?

Я не знаю, потому и спрашиваю.

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

AVK>То, что LINQ можно использовать для автоматического распараллеливания еще не означает, что LINQ является средством распараллеливания. Чувствуешь разницу?

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

В C++, в принципе, возможно создание ParallelSTL, но без лямб в языке толку от него будет не много. Так что придется ждать C++0x.

E>>А что, для Java пока ничего не планируется?

AVK>Я не знаю, потому и спрашиваю.

Я то же не знаю. В Google нарыл всего несколько ссылок:
LINQ for Java: Quaere -- какая-то библиотека, про которую говорят, что она привносит LINQ в мир Java.
Carl Rosenberger's web log : LINQ for Java -- один из разработчиков db4o приглашает заинтересованных людей принять участие в разработке прототипа LINQ for Java с последующей выработкой JSR.

Есть еще какая то странная информация: Sun announces LINQ for Java [Kudzu World] -- якобы в сентябре 2006 Sun анонсировала что-то типа LINQ для Java. Но самого прессрелиза на сайте Sun я не нашел. Так что данное сообщение не вызывает доверия.

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

E>Вот и получится, что в скором времени выбор быстрого языка для разработки можно будет делать между Java, C# и C++, а всякие Eiffel/Ada/Modula/Objective-C/OCaml и пр. не брать в расчет. Хотя открытым останется вопрос о других .NET-овских и JVM-овских языках -- F# и Scala.

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

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

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

E>>Вот и получится, что в скором времени выбор быстрого языка для разработки можно будет делать между Java, C# и C++, а всякие Eiffel/Ada/Modula/Objective-C/OCaml и пр. не брать в расчет. Хотя открытым останется вопрос о других .NET-овских и JVM-овских языках -- F# и Scala.

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

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

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

К>Всё бы хорошо, но только вот куда нужен этот мощный параллелизм?
К>Люди хоть бы обычные компы освоили

Лично мне мощные компьютеры и мощный параллелизм нужны для фоновой компиляции и анализа кода. И имеющихся мощностей очень не хватает.

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

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

К>>Всё бы хорошо, но только вот куда нужен этот мощный параллелизм?
К>>Люди хоть бы обычные компы освоили

N>Лично мне мощные компьютеры и мощный параллелизм нужны для фоновой компиляции и анализа кода. И имеющихся мощностей очень не хватает.

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

AndrewVK,

E>> Так, Sun и MS могут (да и вынуждены) вкладывать серьезные средства в реализацию таких средств для JVM и .NET.

AVK>А можно ссылочку на аналог LINQ для джава? Можно на JSR, который не умер.

JLINQ, небольшой пример, как это выглядит: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0708ahadian/
(это правда, как мне думается, не аналог Linq, а аналог Linq2Sql)

Для Скалы тоже разрабатывается библиотека dbc2, уже можно писать вещи типа:

val createTable1 = create table 'table1 columns(
                'col1 integer constraint('cons1) not nullVal,
                'col2 character(20) default(1),
                constraint('cons2) check('col1 > 3),
                primary key('col2))

val selectValues1 = select('CITYNAME of character varying(20)) from('CITY) where 'NBINHABITANTS <= 100000

Пока немного некрасиво (лично мне не нравятся пред-апострофы), но люди работают. Используются expression trees, которые существуют уже сейчас, но команда Скалы не хочет их открывать пока. В частности Мартин говорит, что:

> I'd love to see Expression Trees officially making it into Scala.
There's actually a move to do this, but the current approach was
completely experimental and turned out to be a dead end. That's why it
never got documented. But the new annotations can already refer to
AST's, and we plan to generalize this.

Курилка,

К>Ммм, я всегда думал, что анализом человек занимается в первую очередь
К>А компиляция в фоне наверное затык при отсутствии REPL, но, наверное, я как обычно ршибаюсь.
К>Ну и реально программист как правило работает с относительно небольшим участком кода, иначе это не код, а спагетти.

Ты всегда уверен, что текущей функции из трёх строк второй аргумент не может быть нулём?

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

LCR>Курилка,

К>>Ммм, я всегда думал, что анализом человек занимается в первую очередь
К>>А компиляция в фоне наверное затык при отсутствии REPL, но, наверное, я как обычно ршибаюсь.
К>>Ну и реально программист как правило работает с относительно небольшим участком кода, иначе это не код, а спагетти.

LCR>Ты всегда уверен, что текущей функции из трёх строк второй аргумент не может быть нулём?

Это по сути часть контракта функции
Если контракты не соблюдаются...
А как их соблюдать (или принуждать соблюдать), я думаю ты и сам можешь рассказать.
Плюс — причём тут многопроцессорность?

Курилка,

К>>>Ммм, я всегда думал, что анализом человек занимается в первую очередь
К>>>А компиляция в фоне наверное затык при отсутствии REPL, но, наверное, я как обычно ршибаюсь.
К>>>Ну и реально программист как правило работает с относительно небольшим участком кода, иначе это не код, а спагетти.

LCR>>Ты всегда уверен, что текущей функции из трёх строк второй аргумент не может быть нулём?

К>Это по сути часть контракта функции
К>Если контракты не соблюдаются...
К>А как их соблюдать (или принуждать соблюдать), я думаю ты и сам можешь рассказать.
К>Плюс — причём тут многопроцессорность?

Я хочу сказать, что онализ кода машиной и доказательство неравенства второго аргумента нулю тут очень даже притом. Пусть пыжится, доказывает. А процессор этому думателю как раз даст в помощь ещё 4095 таких же думателей. Вместе глядишь и докажут. И тогда не надо будет специально городить if (a2 == null) throw InvalidUserException() ...

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

LCR>JLINQ, небольшой пример, как это выглядит: http://www.ibm.com/developerworks/db2/library/techarticle/dm-0708ahadian/
LCR>(это правда, как мне думается, не аналог Linq, а аналог Linq2Sql)

Эта фиговина с линком ничего общего, кроме названия, не имеет. Это просто генератор акцессоров, каких вагон и маленька тележка.

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

LCR>Я хочу сказать, что онализ кода машиной и доказательство неравенства второго аргумента нулю тут очень даже притом. Пусть пыжится, доказывает. А процессор этому думателю как раз даст в помощь ещё 4095 таких же думателей. Вместе глядишь и докажут. И тогда не надо будет специально городить if (a2 == null) throw InvalidUserException() ...

Так-то оно так, только вот всё ещё автоматического "писателя" программ не изобрели и в любом случае человек крайним остаётся. А то получится как в явовских программах, которым памяти не хватает, потому что разработчики посчитали, что суперумный сановский GC за них сделает сам всё. И

Курилка,

LCR>>Я хочу сказать, что онализ кода машиной и доказательство неравенства второго аргумента нулю тут очень даже притом. Пусть пыжится, доказывает. А процессор этому думателю как раз даст в помощь ещё 4095 таких же думателей. Вместе глядишь и докажут. И тогда не надо будет специально городить if (a2 == null) throw InvalidUserException() ...

К>Так-то оно так, только вот всё ещё автоматического "писателя" программ не изобрели и в любом случае человек крайним остаётся. А то получится как в явовских программах, которым памяти не хватает, потому что разработчики посчитали, что суперумный сановский GC за них сделает сам всё. И

(...и тут рука писателя дрогнула) Ты тоже правильно пишешь, просто взгляд с другой стороны. Ладно, миру бир

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

К>А про зависимости согласен, только вот _|_ — это немного другое, хотя местами эти вещи (зависимости и _|_) связаны.
Легче от этого не становится.
Доказательства всеравно рассыпаются...

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

E>> Поскольку я не .NET программист, то мне проще считать, что есть LINQ, за которым могут скрываться разные PLINQ, LINQ to SQL и пр.

AVK>То, что LINQ можно использовать для автоматического распараллеливания еще не означает, что LINQ является средством распараллеливания.

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

AVK>Чувствуешь разницу?

Разница в отделении фасада от бэкенда, но суть рассуждений у Евгения была верная.


E>>А что, для Java пока ничего не планируется?

AVK>Я не знаю, потому и спрашиваю.

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

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

E>> Так, Sun и MS могут (да и вынуждены) вкладывать серьезные средства в реализацию таких средств для JVM и .NET.
AVK>А можно ссылочку на аналог LINQ для джава? Можно на JSR, который не умер.
Нету. LINQ повторять пока никто не собирается. Точнее, в Скале хотят генерализовать ту систему, которую использовали для добавления поддержки XML в язык так, чтобы был возможен и LINQ.

В контексте Java сейчас обсуждается улучшение fork/join модели работы с данными: http://www.infoq.com/news/2008/03/fork_join

double bestGpa = students.withFilter({Student s => (s.graduationYear == THIS_YEAR) })
                         .withMapping({ Student s => s.gpa })
                         .max();

это пример оттуда.