Вторая неделя с компанией Intel
Всем привет! Продолжаем увлекательное путешествие «5 недель с компанией Intel» — тема второй дискуссии — инструменты разработки Intel, разработка и оптимизация параллельных приложений, в частности — Intel Parallel Studio.
Сегодня у нас в гостях Владимир Цымбал — работая в компании с 2005 года, он занимается поддержкой пользователей инструментов разработки параллельных приложений Intel.
Прежде всего хочется поздравить хабрапользователя SSE — на первой неделе дискуссий его вопрос больше всех понравился представителям компании Intel. За свое любопытство он получит приз — комплект «Мышка и клавиатура». Приз можно будет получить после пятой недели дискуссий, на личной встрече в компании. Кстати, интересное совпадение! ;)
Участвуйте в дискуссии — глядишь, и Вам повезет! Клавиатуры и нетбуки у нас еще есть ;)
Ну а теперь интервью:
Владимир закончил Таганрогский государственный радиотехнический университет в 1996-м году по специальности «радиотехника»; там же защитил кандидатскую диссертацию. Преподавал в университете, работал научным сотрудником в КБ, разрабатывал аппаратные графические ускорители и участвовал в разработке программно-аппаратных комплексов для медицинской диагностики как старший инженер-программист.
В Intel с 2005 года, участвовал в разработке VTune Performance Analyzer, а сейчас работает в Intel Performance Analysis and Threading Lab, где занимается поддержкой пользователей инструментов разработки параллельны приложений Intel и, в частности, Parallel Studio.
Честно говоря, я с самого начала хотел оказаться в Intel. Года два отслеживал предложения о вакансиях и, когда подходящая мне вакансия открылась, пришел на собеседование.
Приложения самые разные — скажем, клиентские приложения из различных областей, например, финансовой. Или взять здравоохранение — это приложения, работающие с медицинским оборудованием, а это и обработка сигналов, и алгоритмы подсчета различных характеристик исследуемых сигналов, и визуализация данных. Таким приложениям всегда нехватает производительности компьютеров. Могут быть и серверные приложения —программы, обрабатывающие запросы клиентских машин и работающие по умолчанию в многопоточном и многопроцессорном режиме. Для них максимальное использование всех имеющихся в системе микропроцессоров и ядер является критичным. Их разработчики стараются на все 100% использовать имеющиеся вычислительные ресурсы — для этих людей это вопрос конкурентного преимущества на рынке, так что они ищут инструменты для того, чтобы улучшить свои серверные приложения в плане многопоточности и многопроцессорности.
Сложные случаи — их, на самом деле, не так много, но они происходят довольно часто. Как правило, это те случаи, когда race condition, то есть конкурентный доступ к одним и тем же данным, просто не заметен программисту. Он не видит эффект от ошибки. Она возникает, но программист об этом узнает слишком поздно — в худшем случае, когда приложение уже у заказчика. Коварность этих ошибок состоит в том, что они зависимы от среды, в которой работает программа. Например, приложение установили на более быструю машину, и результаты работы программы изменились, хотя на тестовой машине таких эффектов не было обнаружено. Поэтому разработчики заинтересованы в таких инструментах, которые бы обнаруживали такого рода ошибки вне зависимости от среды работы приложений. Эти ошибки случаются всегда, постоянно, от них никто не застрахован, поэтому такие инструменты, как Intel Parallel Studio, очень популярны и являются необходимой частью набора любого программиста, занимающегося параллельным программированием.
Мы не говорим о преимуществе над инструментами Microsoft, мы дополняем возможности Visual Studio обнаруживать ошибки работы с памятью и ошибки многопоточности, делая ее полноценным отладчиком параллельных программ — это первое; второе — мы помогаем сразу создавать параллельные приложения более эффективными. В каком смысле? Дело в том, что недостаточно просто использовать потоки при разработке приложений. Нужно знать, насколько эффективно эти потоки используют микропроцессорные ядра. Microsoft Visual Studio не содержит инструментов, позволяющих отслеживать временные характеристики исполнения программы, чтобы оценить насколько приложение активно использует все микропроцессоры, находящиеся в системе, и в какой именно функции программы многопроточность реализована неэффективно. Мы дополняем Visual Studio таким функционалом профилировки многопоточных приложений.
Это первая область моих научных интересов, еще со времени работы над моей диссертацией вместе с научным руководителем. Если коротко, то я занимался разработкой признаков для распознавания многомерных сигналов, специализируясь в медицинской области. Мы пытались понять, каким образом можно выделить некоторые специфические признаки из сигналов энцефалографии, по которым можно было бы распознавать различные патологии. Эта тема продолжает меня интересовать, сейчас я довольно часто сталкиваюсь с компаниями, которые занимаются обработкой сигналов и изображений, и имеют свои собственные разработки в области распознавания образов. Я продолжаю сотрудничать со своим научным руководителем в этой области. Это не имеет никакого отношения к моей непосредственной работе, но эта тема находится в области моих интересов.
Да — вне работы я занимаюсь научной деятельностью.
Intel к любой научной деятельности относится очень хорошо, поощряет научные публикации и участие в конференциях.
Знаете, когда занимаешься научной деятельностью, важно понять, чем конкретно ты занимаешься — фундаментальными научными разработками, или прикладными. Я занимаюсь разработкой базовых методик и алгоритмов, а их применение — область, в которой работают конкретные компании, занимающиеся разработкой диагностического оборудования. Их можно воплотить в программном виде и применять в различных областях.
Верно.
Да, я сертифицированный дайвер, и регулярно погружаюсь как в России, так и за рубежом.
Дело тут не во всесторонности — дайвингом я занимаюсь, чтобы голова не вскипела от всех научных и рабочих моментов (смеется). Иногда нужно чем-то заняться, чтобы отвлечься от работы — экстремальный отдых как раз очень хорошо от нее отвлекает.
Не стесняйтесь участвовать в обсуждении, задавайте вопросы!
Сегодня у нас в гостях Владимир Цымбал — работая в компании с 2005 года, он занимается поддержкой пользователей инструментов разработки параллельных приложений Intel.
Прежде всего хочется поздравить хабрапользователя SSE — на первой неделе дискуссий его вопрос больше всех понравился представителям компании Intel. За свое любопытство он получит приз — комплект «Мышка и клавиатура». Приз можно будет получить после пятой недели дискуссий, на личной встрече в компании. Кстати, интересное совпадение! ;)
Участвуйте в дискуссии — глядишь, и Вам повезет! Клавиатуры и нетбуки у нас еще есть ;)
Ну а теперь интервью:
Владимир закончил Таганрогский государственный радиотехнический университет в 1996-м году по специальности «радиотехника»; там же защитил кандидатскую диссертацию. Преподавал в университете, работал научным сотрудником в КБ, разрабатывал аппаратные графические ускорители и участвовал в разработке программно-аппаратных комплексов для медицинской диагностики как старший инженер-программист.
В Intel с 2005 года, участвовал в разработке VTune Performance Analyzer, а сейчас работает в Intel Performance Analysis and Threading Lab, где занимается поддержкой пользователей инструментов разработки параллельны приложений Intel и, в частности, Parallel Studio.
Как вы попали в Intel?
Честно говоря, я с самого начала хотел оказаться в Intel. Года два отслеживал предложения о вакансиях и, когда подходящая мне вакансия открылась, пришел на собеседование.
К вам обращаются люди, разрабатывающие параллельные приложения. Какого рода эти приложения?
Приложения самые разные — скажем, клиентские приложения из различных областей, например, финансовой. Или взять здравоохранение — это приложения, работающие с медицинским оборудованием, а это и обработка сигналов, и алгоритмы подсчета различных характеристик исследуемых сигналов, и визуализация данных. Таким приложениям всегда нехватает производительности компьютеров. Могут быть и серверные приложения —программы, обрабатывающие запросы клиентских машин и работающие по умолчанию в многопоточном и многопроцессорном режиме. Для них максимальное использование всех имеющихся в системе микропроцессоров и ядер является критичным. Их разработчики стараются на все 100% использовать имеющиеся вычислительные ресурсы — для этих людей это вопрос конкурентного преимущества на рынке, так что они ищут инструменты для того, чтобы улучшить свои серверные приложения в плане многопоточности и многопроцессорности.
Если взять такую поддающуюся распараллеливанию задачу, как архитектурная визуализация, то дискретными задачами становятся процессы визуализации отдельных кадров. Эти процессы друг с другом никак не связаны, не конкурируют — их можно считать в любом порядке. А есть другие приложения, где возникает race condition — это когда одна часть вычислений использует другую, и требует данных от другого процесса. Какие сложные случаи такого параллелизма бывают?
Сложные случаи — их, на самом деле, не так много, но они происходят довольно часто. Как правило, это те случаи, когда race condition, то есть конкурентный доступ к одним и тем же данным, просто не заметен программисту. Он не видит эффект от ошибки. Она возникает, но программист об этом узнает слишком поздно — в худшем случае, когда приложение уже у заказчика. Коварность этих ошибок состоит в том, что они зависимы от среды, в которой работает программа. Например, приложение установили на более быструю машину, и результаты работы программы изменились, хотя на тестовой машине таких эффектов не было обнаружено. Поэтому разработчики заинтересованы в таких инструментах, которые бы обнаруживали такого рода ошибки вне зависимости от среды работы приложений. Эти ошибки случаются всегда, постоянно, от них никто не застрахован, поэтому такие инструменты, как Intel Parallel Studio, очень популярны и являются необходимой частью набора любого программиста, занимающегося параллельным программированием.
Скажите, а в чем преимущество Parallel Studio над инструментарием Microsoft?
Мы не говорим о преимуществе над инструментами Microsoft, мы дополняем возможности Visual Studio обнаруживать ошибки работы с памятью и ошибки многопоточности, делая ее полноценным отладчиком параллельных программ — это первое; второе — мы помогаем сразу создавать параллельные приложения более эффективными. В каком смысле? Дело в том, что недостаточно просто использовать потоки при разработке приложений. Нужно знать, насколько эффективно эти потоки используют микропроцессорные ядра. Microsoft Visual Studio не содержит инструментов, позволяющих отслеживать временные характеристики исполнения программы, чтобы оценить насколько приложение активно использует все микропроцессоры, находящиеся в системе, и в какой именно функции программы многопроточность реализована неэффективно. Мы дополняем Visual Studio таким функционалом профилировки многопоточных приложений.
Ваша область интересов — алгоритмы распознавания сигналов и обработка изображений. Расскажите подробнее?
Это первая область моих научных интересов, еще со времени работы над моей диссертацией вместе с научным руководителем. Если коротко, то я занимался разработкой признаков для распознавания многомерных сигналов, специализируясь в медицинской области. Мы пытались понять, каким образом можно выделить некоторые специфические признаки из сигналов энцефалографии, по которым можно было бы распознавать различные патологии. Эта тема продолжает меня интересовать, сейчас я довольно часто сталкиваюсь с компаниями, которые занимаются обработкой сигналов и изображений, и имеют свои собственные разработки в области распознавания образов. Я продолжаю сотрудничать со своим научным руководителем в этой области. Это не имеет никакого отношения к моей непосредственной работе, но эта тема находится в области моих интересов.
То есть у вас есть время и для работы, и для науки?
Да — вне работы я занимаюсь научной деятельностью.
А как Intel к этому относится?
Intel к любой научной деятельности относится очень хорошо, поощряет научные публикации и участие в конференциях.
Алгоритмы, которыми вы занимаетесь — они где-то используются?
Знаете, когда занимаешься научной деятельностью, важно понять, чем конкретно ты занимаешься — фундаментальными научными разработками, или прикладными. Я занимаюсь разработкой базовых методик и алгоритмов, а их применение — область, в которой работают конкретные компании, занимающиеся разработкой диагностического оборудования. Их можно воплотить в программном виде и применять в различных областях.
Но у вас есть и хобби — дайвинг.
Верно.
Есть сертификация?
Да, я сертифицированный дайвер, и регулярно погружаюсь как в России, так и за рубежом.
Выходит, вы всесторонне развитая личность — сочетаете и научную деятельность, и полезный труд, и экстремальные виды спорта?
Дело тут не во всесторонности — дайвингом я занимаюсь, чтобы голова не вскипела от всех научных и рабочих моментов (смеется). Иногда нужно чем-то заняться, чтобы отвлечься от работы — экстремальный отдых как раз очень хорошо от нее отвлекает.
Не стесняйтесь участвовать в обсуждении, задавайте вопросы!
комментарии (46)
Вопрос как к специалисту поддержи Intel Parallel Studio — насколько эффективно использование данного продукта для многопоточного профилирования приложений на платформе .net? Есть ли у ваших клиентов успешный опыт подобной работы; или IPS наиболее применим только для native (c/c++)? Понятно, что при помощи sos и windbg можно отлаживать и .net, но хотелось бы узнать про .net-specific возможности (если есть).
Спасибо.
P.S. Я тоже окончил ТРТУ, факультет РТФ ;)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
Что касается клиентского ПО, то тут немного сложнее, хотя бы потому, что клиентского ПО очень много. Действительно, последовательные программы разрабатывать много проще, и часто производители ПО просто «не заморачиваются» с параллелизмом. Однако, если взять отдельные сегменты приложений, где скорость работы программы является ее конкурентным преимуществом, то тут дела обстоят как раз наоборот – редкая программа не использует все имеющиеся ядра. К примеру, все современные кодеки исключительно оптимизированы для выполнения в одном потоке, и вдобавок еще и распараллелены. Кому, скажем, нужен кодек 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 архитектуре)
Так как вы занимаетесь (занимались) вопросами производительности, хочу задать очередной свой вопрос про будущее.
Как скоро 64-битные системы выйдут на первый план, скоро ли они вытеснят 32-битную архитектуру?
И вопрос-оффтопик. Какое у вас распределение ОС по компании (для личного использования)? Большинство использует Windows? И тот же самый вопрос касательно компьютеров для рабочего использования. Преимущественно работаете на Windows или тестируете что-то под Linux, MacOS?
В связи со всем этим процессоры поддерживают 32-битный режим, не смотря на то что они уже 64-битные по своей архитектуре. И продлится это, скорее всего, довольно долго, и в основном во имя backward compatibility.
На моем рабочем лэптопе стоит и Windows XP и Linux Fedora, в основном из-за того, что приходится бывать у клиентов с разными специализациями. Программисты, естественно, тестируют продукты на всевозможных ОС (все виды Windows, c десяток Linux-дистрибутивов, и внутри каждого по три версии, и конечно же MacOS, куда же без нее :)), так как мы разрабатываем кросс-платформенные продукты. Что иметь в качестве рабочей среды, каждый решает сам, что ему удобнее или в чем больше приходится разбираться, с тем и работает. Бухгалтерия и Human Resources работают, естественно, под Windows :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
Не входит ли в планы компании Intel создание упрощенных (с урезанным функционалом), бесплатных версий, таких продуктов как VTune и Intel Parallel Studio?
Что касается бесплатных версий. Дело в том, что 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.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
Понятно, что производительность алгоритма будет зависеть не только от тактовой частоты процессора, но и от конфигурации системы, текущей загрузки. Но тут можно делать оговорку — что результаты даются на систему с другой частотой процессора и прочих равных.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
Спасибо Вам за содержательные ответы.
Обычно так и делают. Это называется стресс-тесты.
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
Не совсем. В виде MPI Intel редлагает стандартный интерфейс. Под стандартным понимается, что он принят в индустрии «де-факто» как стандарт, и вопрос портирования состоит только в отладке спортрованного проекта. Кроме того, под «стандртным интерфейсом» кроется понятие совместимости.., с планировщиками очердей, сетевыми средами, и т.д.
Поэтому собрать свой велосипед под свои задачи из стандартных комплектующих иногда проще и дешевле, чем получить лишь красивый и бестящий звонок от модели, которая не ездит по большинству имеющихся дорог.
В этом его приемущество. Т.е. это зависит от того, с какой стороны на этот вопрос смотреть.
Ваша академическая задача не отражает всего моножество задач, которые решаются с помощью распределенных вычислений. И если для ее решения имеются какие-то более удобные высокоуровневые средства, помогающие ее решить в сотню строк кода, то это свсем не означает, что и другие задачи решться так же просто.
Я слышал также мнение апологетов .Net и Java, что язык С++ плох тем, что перекладывает сложности программирования, обусловлнные архитектурой вычислительной системы, на плечи программистов. :) По-моему это просто вопрос компетенции и опыта, не более того.
Дело в том, что принимаемый нами уровень абстракции зависит от эффективности решеия задачи на нем. Если раньше, например, кодеки и фильтры писали исключительно на ассемблере, то теперь, с хорошим оптимизирующим компилятором С/C++ в этом нет особой необходимости.
В кластерных приложениях «узким местом» производительности чаще всего является интерфейс коммуникации, а не производительность узлов, поэтому разрботчик хочет иметь в своем распоряжении все рычаги для оптимизции взаимодействия между процессами, тоесть управлять интерфейсами котрые стоят либо непосредственно над транспортным уовнем, либо близко к нему. Если же интерфейсы будут покрыты какими либо аморфными абстракциями, то ни о какой оптимизации и речи не может быть. Понятно, что кластерные приложения, это те задачи, которым не хватает производительности одного PC, поэтму в угоду возможности оптимизации в жертву приносится некоторое удобство пользования абстракциями.
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
Расскажите об этом как можно подробнее? (Причём не как маркетологи на сайте пишут, а как программист программисту)
Вот возможные пункты: (Но это что я могу предположить, а вы то знаете особенности наверняка)
Что именно Интел туда поставляет, что и как вы помогли сделать Микрософту?
Что из Интеловской параллельной студии войдёт в МС студю 2010?
Продвинутая оптимизация Интеловского компилятора хоть краем туда войдёт?
Какие новые, и сейчас не известные вашим-пользователям-программистам возможности туда войдут?
Ну, и напоследок:
Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Заранее, Спасибо!
При линковке с 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.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
Я думаю, что то, чем занимается компания является следствием нескольких причин: тем, что исторически корпорация производила все последние годы, ситуацией на рынке, в конце концов, размером штата сотрудников. Чтобы вырваться на рынок с конечными продуктами, необходимо быть не хуже конкурентов, причем сразу. А для этого у больших компаний, как ни странно, нет ресурсов.
Поэтому с хорошими идеями и конечной продукцией выходят маленькие компании, которые потом выкупаются монстрами вместе со штатом сотрудников.