Комментарии 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. Я тоже окончил ТРТУ, факультет РТФ ;)
Вопрос засчитан ;) А я окончил МЭИ, факультет ИРЭ ЭТФ ;)
С ответами на вопросы, как и запланировано, будем разбираться в среду. Но тут не могу не поприветстовать коллегу по альма матер :)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
Intel Parallel Studio предназначена для работы только с кодом, написанным на C/C++ (native).
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
Уж как-то «воды» много, видимо расчет на вопросы от хабражителей. Требую мяса и крови! :)
Собственно, да ) Вы задаете любые вопросы, а компания Intel отвечает на них. Самым интересным и активным участнникам — всякие приятности.
мне вот интересно вообще, насколько активно сейчас решается вопрос с распараллеливанием нагрузки на ядра 2/3/4-ядерных процессоров в серверном/домашнем ПО? ибо сколько я работаю, замечаю то, что в основном грузится только первое ядро (особенно заметно это на Ubuntu, там первое ядро загоняется до 70% в то время, как второе всего на 5-10%)
В серверном ПО вопрос распараллеливания рассматривался с самого начала существования многопроцессорных систем. В данный момент идет активная разработка серверных приложений использующих многопотоковость. Однако и приложения, основанные на инфраструктуре межпроцессного взаимодействия (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)
Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
а вообще, каково в плане финансов/ресурсоемкости, ПО под какие системы проще и дешевле писать, обслуживать и какое вообще будет более эффективным при работе на машине с необходимостью проводить логические операции, или, предположим, рендеринг неслабой такой трехмерной сцены?
Ой, что-то я, боюсь, не понял вопроса :) Попробую ответить, как понял, а вы меня поправите, если что.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
Да, вероятно не поняли :) Я имел ввиду, под какие системы будет дешевле и эффективнее по ресурсозатратам написать программное обеспечение: под многоядерные процессоры, или же на многопроцессорные, но с более мощными одноядерными процессорами
или же на многопроцессорные, но с более мощными одноядерными процессорами
Таких систем не бывает (по крайней мере, если речь идет об х86 архитектуре)
Владимир — почти прав, сейчас многопроцессорная система одноядерных процессоров IA32-скорее исключение, чем правило. Но тенденция — к многопроцессорным многоядерным системам. Так что это придется учитывать в разработке.
Здравствуйте, Владимир :)
Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
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 :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
Как скоро Intel Parallel Advisor войдет в состав Intel Parallel Studio?
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?
Хороший вопрос. Я не знаю, как скоро. Возможно после того, как произойдет осознание его места и 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 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.
Спасибо Вам за подробный и развернутый ответ.
У меня есть предложение для VTune. Добавить возможность прогнозирования (разумеется примерного) времени выполнения анализируемого кода на других процессорах. Например, с другой тактовой частотой, количеством ядер и т.д. Если это, конечно, возможно и вяжется с идеологией VTune.
У меня есть предложение для VTune. Добавить возможность прогнозирования (разумеется примерного) времени выполнения анализируемого кода на других процессорах. Например, с другой тактовой частотой, количеством ядер и т.д. Если это, конечно, возможно и вяжется с идеологией VTune.
Отличная идея. Владимир, сорри что прерываю твой бенефис :) С другим количеством ядер вряд ли получится в Vtune, но с другой частотой и микроархитектурой как часть «Generate advice» может лечь хорошо. Прогнал пользователь на CVT 2Ghz, а advicer говорит — на NHM 3Ghz было бы столько то.
Идея на столко же отличная, на сколько и нереализуемая. Про частоту я уже ответил ниже. А вот по мкроархитектуре не так все просто. Advice генерируется для всей программы вцелом, а вся программа исполняется не только внутренними блоками процессора, ведь еще задействована память, система ввода-вывода (сеть, диски, ит.д.). Какой тут можно дать прогноз по производительности программы, если мы рассматриваем только одну компоненту системы, а об остальных и понятия не имеем?
Такая возможность уже есть в Parallel Amplifier ( software.intel.com/ru-ru/articles/intel-parallel-amplifier, раздел Concurrency-анализ). Запустив Concurrency Analysis, мы получаем диаграмму масштабируемости программы вцелом на процессоре, в которм она исполнялась. Для почти идеально масштабируемого приложния ее пик находится в точке N (как дельта-функция), равной количеству ядер в системе. В реале же, диаграмма будет распределена по количеству ядер каким-либо образом, и это распределение можно, с некоторым приближеим, экстраполировать, чтобы понять, как программа будет вести себя, исполняясь в процессоре с бОльшим кол-вом ядер.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
Меня в данном контексте, если честно, больше интересует не столько прогноз повышения производительности с увеличением тактовой частоты, сколько наоборот — «деградация» с понижением частоты. Для того чтобы можно было получить пессимистический прогноз.
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных.
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных.
Если ваши задачи настолько специфичны, что для них важен пессимистичный прогноз, то лучше использовать натуральный эксперимент.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
С интересом прочитал вашу статью по MC# ;)
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
НЛО прилетело и опубликовало эту надпись здесь
Ну т.е. Intel предлагает каждый раз изобретать свои велосипеды? ;)
Не совсем. В виде MPI Intel редлагает стандартный интерфейс. Под стандартным понимается, что он принят в индустрии «де-факто» как стандарт, и вопрос портирования состоит только в отладке спортрованного проекта. Кроме того, под «стандртным интерфейсом» кроется понятие совместимости.., с планировщиками очердей, сетевыми средами, и т.д.
Поэтому собрать свой велосипед под свои задачи из стандартных комплектующих иногда проще и дешевле, чем получить лишь красивый и бестящий звонок от модели, которая не ездит по большинству имеющихся дорог.
Однако, беда в том, что MPI слишком низкоуровневый!
В этом его приемущество. Т.е. это зависит от того, с какой стороны на этот вопрос смотреть.
Я вот не знаю как с помощью разумных временных затрат решать подобный тип задач на MPI, т.к. примитивные MPI-ные барьеры просто не предназначены для этого.
Ваша академическая задача не отражает всего моножество задач, которые решаются с помощью распределенных вычислений. И если для ее решения имеются какие-то более удобные высокоуровневые средства, помогающие ее решить в сотню строк кода, то это свсем не означает, что и другие задачи решться так же просто.
Любая более-менее нестандартная и нетривиальная задача на распараллеливание решается в MPI с большим треском и все трудности перекладываются на прикладных программистов…
Я слышал также мнение апологетов .Net и Java, что язык С++ плох тем, что перекладывает сложности программирования, обусловлнные архитектурой вычислительной системы, на плечи программистов. :) По-моему это просто вопрос компетенции и опыта, не более того.
НЛО прилетело и опубликовало эту надпись здесь
Я знал, что вы приведте контраргумент с ассемблером :)
Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.
Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.
Инстументы?
Расскажите по-подробнее о применении параллельных приложений в медицине. Просто я недавно закончил бауманку по специальности инж. дело в мед. технике, и мне было бы ужасно интересно, какие именно задачи можно решать с помощью современных параллельных вычислений. В родной альма-матер об этом и близко ничего не было)
Подходы к написанию параллельных приложений в медицине почти ни чем не отличаются от подходов к параллельным программам в других отраслях. Тут нужно говорить о задачах, которые решаются в медицинской тематике и к которым применимо распараллеливание. Наиболее сложные и алгоритмически нагруженные программы пишутся, как правило, для применеия в диагностических целях с использованием обработки большого количества объективных данных, как например в томографии, радиографии или рентгенографии. А там стоит несколько основных этапных задач:
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
Интел с Микрософтом совместно работаю над Микрософтской параллельной средой выполнения (Microsoft Concurrency Runtime) и она будет встроена в Визуальную студию 2010.
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)
Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?
Что из Интеловской параллельной студии войдёт в МС студю 2010?
Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Заранее, Спасибо!
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)
Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?
Что из Интеловской параллельной студии войдёт в МС студю 2010?
Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Заранее, Спасибо!
Да, действительно, 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.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
А про manageability (Intel AMT) будет?
Как известно, помимо параллелизма на CPU и Intel Parallel Studio, у программистов есть еще возможность эффективно использовать плюсы параллельной архитектуры GPU с помощью таких продуктов, как CUDA от NVIDIA. Так что мой вопрос таков: а есть ли возможность одновременного использования параллельных вычислений как на CPU, так и на GPU (с помощью Intel Parallel Studio и CUDA)? И если есть, то будет ли такой подход эффективен или использование их по отдельности выгоднее?
Пока мы рассматриваем Intel Parallel Studio только рак средство разработки для CPU. Сечас пока мне сложно говорить от GPGPU в контексте интеловских инструментов — очень много планов, очень много секретов, и очень все туманно. Кроме того, вы задали очень правильный вопрос по поводу эффективности. Думаю, ответа на него пока нет не у кого. Возможно, мои коллеги что-то скажут в течение недели, посвященной графике и лараби.
Спрошу не для конкурса (не по теме), а для себя. С вашей точки зрения, почему Intel занимается только какими-то составляющими (частями) как на уровне ПО так и на уровне железа. Разве у Intel нет ресурсов или потенциала конкурировать с компаниями предоставляющими конечный продукт (к примеру с тем же Apple, со своими mac'ами)?
Извините, что не сразу отвечаю (я отслеживал вопросы только на данной неделе).
Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.
Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вторая неделя с компанией Intel