Как стать автором
Обновить

Комментарии 58

Друзья, задавать вопросы по тематике данного поста — Владимир и Анатолий постараются ответить на них. Самого заинтересованного по итогам недели наградим замечательной мышкой Razer Mamba, а самому активному по итогам всей программы «5 недель с компанией Intel» достанется SSD-диск. Так что не стесняйтесь ;)
Алексей, а ссылка(и) где?
А о каких именно ссылках идет речь? Может я могу помочь? Кроме того, Анатолий хоть и в отпуске, просматривает сайт, так что ему вопросы можно задавать, не дожидаясь его возвращения.
Бета Intel Parallel Studio XE. Спасибо
Intel Parallel Studio XE Beta распространяется среди зарегистрированных пользователей софта от Intel, поэтому прямой ссылки не существует. Однако есть обходные пути, например, заполнив определенный опросник, можно получить доступ к бета-программе.
Спасибо за ссылку. Как раз есть у меня один кусок кода, который не дает мне покоя вторую неделю… :)
Кстати, очень рекомендую зарегистрироваться по-нормальному, а не просто вписать левые данные на скорую руку. Во-первых, вы будете получать сообщения об апдейтах компонент пакета инструментов, что очень важно, так как баги фиксятся сотнями от апдейта к апдейту. Во-вторых, нам так легче будет обеспечить вам суппорт, потому что для данного продукта суппорт происходит не на форумах, а через систему https://premier.intel.com/
Хотя, впрочем, никто не мешает вам задавать вопросы и на форумах.
А в саппорт по-русски писать можно? :)
В принципе можно, то вы тогда лишаетесь возможности получения ответа от любого инженера в команде поддержки, так как процесс обучения наших американских коллег русскому языку идет очень медленно :)
А вот русские форумы для того и были созданы, чтобы там можно было спрашивать по-русски.
Боюсь, что я могу так витиевато описать свою проблему на английском, что меня в конечном итоге не поймут ни те ни другие. :)

У меня возникли трудности с установкой, подозреваю, что с этим лучше в саппорт.
тогда да, лучше в суппорт написать
Анатолий вроде как сейчас в отпуске, так что ответит не раньше чем через неделю :)
да, я в отпуске, но постараюсь отвечать сегодня и завтра (в пятницу). Мне самому очень интересно. Пожалуйста, задавайте ваши вопросы. К сожалению, начиная с субботы я уезжаю туда, где компьютеров нет.
А в чем вы готовите картинки для спецификаций? Те, на которых детализация интерфейса.
Только не смейтесь, в Photoshop. Я просто знаю этот продукт с 90х, и он мне привычнее всего. В Интеле, я один из немногих («гордый обладатель») лицензионной копии. Вообще, я думаю, инстремент может быть любым, лишь бы результат говорил сам за себя, и сделать mock-up можно было бы за несколько минут.
Понравилась картинка, я уж было подумал, что есть инструмент, который делает красиво. :)
Спасибо
А как у вас вообще происходит создание интерфейса для новых версий? Интерфейс проектируется с нуля таким, каким он видится разработчику? Или берется старый и изменяются элементы с учетом пожеланий к предыдущей версии?
Это, скажу вам, мучительнейший процесс. С одной стороны мы пытаемся начать с чистого листа. Но очень быстро приходим к проверенным временем решениям. С другой стороны есть очень серьезные наработки, которые представляют собой более или менее компактные «блоки» (некие куски продукта, которые хорошо зарекомендовали себя в предыдущих версиях. Такие куски обычно отполированы в боевых условиях представителями многих именитых компаний). Часто такие куски невозможно логично сгруппировать в единый продукт. Приходится чем-то жертвовать, или идти на компромисы. Спросите пожалуйста конкретней, на каком либо примере из Intel Parallel Studio, я вам расскажу историю :)
Индикатор уровня анализа в виде спидометра понравился, дает наглядное представление.

А бывает такое, что вы, как вам показалось, изменили интерфейс в лучшую сторону, а пользователи начинают сетовать на непривычность и просят вернуть все как было. Если да — как вы поступаете в таких случаях?
Спасибо.

:) наступаю на горло собственной песне. Я же дизайнер в Intel, а не художник. Вот в картине, изивните, я ничего ни для кого менять не стану.
Как и во всяком другом приложении, при проектировании интерфейса надо попытаться сохранить хрупкий баланс между простотой, функциональностью и удобством. Как Вы считаете, насколько удачен (с вашей точки зрения) интерфейс разрабатываемого Вами продукта, и опишите, пожалуйста, основные сложности про проектировании подобных продуктов. На что уходит больше времени, что затрачивает больше всего усилий, какие моменты были спорными или пересмотренными позднее?

Очень интересно, заранее спасибо.
Баланс хрупкий, согласен. Эта проблема вечная как мир. Внутри комманды мы договорились сделать Intel Parallel Studio как можно более простой и дружелюбной для пользователя, пусть даже ущемляя наши технические возможности. Зато Intel Parallel Studio XE будет использовать весь спектр наших последних технологий, пусть даже не всегда будет немедленно понятно как этим пользоваться. Эта договоренность внутренняя. Несколько раз мы пытались изменить сами себе — сделать «первую студию» более технически подкованной, а «вторую» более понятной. Но в целом слово сдержали. Считаю ли я результат удачным? Да. Есть оговорки, но разрешите их оставить при себе. Были ли сложности? Да и много. Например известный синдром «разработки второго продукта». Если интересно, то распросите меня дальше :)
Интересно-интересно. На что больше тратится времени, на изначальное проектирование, или на правки к прототипу? Были случаи принятия первого же варианта с незначительными правками? Как часто финальный результат внешне кардинально отличается от прототипа? Часто-ли смотрите на продукты других компаний в поисках хороших идей и интересных решений? Возникали-ли сложности с реализацией прототипа (т.е. на бумаге и теоретически — все хорошо, а на практике сделать так, как на бумаге — не выходит).
«синдром второго продукта» в двух словах это ситуация когда в «первом продукте» ты сумел ограничить полет своей фантазии, а во втором никак не можешь. У нас столько отличных идей и так хочется все-все сделать, но к сожалению «второй продукт» должен быть сделан в срок и с высочайшим качеством. Нужно сделать хорошо, но меньше. Это проблема :)

Больше всего времени тратится на координацию идей. Если ваша команда из 10 человек, вы достигаете договоренности за час. Если из 20, то за рабочий день. Если из 100, то можете не достигнуть договоренности никогда. Моя работа состоит в быстрой визуализации. Да, бывает что я «угадаю» с первой же картинкой — все посмотрят и скажут, что это то, что надо. Бывает наоборот, проходим долгие 15-20 итераций, а потом через месяц все равно все выбросим. Финальный результат бывает что сильно отличается от начальной идеи, это нормально. Хотя, недавно я пересматривал самые первые эскизы, почти все от первых идей будет в продуктах. На конкурентов (партнеров) смотрим регулярно и пристально :)

Насчет сложностей с реализацией долго думал как ответить. Кратко — нет, больших проблем не было. Я стараюсь рисовать только feasible things. Конечно бывает, что та или иная операция на практике оказывается долгой (объективно долгой, например перелопатить 2-3Gb данных и выдать результат 30 раз в секунду сложно). Стараемся выкрутиться как-то, но без кнопок «Update» (терпеть не могу кнопки Update/Refresh и т.д.). В Intel работают очень хорошие программисты, рано или поздно, у нас все получается.
Большое спасибо за ответы :)

А по-поводу кнопок Update/Refresh — очень классно в этом плане выглядит лента твиттера, когда там появляются новые сообщения — единственное, что она показывает — количество пропущенных ивентов (собщений), и только по клику подгружает информацию. Получается такое вот компромиссное решение, вроде и не ручное обновление, но и не полная автоматика, когда какой-либо из ивентов можно прошляпить, т.к. оно подгрузилось автоматом и ушло с экрана/страницы.
По поводу интерфейсов, профессиональные пользователи — тоже люди и имеют такие же потребности в удобстве при работе как и обычные пользователи при использовании софта. Единственная разница в том что обычный пользователь может отказаться от продукта.

А теперь собственно вопрос Анатолию.

Мне часто приходится работать на ноутбуке, но разрешение экрана за частую не позволяет комфортно работать в большинстве сред разработки. Как вы к этому относитесь? Есть ли у вас какие либо наработки в данной области?
Некторый элемент «насилия» над профессиональным пользователем неявно подразумевается (Если продукт дает ценный результат, пусть даже в убогой форме, то пользователь продолжит им пользоваться, даже неудобным). Я лично хотел бы сохранить на первом месте ценность информации, пусть даже в ущерб способу ее представления. С другой стороны не хотелось бы злоупотреблять терпением наших пользователей. Баланс… как и во всем.

Ноутбуки дают преимущество по горизонтали… Да, мы думали над этим. Для больших EBS-based результатов с большим количеством столбцов это очень ценное преимущество. Мы думали над этой проблемой несколько шире. Я вспоминаю одну usability testiing session, когда испытуемый первым делом развернул экран на 90 градусов (портретное расположение экрана) и весь мой дизайн поплыл. Представляете? :)
Представлю. Только вот по преимущество по горизонтали для ноутбуков не соглашусь, стационарные мониторы и по горизонтали и по вертикали в выигрыше как по разрешению так и по диагонали. В любом случае спасибо за ответ. Еще такой вопрос в догонку. Вы учитываете возможность масштабирования изображения?
А, вы про малое разрешение в целом… Да, конечно, это учитывается при дизайне.

Про масштабирование изображений: да, мы выбираем подготовленную иконку из ряда (16х16, 24х24, 32х32) под конкретный размер шрифта в системе. Не всюду получается это сделать (некоторые продукты очень большие, они пишутся разными людьми), но, например Intel Parallel Advisor полностью следует этому принципу.
Я могу ошибаться, но, по моему, пока ни один инструмент не предлагает (не знаю как правильно назвать) динамического анализа, анализа входных данных. Поясню на примере, который я уже как-то приводил. Есть процедура примерно такого вида.

int ClampByte(int byte)
{
if(byte < 0) return 0;
if(byte > 255) return 255;
return byte;
}

Казалось бы все просто и оптимизации нет места. Но если, к примеру, в обрабатываемых данных будет чаще срабатывать if(byte > 255), то изменение порядка проверок может дать если не ощутимой, но результат.
Хотелось бы получить в распоряжение инструмент, который бы не только замерял, но и выявлял такие места. Если таковой уже существует — ткните носом :)
упс, ответ уплыл ниже
картинка первая забавная:

аминько
хехехехе
Как в анекдоте «хотите поговорить об этом?». Серьезно, мне нужно что-то передать маректологам или просто посмеемся вместе и все?
Если таковой уже существует — ткните носом

Этот инструмент называется, как ни банально это звучит, тестирование. При этом тест должен обладать свойством полноты. То есть отражать адекватную статистику ветвления тестируемого приложения. А дальше уже на полноценный тест, или бенчмарк, натравливается профилировщик производительности, например Parallel Amplifier или VTune Amplifier XE.
Это скучно и долго, особенно когда таких мест в программе великое множество. Их, конечно, можно выявлять либо методом тыка, либо кропотливо вставляя собственный анализ данных, но ведь 21-й век на дворе. :)

Еще из примеров — процедура, производящая альфа блендинг, специфика программы была такова, что часто попадались похожие участки на изображениях, добавление сравнения исходного блока пикселей с предыдущего результата со следующим и пропуск обработки дало около 20% выигрыша производительности, а сколько еще таких мест может быть в программе — никто не скажет, потому, что такой анализ является очень трудоемким.
Вы совершенно правы, тестирование — это скучно и долго, но необходимо. Для увеличения производительности тестирования используется автоматизация процесса. А если в программе куча мест, где «проседает» производительность приложения, то любой профилировщик их найдет. Все остальные места с точки зрения повышения скорости работы программы не представляют интереса.
Насчет «не представляют интереса» не согласен. «Прогнал» я свой проект и выяснил, что самая нагруженная функция «съедает» всего 35% времени, остальное время размазано по 30-ти, казалось бы незначительным (65% в сумме) функциям. Основную я оптимизировать не могу, дальше некуда, остается начать присматриваться к незначащим, и уменьшать их влияние. А самое интересное, в этой задаче, что рост показателей работы основной, будет означать, что я на верном пути. :)
Это не противоречит тому, что я сказал. Т.е. если эти 30 функций действительно отъедают 65% времени, то они все будут в репорте профилировщика.
а ведь неокрепшие умы ведутся и думают, что этот интерфейсный ад и методология разработки являются чем-то хорошим и правильным
ой нет, каждый, так сказать, «поступает как может». Кем я точно не хочу быть, так изрекателем истины в первой инстанции. Описанный подход более или менее работает в команде 100+ человек расположенной в 4 частях света при наличии одного дизайнера. Kigorw, будьте добры, раскойте в деталях, что вы имели в виду?
Была упомянута интеграция с .net. Хотелось бы узнать об этом по-подробнее. Например, насколько это всё может быть совместимо с plinq и parallel task library.
Почему было обращено внимание на .net платформу? Я уверен, что компания Intel увидела какие-то важные для себя перспективы на рынке .net, а не просто

основная претензия к Parallel Studio состояла в том, что продукт слишком простой и охватывает только приложения, написанные на C++ для Windows.
На счет совместимости с библиотеками Microsoft. Мы взяли курс на сближение с майкрософтовскими параллельными библиотеками, а особенно с ран-таймом Microsoft Concurrency Runtime, так как в нашей TBB изначально предлагалось тоже самое. Так как TBB run-time полностью поддержан нашими продуктами, то и до библиотек MS рукой подать :) Насколько мы будем совместимы, покажет будущее.

Поддержка .Net прежде всего определяется спросом на рынке, поэтому одна из причин именно эта: «основная претензия к Parallel Studio состояла в том, что продукт слишком простой и охватывает только приложения, написанные на C++ для Windows.»

Так как мы «помешаны» на производительности, то основной фокус все-равно остается на нативных языках, на которых собственно и пишут критичные к производительности библиотеки. Однако, почти любое более-менее сложное приложение для Windows, содержащее графический интерфейс, содержит .Net код, и провести границу между графикой и вычислениями порою очень сложно. Поэтому главная «фишка» наших продуктов — это поддержка mixed mode приложений, т.е. программ содержащих и native код, и managed.

С точки зрения профилировщиков производительности, для .Net есть предложения инструментов на рынке, от той же Microsoft например, а вот для смешанных приложений ощущается нехватка инструментария. Что же касается инструментов для обнаружения ошибок, то Memory Checker для .Net не имеет особого смысла, но опять же, для смешанных приложений — очень даже актуален. Thread Checker же вообще практически не имеет аналогов во всех нишах (за редким исключением).

Так что перспективы на рынке .Net мы видим в том, что огромная ниша профилировщиков и чекеров для параллельных программ ни кем не занята, а объем разрабатываемых коммерческих проектов на .Net растет.
Как раз сейчас пишу DLL, которая юзает потоки, мьютексы и другую дрянь. Есть смысл регистрироваться для скачивания Parallel Studio, оно мне реально как-нибудь поможет?
Я вам предлагаю поставить такой научный эксперимент. Допишите свой проект до конца, а перед сдачей его заказчику зарегистрируйтесь и проверьте свою дрянь на корректность. Будет сюрприз :)
На чём именно пишут интерфейс? Ну т.е. в статье подробно рассказывается как он проектируется, а с помощью каких технических средств (язык, среда разработки, библиотеки) он создаётся?
Мы пишем «монстров» которые имеют на Windows и Linux совершенно одинаковые user interfaces. Монстров, в том смысле, что та или иная операционная система дает определенные преимущества (и мне, как дизайнеру), но приходится себе отказывать и не использовать эти преимущества. Наши «монстры» не всегда выглядят нативно в конкретной операционной системе или среде разработки. Они пользуются неким кросплатформенным минимумом. Ресурсов на то чтобы писать два (или четыре) совершенно различных frontend`а у нас просто нет. Каждый программист задумывается о том, как вот этот контрол будет выглядеть под MS Visual Studio и в Ubuntu. Вы понимаете куда я клоню, да? Остается С++, и WxWidgets (не будем обсуждать недостатки или преимущества). Код компилируется Intel C++ Compiler (и Майкрософтовским тоже), я так понимаю для того, чтобы код был менее компиляторо-зависимым. Внутри продуктов активно используется потоковость и в частности Intel TBB (в том числе для «отзывчивого» UI, не держим GUI thread — перекладываем time-consuming операции на другие потоки). И конечно же при разработке мы пользуемся собственными разработками — проверям утечки памяти и корректность параллельного кода при помощи Intel Parallel Inspector или Inspector XE, оптимизируем производительность при помощи Intel VTune Amplifier XE.
А не могли бы Вы привести небольшой пример того, как используется TBB для создания «отзывчивого» UI? Насколько это проще, чем, например банальный запуск потока, обрабатывающего событие (например, нажатие кнопки), дает ли это какие-либо преимущества, упрощает ли жизнь разработчика?
:) я дизайнер. Для того, чтобы ответ был профессиональным, надо кого-то другого спросить.

Я очень люблю асинхронный интерфейс. Вы «заказываете» какую-то «тежелую» работу (например, нажали на кноку отфильтровать по модулю 'foo.exe'), интерфейс должен быть немедленно готов к следующему вашему «заказу». Возможно, вы тут же передумаете и сделаете фильтрацию по модулю 'bar.exe', тогда предыдущая аналогичная работа должна быть отменена. Очень часто в моей практике программисты недооценивают время исполнения казалось бы простой обработки нажатия на кнопку. Или на их быстрой машине работает все быстро, либо заказываемая по нажатию работа специфично маленькая. Интерфейс подвисает. Через 20 секунд начинаешь волноваться. Через пару минут тянешься снять весь процесс. Ну, вы знаете…
Полностью с Вами согласен, если программа выполняет «тяжелую» работу и не подает никаких признаков жизни — это сначала напрягает, потом раздражает, а потом начинает нервировать.

Не знаю как у кого, но у нас очень часто это является результатом того, что программисту было лень создать отдельный поток, для выполнения трудоемкой операции, и он понадеялся, что у всех будет работать так же быстро как и у него. Вспоминается Вовка из тридесятого царства «и так сойдет, зажарится как нибудь».

Не подскажите, к кому из Ваших коллег можно обратиться с этим вопросом?
Не подскажите, к кому из Ваших коллег можно обратиться с этим вопросом?

Задайте свой вопрос здесь
Parallel Studio приходит в Linux — это не может не радовать. Тем более что Intel привносит значительный вклад в развитие Linux'a. Но у меня есть простой вопрос, насколько компилятор Intel совместим с GCC? Взять хотя бы ядро, можно ли его перекомпилировать Intel компилятором, будет ли оно после этого работать и будет ли повышение производительности его работы? Проводились ли подобные тесты, испытания? Ну или не обязательно ядро, взять тот же софт — OpenOffice, FireFox, GIMP…
Intel Compiler бинарно совместим с GCC, поэтому перекомпилировать модули легко. Но дьявол, как всегда, в деталях. И все ядро скорее всего не скомпилируется. Однако это и не нужно, так как особого смысла в этом нет — какого-либо значительного роста в производительности все-равно не будет. Другое дело приложения. Особенно те, что работают с большими объемами данных. Я не знаю открытых проектов, скомпилированных на Intel Compiler (просто это не моя тема), однако коммерческие приложения, для которых производительность критична, особенно в HPC, вполне успешно его используют, в том числе вместе с GCC в одном проекте.
Так же, в новой версии The Intel® C++ Composer XE 2011 появилась поддержка новых возможностей как то Cilk, CEAN, GAP, C++0x… Есть ли примеры реальных приложений, а не синтетических тестов в которых использование новых возможностей так или иначе улучшило быстродействие/производительность? Или это больше ориентированно на программистов, на их удобство при написании кода. Так или иначе хотелось бы узнать пару примеров использования в реальных продуктах и о результатах внедрения.
Говорить о success story для этих новых фич пока рано, они только что появились. Сейчас только начали публиковаться case study для TBB, а ведь библиотека доступyна уже пару лет. А case study по компилятору вообще можно найти здесь.
Можно ли использовать триальную версию композера для сборки бесплатных программ? Где можно почитать об ограничениях при использовании триальной версии?
Я не силен в вопросах правил легального применения софта. Но по-моему, для сборки бесплатных программ используют открытые лицензии типа GPL. А триальная используется только для ознакомления с возможностями продукта.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.