Конечно! А еще добавляет в силикон для производства процессоров человеческую кровь.
Не знаю как вас убедить в том, что ваш комментарий — чушь полная, скажу только, что ни один разработчик софта не согласится покупать и использовать компилятор, дающий ухудшение производительности примерно на 1\3 всех клиентских машин (доля AMD).
Установить пользователи AMD конечно, смогут. Но не точно также :) Установка предполагается только через специальную программу-клиент, а она не должна ставиться на неинтеловские cpu.
2) ответ там точно есть. Если ARM придет на десктоп, то будет АRM на десктопе :) Естественно, только на том, который предназначен для потребления контента. На десктопах-создателях контента Арма не будет по причинам отсутствия соответствующего софта, а, главное, недостаточной для этого производительности.
3) у меня, как у частного лица, тоже насчет «Атома на смартфонах» большие сомнения — объективных причин иметь его там нет, зато недостатки, которые вы упомянули- «размер, время жизни от зарядки»
пока есть.
4) я бы поспорила с этим комментарием, если бы он не спорил с собой сам :) а именно, начало — «Если строить ARM-процессор и x86-процессор по одним и тем же принципам, ARM уделает x86 с огромным приемуществом», с которым я не согласна, конфликтует с концом -«потому что альтернативные архитектуры в современных условиях эффективнее.» С концом я согласна.
Чуть-чуть расширю ответ Марианны, конечно же, оставаясь в рамках NDA :)
Смыслов жизни у Ларраби — два. Первый — это максимальная производительность, второй — максимальная совместимость-легкость обычного многопоточного х86 программирования.
Второй пункт означает, что специальная среда разработки просто не нужна. Нужна она в тех случаях, когда «не все так просто», а разработчики Ларраби старались этого не допустить. Поэтому Larrabee SDK, а также при желании, набор оптимизированных под Larrabee библиотек — это все, что нужно разработчику. OpenMP, p-threads — это все прекрасно поддерживается Larrabee.
Ядра Ларраби — х86 (т.е. 32 бита) с поддержкой 64битного расширения. Но у Ларраби есть очень полезные с точки зрения производительности SIMD инструкции, шириной 512 бит. Кстати, информация по ним открыта, более того, вы можете уже сейчас бесплатно скачать с сайта Интел эмулятор интринсик-функций этих инструкций (функции просто реализованы на С\С++).
Поясню ситуацию. Жульническая оптимизация, на которой попадались другие компании — это на 90% просто неделанье картой какой-то части работы, которую на глаз заметить трудно, но время таким образом экономится. Т.е. определяем, что у нас конкретный тест\игра и, грубо говоря, не рисуем каждый 100ый треугольник, или упрощаем формулу смешения текстур и тп. Еще 10% — это написание в драйвере спец. пути под конкретный тест, т.е. если известно заранее, по каким if мы будем ходить, какие шейдеры выполнять, то много чего можно просчитать заранее, сэкономив время. Также можно сэкономить его на (пере)выделении памяти, если знать заранее, чего и сколько понадобится. Все это — именно жульничество, и ничего больше.
К ситуации с интегрированными картами Интел оно отношения не имеет.
А именно, у карт Интел есть 2 режима работы: с софтовым преобразованием\освещением вершин и шедингом и с хардверным. При этом, делаться будет абсолютно то же самое, только либо на CPU либо на GPU. Но в зависимости от конфигурации системы (прежде всего, от качества CPU) и выполняемой конкретной графической программы, быстрее может оказаться или один метод или другой.
Узнать заранее с приемлемой точностью, что быстрее — невозможно — для этого надо выполнить и так и сяк и посмотреть :) Но, увы, в реальных приложениях такой возможности (выполнить один кусок дважды и сравнить результат) обычно нет. Кстати, не факт, что если маленький кусок будет лучше одним способом, то и целое приложение — тоже.
Поэтому делается такая вещь — по умолчанию интегрированная карта интел работает «в железе». Но для некоторого набора приложений и конфигураций системы инженерами Интел проводятся тесты — выясняется, что быстрее — CPU или GPU. После чего, если оказывается, что CPU быстрее, то названия этих приложений вносятся в спец. файл, поставляемый вместе с драйвером (кстати, пользователь может его модифицировать, если считает, что его приложения идут быстрее на CPU). После чего работа с приложениями из списка идет по софтовому пути.
Я не считаю это жульничеством, но понимаю, что это — скажем так, «криво». Поэтому сейчас инженеры Интел работают над тем, чтобы все-же определять «на лету», какой же метод обработки вершин будет лучше в конкретном случае.
1. Да, будет
2. Ключевая особенность Larrabee -это не только производительность, поддержка D3D и OpenGL, но и попытка сделать его максимально дружественным программисту для разработки native кода, а также — максимально «совместимым». Насколько получится решить эту задачу, вы увидите сами, когда Larrabee появится.
У Интел есть давний опыт сотрудничества с производителями игр — еще в 90-ые годы Интел выпускал свою дискретную видеокарту, а далее — целую линейку интегрированной графики. Ларраби — совсем не исключение. Так что тут Интел весьма конкуретоспособен. На остальную часть вопроса, а также на вопрос№3 советую поискать ответ в NVidia.
4.Интел уделяет громное внимание именно графическим вычислениям на GPU. Мы не только работаем со многими ведущими компаниями в этом направлении, но и имеем свои собственные разработки. Появится Larrabee — увидите.
5. «Первые руки» бывают разные. У наших инженеров, увы (или ура) нет полномочий подтверждать\опровергать подобные новости.
Добавлю к ответу 4., что это писалось ДО IDF 2009. А как раз на IDF был показан работающий образец Larrabee -подробности есть на многих сайтах. Выводы делайте сами :)
В дополнение к ответу Владимира скажу, что даже среди геймеров (если речь не идет о самом-самом hi-end) видеокарта не всегда главное — в играх сейчас есть и физика и искусственный интеллект, да и немалая часть того же d3d — runtime выполняется на CPU, а не на GPU.
И еще — по правилам игры доп. вопросы (после 15:00 сегодняшнего дня) не принимаются, так что этот ответ — вне конкурса.
вектор развития CPU — именно такой. Хотя говорить не только о точном количестве ядер, но даже об их модели (возможно, это тогда уже будет не i7 и не Larrabee), я бы не стала.
Не знаю как вас убедить в том, что ваш комментарий — чушь полная, скажу только, что ни один разработчик софта не согласится покупать и использовать компилятор, дающий ухудшение производительности примерно на 1\3 всех клиентских машин (доля AMD).
Вот вычисление пи интегрированием.
Экспериментируйте :)
#include <stdio.h>
#include <time.h>
long long num_steps = 1000000000;
double step;
int main(int argc, char* argv[])
{
clock_t start, stop;
double x, pi, sum=0.0;
int i;
step = 1./(double)num_steps;
start = clock();
#pragma omp parallel for private(x) reduction(+:sum)
for (i=0; i<num_steps; i++)
{
x = (i + .5)*step;
sum = sum + 4.0/(1.+ x*x);
}
pi = sum*step;
stop = clock();
printf(«The value of PI is %15.12f\n»,pi);
printf(«The time to calculate PI was %f seconds\n»,((double)(stop — start)/1000.0));
return 0;
}
3) у меня, как у частного лица, тоже насчет «Атома на смартфонах» большие сомнения — объективных причин иметь его там нет, зато недостатки, которые вы упомянули- «размер, время жизни от зарядки»
пока есть.
4) я бы поспорила с этим комментарием, если бы он не спорил с собой сам :) а именно, начало — «Если строить ARM-процессор и x86-процессор по одним и тем же принципам, ARM уделает x86 с огромным приемуществом», с которым я не согласна, конфликтует с концом -«потому что альтернативные архитектуры в современных условиях эффективнее.» С концом я согласна.
software.intel.com/ru-ru/blogs/2009/08/13/iii/
software.intel.com/ru-ru/blogs/2009/08/10/arm-atom-x86-pda-umpc/
software.intel.com/ru-ru/blogs/2009/08/12/ii/
полагаю, что там есть ответ на ваши вопросы
Смыслов жизни у Ларраби — два. Первый — это максимальная производительность, второй — максимальная совместимость-легкость обычного многопоточного х86 программирования.
Второй пункт означает, что специальная среда разработки просто не нужна. Нужна она в тех случаях, когда «не все так просто», а разработчики Ларраби старались этого не допустить. Поэтому Larrabee SDK, а также при желании, набор оптимизированных под Larrabee библиотек — это все, что нужно разработчику. OpenMP, p-threads — это все прекрасно поддерживается Larrabee.
Ядра Ларраби — х86 (т.е. 32 бита) с поддержкой 64битного расширения. Но у Ларраби есть очень полезные с точки зрения производительности SIMD инструкции, шириной 512 бит. Кстати, информация по ним открыта, более того, вы можете уже сейчас бесплатно скачать с сайта Интел эмулятор интринсик-функций этих инструкций (функции просто реализованы на С\С++).
К ситуации с интегрированными картами Интел оно отношения не имеет.
А именно, у карт Интел есть 2 режима работы: с софтовым преобразованием\освещением вершин и шедингом и с хардверным. При этом, делаться будет абсолютно то же самое, только либо на CPU либо на GPU. Но в зависимости от конфигурации системы (прежде всего, от качества CPU) и выполняемой конкретной графической программы, быстрее может оказаться или один метод или другой.
Узнать заранее с приемлемой точностью, что быстрее — невозможно — для этого надо выполнить и так и сяк и посмотреть :) Но, увы, в реальных приложениях такой возможности (выполнить один кусок дважды и сравнить результат) обычно нет. Кстати, не факт, что если маленький кусок будет лучше одним способом, то и целое приложение — тоже.
Поэтому делается такая вещь — по умолчанию интегрированная карта интел работает «в железе». Но для некоторого набора приложений и конфигураций системы инженерами Интел проводятся тесты — выясняется, что быстрее — CPU или GPU. После чего, если оказывается, что CPU быстрее, то названия этих приложений вносятся в спец. файл, поставляемый вместе с драйвером (кстати, пользователь может его модифицировать, если считает, что его приложения идут быстрее на CPU). После чего работа с приложениями из списка идет по софтовому пути.
Я не считаю это жульничеством, но понимаю, что это — скажем так, «криво». Поэтому сейчас инженеры Интел работают над тем, чтобы все-же определять «на лету», какой же метод обработки вершин будет лучше в конкретном случае.
2. Ключевая особенность Larrabee -это не только производительность, поддержка D3D и OpenGL, но и попытка сделать его максимально дружественным программисту для разработки native кода, а также — максимально «совместимым». Насколько получится решить эту задачу, вы увидите сами, когда Larrabee появится.
У Интел есть давний опыт сотрудничества с производителями игр — еще в 90-ые годы Интел выпускал свою дискретную видеокарту, а далее — целую линейку интегрированной графики. Ларраби — совсем не исключение. Так что тут Интел весьма конкуретоспособен. На остальную часть вопроса, а также на вопрос№3 советую поискать ответ в NVidia.
4.Интел уделяет громное внимание именно графическим вычислениям на GPU. Мы не только работаем со многими ведущими компаниями в этом направлении, но и имеем свои собственные разработки. Появится Larrabee — увидите.
5. «Первые руки» бывают разные. У наших инженеров, увы (или ура) нет полномочий подтверждать\опровергать подобные новости.
software.intel.com/ru-ru/blogs/2009/08/12/ii/
software.intel.com/ru-ru/blogs/2009/08/13/iii/
нет, я говорю не о Silverthorne, а о Pineview и дальше. Вы можете не верить, но Atom от этого хуже не станет :) остальное я сказала в своем блоге.
И еще — по правилам игры доп. вопросы (после 15:00 сегодняшнего дня) не принимаются, так что этот ответ — вне конкурса.