<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
<channel>
	<title>Хабрахабр / Комментарии к посту «Parallel Extensions для .net 3.5» в блоге «.NET»</title>
	<link>http://habrahabr.ru/rss/post/45732/</link>
	<description><![CDATA[Новые комментарии к посту «Parallel Extensions для .net 3.5» в блоге «.NET»]]></description>
	<language>ru</language>
	<managingEditor>editor@habrahabr.ru</managingEditor>
	<generator>habrahabr.ru</generator>
	<pubDate>Sat, 11 Feb 2012 12:18:08 GMT</pubDate>
	<lastBuildDate></lastBuildDate>
	<image>
		<link>http://habrahabr.ru/</link>
		<url>http://habrahabr.ru/i/logo.gif</url>
		<title>Хабрахабр</title>
	</image>
	

	
	
	
	
	
		
	
		<item>
			<title>18.01.2009 12:51:21 OLweb</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1290441</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1290441</link>
			<description><![CDATA[Действительно крутая и удобная штука. Возьму на заметку, спасибо ;)]]></description>
			<pubDate>Sun, 18 Jan 2009 12:51:21 GMT</pubDate>
			<author>OLweb</author>
		</item>
	

	
		<item>
			<title>04.12.2008 16:38:34 markshevchenko</title>
			<guid isPermaLink="true">#comment_1174097</guid>
			<link>#comment_1174097</link>
			<description><![CDATA[Присоединился. :)<br/>
<br/>
Думаю, в ближайшие 10 лет нас ждут серьёзные прорывы, потому что параллельное программирование стало востребованным — многоядерные процессоры практически на каждом рабочем столе.<br/>
<br/>
Лет 5 назад серьёзно этим занимались только разработчики серверного софта и научные сообщества. А теперь придётся заниматься всем. :) Так что я стараюсь не отставать, и мало помалу изучаю наработки.]]></description>
			<pubDate>Thu, 04 Dec 2008 16:38:34 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>04.12.2008 16:04:15 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1174017</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1174017</link>
			<description><![CDATA[Я и не спорю, в этой области сейчас большой прогресс. Но всё равно останутся задачи, которые не решить простым распараллеливанием циклов :)<br/>
<br/>
Присоединяйтесь: <a href="http://habrahabr.ru/blogs/development/46129/" title="Опрос">Знакомы ли вы с параллельным программированием?</a> :)]]></description>
			<pubDate>Thu, 04 Dec 2008 16:04:15 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>04.12.2008 10:34:30 markshevchenko</title>
			<guid isPermaLink="true">#comment_1172822</guid>
			<link>#comment_1172822</link>
			<description><![CDATA[Гарантирую: будет страшно! Помните время, когда Java завоёвывала себе место под солнцем? Виртуальная машина, сборка мусора — и лозунг: «всё-таки мы не намного медленнее Си++, всего на каких-то 30%».<br/>
<br/>
Прошло 10 лет, ребята поработали над оптимизацией, над сборщиком, над JIT, и вот уже тесты показывают странную вещь: код на Java быстрее кода на Си++. Одна проблема осталась: старт приложений всё-таки небыстрый. Сейчас решают.<br/>
<br/>
Сделано настолько хорошо, что .NET всё ещё отстаёт по сборщику мусора.<br/>
<br/>
Подозреваю, с ФЯ будет то же самое. Через год F# будет в продакшене, можно будет сравнивать. Но и сейчас есть первые ласточки, очень странные. Есть такой архиватор freearc того же класса, что и 7zip. Где-то полгода назад он стал первым по скорости среди архиваторов этого типа. 7zip написан на C++ и C, а freearc на Haskell и C. Вот такая удивительная штука. :)]]></description>
			<pubDate>Thu, 04 Dec 2008 10:34:30 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>04.12.2008 05:01:25 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1172185</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1172185</link>
			<description><![CDATA[Поживём — увидим :) Может быть даже жоведу себя до проведения тестов производительности, когда будет что сравнивать. Для меня это важнее, чем небольшое удобство при разработке :)]]></description>
			<pubDate>Thu, 04 Dec 2008 05:01:25 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>04.12.2008 01:15:36 markshevchenko</title>
			<guid isPermaLink="true">#comment_1172102</guid>
			<link>#comment_1172102</link>
			<description><![CDATA[Трудно спорить. Но мой опыт (небольшой, кстати) разработки таких вот штук на Си++ привёл меня к неутешительным выводам.<br/>
<br/>
Да, библиотеку нечёткой логики для Си++ разработать можно.<br/>
<br/>
Нет, человеческим этот код назвать никак нельзя. :)<br/>
<br/>
То же самое относится не только к Си++, но и к Java, и в очень большой мере к C#. В последнем, хоть и есть функциональные расширения (лямбды с замыканиями, LINQ и даже каррирование в какой-то мере), многого всё-таки нет. Но всё это есть в F#, и через год мы сможем писать параллельный код, практически, одной левой. :)]]></description>
			<pubDate>Thu, 04 Dec 2008 01:15:36 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>03.12.2008 23:27:23 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1172031</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1172031</link>
			<description><![CDATA[Если человек научится, он сможет написать это и не на функциональном языке, это я и хотел сказать :) Благо средства есть.]]></description>
			<pubDate>Wed, 03 Dec 2008 23:27:23 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>03.12.2008 22:42:23 markshevchenko</title>
			<guid isPermaLink="true">#comment_1171982</guid>
			<link>#comment_1171982</link>
			<description><![CDATA[Ну, как бы, теоретически, изучение ФП как раз и предполагает осваивание таких вот подходов к решению. Я бы, например, рекомендовал разработчикам без опыта, решать любую такую вычислительную задачу с помощью Excel, тогда опыт быстро наработается. :)]]></description>
			<pubDate>Wed, 03 Dec 2008 22:42:23 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>03.12.2008 22:00:52 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1171936</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1171936</link>
			<description><![CDATA[Но ведь можно было написать и на функциональном языке этот пример с использованием цикла? А значит об использовании в данном месте map/reduce ему нужно отдельно думать, по крайней мере он должен был это где изучить/услышать/прочитать :) Особенно если его первым языком был какой-то из «последовательных». Так что в этом смысле нет разницы в том, «думает» ли программист при проектировании расчёта на языке map/reduce(а ведь не всё можно к нему свести), или думает по привычной ему схеме, пишет циклы и потом(либо по ходу действия) расставлять в коде комментарии OpenMP.<br/>
<br/>
P.S. Посмотрю завтра, будет ли Intel Compiler предлагать распараллеливание цикла в вашем примере :)]]></description>
			<pubDate>Wed, 03 Dec 2008 22:00:52 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>03.12.2008 11:22:41 3fonov</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1170299</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1170299</link>
			<description><![CDATA[Это известный им баг. <br/>
<br/>
Т.е. если просто запусть процесс веб-сервиса, отрезанный от мира, то он начинает в холостую гонять комп сразу после загрузки библиотеки. Хотя никаких операций с ней не производилось. На девелопмент-сервере такого эффекта нет.]]></description>
			<pubDate>Wed, 03 Dec 2008 11:22:41 GMT</pubDate>
			<author>3fonov</author>
		</item>
	

	
		<item>
			<title>03.12.2008 10:30:43 markshevchenko</title>
			<guid isPermaLink="true">#comment_1170049</guid>
			<link>#comment_1170049</link>
			<description><![CDATA[Тут всё-таки есть одна тонкость. Сам пример показывает, что для ФЯ map и reduce не являются чем-то искусственным. Наоборот, они из ФП как раз и пришли. И параллелятся они прекрасно сами по себе, ну вот разве с reduce бывают сложности.<br/>
<br/>
А вот как будет распараллелен приведённый код на Си++, я не знаю. Думаю, будут серьёзные сложности, если речь идёт об автоматическом распараллеливании. Вручную, конечно, без проблем.<br/>
<br/>
Про доступность есть две точки зрения. С одной стороны, всё это уже можно крутить в личных проектах на свой страх и риск. Там много интересных наработок, например, DLR (поддержка динамических языков) и F# (язык на базе OCaml, где параллельность уже по умолчанию должна работать). Но на работе на боевой сервер не дадут PE поставить, пока не выйдет официальный .NET 4. :)<br/>
<br/>
Поэтому с одной стороны всё уже есть, а с другой — ждём. :)]]></description>
			<pubDate>Wed, 03 Dec 2008 10:30:43 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>03.12.2008 08:14:12 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1169583</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1169583</link>
			<description><![CDATA[Мне вчера попался интересный доклад на эту тему: <a href="http://channel9.msdn.com/pdc2008/TL25/.">channel9.msdn.com/pdc2008/TL25/.</a> Аудитория там правда C++ программисты и для них Microsoft поддерживает OpenMP и MPI в оригинальном виде, однако в докладе много есть и про их специфичные инструменты, которые делаются сейчас для всех .NET языков. Если вас интересует, то в Википедии вполне достойно представлены эти технологии.<br/>
<blockquote>PE в некоторых случаях (например у нас на дуал-ксеоне) при отсутствии работы начинает ее активно искать. При этом так активно, что занимает 80% от всех 8 ядер.</blockquote>Лишнее подтверждение тому, что от всех проблем эти абстракции не спасут. конечно же, они скорее всего исправят шедулер потоков, если дело в нём, но программист по хорошему тоже должен думать о том, чтобы все потоки выполнялись примерно одинаковое время. В конечном счёте это выгоднее :)]]></description>
			<pubDate>Wed, 03 Dec 2008 08:14:12 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>03.12.2008 07:52:03 3fonov</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1169533</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1169533</link>
			<description><![CDATA[Программисты занимаются внедрением. А на Си я к сожалению практически не писал и слова MapReduce и OpenMP мне мало о чем говорят. Но я с удовольствием читаю и делаю заметки по разбору на будущее.<br/>
Кстати, в PE есть недоработки. На то и CTP. PE в некоторых случаях (например у нас на дуал-ксеоне) при отсутствии работы начинает ее активно искать. При этом так активно, что занимает 80% от всех 8 ядер.]]></description>
			<pubDate>Wed, 03 Dec 2008 07:52:03 GMT</pubDate>
			<author>3fonov</author>
		</item>
	

	
		<item>
			<title>02.12.2008 19:29:56 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1168543</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1168543</link>
			<description><![CDATA[Вот только непонятные «эти» программисты. Мы тут с вами довольно на интересную тему беседуем, а они уже забыли про новость :)]]></description>
			<pubDate>Tue, 02 Dec 2008 19:29:56 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>02.12.2008 19:28:27 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1168536</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1168536</link>
			<description><![CDATA[Я в конечном счёте считаю, что наличие для распараллеливания отдельной строчки #pragma omp parallel или .AsParallel() в LINQ не такая уж и сложность для пишущего программу :) Тем более, что компиляторы, поддерживающие OpenMP, обычно имеют опции для выявления конструкций, поддающихся распараллеливанию. Так что это тоже не теория, а вполне себе практика :)<br/>
<br/>
Очень рад за .NET-чиков, что теперь и им это доступно. Надеюсь, что .AsParallel будет реализован во всех необходимых местах и костылей придётся писать меньше.]]></description>
			<pubDate>Tue, 02 Dec 2008 19:28:27 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>02.12.2008 09:59:28 markshevchenko</title>
			<guid isPermaLink="true">#comment_1166726</guid>
			<link>#comment_1166726</link>
			<description><![CDATA[Здесь дело не в синтаксическом сахаре. [1..3..11] это действительно ерунда. Основное достоинство ФП — в данном случае и map и reduce уже выполняются параллельно. То есть, это не теоретическая возможность, существующие системы уже так работают.<br/>
<br/>
И основное отличие в том, что (если, например, мы хотим составить таблицу синусов до миллионного знака после запятой), код на Си++ нужно будет распараллеливать вручную. А код на OCaml нет. Вот он такой, какой есть, и останется.<br/>
<br/>
Здесь речь не о краткости кода (в Си++ вычисление факториала можно было бы вынести в отдельную функцию, но тут уж тяга к правде сыграла — так не пишут). Только о возможности автоматического распараллеливания.]]></description>
			<pubDate>Tue, 02 Dec 2008 09:59:28 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>01.12.2008 20:12:27 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1165765</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1165765</link>
			<description><![CDATA[:) Одно дело разная запись, другое — не согласуемые концепции языков. Как я уже сказал, второго я особо не вижу в параллелизации C++. Что касается [1..3..11], то это уже синтаксический сахар, который, в общем-то можно использовать и в императивных языках, если написать нужный препроцессор. А если использовать тот же OpenMP, то эту функцию можно записать и на C++ с возможностью распараллеливания.<br/>
<br/>
Холивар я вижу лишь в том, что вы, как и многие приводящие этот и похожие примеры, сознательно сократили вычисления синуса в функциональном стиле, не учтя оптимизацию вычисления факториала в примере на C++ и сократив количество кода чисто языковыми конструкциями, которые можно ввести в любом языке. При идентичной сути эти фрагменты будут не так сильно отличаться, а распараллеливать можно и C++ код, для этого не нужно функциональное программирование :)]]></description>
			<pubDate>Mon, 01 Dec 2008 20:12:27 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>01.12.2008 18:27:37 markshevchenko</title>
			<guid isPermaLink="true">#comment_1165590</guid>
			<link>#comment_1165590</link>
			<description><![CDATA[&gt; Для этого в C(++) ничто не мешает особо :)<br/>
<br/>
О, это тема для отдельного холивора. :) Тут можно было бы привести пример с тем самым map-reduce. Само название пошло от двух функций: map (отображение) и reduce (свёртка), которые очень часто применяются в ФП.<br/>
<br/>
Если взять, например, вычисление синуса: sin(x) = x — x^3/3! + x^5/5! ..., то в императивном стиле функция будет выглядеть так:<br/>
<br/>
<pre>
double sin(double x)
{
  int iteration = 3;
  int sign = -1;
  double factorial = 6;

  double result = x;
  double pow = x * x * x;

  do
  {
    double next = (sign * pow)/factorial;
    result += next;
    sign = -sign;
    pow *= x * x;
    iteration += 2;
    factorial * iteration * (iteration - 1);
  }
  while(iteration &lt;= 11);

  return result;
}
</pre><br/>
<br/>
И её довольно трудно параллелить, по крайней мере автоматически. (Неизбежный комментарий: на 11-й итерации мы достигаем наибольшей для double точности в 13 или 14 цифр после запятой). В функциональном стиле она будет уже другой.<br/>
<br/>
<pre>
let sin_mmbr x i = (x^i * (-1)^((i - 1)/2))/factorial(i)
let after_map x = map (sin_mmbr x) [1..3..11]
let sin x = fold_left (+) 0 (after_map x)
</pre><br/>
<br/>
Оба кода писал на ходу, поэтому возможны ошибки и там, и там. Во втором случае главное отличие в том, что здесь не задан порядок вычислений. Есть некий список чисел от 1 до 11 с шагом 2. К каждому числу нужно применить преобразование sin_mmbr. Это map. На этом этапе возможно естественное распараллеливание. Вторая часть — reduce, свести результаты воедино. И эта операция тоже распаралеливается (может, по крайней мере). В данном случае свёртку выполняет функция fold_left.]]></description>
			<pubDate>Mon, 01 Dec 2008 18:27:37 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>01.12.2008 16:33:33 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1165383</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1165383</link>
			<description><![CDATA[LINQ полезная вещь, судя по тому что про неё попадается на глаза. Но если говорить об автоматическом распараллеливании, то Intel уже выпустила Cluster OpenMP, работающую на распределённых системах.<br/>
<br/>
<blockquote>Не знаю. Там ведь фишка не только в архитектурном решении, там фишка в LINQ. Нормально параллелятся функциональные языки, и LINQ как раз такой подъязык. Подозреваю, что код на Си++ окажется просто сложнее, поскольку там вся функциональность в шаблонах.</blockquote>Если параллелить по задачам, то думаю и нынешних средств хватит, всё-таки все примеры выше и в статье так или иначе относятся к распараллеливанию циклической обработки данных. Для этого в C(++) ничто не мешает особо :)<br/>
<br/>
К сожалению мой интерес в области параллельного программирования не очень далеко распространяется, так что рассуждать о практической полезности создавать настолько автоматизированные средства мне сложно. Главное чтобы программисты не забывали о появляющихся при использовании этих средств последствиях, которые они не смогут скорее всего контролировать в таком случае.]]></description>
			<pubDate>Mon, 01 Dec 2008 16:33:33 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>01.12.2008 10:40:16 markshevchenko</title>
			<guid isPermaLink="true">#comment_1164405</guid>
			<link>#comment_1164405</link>
			<description><![CDATA[Они действительно простые, эти примеры. Но оказались очень поучительными для меня в своё время. Взять такой простой паттерн, как singleton. Предположим, есть многопоточная программа, разные потоки в которой должны пользоваться одним и тем же объектом. Возникает вопрос — как его создавать? В однопоточной программе он создаётся по запросу:<br/>
<br/>
<pre>
Singleton *getSingleton()
{
  static *singleton = NULL;
  if(singleton == NULL)
    singleton = new Singleton();
  return singleton;
}
</pre><br/>
<br/>
В многопоточной программе этот код может работать со сбоями. Например, первый поток проверяет singleton, он равен NULL, и поток создаёт объект. Но за это время второй поток успевает создать объект раньше и присвоить значение переменной signleton.<br/>
<br/>
Может так оказаться, что в программе оказываются два одиночки. Очевидно, нужно как то регламентировать создание объекта. В Windows API это делается, например, через критические секции (critical sections). Собственно, это упрощённый вариант блокировки, когда несклько потоков пытаются обратиться к одному и тому же объекту.<br/>
<br/>
Возникает вопрос: когда должна начинаться и когда заканчиваться блокировка? Оказывается, правильный вариант таков:<br/>
<br/>
<pre>
Singleton *getSingleton()
{
  static *singleton = NULL;
  if(singleton == NULL)
  {
    Lock();
    if(singleton == NULL)
      singleton = new Singleton();
    Unlock();
  }
  return singleton;
}
</pre><br/>
<br/>
Проверки должно быть две, тогда программа гарантированно работает и не теряет производительности на лишних блокировках. И вот о таких вещах приходиться помнить при параллельном программировании. Понятно, поэтому, что спецов в этой теме мало (и себя я к ним не отношу). И понятно, что автоматизация здесь очень востребована.<br/>
<br/>
&gt; Нет, его я хотел сравнить с MPI. Имхо они одного порядка решения, а MapReduce<br/>
&gt; действительно упрощённый вариант.<br/>
<br/>
Не знаю. Там ведь фишка не только в архитектурном решении, там фишка в LINQ. Нормально параллелятся функциональные языки, и LINQ как раз такой подъязык. Подозреваю, что код на Си++ окажется просто сложнее, поскольку там вся функциональность в шаблонах.<br/>
<br/>
Ну вот, например:<br/>
<br/>
<pre>
DryadDataContext ddc = new DryadDataContext(dir);
DryadTable&lt;LineRecord&gt; table = ddc.GetTable&lt;LineRecord&gt;(filename);
IQueryable&lt;string&gt; lines = table.Select(lr =&gt; lr.line);
IQueryable&lt;string&gt; match = search(lines, searchString);

...

public static IQueryable&lt;string&gt;
search(IQueryable&lt;string&gt; collection,
string searchString)
{
return collection.Where(s =&gt; s.IndexOf(searchString) &gt;= 0);
}
</pre><br/>
<br/>
Всё, что идёт до вызова table.Select(lr =&gt; lr.line) — ввод данных, который на текстовых файлах не параллелится (хотя есть варианты). А вот вызов search уже может выполняться на разных машинах. Главное же то, что не надо писать новую программу для всего этого, нужно добавить три строчки, а всё остальное уже именно так и пишется в C#.<br/>
<br/>
&gt; Просто жаль, что после того, как Microsoft не уделяла внимание HPC и более мирным<br/>
&gt; параллельным технологиям, она начала выпускать продукты, как две капли воды воды<br/>
&gt; похожие на давно известные решения :)<br/>
<br/>
Почему не уделяла? Им с задачей распараллеливания приходится работать ничуть не меньше, чем гуглу. Из 10-та самых посещаемых сайтов в мире, три или четыре принадлежат Microsoft. Просто сейчас есть почва для промышленных решений — есть сообщество программистов, которые пишут на C#, есть проекты, есть LINQ. Просто всё это не так быстро делается, но делается.]]></description>
			<pubDate>Mon, 01 Dec 2008 10:40:16 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>30.11.2008 23:44:49 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1163629</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1163629</link>
			<description><![CDATA[Мне сложно примерять на себя роль промышленного программиста на .NET, но я понял вас. Да, для .NET, и в частности для веб приложений это является сейчас трудностью. Для большинства программистов под .NET эта технология действительно будет очень полезна. Жаль, что она появилась позже аналога для Fortran/C/C++. Кстати говоря, о MPI для C# я слышал ещё год назад, сейчас это считают <a href="http://blogs.msdn.com/philpenn/archive/2008/10/08/mpi-net-1-0-is-now-released.aspx">готовым продуктом</a>.<br/>
<blockquote>Достоинства PE в том, что они позволяют в существующий проект внедрить параллельный код без особых проблем. Берётся, фактически, любое LINQ выражение в программе, и, при наличии нескольких ядер или процов, начинает обрабатываться параллельно. Без изучения тонкостей вопроса, без изучения нового языка программирования. </blockquote>Что ещё раз доказывает, что можно сравнивать PE и OpenMP :) В удобстве OpenMP для своих прямых и не только задач я убедился.<br/>
<blockquote>Насколько я понимаю, Ваш вопрос таков: чем он лучше или круче MapReduce?</blockquote>Нет, его я хотел сравнить с MPI. Имхо они одного порядка решения, а MapReduce действительно упрощённый вариант.<br/>
<br/>
Просто жаль, что после того, как Microsoft не уделяла внимание HPC и более мирным параллельным технологиям, она начала выпускать продукты, как две капли воды воды похожие на давно известные решения :)<br/>
<blockquote>И из этого вовсе не следует, что сейчас разработчик не пишет многопоточные программы, просто сейчас это требуется делать вручную и держать в голове очень много лишней информации. Если хотите, могу привести пару интересных примеров.</blockquote>Интересные примеры бесполезными никогда не будут. Не так часто удаётся прорваться и пообщаться с знающими людьми. Не сочтите снова за занудство, но только совсем простые примеры мне будут понятны, ибо мне приходится работать и на <a href="http://parallel.ru/cluster/">СКИФе</a>, так что я немного в теме :)]]></description>
			<pubDate>Sun, 30 Nov 2008 23:44:49 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>30.11.2008 12:31:41 markshevchenko</title>
			<guid isPermaLink="true">#comment_1162503</guid>
			<link>#comment_1162503</link>
			<description><![CDATA[Фреймворк и так работает нормально на многопроцессорных системах, и работал с первой версии. Просто тогда всё приходилось делать вручную через Sytesm.Threading.Thread.<br/>
<br/>
Собственно, единственное, что реально можно сделать для автоматического распараллеливания — пересаживать народ на функциональные языки. Ну вот, с одной стороны MS готовит F#, с другой — сделала LINQ, который сам по себе является функциональным подъязыком.<br/>
<br/>
Ну и непонятно, почему Вы пишете, что программисту надо знать, на каких машинах будет выполняться программа. Использовать надо везде. Если машина будет многоядерной, ядра подхватятся. Если одноядерной, накладные расходы будут небольшими. В существующий код больших изменений вносить не придётся — это самый большой плюс.]]></description>
			<pubDate>Sun, 30 Nov 2008 12:31:41 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>30.11.2008 12:19:15 markshevchenko</title>
			<guid isPermaLink="true">#comment_1162485</guid>
			<link>#comment_1162485</link>
			<description><![CDATA[Вот простая рабочая ситуация: есть вебовский проект на сишарпе, ему около трёх лет. Как там использовать OpenMP? Я не представляю. Мы используем внешние компоненты, писанные на C++, которые интегрируются с трудом — есть такая проблема. До сих пор, если нет исходников, единственный доступный способ интеграции C++ кода — это <code>extern &quot;C&quot;</code>. Ну вот, с OpenMP, теоретически, можно попробовать компилировать его managed C++ компилятором и смотреть, как оно будет работать. Без гарантий.<br/>
<br/>
Писать на PHP, Ruby? Они объективно медленнее. Писать на Java? Можно. Вопрос — есть ли решения, аналогичные PE для Java? Нет.<br/>
<br/>
Каким образом сейчас достигается распараллеливание? Вручную. Есть такие объекты, про которые разработчик должен помнить — они расшарены и доступны с любой машины фермы. А про другие надо помнить, что они локальны. Это, как обычно, немного лишняя информация при разработке, но от неё никуда не деться.<br/>
<br/>
Достоинства PE в том, что они позволяют в существующий проект внедрить параллельный код без особых проблем. Берётся, фактически, любое LINQ выражение в программе, и, при наличии нескольких ядер или процов, начинает обрабатываться параллельно. Без изучения тонкостей вопроса, без изучения нового языка программирования. И без геморроя с начальством, которое, как обычно, очень подозрительно. И с точки зрения разработчика это всё очень удобно. И из этого вовсе не следует, что сейчас разработчик не пишет многопоточные программы, просто сейчас это требуется делать вручную и держать в голове очень много лишней информации. Если хотите, могу привести пару интересных примеров.<br/>
<br/>
Теперь про Dryad. Насколько я понимаю, Ваш вопрос таков: чем он лучше или круче MapReduce? Пока на Ваш вопрос ответ есть только теоретический. Собственно, то, что он также встраивается через LINQ в любой язык, которые поддерживается дотнетом, достоинством не является. По той простой причине, что я не сильно верю в возможности «автоматически» распараллеливать программу. Чтобы программа эффективно работала на сотне машин, её надо затачивать и надо разбираться. Пара-другая строчек Dryad LINQ её не спасёт.<br/>
<br/>
Преимущество в том, что модель Dryad предлагает больше альтернатив к организации распределённых вычислений и MapReduce становится частным случаем. Это значит, что есть больше возможностей распараллеливать существующий код, а не писать его заново под парадигму MP. Хорошо это или плохо? Будет востребовано или нет? Сейчас ответить трудно. Но большая гибкость в Dryad заложена.]]></description>
			<pubDate>Sun, 30 Nov 2008 12:19:15 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>29.11.2008 23:45:35 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1161940</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1161940</link>
			<description><![CDATA[Наверное я невнимательно читал доступную по Dryad информацию. Если у вас найдётся минутка, может быть вы сможете аргументированно указать на явные прорывы? Буду только рад.<br/>
<br/>
P.S. OpenMP я противопоставляю новости в топике, о его особенностях я знаю. Хотя почему же, не так давно стало возможным применять его для автоматического распараллеливания и на системах с распределённой памятью.]]></description>
			<pubDate>Sat, 29 Nov 2008 23:45:35 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>29.11.2008 23:40:39 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1161931</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1161931</link>
			<description><![CDATA[Хм, а мы с <strong>Kroz</strong> поняли друг друга :)]]></description>
			<pubDate>Sat, 29 Nov 2008 23:40:39 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>29.11.2008 23:10:05 markshevchenko</title>
			<guid isPermaLink="true">#comment_1161878</guid>
			<link>#comment_1161878</link>
			<description><![CDATA[А Вы голову включите, и постарайтесь понять, о чём написано. Если голова не работает, не читайте. Для здоровья полезнее.]]></description>
			<pubDate>Sat, 29 Nov 2008 23:10:05 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>29.11.2008 23:07:04 markshevchenko</title>
			<guid isPermaLink="true">#comment_1161874</guid>
			<link>#comment_1161874</link>
			<description><![CDATA[Ну, началось… При чём тут OpenMP?<br/>
<br/>
Мы обсуждаем что тут у нас на платформе в ближайшее время появится. Приходит сноб-знаток, и начинает нудеть. Много вы работающих приложений написали на базе OpenMP? Люди пользуются? Миллионы свои заработали?]]></description>
			<pubDate>Sat, 29 Nov 2008 23:07:04 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>29.11.2008 23:04:06 markshevchenko</title>
			<guid isPermaLink="true">#comment_1161866</guid>
			<link>#comment_1161866</link>
			<description><![CDATA[Сейчас, как 20 лет назад на PC XT — любая задача решается самописным кодом. А будет по-человечески — мы пишем высокоуровневый код, машина сама его распаралеливает, распределяет, и собирает результаты.]]></description>
			<pubDate>Sat, 29 Nov 2008 23:04:06 GMT</pubDate>
			<author>markshevchenko</author>
		</item>
	

	
		<item>
			<title>29.11.2008 15:57:32 jawbreaker</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1161215</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1161215</link>
			<description><![CDATA[Насколько я знаю он войдёт в .Net 4.0, так что это действительно перспективная вещь.]]></description>
			<pubDate>Sat, 29 Nov 2008 15:57:32 GMT</pubDate>
			<author>jawbreaker</author>
		</item>
	

	
		<item>
			<title>29.11.2008 09:56:08 Kroz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1160676</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1160676</link>
			<description><![CDATA[Да, я с Вами полностью согласен. Мне вообще не нравится идея писать на .NET хоть сколь-нибудь серьезные вычисления. Зато GUI я пишу только на нем.<br/>
<br/>
Мой пост скорее о другом: что мир на OpenMP не сошелся и я, в частности, не сумел на нем решить свою задачу распараллеливания. Мне пришлось использовать относительно новую библиотеку Intel Threading Building Blocks.<br/>
<br/>
Ну а про распараллеливание между компами это да… Хотя знаете, иногда нужно быстро проверить идею. Ключевое слово «быстро». В этих случаях удобно это написать на .NET (например), а затем переносить на С++. Хотя, конечно, такой сценарий больше подходит для исследователей-одиночек, чем для компаний.]]></description>
			<pubDate>Sat, 29 Nov 2008 09:56:08 GMT</pubDate>
			<author>Kroz</author>
		</item>
	

	
		<item>
			<title>29.11.2008 09:49:22 dmitry39</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1160669</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1160669</link>
			<description><![CDATA[круть, наконец-то, Extensions — отличная штука :)]]></description>
			<pubDate>Sat, 29 Nov 2008 09:49:22 GMT</pubDate>
			<author>dmitry39</author>
		</item>
	

	
		<item>
			<title>28.11.2008 23:34:18 ItGold</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1160272</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1160272</link>
			<description><![CDATA[Меня терзают смутные сомнения. Вообще то задача управления потоков и разруливания принципов распределения ресурсов между процессорами — задача достаточно низкоуровнего характера. Т.е. по хорошему сама среда, в которой выполняется приложение пользователя должна заниматься этими делами, предоставляя возможность программисту бизнес приложений сконцентрироваться на бизнес-задачах соответственно. А здесь вместо этого мы имеем coupling с resource management и самому разработчику предлагается а) знать, на каких машинах будет выполняться приложение, б) вставлять в код приложения подобного рода затычки, если есть вероятность, что приложение установят на многопроцессорную машину. в) менеджить это все добро со всеми вытекающими последствиями.<br/>
Вопрос — действительно ли стоит так восторгаться сим замечательным поделием? Может это просто hot-fix от микрософт перед выпуском фреймворка, который будет работать нормально на многопроцессорных системах?<br/>
Да, впринципе может быть еще какой-нибудь подтип приложений, в которых нужно руками распределять нагрузку на процессоры, и там такой подход будет несомненно полезен. Но повальное большинство проектов к такому классу не относятся.]]></description>
			<pubDate>Fri, 28 Nov 2008 23:34:18 GMT</pubDate>
			<author>ItGold</author>
		</item>
	

	
		<item>
			<title>28.11.2008 21:09:21 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159978</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159978</link>
			<description><![CDATA[Ко мне эта новость пришла из других рук. Но вы верно уточнили, «старались». Так вот если раньше этим нельзя было управлять, то в 2008-м такая возможность вроде как появилась. Просто если параллельно выполняются несколько вычислительных процессов на разных ядрах и известно, что нагрузку они создают одинаковую, то их лучше привязать намертво к процессорам. А раньше были частые случаи, когда при синхронизациях, и следовательно простоях, потоки перемещались между ядрами, что естественно приводило к падению производительности. А для серверов, работающих по потоковой схеме, это не должно быть так критично.]]></description>
			<pubDate>Fri, 28 Nov 2008 21:09:21 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>28.11.2008 20:44:29 dmx</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159883</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159883</link>
			<description><![CDATA[Вообще такой подход как вы описали — довольно таки сомнительный. Есть поток 1, он запустился на одном процессоре, запустился поток 2 и полностью загрузил процессор. Теперь если запрос к потоку 1 опять придет, то он будет вынужден выполняться медленно, так как уже привязан к этому процессору. А у вас там ещё 7 простаивают…<br/>
<br/>
Если брать на примере IIS6, то там потоки «старались» выполняться на тех же процессорах, но это было не гарантированно. Гарантированно запрос выполнялся именно на свободном процессоре.]]></description>
			<pubDate>Fri, 28 Nov 2008 20:44:29 GMT</pubDate>
			<author>dmx</author>
		</item>
	

	
		<item>
			<title>28.11.2008 20:42:26 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159879</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159879</link>
			<description><![CDATA[<blockquote>Во-вторых, с помощью него не так просто распараллелить сложные алгоритмы.</blockquote>А с помощью Parallel Extensions, которые судя по описанию аналогичны OpenMP, это будет сделать легче? Нет. Что я для себя извлёк из этого: кому действительно нужно было увеличить быстродействие — написали нужный кусок кода на C+OpenMP, а не ждали пока сделают подобное для .NET. Думаю вы, как человек явно разбирающийся в теме, согласитесь, что слышать в нынешнее время фразу<br/>
<blockquote>Так что скоро будем параллелить не только между процессорами, но и между компами. :)</blockquote> довольно странно.]]></description>
			<pubDate>Fri, 28 Nov 2008 20:42:26 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>28.11.2008 19:52:25 Kroz</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159743</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159743</link>
			<description><![CDATA[Ну OpenMP, вообще говоря, не панацея… <br/>
Во-первых, насколько мне известно, он только для C++ и Fortran.<br/>
Во-вторых, с помощью него не так просто распараллелить сложные алгоритмы. В частности, алгоритмы парадигмы «разделяй и властвую» (простой пример — быстрая сортировка), так просто не параллелятся…]]></description>
			<pubDate>Fri, 28 Nov 2008 19:52:25 GMT</pubDate>
			<author>Kroz</author>
		</item>
	

	
		<item>
			<title>28.11.2008 19:44:34 Joshua</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159727</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159727</link>
			<description><![CDATA[Спасибо за статью!<br/>
Кстати, цикл с простыми числами можно сократить до корня, и проверять хотя бы с шагом два (отбросив четные). А можно и еще быстреее :)]]></description>
			<pubDate>Fri, 28 Nov 2008 19:44:34 GMT</pubDate>
			<author>Joshua</author>
		</item>
	

	
		<item>
			<title>28.11.2008 19:19:52 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159670</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159670</link>
			<description><![CDATA[Говорят, в 2008-м сервере это уже не так актуально. Программисты Микрософта таки переписали sheduler потоков, так что теперь они привязываются к своим процессорам. А раньше потоки после простоя могли продолжить выполнение на другом ядре, в результате чего были накладки на переключение и перезапись кешей. Двигаются в правильном направлении :)]]></description>
			<pubDate>Fri, 28 Nov 2008 19:19:52 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>28.11.2008 19:14:32 Sannis</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159658</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159658</link>
			<description><![CDATA[Про такие вещи, как OpenMP и MPI программисты под .NET видимо не слышали :(]]></description>
			<pubDate>Fri, 28 Nov 2008 19:14:32 GMT</pubDate>
			<author>Sannis</author>
		</item>
	

	
		<item>
			<title>28.11.2008 18:50:42 ashmind</title>
			<guid isPermaLink="true">http://habrahabr.ru/blogs/net/45732/#comment_1159595</guid>
			<link>http://habrahabr.ru/blogs/net/45732/#comment_1159595</link>
			<description><![CDATA[Надо учитывать что по лицензии (насколько я её понимаю) PFX нельзя использовать в готовых продуктах, только для тестирования.<br/>
С другой стороны, Mono сделали свою версию — и в ней такого ограничения нет (но у меня не собралось).<br/>
]]></description>
			<pubDate>Fri, 28 Nov 2008 18:50:42 GMT</pubDate>
			<author>ashmind</author>
		</item>
	

	
</channel>
</rss>

