Comments 46
Здравствуйте, Владимир!
Вопрос как к специалисту поддержи Intel Parallel Studio — насколько эффективно использование данного продукта для многопоточного профилирования приложений на платформе .net? Есть ли у ваших клиентов успешный опыт подобной работы; или IPS наиболее применим только для native (c/c++)? Понятно, что при помощи sos и windbg можно отлаживать и .net, но хотелось бы узнать про .net-specific возможности (если есть).
Спасибо.
P.S. Я тоже окончил ТРТУ, факультет РТФ ;)
Вопрос как к специалисту поддержи Intel Parallel Studio — насколько эффективно использование данного продукта для многопоточного профилирования приложений на платформе .net? Есть ли у ваших клиентов успешный опыт подобной работы; или IPS наиболее применим только для native (c/c++)? Понятно, что при помощи sos и windbg можно отлаживать и .net, но хотелось бы узнать про .net-specific возможности (если есть).
Спасибо.
P.S. Я тоже окончил ТРТУ, факультет РТФ ;)
+2
Вопрос засчитан ;) А я окончил МЭИ, факультет ИРЭ ЭТФ ;)
0
С ответами на вопросы, как и запланировано, будем разбираться в среду. Но тут не могу не поприветстовать коллегу по альма матер :)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
+2
Intel Parallel Studio предназначена для работы только с кодом, написанным на C/C++ (native).
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
0
Уж как-то «воды» много, видимо расчет на вопросы от хабражителей. Требую мяса и крови! :)
+1
мне вот интересно вообще, насколько активно сейчас решается вопрос с распараллеливанием нагрузки на ядра 2/3/4-ядерных процессоров в серверном/домашнем ПО? ибо сколько я работаю, замечаю то, что в основном грузится только первое ядро (особенно заметно это на Ubuntu, там первое ядро загоняется до 70% в то время, как второе всего на 5-10%)
+1
В серверном ПО вопрос распараллеливания рассматривался с самого начала существования многопроцессорных систем. В данный момент идет активная разработка серверных приложений использующих многопотоковость. Однако и приложения, основанные на инфраструктуре межпроцессного взаимодействия (IPC), вполне себе могут эффективно работать на многоядерных процессорах. Навскидку из представителей серверного рынка сразу вспоминается Oracle, который скурпулезно распараллеливает и оптимизирует свои продукты.
Что касается клиентского ПО, то тут немного сложнее, хотя бы потому, что клиентского ПО очень много. Действительно, последовательные программы разрабатывать много проще, и часто производители ПО просто «не заморачиваются» с параллелизмом. Однако, если взять отдельные сегменты приложений, где скорость работы программы является ее конкурентным преимуществом, то тут дела обстоят как раз наоборот – редкая программа не использует все имеющиеся ядра. К примеру, все современные кодеки исключительно оптимизированы для выполнения в одном потоке, и вдобавок еще и распараллелены. Кому, скажем, нужен кодек H.264, если он не может загрузить работой все четыре ядра под 100%? Графические приложения тоже не отстают. Adobe, например, прилагает очень серьезные усилия для оптимизации и распараллеливания своих продуктов.
Именно для разработки клиентских приложений и предназначена Parallel Studio (обзор: software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit). В частности, для анализа эффективности и оптимизации использования всех ядер микропроцессора используется Amplifier (подробно на русском языке тут: software.intel.com/ru-ru/articles/intel-parallel-amplifier), а для отладки ошибок многопоточности и памяти – Inspector (еще одна статья на русском: software.intel.com/ru-ru/articles/intel-parallel-inspector-finding-memory-errors)
Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
Что касается клиентского ПО, то тут немного сложнее, хотя бы потому, что клиентского ПО очень много. Действительно, последовательные программы разрабатывать много проще, и часто производители ПО просто «не заморачиваются» с параллелизмом. Однако, если взять отдельные сегменты приложений, где скорость работы программы является ее конкурентным преимуществом, то тут дела обстоят как раз наоборот – редкая программа не использует все имеющиеся ядра. К примеру, все современные кодеки исключительно оптимизированы для выполнения в одном потоке, и вдобавок еще и распараллелены. Кому, скажем, нужен кодек H.264, если он не может загрузить работой все четыре ядра под 100%? Графические приложения тоже не отстают. Adobe, например, прилагает очень серьезные усилия для оптимизации и распараллеливания своих продуктов.
Именно для разработки клиентских приложений и предназначена Parallel Studio (обзор: software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit). В частности, для анализа эффективности и оптимизации использования всех ядер микропроцессора используется Amplifier (подробно на русском языке тут: software.intel.com/ru-ru/articles/intel-parallel-amplifier), а для отладки ошибок многопоточности и памяти – Inspector (еще одна статья на русском: software.intel.com/ru-ru/articles/intel-parallel-inspector-finding-memory-errors)
Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
0
а вообще, каково в плане финансов/ресурсоемкости, ПО под какие системы проще и дешевле писать, обслуживать и какое вообще будет более эффективным при работе на машине с необходимостью проводить логические операции, или, предположим, рендеринг неслабой такой трехмерной сцены?
0
Ой, что-то я, боюсь, не понял вопроса :) Попробую ответить, как понял, а вы меня поправите, если что.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
0
Да, вероятно не поняли :) Я имел ввиду, под какие системы будет дешевле и эффективнее по ресурсозатратам написать программное обеспечение: под многоядерные процессоры, или же на многопроцессорные, но с более мощными одноядерными процессорами
0
или же на многопроцессорные, но с более мощными одноядерными процессорами
Таких систем не бывает (по крайней мере, если речь идет об х86 архитектуре)
0
Владимир — почти прав, сейчас многопроцессорная система одноядерных процессоров IA32-скорее исключение, чем правило. Но тенденция — к многопроцессорным многоядерным системам. Так что это придется учитывать в разработке.
0
Здравствуйте, Владимир :)
Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
+1
64-битные системы занимают свою нишу в рынке ПО, которое не может обойтись без адресации к объему памяти, намного превышающему дозволенные 2ГБ в пользовательской области. Сейчас мы наблюдаем не только серверные, но и клиентские приложения, например CAD/CAM, которым просто необходимы 64-бит. Основная же масса клиентского ПО прекрасно себе живет и в 32-битном мире, и программисты не видят принципиальной необходимости что-то менять в этом плане. Более того, большая длина инструкции может даже замедлить исполнение программы в 64-битной среде. Однако, если есть определенные преимущества использования удвоенного набора регистров, в том числе и XMM, а также SIMD-блока для исполнения floating point команд, для значительного улучшения производительности программы, то имеет смысл писать 64-битное приложение, даже если оно и не использует возможности расширенной адресации памяти.
В связи со всем этим процессоры поддерживают 32-битный режим, не смотря на то что они уже 64-битные по своей архитектуре. И продлится это, скорее всего, довольно долго, и в основном во имя backward compatibility.
На моем рабочем лэптопе стоит и Windows XP и Linux Fedora, в основном из-за того, что приходится бывать у клиентов с разными специализациями. Программисты, естественно, тестируют продукты на всевозможных ОС (все виды Windows, c десяток Linux-дистрибутивов, и внутри каждого по три версии, и конечно же MacOS, куда же без нее :)), так как мы разрабатываем кросс-платформенные продукты. Что иметь в качестве рабочей среды, каждый решает сам, что ему удобнее или в чем больше приходится разбираться, с тем и работает. Бухгалтерия и Human Resources работают, естественно, под Windows :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
В связи со всем этим процессоры поддерживают 32-битный режим, не смотря на то что они уже 64-битные по своей архитектуре. И продлится это, скорее всего, довольно долго, и в основном во имя backward compatibility.
На моем рабочем лэптопе стоит и Windows XP и Linux Fedora, в основном из-за того, что приходится бывать у клиентов с разными специализациями. Программисты, естественно, тестируют продукты на всевозможных ОС (все виды Windows, c десяток Linux-дистрибутивов, и внутри каждого по три версии, и конечно же MacOS, куда же без нее :)), так как мы разрабатываем кросс-платформенные продукты. Что иметь в качестве рабочей среды, каждый решает сам, что ему удобнее или в чем больше приходится разбираться, с тем и работает. Бухгалтерия и Human Resources работают, естественно, под Windows :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
+1
Как скоро Intel Parallel Advisor войдет в состав Intel Parallel Studio?
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?
+2
Хороший вопрос. Я не знаю, как скоро. Возможно после того, как произойдет осознание его места и value proposition, которые предоставляет Advisor для цикла разработки многопоточного ПО. Этот процесс не быстрый, и зависит от интереса пользователей, их вклада в виде фидбэков на новые технологии ( software.intel.com/en-us/articles/intel-parallel-advisor-lite/ ). Этот путь, кстати, прошел Parallel Amplifier, который был выложен на сайт новых разработок в виде проекта PTU. Он там и сейчас присутствует ( software.intel.com/en-us/articles/intel-performance-tuning-utility/ ) и продолжает развиваться, а результаты в виде конечного продукта мы у видим в HE-версиях профилировщиков.
Что касается бесплатных версий. Дело в том, что Intel (SSG) не зарабатывает продажей софта, и не ставит себе это целью, и ценообразование на инструменты оптимизации производительности носит психологический характер. В западном (преимущественно американском) рынке ПО существует стереотип: бесплатоное ПО (не путать с open source) – это неподдерживаемые программы, написанные кучкой энтузиастов, или research-проект, перспективы которого туманны, а поэтому принимать его в свой «парк инструментов» не имеет смысла. Если же производитель берет оплату за ПО, значит он и берет на себя некоторую ответственность по сопровождению, поддержке пользователей, обновению версий, расширению функционала, и т.д. Чем выше стоимость ПО, тем сильнее должны «вылизывать» пользователя, в том числе предлагая различные сервисы.
Мы находимся где-то посередине этих двух крайностей, то есть между research-проектом и дорогостоящим проприетарным софтом. Это позволяет нам, предлагая инновационные методы распараллеливания программ и анализа производительности, не концентрировать огромное количество ресурсов в суппорт-инфраструктуре (примером последнего может быть IBM). Поэтому непосредственным суппортом (first-line support) у нас занимаются не натренированные девочки-телефонистки, а инженеры-консультанты, корорые непосредственно принимают участие в разработке продуктов, например, путем участия в architecture-board или в QA-процессах. Теже инженеры и разработчики отвечают на вопросы в форумах ISN по продуктам: англоязычном ( software.intel.com/en-us/forums/ ) и русскоязычном ( software.intel.com/ru-ru/forums/ ).
Для рынка ПО цены на наши продукты более чем скромные (опять же, с американской точки зрения), и при этом существуют академические программы (софт в два раза дешевле) и программы лояльности (когда компании получают бесплатно софт за то, что регулярно пользуются нашими новыми продуктами, и присылают отчеты по багам и пожелания по улучшению usability).
Ну и 30 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.
Что касается бесплатных версий. Дело в том, что Intel (SSG) не зарабатывает продажей софта, и не ставит себе это целью, и ценообразование на инструменты оптимизации производительности носит психологический характер. В западном (преимущественно американском) рынке ПО существует стереотип: бесплатоное ПО (не путать с open source) – это неподдерживаемые программы, написанные кучкой энтузиастов, или research-проект, перспективы которого туманны, а поэтому принимать его в свой «парк инструментов» не имеет смысла. Если же производитель берет оплату за ПО, значит он и берет на себя некоторую ответственность по сопровождению, поддержке пользователей, обновению версий, расширению функционала, и т.д. Чем выше стоимость ПО, тем сильнее должны «вылизывать» пользователя, в том числе предлагая различные сервисы.
Мы находимся где-то посередине этих двух крайностей, то есть между research-проектом и дорогостоящим проприетарным софтом. Это позволяет нам, предлагая инновационные методы распараллеливания программ и анализа производительности, не концентрировать огромное количество ресурсов в суппорт-инфраструктуре (примером последнего может быть IBM). Поэтому непосредственным суппортом (first-line support) у нас занимаются не натренированные девочки-телефонистки, а инженеры-консультанты, корорые непосредственно принимают участие в разработке продуктов, например, путем участия в architecture-board или в QA-процессах. Теже инженеры и разработчики отвечают на вопросы в форумах ISN по продуктам: англоязычном ( software.intel.com/en-us/forums/ ) и русскоязычном ( software.intel.com/ru-ru/forums/ ).
Для рынка ПО цены на наши продукты более чем скромные (опять же, с американской точки зрения), и при этом существуют академические программы (софт в два раза дешевле) и программы лояльности (когда компании получают бесплатно софт за то, что регулярно пользуются нашими новыми продуктами, и присылают отчеты по багам и пожелания по улучшению usability).
Ну и 30 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.
0
Спасибо Вам за подробный и развернутый ответ.
У меня есть предложение для VTune. Добавить возможность прогнозирования (разумеется примерного) времени выполнения анализируемого кода на других процессорах. Например, с другой тактовой частотой, количеством ядер и т.д. Если это, конечно, возможно и вяжется с идеологией VTune.
У меня есть предложение для VTune. Добавить возможность прогнозирования (разумеется примерного) времени выполнения анализируемого кода на других процессорах. Например, с другой тактовой частотой, количеством ядер и т.д. Если это, конечно, возможно и вяжется с идеологией VTune.
0
Отличная идея. Владимир, сорри что прерываю твой бенефис :) С другим количеством ядер вряд ли получится в Vtune, но с другой частотой и микроархитектурой как часть «Generate advice» может лечь хорошо. Прогнал пользователь на CVT 2Ghz, а advicer говорит — на NHM 3Ghz было бы столько то.
+1
Идея на столко же отличная, на сколько и нереализуемая. Про частоту я уже ответил ниже. А вот по мкроархитектуре не так все просто. Advice генерируется для всей программы вцелом, а вся программа исполняется не только внутренними блоками процессора, ведь еще задействована память, система ввода-вывода (сеть, диски, ит.д.). Какой тут можно дать прогноз по производительности программы, если мы рассматриваем только одну компоненту системы, а об остальных и понятия не имеем?
0
Такая возможность уже есть в Parallel Amplifier ( software.intel.com/ru-ru/articles/intel-parallel-amplifier, раздел Concurrency-анализ). Запустив Concurrency Analysis, мы получаем диаграмму масштабируемости программы вцелом на процессоре, в которм она исполнялась. Для почти идеально масштабируемого приложния ее пик находится в точке N (как дельта-функция), равной количеству ядер в системе. В реале же, диаграмма будет распределена по количеству ядер каким-либо образом, и это распределение можно, с некоторым приближеим, экстраполировать, чтобы понять, как программа будет вести себя, исполняясь в процессоре с бОльшим кол-вом ядер.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
0
Меня в данном контексте, если честно, больше интересует не столько прогноз повышения производительности с увеличением тактовой частоты, сколько наоборот — «деградация» с понижением частоты. Для того чтобы можно было получить пессимистический прогноз.
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных.
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных.
0
Если ваши задачи настолько специфичны, что для них важен пессимистичный прогноз, то лучше использовать натуральный эксперимент.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
0
Задачи не очень специфичные, просто, иной раз, хочется знать — а как код поведет себя на более «слабой» машине? Хотя, наверное, проще под такие эксперименты завести отдельную машину с конфигурацией ниже среднего и гонять на ней подобные тесты.
Спасибо Вам за содержательные ответы.
Спасибо Вам за содержательные ответы.
0
UFO just landed and posted this here
UFO just landed and posted this here
С интересом прочитал вашу статью по MC# ;)
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
+2
UFO just landed and posted this here
Ну т.е. Intel предлагает каждый раз изобретать свои велосипеды? ;)
Не совсем. В виде MPI Intel редлагает стандартный интерфейс. Под стандартным понимается, что он принят в индустрии «де-факто» как стандарт, и вопрос портирования состоит только в отладке спортрованного проекта. Кроме того, под «стандртным интерфейсом» кроется понятие совместимости.., с планировщиками очердей, сетевыми средами, и т.д.
Поэтому собрать свой велосипед под свои задачи из стандартных комплектующих иногда проще и дешевле, чем получить лишь красивый и бестящий звонок от модели, которая не ездит по большинству имеющихся дорог.
Однако, беда в том, что MPI слишком низкоуровневый!
В этом его приемущество. Т.е. это зависит от того, с какой стороны на этот вопрос смотреть.
Я вот не знаю как с помощью разумных временных затрат решать подобный тип задач на MPI, т.к. примитивные MPI-ные барьеры просто не предназначены для этого.
Ваша академическая задача не отражает всего моножество задач, которые решаются с помощью распределенных вычислений. И если для ее решения имеются какие-то более удобные высокоуровневые средства, помогающие ее решить в сотню строк кода, то это свсем не означает, что и другие задачи решться так же просто.
Любая более-менее нестандартная и нетривиальная задача на распараллеливание решается в MPI с большим треском и все трудности перекладываются на прикладных программистов…
Я слышал также мнение апологетов .Net и Java, что язык С++ плох тем, что перекладывает сложности программирования, обусловлнные архитектурой вычислительной системы, на плечи программистов. :) По-моему это просто вопрос компетенции и опыта, не более того.
0
UFO just landed and posted this here
Я знал, что вы приведте контраргумент с ассемблером :)
Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.
Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.
0
Инстументы?
+1
Расскажите по-подробнее о применении параллельных приложений в медицине. Просто я недавно закончил бауманку по специальности инж. дело в мед. технике, и мне было бы ужасно интересно, какие именно задачи можно решать с помощью современных параллельных вычислений. В родной альма-матер об этом и близко ничего не было)
0
Подходы к написанию параллельных приложений в медицине почти ни чем не отличаются от подходов к параллельным программам в других отраслях. Тут нужно говорить о задачах, которые решаются в медицинской тематике и к которым применимо распараллеливание. Наиболее сложные и алгоритмически нагруженные программы пишутся, как правило, для применеия в диагностических целях с использованием обработки большого количества объективных данных, как например в томографии, радиографии или рентгенографии. А там стоит несколько основных этапных задач:
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
+1
Интел с Микрософтом совместно работаю над Микрософтской параллельной средой выполнения (Microsoft Concurrency Runtime) и она будет встроена в Визуальную студию 2010.
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)
Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?
Что из Интеловской параллельной студии войдёт в МС студю 2010?
Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Заранее, Спасибо!
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)
Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?
Что из Интеловской параллельной студии войдёт в МС студю 2010?
Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Заранее, Спасибо!
+1
Да, действительно, Microsoft Concurrency Runtime появится в новой Dev10. Инфраструктура ConcRT очень схожа с той, что была представлена в Intel TBB. Наша работа с Microsoft заключается в том, чтобы интерфейсты параллельных алгоритмов TBB были совместимы с интерфейсами Parallel Patterns Library (PPL). Это делается для того, чтобы пользователь мог без проблем с линковаться с TBB-шным рантаймом, и наслаждаться улучшенной производительностью :)
При линковке с TBB run-time программист может пользоваться гораздо более широким набором функционала, который будет является надстройкой над планировщиком Microsoft, и который, например, позволит пользоваться не только дополнительными параллельными алгоритмами, но и эффективными аллокаторами.
>Что из Интеловской параллельной студии войдёт в МС студю 2010?
Если вы имеете ввиду в поставку от Microsoft, то ничего. Parallel Studio останется plug-in’ом в MSVS2010, который надо приобретать отдельно, и не у MSFT.
>Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Она там окажется вместе и интеловским компилятором, который в Parallel Studio является основным компонентом в инструменте Parallel Composer
Вообще со структурой Parallel Studio можно ознакомиться в моей обзорной статье на русском языке software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit/
>Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Обычно такие данные предоставляются только организациям, подписавшим NDA.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
При линковке с TBB run-time программист может пользоваться гораздо более широким набором функционала, который будет является надстройкой над планировщиком Microsoft, и который, например, позволит пользоваться не только дополнительными параллельными алгоритмами, но и эффективными аллокаторами.
>Что из Интеловской параллельной студии войдёт в МС студю 2010?
Если вы имеете ввиду в поставку от Microsoft, то ничего. Parallel Studio останется plug-in’ом в MSVS2010, который надо приобретать отдельно, и не у MSFT.
>Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Она там окажется вместе и интеловским компилятором, который в Parallel Studio является основным компонентом в инструменте Parallel Composer
Вообще со структурой Parallel Studio можно ознакомиться в моей обзорной статье на русском языке software.intel.com/ru-ru/articles/intel-parallel-studio-parallelism-toolkit/
>Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Обычно такие данные предоставляются только организациям, подписавшим NDA.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
0
А про manageability (Intel AMT) будет?
+1
Как известно, помимо параллелизма на CPU и Intel Parallel Studio, у программистов есть еще возможность эффективно использовать плюсы параллельной архитектуры GPU с помощью таких продуктов, как CUDA от NVIDIA. Так что мой вопрос таков: а есть ли возможность одновременного использования параллельных вычислений как на CPU, так и на GPU (с помощью Intel Parallel Studio и CUDA)? И если есть, то будет ли такой подход эффективен или использование их по отдельности выгоднее?
0
Пока мы рассматриваем Intel Parallel Studio только рак средство разработки для CPU. Сечас пока мне сложно говорить от GPGPU в контексте интеловских инструментов — очень много планов, очень много секретов, и очень все туманно. Кроме того, вы задали очень правильный вопрос по поводу эффективности. Думаю, ответа на него пока нет не у кого. Возможно, мои коллеги что-то скажут в течение недели, посвященной графике и лараби.
0
Спрошу не для конкурса (не по теме), а для себя. С вашей точки зрения, почему Intel занимается только какими-то составляющими (частями) как на уровне ПО так и на уровне железа. Разве у Intel нет ресурсов или потенциала конкурировать с компаниями предоставляющими конечный продукт (к примеру с тем же Apple, со своими mac'ами)?
0
Извините, что не сразу отвечаю (я отслеживал вопросы только на данной неделе).
Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.
Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.
0
Sign up to leave a comment.
Вторая неделя с компанией Intel