Pull to refresh

Comments 22

Здравствуйте! У меня вопрос немного не по теме, но я уже честно попробовал много разных способов получить ответ, в том числе официальные TBB licensing FAQ, Intel support mailing list, TBB forum, StackOverflow; пока безрезультатно.

Я разрабатываю приложение для компании. Приложение с закрытым кодом, но бесплатное, и не предполагает подсчет пользователей, какие-либо манипуляции с регистрацией и прочее. Существует ли вид лицензии Intel TBB, который компания могла бы приобрести, что позволило бы мне использовать TBB в моем приложении?

Все виды коммерческих лицензий, которые я видел до сих пор, упоминают per-user, или per-LAN модель, но платить $xxx за пользователя бесплатного приложения нас не устраивает, поэтому суть вопроса сводится вот к чему: правильно ли я понял коммерческую модель описанную выше, и если да, то есть ли возможность выкупить лицензию для неограниченного распространения одного программного продукта?

Спасибо!
Насколько мне известно под per-user имеется ввиду не конечный пользователь системы, а программист, который использует инструмент для разработки.
Правильно, лицензии Intel® TBB нужны для разработчиков — сколько их, столько и лицензий (принцип как с компилятором). Количество конечных пользователей приложения с TBB не ограничивается лицензией.
Здравствуйте,

Я не юрист и не могу давать юридические советы по использованию или лицензированию.

Но у меня есть вопрос: Вы рассматривали использование версии Intel TBB с открытым кодом? Она доступна по лицензии GPLv2 and for the runtime exception.

И как там написано, если что-то непонятно, то лучше обратиться к своему юристу («Hopefully that text is self-explanatory. If it isn't, you need to speak to your lawyer, or the Free Software Foundation.»)

--Владимир
К чему весь этот геморрой с интелом, когда в windows есть PPL, который полностью интегрируется с WinRT async model?
Кроссплатформенность.

Например, если Вам надо поддерживать игрушку для андройда и виндовс, а может и других магазинных систем, физический движок достаточно написать один раз, а не переписывать его для каждой системы.

--Владимир
WinRT не подразумевает кроссплатформенности. Все взаимодействие с API, всё равно, будет вынесено в отдельный модуль. Так что нет, кроссплатофрменность тут роли не играет.
А судя по тому, что выше Вы написали про GPL, то за неё еще и платить придется. Точно не конкурент PPL.
Я не писал, что WinRT подразумевает кроссплатформенность.

Я писал, что человек при разработке своего приложения для нескольких систем не будет задумываться о потоках в написании алгоритма работы, а может опираться на кроссплатформенную библиотеку, которая уже будет заботится о Win threads, WinRT или pthreads.

про то, что надо платить за GPL — совсем не понял. Кто платит за GPL лицензию?
--Владимир
Вы пишите статью в контексте WinRT и XAML. Весь код, который относится к вышеозначенным, в кроссплатформенном приложении будет вынесен в отдельный модуль(скорее всего). Если только выносить весь код с потоками за пределы этого модуля. Но тогда непонятна вся помпа «мы выпустили библиотеку для Windows 8». Конкретно в windows 8 Ваша библиотека имеет спорные плюсы, мягко говоря.

Про GPL: мало кто хочет делать код публичным, GPL паразитивен. А значит остается покупать, что тоже не добавляет плюсов в копилку TBB.
Конкретно в windows 8 Ваша библиотека имеет спорные плюсы, мягко говоря.


Win8 + портабельность = разрыв шаблона (с) пришло в IM.

Я, конечно, извиняюсь. У Вас есть опыт командной разработки приложения для нескольких платформ (операционных систем и архитектур) одновременно? Другими словами, это мнение, основанное на опыте или на эмоциях?
Есть. Что это меняет? Вы попробуйте ответить на мои вопросы, которые я задал ранее. Попробую его переформулировать: Зачем с такой помпой рассказывать о TBB в Windows 8, когда все её преимущество заканчиваются на кроссплатформенности?

P.S. Эмоций при написании комментариев к данной статье не испытываю.
Т.е. лично у меня, после прочтения статьи сложилась следующая картина: в Windows8 сменилось API и от старого способа работы с тредами пора отказываться. И вот тут-то интел и решил всем помочь и «запилил» TBB под Windows 8. Более того, непонятно как до этого мы жили. Но, Вы скромно умалчиваете, что есть стандарт де-факто для написания WinRT приложений на C++ — PPL(которому уже ~2 года). Я понимаю, что блог компании и всё такое. Но это всё же хабр, а не сайт интела.
Последние два комментария стали очень адекватные, спасибо:) До этого было больше похоже на тролление.

Данный пост это не рассказ с помпой, а именно учебное пособие, как написать или портировать приложение на новый интерфейс windows с помощью Intel TBB. Я специально поставил значок «tutorial».

А что лучше «стандарт де-факто PPL», чистые тредпулы, Intel TBB (который, в принципе, совместим с PPL) — это всё офтопик и не рассматриваются в рамках этого блога. Копья можно и в другом блоге поломать. Преимущества и возможные недостатки библиотеки я здесь тоже не рассматривал. Так же, как наверно все заметили, блог также не рассматривает публикацию приложения в самом магазине. Я видел тут, на хабре, отличный блог по этому поводу.

Давайте перейдем к существу блога, если есть, что спросить или высказать о нем.

--Владимир
Вот именно что совместим лишь «в принципе».

Есть ли поддержка Windows::Foundation::IAsyncInfo? Нет? Тогда о какой поддержке Win8 приложений вообще идет речь?

Нет apartment awareness (в частности, то самое блокирование ASTA потока не было выявлено в частности потому, что TBB «все равно» какой поток блокировать, а вот ConcRT — не все равно).

Да и в принципе использовать task-based параллелизм в TBB значительно сложнее, чем в PPL (отмечу, в последнем PPL — тот который в VS2010 тоже не особо хорошо его поддерживал).

Не говоря уже о всяких create_async для тех, кто хочет не только «потреблять» асинхронные операции, но и создавать (например в библиотеке, которая дальше используется из C# или JS).

Нет, вот конкретно в части поддержки непосредственно Windows 8 совместимость не то чтобы плохая — она полностью отсутствует.
Про GPL: мало кто хочет делать код публичным, GPL паразитивен
TBB распространяется не по простой GPL, а по лицензии
GPLv2 and for the runtime exception
Принципиальная разница в том, что код своего приложения распространять не обязательно, и можно делать коммерческие приложения с бесплатной TBB. Какие-то нюансы есть, но в общем случае можно.
#include "tbb/tbb.h"

void App1::MainPage::XX_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
  float sum = tbb::parallel_reduce(
// ...
    );	
    Xx->Content="Press to run Simple Reduction\nThe result is " + sum.ToString();
}


Я чего-то недопонимаю или в официальном блоге Intel появилась статья о параллельном программировании, в которой НЕСКОЛЬКО раз допущена «детская» ошибка. Вы же осознаете, что одна из существенных причин, по которой МС связались с реализацией полностью нового АПИ — это попытка сделать так, чтобы «дети» больше не допускали таких ошибок.

Пожалуйста, спрячьте статью в черновики и не вытаскивайте ее пока не осознаете, почему в WinRT ВСЕ «долгие» операции сделаны асинхронными. Почему concurrency::task::wait() (и прочие блокирующие операции) бросят исключение (почитайте желтенькое вот там), если кто-нибудь попытается их использовать в похожем контексте (еще одна причина использовать ConcRT/PPL вместо TBB). Что такое task_continuation_context и как он связан с ASTA (читай UI) потоками.

Не поймите меня неправильно, TBB — неплохая библиотека, но блокировать UI поток в ПРИМЕРЕ использования библиотеки от производителя самой библиотеки — это выше моего понимания. И да, за каждое «unresponsive» приложение в сторе отныне я буду винить лично Вас
Вообще-то у меня в блоге ни одного слова про WinRT нет.:) А если Вы посмотрите на PPL'ный concurrency::parallel_reduce(), то там нет ничего желтенького. Одно дело, когда Вы уверены, что UI поток будет стоять достаточно мало времени, чтобы пользователь не успел это прочувствовать, а совсем другое, когда Вы сами останавливаете UI поток и чего-то ждете.

Проблема блокирования UI потока — общая для любой ОС. Если Вы посмотрите наши DirectX примеры в пакете, то там есть примеры как с блокированием UI потока, так и без; как с пропуском кадров, так и без. А OpenGL примеры для OS X* реализованы только без блокирования потоков, и UI написан на Object C, а бэкэнд на С++.

Если уж на то пошло, то, на мой взгляд, вторая по значимости UI проблема — это вывести адекватный прогрессбар в UI потоке. Но и эта проблема также за рамками данной статьи:)

Какие еще «детские ошибки» в моем «хелло ворлд»? Из всего представленного примера осталось придраться только к лямбда функции и к float переменной, из-за которой получается недостаточно точный результат обычной редукции. Больше там просто слов не хватит:)
--Владимир
Начну с того, что я проверил PPL-ные (не ppltasks) алгоритмы (parallel_reduce, parallel_for и пр..) и они действительно ничего знать не знают о UI потоках. Так что здесь мне ничего не остается кроме как признать себя ослом.

Дальше, сразу отвечу на простую часть. Нет, больше «детских ошибок» в коде нет. Ни во float, ни тем более в лямбдах нет ничего плохого. Точность редукции не имеет значения для семпла (да и в «реальной жизни» производительность может быть гораздо важнее дополнительной точности) — так что здесь я тоже и не думал «придираться».

Проблема блокирования UI потока действительно общая для всех ОС. Просто потому что UI имманентно последователен. Совершено очевидно, что все пользовательские события (например нажатия на клавиши, движения/клики мыши и т.п.) должны быть обработаны в точности в том порядке, в котором поступили. По большей части то же самое касается и вывода. То есть никаких проблем с однопоточностью GUI я не вижу. В смысле, проблем дизайна не вижу — проблем ИСПОЛЬЗОВАНИЯ существует множество и одна из основных это как раз блокирование того самого UI потока.

Что же «ни слова про WinRT». Ну во первых он есть у Вас прямо вот здесь — в примерах. Все эти Windows::UI::Xaml и Platform::Object — это как раз таки WinRT (последний правда — часть проекции в C++, а не часть самого WinRT, но не суть). Да и Windows 8 в качестве платформы Вы выбрали сами. И в качестве примера используется Modern app.

Ну а теперь, собственно, обратно к сути претензий.
Блокировать UI поток операцией, для ускорения которой потребовалось распараллеливание — очень плохая идея. Либо операция выполняется быстро без всякого параллелизма, либо мы таки вычисляем все параллельно и асинхронно доставляем результат обратно в UI поток. И это тем более важно, поскольку Вы не можете предсказать сколько это «достаточно мало времени». Как количество ядер, так и производительность каждого ядра — штуки достаточно разнообразные. Код может работать без заметных задержек на машине разработчика, но будучи просто перекомпилированным под ARM внезапно начнет тормозить. Или, раз уж мы говорим о реалистичности сценариев, то вряд ли Вы будете постоянно вычислять одну и ту же величину — скорее всего будете обрабатывать какие-нибудь внешние данные. И вот тут то опять таки начинается веселье. На тестовых данных все хорошо, а у пользователя — тормозит и заикается.

В общем пример должен показывать как НУЖНО решать какую-нибудь задачу (при этом сама задача может быть и полностью высосанной из пальца, как, к примеру, те же обедающие философы). В Вашем же примере показана очень опасная техника, требующая от разработчика точного знания условий работы его программы. Не только нынешних, но и будущих. И это при том, что есть множество простых способов сделать все то же самое, но безопасно и эффективно.
Sign up to leave a comment.