Intel выпустила инструментарий для создания ПО под многоядерные процессоры

Задействуют все дыры в процессорах ;-)

>Задействуют все дыры в процессорах ;-)

возможно обратное развитие событий: без этих "инструментов" программы не будут работать на новых процессорах, т.к. там полно дыр

быгага

Этот - он для предотвращения работы программ на AMD?

>он для предотвращения работы программ на AMD

Интел хоть что-то делает для разработчиков! Где аналогичные тулзы от АМД??? Давно пора запретить работать программам на АМД.

>и легко масштабируемые

Вместо оптимизации кода для существующих процессоров, параллельте его, дорогие разработчики, а уж впарить 'новинки' мы сами сможем. Так и вижу CoreQuad - на одном ядре крутится пузырьковая сортировка, на другом garbage collector, а на третьем и четвертом свистоперделкин гуй от висты.

>Задействуют все дыры в процессорах ;-)

бггг +1

Параллель не параллель всё-равно получишь дрель! И дыры, которая она сверлит.

Да оно денег стоит 0_0

У кого нить есть ссылочка на ператку сабжа?)))

Кстати, да. Ядра нормально использовать это еще уметь надо. Какой процент разрабов умеет писать парралельно ориентированные проги. Думаю не более 5-10.

>Ядра нормально использовать это еще уметь надо

Я считаю, что это не основная фишка многоядерности. Да, конечно, "на отлично" написанная программа, распараллеленая, будет приятно исполняться на 2х ядернике, за@#ебись, окей. Но это же музей, выставка шедевров. Основная фишка, хотя бы в том же GC, который будет отдельно крутиться, службах индексирования, кодеков, всякой остальной хне, которая преспокойно ляжет на второе ядро и не будет мешать текущей задаче.

А по сабжу: ну хоть обновили VTune свой, замечательно. Надо поближе рассмотреть. Наверняка очередная нае@#бка =)

Что-то я не понял где и в каком месте они выпустили обновления. VTune под линукс как был от 7.05.2007 так и остался. Под Win так вообще от 9.04.2007.

Вообще, глючный он невообразимо под линуксом. Разработчики ориентируются в первую очередь под Win, так там да, пользоваться можно. И VTune'ом и ThreadChecker'ом/ThreadProfiler'ом. А под Linux -- в лучшем случае убедиться, что демки работают.

Кстати в SunStudio есть профайлер со сходными возможностями. Во всяком случае Data Race / DeadLocks обнаруживать умеет. Как-то он мне даже больше понравился. Тем более бесплатно.

Под Linux Интел для Noncommercial тоже бесплатно раздает многие свои продукты. Но уж очень они сыроваты. Хотя компиляторами пользоваться можно.

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

Ага, а нити кто будет создавать? Да и OpenMP тот же -- это к компилятору.

Вот уже Quad'ы пошли в мэинстрим. Что дальше?... Народ, у меня одного сложилось впечатление, что качественное развитие процов кончилось?

Нити, процессы - всё clone(), при чём тут компилятор? Если код ядра не предусматривает поддержку ядер проца, как клмпилятор может использовать возможности проца?

Сколько аппаратных приблуд поддерживает ядро, столько и будет железок работать. Компилятор может помочь, например для выполнения специфических процессорных инструкций аля MMX, но для поддержки многоядерности ядро должно пожжерживать развитый механизм много процессорности, многоядерности и компилятор тут ни при чём.

>Какой процент разрабов умеет писать парралельно...

Действительно, писать слово "параллельно" умеют очень немногие :))

ИМХО, большинству задач не нужна многопроцессорность, в том смысле, что в обычно ОС в фоне работает множество небольших программ, которым и одного процессора хватает...

Сорри, но детский сад. Возьмите хоть срецификацию OpenMP или любое другое решение для систем с общей памятью. Если Ваша программа тупо считает в одном процессе 2 дня, то при возможности пересмотреть алгоритм, на двух ядрах она может считать почти в 2 раза быстрее и т.д.

Тот же OpenMP, поддержкой которого теперь модно хвастать всем производителям компиляторов, включая GNU, позволит вам не писать тупо thread_create()/thread_join(), а автоматизировать сей процесс, внося минимальные изменения (на уровне прагм) в сериальный код. А это уже и есть поддержка компилятором. Ядра же современные все SMP-обученные, и шедулить потоки умеют с балансировкой нагрузки по ядрам умеют. Компилятор же в случае OpenMP, например, сгенерирует код, который в зависимости от числа имеющихся ядер распараллелится на нужное число потоков. Ну а шедулер их потом раскидает по ядрам.

Спасибо. Не знал что компилятор может вставить там где надо за место меня sys_clone().

Ох, ну вставляйте вы ради бога, никто вам не мешает. Некоторые дырки в бетоне ручной дрелью сверлит, тоже ведь не запретишь. Честно, почитайте лучше доку с http://www.openmp.org/drupal/mp-documents/spec25.pdf вопросов меньше будет. Ясно, что OpenMP -- не панацея, но во многих случаях удобнее куда удобнее ручного распараллеливания. Во всяком случае код гораздо прозрачнее.

А у интела, кроме того, есть поддержка векторизации в духе любимых вами sse. man icc (на предмет ключика -axK и ему подобных).

Какое там 5-10. Менее одного процента вообще хотя бы слышало хоть раз, что такое пи-исчисление, а уж пользоваться этим умеет и ещё меньше народу. И никакие тулзы не помогут, проблема в головах - быдловат программирующий народ, учиться не желает, математической подготовки не имеет.

Пока его и пускать не на чем. Моему компу 5-ть или более лет.

Спасибо. Буду учить.

Кто бы по умней сравнил бы этот подход с DragonFlyBSD - она ж затевалась как раз под мультиядерные процы.

Транспьютеры уже почти 20 лет назад были, так что не отмазка. Кому надо было - те с параллельным программированием ещё тогда разобрались (да и SMP было уже очень, очень давно), а кому не интересно, те никогда и не научатся, никогда не разберутся в теме.

Разберутся. Менеджеры заставят. Ибо это теперь мейнстрим, а не экзотика.

Зачем Мэтт Дилон развернул ветку FreeBSD в DragonFlyBSD?

Видимо есть другой подход, отличный от OpenMP,

Параллельным программированием занимаются те, а\перед кем СТАВЯт такие задачи. От меня ни когда не требовали распараллелить процесс на несколько процов - не было таких задач.

Это ж абсолютно РАЗНЫЕ вещи. Стрекозописатели работают над ядром и системным окружением. Будут потоки -- будут работать программы хоть с OpenMP хоть с другой технологией. А тут речь о компиляторной поддержке.

OpenMP -- всего лишь способ писать на C/C++/Fortran параллельный код (почти) не задумываясь над этим. Хорошо, вот пример. Приведите свой код, соответствующий примитивной прагме:

#pragma omp parallel for for (int i=0; i<100000; i++) { // что-то там с i }

На двухядернике этот фрагмент распаралеллится на N+1 поток (по числу ядер + мастер, который просто тупо ждет остальных). Причем в зависимости от числа ядер на процессоре N будет каждый раз своим. Код -- как параллельный. Никаких лишних вызовов в исходном тексте. Если компилятор не поддержививает OpenMP -- соберется обычное сериальное приложением с одним потоком.

Черт, не уследил, в последнем посте должно быть так:
#pragma omp parallel for
for (int i=0; i<100000; i++)
{
// что-то там с i
}

Видимо компилятор долджен быть очень умным.

Мне не очевидно, как компилятор будет склеивать результаты работы двух нитей, тем более если в в теле цикла быдут исключения по разным условиям, а также изменения значения i в большую и меньшу сторону, опять же по условиям.Хотя не спорю, для перебора массивов в БД это должно эффективно работать, но опятьже для простых алгоритмов перебора где компилятор может оптимизированнные им код, ещё более потимизировать за счёт распараллеливания.

Вы почитайте-таки спецификацию. Там еще и не то возможно. Естественно, изгаляться с исключениями вам вряд ли позволят и вообще, компилятор должен "видеть" начало и конец цикла, чтобы вставить код, на ходу рассчитывающий число итераций, которые отдаются каждому потоку. Поэтому разного рода итераторы stl и обход списка -- не самые подходящие циклы для распараллеливания в данном случае. Научные расчеты -- да, расчет каких-нибудь сумм рядов, интегралов -- самое то. В общем, если знакомы с MPI, лишь кое-что покажется вам знакомым, а остальное забудется как страшный сон. Впрочем, ненадолго. Интел еще кластер OpenMP предлагает :))

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

Нет. Мейнстримом оно стало с момента появления дешевых двухядерников. Как рассказывают сами интеловцы, игрописатели только сейчас начали массово переучиваться. Еще пару лет назад они считали это экономически нецелесообразным.

Интел обновил программы своего Software College, они теперь включают занятия по параллельному программированию и их тулзам по отладке/профилированию параллельного кода. Сам код активно начал писАться только сейчас.

А до того -- конечно, системы с общей памятью не вчера появились. Только вот кто и сколько людей под них писали софт? И какой софт?

Приставки уже N лет как SMP.

А игрописатели - те еще бараны, переучиваются медленнее всех прочих. Парадокс, но факт - игрописатели в основной массе абсолютно некомпетентны.

> Какое там 5-10. Менее одного процента вообще хотя бы слышало хоть раз, что такое пи-исчисление, а уж пользоваться этим умеет и ещё меньше народу. И никакие тулзы не помогут, проблема в головах - быдловат программирующий народ, учиться не желает, математической подготовки не имеет.

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

Не, дитёнышь, быдловат таки ты. Потому что многоядерные процессоры уже здесь и сейчас, а ты ещё не умеешь под них программировать. И не научишься никогда. Таких задач, которые от распараллеливания не выиграли бы - весьма мало (и что смешно - большинство их как раз в вычислительной области). Ну да откуда это знать тупому быдлу, которое математики не знает, но при этом смеет себя величать "программистом"?

P.S. Я очень сомневаюсь, что свои задачи ты решаешь "нормально". Более того, я уверен, что работаешь ты до крайности паршиво.

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

уважаемые анонимусы, поделитесь, плиз, программой для мощного фразеологически-семантического анализа, а то вы так ловко друг друга узнаёте и по имени называте что завидки берут, или вы из фсб/анб/моссада будете? :)