Это пятый и последний пост из серии «Великие люди параллельного программирования» . Мои читатели предложили мне длинный список других кандидатов в эту когорту гениев параллелизма и вполне возможно, что некоторое время спустя я продолжу этот цикл и возьму интервью и у других разработчиков тоже.
Ну, а на сегодня, моим гостем будет Джо Даффи – руководитель группы разработчиков Microsoft, которая занимается проблемами параллелизма в рамках CLR (Common Language Runtime, общеязыковая среда исполнения, если кто не знает). Сегодня Джо снова непосредственно работает с кодом, точнее говоря он разрабатывает библиотеки, инфраструктуру и программные модели поддержки параллелизма. Формально он работает в рамках Microsoft’s Developer Division. Поэтому не удивительно, что я решил поговорить именно с Джо Даффи о потоках в рамках платформы .NET, тем более что в интернете этот человек уже давно известен благодаря своему блогу, посвящённому параллельному программированию, и своей книге — Professional .NET Framework 2.0. Я благодарен этому человеку за то, что он согласился ответить на мои вопросы !
И так первые 5 вопросов посвящены параллельному программированию вообщем:
Майкл: Наступает эра многоядерных процессоров, как вы думаете, Джо, как это отразиться на области параллельных вычислений, станет ли, наконец, параллельное программирование частью мейнстрима? Или же это просто ещё один этап на пути использования параллелизма и вскоре интерес к параллельному программированию вновь будут проявлять только люди, занимающиеся высокопроизводительными вычислениями (HPC — high performance community)?
Джо: Сейчас нельзя точно сказать как оно там будет в будущем… и когда же наконец параллельное программирование станет частью мейнстрима. Рост производительности безусловно важен для многих людей (но не для всех) и фактически рост производительности будет способствовать росту продаж ПК (что косвенно повлечет и рост продаж коммерческого ПО). И в этом смысле параллелизм безусловно станет мейнстримом. Но только это вовсе не означает, что каждый программист прям с завтрашнего дня начнёт заботиться о распараллеливании программ, которые он создает, и вообще будет больше думать о параллелизме в процессе разработки.
При этом, однако, большинство разработчиков ПО сегодня не смогут запросто овладеть параллелизмом и работать с ним – сегодня написание параллельного кода это очень непростая задача (если к тому же учитывать те технологии, которые повсеместно сегодня используются разработчиками). Более того, большинство разработчиков просто не представляют куда теперь девать всю вычислительную мощь многоядерных процессоров, которые постепенно заполоняют десктопные машины пользователей. Небольшая кучка истинных приверженцев параллельного программирования научится-таки решать задачи пользователей, используя всю мощь нескольких ядер, именно эти «выскочки-отщепенцы» заработаю свои миллионы и покажут нам всем как нужно программировать и как нужно решать задачи, используя параллелизм. И вот тогда-то можно будет сказать, что параллелизм вошел в мейнстрим программирования. Но на данный момент об этом ещё рано говорить.
Майкл: Время от времени в сети разгораются споры – что лучше для параллельного программирования – программирование в системе с общей, разделяемой памятью(shared-memory programming) или же программирование через посылку сообщений(message passing). Каково ваше мнение на этот счёт?
Джо: Моё мнение таково – реально между взаимодействием через общую память и между взаимодействием через посылку сообщений нет практически никакой разницы. В чем отличие отправки\принятия сообщения и разветвления\объединения(forking\joining) при параллелизме по данным ? Логически это вполне себе похожие вещи, различающиеся разве что в специфике управления данными, доступом и коммуникациями. При этом с точки зрения параллелизма вы точно также должны думать о зависимостях, причинной обусловленности, компонуемости, ошибкоустойчивости и т.д. Системы с общей памятью не способны одномоментно решить все эти важные (и сложные) задачи.
Для меня важным является другой вопрос – каким образом мы можем объединить эти два мира ? Каким образом мы можем перенести такие свойства систем посылки сообщений как атомарность и изолированность на те конструкции программирования, которыми сегодня постоянно пользуются программисты? (Или, другими словами, какие же языки программирования люди должны использовать при параллельном программировании, если мы не можем изменить те языки, которые используются сегодня?). Системы взаимодействия на основе посылки сообщения являются особенными, в том смысле, что они под час изначально создаются с учётом этих вопросов. Я полностью уверен, что неизменяемость(immutability) и изолированность (локальность) – это два столпа, на которых должны основываться (или хотя бы должны их поддерживать) все современные системы типов, даже если эти системы типов предполагается использовать в императивных языках, системах с разделяемой памятью, языках семейства Си. Правда несколько (немного) таких примеров уже есть.
Майкл: Хорошо. Отметьте, пожалуйста, самые выдающиеся, на ваш взгляд, достижения\инновации в области параллельного программирования за прошедшие несколько лет.
Джо: Во-первых, нужно отметить гигантский объем проделанной работы в области верификации программ, новых механизмов синхронизации (нпр., системы на основе транзакционного доступа к памяти), а также новых способов описания мелкозернистого параллелизма (примером такого типа параллелизма является параллелизм по данным). Кроме систем поддержки транзакционного доступа к памяти можно ещё отметить Fortressm, X10 и Chapel (прим.перев. [извините, не сдержался] — а я бы ещё отметил наш ответ IBM’овскому X10 – язык MC# ). В сообществе Haskell программистов проделывают классные штучки с параллелизмом по данным. Обратите внимание на язык NESL и его идею вложенного параллелизма (Nested data parallelism). Вообщем я вижу кучу крайней интересных идей и их реализаций.
Майкл: Каким вы видите будущее параллельного программирования? Что вы можете предложить в качестве серебряной пули в этой области разработки?
Джо: Я не верю в существование каких-либо серебряных пуль в области параллельного программирования. Посмотри на аппаратную поддержку параллелизма – объединяя различные технологии параллелизма на уровне [машинных] команд (ILP: нпр., супер скалярные процессоры, предсказание условного перехода, конвейеризация) мы добиваемся прироста производительности, причём тут нет никакой магии — мы можем спрогнозировать величину этого прироста при использовании той или иной комбинации ILP-методов распараллеливания. Я думаю, что дела будут обстоять подобным образом и в программировании ПО. Мы будем использовать высокоуровневые механизмы для программ, в которых мы можем выделить большие куски независимой функциональности, которую можно легко распараллелить (возможно даже изолированно); более низкоуровневые механизмы для распараллеливания логически независимых активностей; и, наконец, мелкозернистый параллелизм (параллелизм на уровне данных или на уровне задач) — для того чтоб распараллелить конкретные участки кода, из которых состоят активности уровнем выше. Причём подобным образом мы будем поступать на всех уровнях абстракции, начиная от библиотек и заканчивая языками программирования и средами исполнения.
Майкл: На сегодняшний день, одной из главных проблем параллельного программирования является то, что оно несколько сложнее последовательного. Продуктивность кодирования при этом резко отличается, от последовательного программирования. Как вы думаете, существуют ли способы, способные изменить такое положение дел?
Джо: Собственно это всегда так происходило и происходит – всегда что-то новое кажется для некоторых программистов сложным, но я уверен, что мы сможем достигнуть значительных успехов за счёт абстрагирования. И на определённом уровне абстракции параллельное программирование будет доступно большинству программистов. На самом деле при использовании параллелизма просто возникают дополнительные вопросы на этапе проектирования и реализации, но автомат, описывающий программу становиться конечно чрезвычайно сложным. На самом деле программисты должны осознавать существование тех или иных зависимостей в своём коде и проектировать свои программы, обеспечивая более низкое зацепление модулей и более слабые зависимости по данным. Думаю со временем всё утрясется.
--
Это была первая часть интервью. Следующая посвящена, собственно, потокам в .NET:
Майкл: В чём вы видите сильные и слабые стороны потоков в .NET по сравнению с другими системами параллельного программирования ? Что бы вы хотели улучшить ?
Джо: Сила .NET-потоков заключается в многообразии готовых, оттестированных базовых элементов, которые программист может использовать для создания сущностей других уровней абстракции. Главным же недостатком является то, что можно перечислить большое число полезнейших абстракций, которые хотелось бы иметь в базовой библиотеке .NET для работы с потоками, но их нет.
Майкл: Если бы вы сегодня проектировали потоки в .NET с нуля, чтобы вы сделали по-другому?
Джо: Ну, трудно сказать, понятно, что мы могли реализовать потоки в .NET по-другому, но полёт нашей мысли постоянно наталкивался на ограничения( в плане поддержки параллелизма) самого .NET Framework, а также Win32 API. Нам пришлось отталкиваться от разделяемой памяти, изменяемых(mutable) переменных и прочих тонких деталей и опасностей платформы. Можно по пальцам пересчитать людей, которые полностью понимают причины и особенности этих проблем… эти люди должны были либо научить остальных разработчиков(поделиться сокровенным знанием), либо создать для остальных более высокий уровень абстракции, спрятав за ним необходимость работы с тонкими местами платформы. Я конечно же уверен, что мы могли сделать все гораздо лучше, если бы параллелизм был заложен в платформу со дня её основания. Мы работали в мире, где на протяжении 20+ лет властвовало «одноядерное мышление» и этого нельзя не учитывать.
Майкл: Можете ли вы порекомендовать какой-либо инструментарий для людей, использующих потоки в .NET. Может быть IDE? Редакторы? Отладчики? Профайлеры? Верификаторы? Ещё что-нибудь…
Джо: Visual Studio вполне хороший инструмент для отладки многопоточного кода, а WinDbg позволяет наблюдать низкоуровневые структуры данных ОС (в частности связанные с многопоточностью). Профайлер, который идёт в месте с Visual Studio 2005 также может быть полезен, если вы хотите знать куда деваются тики ядер вашего процессора, кроме того разнообразные счетчики позволяют узнать, например, количество промахов в кэше второго уровня и т.д. Можно посоветовать использовать Intel VTune и сопутствующий инструментарий для анализе взаимодействий в многопоточном коде, хотя инструменты Intel работают в рамках .NET с некоторыми ограничениями.
Майкл: Пожалуйста, дайте совет тем, кто только начинает использовать потоки в .NET. С чего бы вы начали сами? Может быть книги? Уроки? Интернет ресурсы? Где, то самое место, где можно найти ответы на все вопросы?
Джо: Думаю стоит почитать мой блог, а также блоги Криса Брумма и Ванса Моррисона. На сайте MSDN’а есть хорошая подборка статей по этой теме . Ну и конечно, не пропустите выход моей новой книги — Concurrent Programming on Windows.
Майкл: Самая ужасная ошибка, с которой вы когда-либо сталкивались в программе, использующей .NET-потоки ?
Джо: Многопоточность в .NET — это достаточно низкоуровневый инструмент для написания параллельных программ. Люди часто испытывают проблемы с гонками и дедлоками, надёжностью, неожидаемой реентерабельностью, с GUI, с таким понятием как thread affinity и прочими вещами. В моём блоге есть обзор наиболее частых ошибок программистов, который может быть полезен и интересен .
Здравствуйте, nixxxin, Вы писали: D>>Джо: Люди часто испытывают проблемы с гонками и дедлоками, надёжностью, неожидаемой реентерабельностью...
N>Че-то "гонки" ИМХО не подходит тут, или это уже стало стандартным переводом для race-condition?
Делаем всё чтоб стало
N>Как по-русски будет race-condition?..
Согласен корявенько перевёл(хотя подчас термин 'race' переводится некоторыми словарями в it-шном контексте именно как 'гонки'\'состязание')... так что можно ещё перевести, как, например, — состояние состязания, ну или конкретизировать термин:
например так —
>>Джо: Люди часто испытывают проблемы с последовательностью исполнения команд потоками(с т.н. состоянием состязания), с дедлоками, надёжностью, неожидаемой реентерабельностью...
Здравствуйте, Константин Л., Вы писали:
КЛ>5 вопросов про потоки в .net (с натяжкой) и ниодного внятного ответа.
Согласен, интервью не ахти, ну какая уж точка зрения(свобода в высказываниях) у Джо Даффи есть — такая и есть, в этом смысле, конечно другие интервью по интересней выглядят(например, с Джо Армстронгом — En|Ru
Но, на мой взгляд, рассуждать о проблемах параллельного программирования в общем у Даффи получается хорошо(особенно когда он с функциональным уклоном на это дело смотрит )
Здравствуйте, Didro, Вы писали:
N>>Как по-русски будет race-condition?.. D>Согласен корявенько перевёл(хотя подчас термин 'race' переводится некоторыми словарями в it-шном контексте именно как 'гонки'\'состязание')... так что можно ещё перевести, как, например, — состояние состязания, ну или конкретизировать термин:
"Состязания" — вполне устоявшийся термин.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
КЛ>5 вопросов про потоки в .net (с натяжкой) и ниодного внятного ответа.
Для меня ключевыми моментами стали следующие цитаты:
Небольшая кучка истинных приверженцев параллельного программирования научится-таки решать задачи пользователей, используя всю мощь нескольких ядер, именно эти «выскочки-отщепенцы» заработаю свои миллионы и покажут нам всем как нужно программировать и как нужно решать задачи, используя параллелизм.
Это сильно перекликается с моим впечатлением от изучения уравнений матфизики и функционального анализа в университете: сотни студентов каждый год пытаются осваивать этот материал и даже умудряются сдавать какие-то лабораторные/курсовые на эти темы. Хотя реально рубят в вопросе единицы, которые все и делают. Так же и с параллельностью -- сложность не в инструментах, сложность в перестройке мышления. Для успешного написания распараллеливаемых программ нужно, в первую очередь, мозги себе перестроить. Как это было году в 94-м, когда ООП в массовом порядке начали осваивать. Или как сейчас с функциональщиной. И как завтра с параллельностью.
Моё мнение таково – реально между взаимодействием через общую память и между взаимодействием через посылку сообщений нет практически никакой разницы. В чем отличие отправки\принятия сообщения и разветвления\объединения(forking\joining) при параллелизме по данным ? Логически это вполне себе похожие вещи, различающиеся разве что в специфике управления данными, доступом и коммуникациями. При этом с точки зрения параллелизма вы точно также должны думать о зависимостях, причинной обусловленности, компонуемости, ошибкоустойчивости и т.д.
Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Моё мнение таково – реально между взаимодействием через общую память и между взаимодействием через посылку сообщений нет практически никакой разницы. В чем отличие отправки\принятия сообщения и разветвления\объединения(forking\joining) при параллелизме по данным ? Логически это вполне себе похожие вещи, различающиеся разве что в специфике управления данными, доступом и коммуникациями. При этом с точки зрения параллелизма вы точно также должны думать о зависимостях, причинной обусловленности, компонуемости, ошибкоустойчивости и т.д.
E>Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной.
если _НЕ_ абстрагироваться от реальных задач, то скорее всего это был он
Здравствуйте, Константин Л., Вы писали:
E>>Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной.
КЛ>если _НЕ_ абстрагироваться от реальных задач, то скорее всего это был он
Если поставить во главу угла надежность получаемых распараллеленных решений (причем здесь я говорю о распаралленивании различных активностей в задаче, а не распараллеливание одной какой-то операции, вроде сложения матриц), то я склонен доверять Даффи. По собственному опыту знаю
, что получение надежного решения на обмене сообщениями не просто. Здесь неоднократо говорилось, что получить надежное решение на обычной многопоточности не просто. Т.е. какой способ не возьми, от геморроя просто так не избавишься, отхлебнуть придется достаточно.
А то, что подводные камни при одном и при другом подходе разные -- так это очевидно. Видимо, Даффи говорил с более высокого уровня абстракции.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной.
А как по мне так именно Джо выкурил слишком много. Причем чегото потяжелее чем бомбук.
Посмотрю я на то как он будет паралелить с разделяемой памятью на нескольких машинах у которых общей памяти нет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Didro, Вы писали:
D> Joe Duffy | Джо Даффи
D>Это пятый и последний пост из серии «Великие люди параллельного программирования» . Мои читатели предложили мне длинный список других кандидатов в эту когорту гениев параллелизма и вполне возможно, что некоторое время спустя я продолжу этот цикл и возьму интервью и у других разработчиков тоже. D>Ну, а на сегодня, моим гостем будет Джо Даффи – руководитель группы разработчиков Microsoft, которая занимается проблемами параллелизма в рамках CLR (Common Language Runtime, общеязыковая среда исполнения, если кто не знает).
Собственно дальше можно уже и не читать. Проблемы параллелизма в CLR на сегодня не решены никак. То есть вообще никак. Параллельный софт на дотнете превращается в тихий ужас.
Внешность его у меня тоже почему-то тоже доверия не вызвает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Собственно дальше можно уже и не читать. Проблемы параллелизма в CLR на сегодня не решены никак. То есть вообще никак. Параллельный софт на дотнете превращается в тихий ужас.
Ну да, в сочетании с невнятной потоковой моделью WinForms и простым переносом примитивов Win32API на новую платформу ситуация в лучшую сторону не поменялась(в худшую правда тоже, так что надо отдать Даффи должное).
Но ведь пишут же . Join-исчисление, например, не плохая модель для message-passing систем, реализована уже и в Nemerle, и в MC#. Intel развивает свои Threading Building Blocks (правда only for C++), или OpenMP, например... На самом деле ситуация отягощается тем, что скажем ни Intel, ни MS(по крайней мере их представители на конференциях\семинарах) не считают необходимым повышать уровень абстракции для конечных пользователей потоков, о чём в свою очередь говорит Даффи.
Здравствуйте, Didro, Вы писали:
D>Но ведь пишут же . Join-исчисление, например, не плохая модель для message-passing систем, реализована уже и в Nemerle, и в MC#. Intel развивает свои Threading Building Blocks (правда only for C++), или OpenMP, например...
Ага. А какое отношение все это имеет к этой Дафни?
D> На самом деле ситуация отягощается тем, что скажем ни Intel, ни MS(по крайней мере их представители на конференциях\семинарах) не считают необходимым повышать уровень абстракции для конечных пользователей потоков, о чём в свою очередь говорит Даффи.
О том и речь. У меня вообще складывается впечатление, что ситуация с многопоточностью сегодня вточности повторяет ситуацию с языками программирования лет 10 назад. Ребат из МС и Интел тупа незнали что кроме С есть еще что-то. По ходу дела выдумывали КОМ-ы и другую хренатень вместо того чтобы просто изучить имеющийся опыт.
Сейчас МС во всю копает в области языков. Поддерживают разные проекты в этой области.
Ну, а в области параллелизма все как и 20 лет назад. Ничего нового. Языки 95-ого года выхода имеют и то большую поддержку параллелизма. А залихватски Дафни несут откровенный бред.
Какие к черту проффесионалы? О чем ом? Проффисионал сделает себе фрэймворк или выберет язык который предоставит ему нужную поддержку. А тот самый мэйнстрим требует чтобы все было просто и прозрачно. Иначе ситуация получается просто идиотская. Разные Хейльсберги боятся в язык добавить мало-мальски серьезную возможность только чтобы безные индусы не запутались, и при этом им же предлагается писать код в условиях полнейшей недетерминированности. Да они через час приведут програму в полностью нерабочее состояние.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>А то, что подводные камни при одном и при другом подходе разные -- так это очевидно. Видимо, Даффи говорил с более высокого уровня абстракции.
ИМХО, всё-таки, здесь он говорит о вполне конкретном случае — fork/join по данным. Например, берём матрицу и делаем fork на каждый её элемент и потом — join для этих потоков. Технически это почти то же самое, что перекинуть элементы матрицы сообщениями в отдельные потоки, а потом ждать ответных сообщений.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, eao197, Вы писали:
E>>Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной. WH>А как по мне так именно Джо выкурил слишком много. Причем чегото потяжелее чем бомбук. WH>Посмотрю я на то как он будет паралелить с разделяемой памятью на нескольких машинах у которых общей памяти нет.
А все аналогично. В обычной SMP системе с "общей" памятью на микроуровне на самом деле происходит тот же message-passing в/из кешей каждого процессора из/в общую пямять через системную шину. Только для прикладного программиста эти детали несущественны. Аналогичные механизмы можно применять и на более высоком уровне. Реализация примерно может быть как виртуальная память — обращение к невалидной странице генерирует исключение и обработчиком нужная информация подгружается с другой машины.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>А все аналогично. В обычной SMP системе с "общей" памятью на микроуровне на самом деле происходит тот же message-passing в/из кешей каждого процессора из/в общую пямять через системную шину. Только для прикладного программиста эти детали несущественны. Аналогичные механизмы можно применять и на более высоком уровне. Реализация примерно может быть как виртуальная память — обращение к невалидной странице генерирует исключение и обработчиком нужная информация подгружается с другой машины.
Такие системы не живут при наличии сколь нибудь заметной нагрузки.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
E>>Очень необычный взгляд на вещи. Гораздо чаще встречается противопоставление одной модели другой. А оно вона как оказывается -- если долго и серьезно заниматься параллелизмом, то особой разницы-то и нет. Лично меня такое утвеждение заставляет задуматься -- либо я не достаточно выкурил еще бамбука на эту тему, либо Джо Даффи выкурил слишком много. Более вероятен, однако, первый вариан, следовательно, нужно пересмотреть свою ортодоксальную приверженность message-passing механизма в пользу более умеренной. WH>А как по мне так именно Джо выкурил слишком много. Причем чегото потяжелее чем бомбук.
WH>Посмотрю я на то как он будет паралелить с разделяемой памятью на нескольких машинах у которых общей памяти нет.
Либо я вас не правильно понял, либо такие системы есть и их архитектура называется ccNuma. Если первое, то извиняюсь.
VD>Сейчас МС во всю копает в области языков. Поддерживают разные проекты в этой области.
VD>Ну, а в области параллелизма все как и 20 лет назад. Ничего нового. Языки 95-ого года выхода имеют и то большую поддержку параллелизма. А залихватски Дафни несут откровенный бред.
Понимая, что особо это свет на ситуацию не пройлёт, задал, ради интереса, подобный вопрос(куда смотрела MS, когда они делали .NET Threading Library) самому Дафни:
>>
Hello, could you explain why some "useful abstractions (to have it available “out of the box”)" were not included in .NET FW Threading library.
You note, that it is the main weakness of .NET Threading, and point to the way to correct it — developers should base new (their own) abstrations on "approved .NET basic threading building blocks"... but why does the level of abstraction of .NET Threading so low ?
What is the cause of that ".NET threading is a very low-level" ?
Thank you.
Alexander Petrov
>>
Hi Alexander, I think the reason is just that having these higher level coordination primitives have never been as high a priority as it is now. It seems obvious with multicore everywhere that we need them, but hindsight is 20/20. My only hope is that the current situation gets better... relatively soon.
Joe Duffy
Joe Duffy | Джо Даффи
)
