Если ваши задачи настолько специфичны, что для них важен пессимистичный прогноз, то лучше использовать натуральный эксперимент.
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
Пока мы рассматриваем Intel Parallel Studio только рак средство разработки для CPU. Сечас пока мне сложно говорить от GPGPU в контексте интеловских инструментов — очень много планов, очень много секретов, и очень все туманно. Кроме того, вы задали очень правильный вопрос по поводу эффективности. Думаю, ответа на него пока нет не у кого. Возможно, мои коллеги что-то скажут в течение недели, посвященной графике и лараби.
Идея на столко же отличная, на сколько и нереализуемая. Про частоту я уже ответил ниже. А вот по мкроархитектуре не так все просто. Advice генерируется для всей программы вцелом, а вся программа исполняется не только внутренними блоками процессора, ведь еще задействована память, система ввода-вывода (сеть, диски, ит.д.). Какой тут можно дать прогноз по производительности программы, если мы рассматриваем только одну компоненту системы, а об остальных и понятия не имеем?
Такая возможность уже есть в Parallel Amplifier ( software.intel.com/ru-ru/articles/intel-parallel-amplifier, раздел Concurrency-анализ). Запустив Concurrency Analysis, мы получаем диаграмму масштабируемости программы вцелом на процессоре, в которм она исполнялась. Для почти идеально масштабируемого приложния ее пик находится в точке N (как дельта-функция), равной количеству ядер в системе. В реале же, диаграмма будет распределена по количеству ядер каким-либо образом, и это распределение можно, с некоторым приближеим, экстраполировать, чтобы понять, как программа будет вести себя, исполняясь в процессоре с бОльшим кол-вом ядер.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
Да, действительно, 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.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
Подходы к написанию параллельных приложений в медицине почти ни чем не отличаются от подходов к параллельным программам в других отраслях. Тут нужно говорить о задачах, которые решаются в медицинской тематике и к которым применимо распараллеливание. Наиболее сложные и алгоритмически нагруженные программы пишутся, как правило, для применеия в диагностических целях с использованием обработки большого количества объективных данных, как например в томографии, радиографии или рентгенографии. А там стоит несколько основных этапных задач:
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
С интересом прочитал вашу статью по MC# ;)
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
Хороший вопрос. Я не знаю, как скоро. Возможно после того, как произойдет осознание его места и 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 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.
Ой, что-то я, боюсь, не понял вопроса :) Попробую ответить, как понял, а вы меня поправите, если что.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
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 :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
В серверном ПО вопрос распараллеливания рассматривался с самого начала существования многопроцессорных систем. В данный момент идет активная разработка серверных приложений использующих многопотоковость. Однако и приложения, основанные на инфраструктуре межпроцессного взаимодействия (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)
Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
Intel Parallel Studio предназначена для работы только с кодом, написанным на C/C++ (native).
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
С ответами на вопросы, как и запланировано, будем разбираться в среду. Но тут не могу не поприветстовать коллегу по альма матер :)
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)
В некоторых тулах (Shark) есть возможность оценить производительность с изменением размера кэша последнего уровня (LLC) процессора (при фиксированно частоте). Однако, эта оценка дается относительно определенного участка кода, что логично. Что-то пдобное используется и в экспериментальных версиях нашей PTU. Оценивать же производительность всего приложения, зная только параметры процессора — бесперспективная задача. Ибо обобщенная производительнось уредненного по больнице приложения зависит от процессора процентов на 20, а по некоторым оценкам вообще на 5. А «прочих равных условий» в смысле конфиигураций систем в жизни не бывает.
Что же касается тактовой частоты, то тут по-прежнему все просто: производительность большинства программ растет пропорционально росту тактовой частоты. Вот только значительного роста последней можете уже не ожидать :)
При линковке с 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.
>Какие планы насчёт включения массовых вычислений с помощью графических адаптеров?
Я не силен в этом вопросе. Наверное, лучше спросить об этом Вику Жислину, когда она будет вести конференцию по графическим адаптерам.
— Регистрация данных
— Снижение шума/нелинейная фильтрация
— Выделение признаков/распознавание образов
— Восстановление изображений
Каждый из этих этапов выполняется в конвейерном режиме, то есть все задачи выполняются одновременно, но над разными во времени участками данных. В зависимости от объема информации параллельность может быть как на уровне одного персонального компьютера, так и на уровне дата-центров. Внутри каждого этапа есть простор для декомпозиции задач по данным (разные участки в пространстве) и одновременной их обработки. Надо сказать, что как раз обработка 2D/3D изображений, а также обработка одномерных и многомерных сигналов, является передним форонтом, где применяются самые эффективные и новые методы распараллеливания. Благодаря близко к линейному приросту производительности от количества исполняемых потоков, такие системы наибольшим образом выигрывают от многоядерности.
Надо сказать, что что-то более высокоуровневое, чем MPI, обычно пишут сами разработчики систем. MPI, как и сокеты, RDMA, Corba, COM, etc. – это всего лишь интерфейсы, в которых есть синхронные и асинхронные сообщения. А на более высоком уровне абстракции можно реализовать каналы, приоритезацию (я точно не знаю, но врядли она на транспортном уровне в .Net), объекты сообщений, и т.д. У вас правильно было замечено, что интерфейсная среда должна предоставлять возможности балансировки нагрузки и анализа перегрузки/ошибок. Intel MPI их предоставляет. Возможно MC# намного облегчает разработку систем распределенных вычислений, предоставляя уже готовые абстракции. Однако они не так уж сложны и их можно реализовать на любых интерфейсах, вопрос только в опыте и привязанностях.
Что касается бесплатных версий. Дело в том, что 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 дней бесплатного пользования никто не отменял.
В этой иерархии ценообразования нет особого места для совсем бесплатных версий. Что-то там урезать в ПО, потом защищать от кракинга, чтобы потом раздавать это бесплатно, мы считаем нецелесообразным, хотябы потому, что на это необходимо тратить драгоценные человекочасы.
Просто и дешево пишутся только программы, решающие никому не нужные задачи. Остальные задачи либо уже решены, либо требуют вложения ресурсов в их решение. Количество естественно ресурсов зависит от сложности, и возможности свести задачу к уже решенной.
Что же касается эффективности параллельных программ, то это зависит от математической структуры алгоритмов — есть непараллелящиеся, трудно поддающиеся распараллеливанию и соответственно легко распараллеливаемые алгоритмы. Рендеринг сам по себе — довольно хорошо поддающаяся распараллеливанию задача.
В связи со всем этим процессоры поддерживают 32-битный режим, не смотря на то что они уже 64-битные по своей архитектуре. И продлится это, скорее всего, довольно долго, и в основном во имя backward compatibility.
На моем рабочем лэптопе стоит и Windows XP и Linux Fedora, в основном из-за того, что приходится бывать у клиентов с разными специализациями. Программисты, естественно, тестируют продукты на всевозможных ОС (все виды Windows, c десяток Linux-дистрибутивов, и внутри каждого по три версии, и конечно же MacOS, куда же без нее :)), так как мы разрабатываем кросс-платформенные продукты. Что иметь в качестве рабочей среды, каждый решает сам, что ему удобнее или в чем больше приходится разбираться, с тем и работает. Бухгалтерия и Human Resources работают, естественно, под Windows :)
Операционная система домашнего компьютера определяется, наверное, игрушками, в которые играется владелец :) Лично у меня домашнего нет (правда это не значит, что я играюсь на работе :))
Что касается клиентского ПО, то тут немного сложнее, хотя бы потому, что клиентского ПО очень много. Действительно, последовательные программы разрабатывать много проще, и часто производители ПО просто «не заморачиваются» с параллелизмом. Однако, если взять отдельные сегменты приложений, где скорость работы программы является ее конкурентным преимуществом, то тут дела обстоят как раз наоборот – редкая программа не использует все имеющиеся ядра. К примеру, все современные кодеки исключительно оптимизированы для выполнения в одном потоке, и вдобавок еще и распараллелены. Кому, скажем, нужен кодек 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)
Несколько особняком здесь стоят игры. С одной стороны, польователи рассчитывают на серьезный прирост производительности в игрушках на мультиядерной платформе, а с другой, игровые движки разрабатывались довольно давно, и заточены исключительно под однопотоковое исполнение, и переделать их очень сложно из-за собенностей структуры игрового ПО – проще переписать заново. Так вот заново написанные игры и используют многопоточность на столько, на сколько это возможно.
Не раскрывая особых секретов, скажу, что мы готовим к выпуску HE (“Hi-End”) версию инструментов, которые называться будут скорее всего по-другому, и будут иметь возможности анализа .Net-приложений. Первую бета-версию пользователи предположительно увидят только в следующем году.
Искренне рад вас видеть здесь. Этм летом был в Таганроге, прошелся по корпусам. Многое изменилось с тех пор, пропускная система, вокруг полно кафешек, беляшных… Что больше вего поразило, так это то, что в 5-й общаге поставили стеклопакеты, почти везде… Прогресс однако :)
Моя родная кафедра ТОР. Многие профессора так там и работают. Сам я работал потом на каф. РПрУ и ТВ. К сожалению, времни было не много, и зайти не успел в рабочее время.
Кстати, если посмотреть на сайте университета, кто где сейчас из выпускников РТФ, то это практическ весь мир и практически все крупные корпрации :)