Havok -просто один из сотен примеров. Intel Larrabee SDK -средство создания именно native приложений для Larrabee. Intel C++ Larrabee Prototype Library — это эмулятор так называемых интринсик-функций (функций, работающих с векторными инструкциями процессора) для новых 512битных векторных инструкций Larrabee. Как вы можете представить, для многих приложений эти инструкции — просто спасение производительности.
Вы правы, я имела в виду Netbooks.
Что касается Atom, то к выходу готовится его новая модификация (поищите данные в сети), которая по параметрам производительности-энергопотребления вполне подходит в MID
Да, если поставить вопрос так, то в Larrabee никаких принципиальных отличий ядер от CPU нет (хотя последние гораздо мощнее). Но есть устоявшаяся с годами архитектура PC, где CPU управляет всем, а GPU может вообще отсутствовать за ненадобностью (интергированная графика). Отказа от этой архитектуры ждать не стоит, зато есть тенденция к другому варианту — интеграции графических ядер в сам CPU.
Ответ: скорость обмена данными. Одно дело, когда обрабатываемые данные уже в процессоре — в его кэш, а другое — когда их еще надо передать для обработки вовне -на интегрированную графическую карту. Разница есть.
Мне известен общий принцип обратной трассировки лучей, но не детали его реализации. Таких реализаций существует много — вы тоже можете написать свою :) И каждый автор выбирает свой метод распараллеливания. Полагаю, что сейчас основной (распространенный) принцип — это каждое ядро обрабатывает группу лучей, но сказть точно не могу.
«принцип построения систем Larrabee — это использование как можно большего количества процессорных ядер» — это НЕ так. Принцип построения Larrabee — обеспечение максимальной производительности как графических (первый приоритет), так и просто вычислительно сложных приложений общего назначения.
Имея опыт работы с ARM (xsale), зная его возможности, я могу утверждать, что х86 соответствует вышеприведенному принципу\целям гораздо лучше.
Плюс — у вас еще одно заблуждение — «на Larrabee будут выпускаться дискретные графические платы, для которых никто, кроме программистов Intel, не будет напрямую писать Софт»
Софт писать не просто будут, его сейчас за пределами активно пишут, а многое уже и написано. И основной плюс тут — действительно простота написания программ в знакомых средах, языках и методах распараллеливания. Larrabee — GPGPU, этим -все сказано.
Насколько я знаю, вижу и ощущаю, Интел с рынка суперкмпьютеров никуда не уходит, поэтому термин возвращаться тут «неприменим».
Да, Larrabee может и должен использоваться для суперкомпьютерных вычислений, этот процесс будет идти в параллель с увеличением количества ядер и их усложнением\развитием. Эти два процесса друг друга дополняют, а не исключают.
Здесь надо пояснить для несведующих. Интегрированная графика отличается тем, что абсолютное большинство операций делает на самом CPU. Потрму она такая дешевая, надежная и тп.
На железе делается не так много, иначе это была бы дискретная графика, просто намертво вделанная в материнскую плату :)
Поэтому предлагаемый вами вариант использования нерационален, если не сказать «невозможен»
В этом отношении Intel GPU ничем не отличается от GPU других компаний. Точно так же, как происходит разработка\отладка драйверов для них (а драйвера выполняются на реальном железе), будет происходить отладка и для Larrabee. Но согласна, это — нетривиально, так же, как нетривиальна отладка любого многопоточного приложения.
Не знаю уж, огорчит вас это известие, или обрадует, но такая вещь, как «распил денег» в Интел просто невозможна. Не потому, что нет денег, а потому, что нет пилы :) Этот механизм просто не предусмотрен. Т.е. в Интел сотруднику\группе сотрудников получить какой-то дополнительный доход от факта разработки нового продукта просто невозможно. Никак.
Другое дело, что если продукт будет выпущен и принесет прибыль, то пропорционально этой прибыли заработают все сотрудники Интел. Если прибыли не будет, то — сами понимаете. Поэтому разрабатывать заведомо ни на что не способную платформу никто не будет.
Вопрос очень хороший, спасибо. Да, мысли о параллельном использовании интегрированной и дискретной графики в Intel есть. Но сделать это эффективно очень непросто…
И еще один момент — в грядущих процессорах Интел планируется интеграция графических ядер в сам процессор. Это упростит задачу одновременного использования всей имеющейся графики.
1. Нельзя. Ограничения в развитии CPU -невозможность бесконечно увеличивать частоту из за физических проблем привели к развитию многоядерности в самих CPU. А GPU — просто еще одно интересное направление деятельности, в котором, кстати, Интел уже двигался в 90-ые годы.
2. Конечно же, нет. Даже исходя из названия — GPGPU= General Puprose GPU, т.е. GPU — не только для графики и видео. Но вот это -«Ограничиваются ли его возможности только возможностью ускорения вычислений» — правда. GPU будет именно ускорять вычисления для многопоточных задач. При этом, делать это максимально user friendly. Т.е. ваша программа будет выглядеть так же, как и для CPU без использования графических терминов и прочих аттрибутов GPU. Соответственно, GPU SDK будет максимально интегрирован со средами разработки, и, прежде всего, VS.
3. Да, при отсутствии GPU, его, конечно, надо эмулировать. А поскольку ни жесткий диск, ни bluetooth модуль, я уж не говорю о CD приводе, с эмуляцией самостоятельно не справятся, то делать это будет CPU. :))
Упомянутое вами место (https://code.fluendo.com) -это не официальное место подачи багов для драйверов Интел. Так что ответить на остальные вопросы я затрудняюсь. Следите за выходом новых версий драйверов.
Ваш вопрос из серии — зачем предприятию нужен начальник. Хотя, в некоторых случаях начальник явно мешает, но в компьютере -начальник CPU, обладающий множеством возможностей (ядра CPU гораздо мощнее, чем ядра GPU), точно нужен. Для очень многих задач можно обойтись без GPU. Без CPU обойтись нельзя.
Другое дело, что развитие идет в сторону «коллективного управления»- т.е. кол-во ядер CPU растет.
Не все алгоритмы распараллеливаются в принципе. Некоторые последовательны по своей природе, для них, увы, многоядерность не поможет.
Некоторые алгоритмы легко распараллеливаются на фиксированное небольшое число потоков (ядер), но при дальнейшем увеличении числа потоков рост производительности прекращается. Это — непреодолимо.
Представить бесконечно распараллеливаемую задачу вообще тяжело. Возьмем, например, обработку картинки. Даже если в идеале (недостижимом, кстати) каждое ядро будет обрабатывать один ее пиксель, то при превышении чесла ядер над числом пикселей картинки, лишние ядра останутся без работы.
Поэтому ответ — эффективность многоядерности зависит от задачи. 1000 ядер в десктопных компьютерах я не представляю, но числа порядка сотни — вполне возможны. 80 ядерный прототип процессора был создан Интел еще пару лет назад.
Упустила один интересный момент — сейчас Интел очень активно развивает направление MID = Moile Internet Device, на платформе Moblin -фактически, на *nix системе. В MID стоит именно мобильная интегрированная графика. Так что драйвера к ней точно будут развиваться.
Для Intel Все ОС равны. Нельзя сказать, что мы дружим с одними больше, чем с другими. Другое дело — количество пользователей разных OC различно — у Windows их больше. Поэтому, просто исходя из количества пользователей, за счет эффекта массовости, проблемы драйверов для Windows обнаруживаются, и соответственно, фиксятся чаще. Кроме того, самые известные -распространенные графические бенчмарки тоже под Windows. Поэтому проблемы с производительностью бывают видны и решены прежде всего, здесь.
И я бы согласилась с предложением ctrlok взять драйвера с intellinuxgraphics.org/ возможно, это поможет.
И еще — поскольку *nix очень много, протестировать все возможные конфигурации очень тяжело. А значит, нет никакой гарантии, что производительность портит именно драйвер IIG, а не сама операционная система, или какой-то сторонний софт.
Здравствуйте, Человек. Я — специальная модель биоробота, созданного Intel в экспериментальных целях. Потому и подчеркнуто «девушка и два молодых человека».
А вообще, вы правы — фраза дико корявая, и вообще Intel не свойственная, тут у нас с этим (дискриминацией по любому признаку) очень строго.
Владимир — почти прав, сейчас многопроцессорная система одноядерных процессоров IA32-скорее исключение, чем правило. Но тенденция — к многопроцессорным многоядерным системам. Так что это придется учитывать в разработке.
Что касается Atom, то к выходу готовится его новая модификация (поищите данные в сети), которая по параметрам производительности-энергопотребления вполне подходит в MID
Имея опыт работы с ARM (xsale), зная его возможности, я могу утверждать, что х86 соответствует вышеприведенному принципу\целям гораздо лучше.
Плюс — у вас еще одно заблуждение — «на Larrabee будут выпускаться дискретные графические платы, для которых никто, кроме программистов Intel, не будет напрямую писать Софт»
Софт писать не просто будут, его сейчас за пределами активно пишут, а многое уже и написано. И основной плюс тут — действительно простота написания программ в знакомых средах, языках и методах распараллеливания. Larrabee — GPGPU, этим -все сказано.
Да, Larrabee может и должен использоваться для суперкомпьютерных вычислений, этот процесс будет идти в параллель с увеличением количества ядер и их усложнением\развитием. Эти два процесса друг друга дополняют, а не исключают.
На железе делается не так много, иначе это была бы дискретная графика, просто намертво вделанная в материнскую плату :)
Поэтому предлагаемый вами вариант использования нерационален, если не сказать «невозможен»
Другое дело, что если продукт будет выпущен и принесет прибыль, то пропорционально этой прибыли заработают все сотрудники Интел. Если прибыли не будет, то — сами понимаете. Поэтому разрабатывать заведомо ни на что не способную платформу никто не будет.
И еще один момент — в грядущих процессорах Интел планируется интеграция графических ядер в сам процессор. Это упростит задачу одновременного использования всей имеющейся графики.
2. Конечно же, нет. Даже исходя из названия — GPGPU= General Puprose GPU, т.е. GPU — не только для графики и видео. Но вот это -«Ограничиваются ли его возможности только возможностью ускорения вычислений» — правда. GPU будет именно ускорять вычисления для многопоточных задач. При этом, делать это максимально user friendly. Т.е. ваша программа будет выглядеть так же, как и для CPU без использования графических терминов и прочих аттрибутов GPU. Соответственно, GPU SDK будет максимально интегрирован со средами разработки, и, прежде всего, VS.
3. Да, при отсутствии GPU, его, конечно, надо эмулировать. А поскольку ни жесткий диск, ни bluetooth модуль, я уж не говорю о CD приводе, с эмуляцией самостоятельно не справятся, то делать это будет CPU. :))
Другое дело, что развитие идет в сторону «коллективного управления»- т.е. кол-во ядер CPU растет.
Некоторые алгоритмы легко распараллеливаются на фиксированное небольшое число потоков (ядер), но при дальнейшем увеличении числа потоков рост производительности прекращается. Это — непреодолимо.
Представить бесконечно распараллеливаемую задачу вообще тяжело. Возьмем, например, обработку картинки. Даже если в идеале (недостижимом, кстати) каждое ядро будет обрабатывать один ее пиксель, то при превышении чесла ядер над числом пикселей картинки, лишние ядра останутся без работы.
Поэтому ответ — эффективность многоядерности зависит от задачи. 1000 ядер в десктопных компьютерах я не представляю, но числа порядка сотни — вполне возможны. 80 ядерный прототип процессора был создан Интел еще пару лет назад.
И я бы согласилась с предложением ctrlok взять драйвера с intellinuxgraphics.org/ возможно, это поможет.
И еще — поскольку *nix очень много, протестировать все возможные конфигурации очень тяжело. А значит, нет никакой гарантии, что производительность портит именно драйвер IIG, а не сама операционная система, или какой-то сторонний софт.
А вообще, вы правы — фраза дико корявая, и вообще Intel не свойственная, тут у нас с этим (дискриминацией по любому признаку) очень строго.