Intel Threading Building Blocks

Саныч, негодяй, во-первых, ты меня опередил, во-вторых, почему не указал цены? ;)

"Рекомендуемые системные требования. Intel Pentium 4 (HT Technology), Intel Xeon, или Intel Itanium 2, 1 GB памяти..." ага и пачку масла - харю намазать чтоб не треснула

> во-вторых, почему не указал цены? ;)

И про скидки для студентов ;)

Почти $200 скидки эт тебе не хухры-мухры ;)

>"Рекомендуемые системные требования. Intel Pentium 4 (HT Technology), Intel Xeon, или Intel Itanium 2, 1 GB памяти..." ага и пачку масла - харю намазать чтоб не треснула

Да это для девелоперов требования а не для юзеров ;)

Зато "Allows unlimited distribution of the runtime libraries with your software"

> И про скидки для студентов ;) > Почти $200 скидки эт тебе не хухры-мухры ;)

Ради такой экономии можно и студенческий откопать, и даже зачотку ;)

странно про SLES10 забыли ! Novell'у низачот !

А есть ли возможности подобных оптимизаций под многопоточность на обычном gcc ?

gcc -pthread ...

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

Итак, читаю "Reference for Intel® Threading Building Blocks Version 1.3" (люблю читать с конца, тк сопли часто прячут подальше, в конец описания):

стр 50

"8 Task Scheduling

The library provides a task scheduler. This task scheduler is the engine that drives the algorithm templates (3). You may also call it directly. Using tasks is often simpler and more efficient than using threads, because the task scheduler takes care of a lot of details. The tasks are logical units of computation. The scheduler maps these onto physical threads. The mapping is nonpreemptive. Once a thread is committed to servicing a given task, it is bound to that task, and its children, until the parent task completes. A task objects are intended for computational intensive tasks. It should not make calls that might block for long periods, because meanwhile that thread is precluded from servicing other tasks..."

планировщик в юзер-спейсе, афигительно. Ввод-вывод, сигналы, блокировка на долгоиграющих вызовах, полный пакет, все гланды "внатуре". Сколько раз говорили, что модель N в M это плохо, нет надо свой велосипед изобрести. Но почему же это сделали? Может быть HyperThreading имеет преимущества в такой модели? Переключение полноценного треда требует работы "тяжёлого" системного планировщика и интеловцы фокусничают с гипертредингом из юзер-спейс планировщика? Тогда всё понятно, надо же впарить HyperThreading потребителю и показать, что хоть где-то он пригождается. (не спорю, для чистых вычислений наверное польза есть, но извините, это даётся ценой жёсткой заточки кода под проц)

стр 25

"4 Containers

The container classes permit multiple threads to simultaneously invoke certain methods on the same container."

я не понял, это они так о thread-safety говорят? ну надо было так и сказать, а то ведь STL reentrant. Контейнеры-контейнеры, память на куче, до свидания временная предсказуемость, здравствуй амортизированное время.

"3 Algorithms

Most algorithms provided by the library are generic. They operate on all types that model the necessary concepts."

И эти люди запрещают мне ковыряться в носу! Не нравится им сишный код на позиксовых низкоуровневых колах к тредам, писать много приходится видите ли. Представляю, что потом нагородят девелоперы из "стандартных блоков", когда придётся нестандартные алгоритмы из этих блоков собирать...

Да не парься, им попросту свои новые процессоры продавать нужно.

Никогда не думал, что такое скажу, но вот, говорю. Это чего вообще такое? Попытка сделать нечто, похожее на STL, только от Intel? Какой в этом смысл, чем оно лучше STL/Boost? Сразу сознаюсь, я "подробности" не читал, мне как-то влом даже.

Проприетарное ПО. Точка.

> Попытка сделать нечто, похожее на STL, только от Intel? Какой в этом смысл, чем оно лучше STL/Boost?

NIH-синдром? :-)

>планировщик в юзер-спейсе, афигительно.

Вообще-то это сейчас у кого-попало (если не сказать почти у всех) так. У жабок, дотнетов, ерлангов и прочих.

>Контейнеры-контейнеры, память на куче, до свидания временная предсказуемость, здравствуй амортизированное время.

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

>Представляю, что потом нагородят девелоперы из "стандартных блоков", когда придётся нестандартные алгоритмы из этих блоков собирать...

Если так - дык и STL гавно. И вообще любые библиотеки - гавно. Да и POSIX гавно - понагородят из стандарных библиотек, а как захочешь "странного" так...

>>планировщик в юзер-спейсе, афигительно. > >Вообще-то это сейчас у кого-попало (если не сказать почти у всех) так. У жабок, дотнетов, ерлангов и прочих.

не у всех ...

в жабе действительно было когда-то

> Если так - дык и STL гавно.

Про некоторые части STL надо большими красными буквами написать "НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ДЛЯ ПАРАЛЛЕЛЬНОГО ДОСТУПА", и ведь не пишут, <редиски>. Как классно я (по неопытности) со строчками нарвался, хоть и только для чтения использовал... После этого внимательно изучал каждый объект в STL, чтобы понять как в многопоточном окружении с ним работать...

> Это чего вообще такое? Попытка сделать нечто, похожее на STL, только от Intel? Какой в этом смысл, чем оно лучше STL/Boost?

ну например, в STL контейнеры не thread-safe, плюс "стандартные блоки" - алгоритмы заточенные под определённые модели организации тредов (несознательные товарищи ругают boost::thread за низкоуровневость)

Вот по поводу thread-safe контейнеров у меня есть подозрение в чрезвычайной хреновости такого решения, когда каждая операция с контейнером будет автоматом лочиться, то при интенсивной работе с контейнерами cpu будет заниматься за/раз-лачиванием и подавлением конвееризации и out-of-order операций повсеместными barier. Я только что разобрался с подобным случаем, где я ставил локи только по необходимости и тогда, когда это действительно нужно и всё равно бОльшая часть времени уходит на синхронизацию :(.

> С другой стороны не надо балываться с локами в каждом встречном поперечном месте, и как следствие воевать с дедлоками в больших сложных приложениях.

плохо это, описал выше почему

> Если так - дык и STL гавно. И вообще любые библиотеки - гавно. Да и POSIX гавно - понагородят из стандарных библиотек, а как захочешь "странного" так...

нет, Г, когда лишают выбора как делать. Если я хорошо запомнил, то в интеловых контейнерах нет итераторов, всё, пипец, работа только через стандартные алгоритмы, а какие стандартные будет решать интель :(

> Про некоторые части STL надо большими красными буквами написать "НИКОГДА НЕ ИСПОЛЬЗУЙТЕ ДЛЯ ПАРАЛЛЕЛЬНОГО ДОСТУПА", и ведь не пишут, <редиски>. Как классно я (по неопытности) со строчками нарвался, хоть и только для чтения использовал... После этого внимательно изучал каждый объект в STL, чтобы понять как в многопоточном окружении с ним работать...

STL _не_ thread-safe, если синхронизоваться, то проблем быть не должно