Легко и непринужденно. Учитывая, что в отличие от ПК нагрузка на ЦПУ будет намного меньше со стороны системы и второй чип можно, к примеру, (но не обязательно) использовать в качестве ускорителя. да и двухчиповые/четырехчиповые процессоры как-то под одной Windows уживаются уже давно


28нм.
http://www.extremetech.com/gaming/156273-xbox-720-vs-ps4-vs-pc-how-the-hardware-specs-compare



1. https://www.overclockers.ru/lab/69675_2/izuchaem-processory-intel-broadwell-test-igpu-s-vneshnej-videokartoj-a-takzhe-podvedenie-itogov-2d-3d.html#6
2. http://www.thg.ru/cpu/obzor_intel_core_i7_5775c_i5_5675c/obzor_intel_core_i7_5775c_i5_5675c-02.html
3. http://www.3dnews.ru/916324/page-2.html#Производительность%20в%20играх (в нижней части - производительностьвстроенного графического ядра)
Хватит или продолжить?



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


Не выгодно. У Интела передовой техпроцесс и лидирующий продукт. И они логично не дают преимуществ своим конкурентам. Вот в консолях Интеловские чипы смотрелись бы неплохо сейчас. В отличие от кота в мешке имени АМД.


Чем их предыдущие чипы - вполне. Но до Интела им как из США до Китая раком. Компоновка чипов софтом дает о себе знать. да и интеловский 14нм техпроцесс лучше, чем айбиэмовский или TSMC-шный.


Нинтендо в любом случае разрабатывать API. И без разницы на чем - на ARM или на х86.


мы говорим о портативных переносных устройствах, которые фактически очень жестко ограничены TDP 15Вт. Но достаточно глянуть на чипы applied micro и cavium, чтобы те же самые консоли на ARM не казались фантастикой. Особенно, учитывая наличие у Нвидии полноценных и весьма производительных GPU, подходящих для консолей. В отличие от того, чем снакбжается все в мобильном сегменте вроде всяки Adreno, которые ещё лучшие из того что есть на рынке. А есть и много худшие. да и вообще, если серьезно, посммотрите как-нибудь игрушки серии Demon Hunter на андроиде. 4 или 5-ую версии. Если для такой игры хватает тостаточно унылых плоаншетно-смартфонныхз ЦПУ, что ещё нужно консоли? Вот АМД-шные встройки сегодняшнего дня явно что не тянут. насчет полярисов пока не сильно понятно, ибо до реальных тестов можно только гадать на кофейной гуще.

ничего нельзя упростить в апи - это само по себе звучит как шутка.
другой вопрос документация на вызовы апи и либами (с готовыми функциями под конкретные задачи) так вот у суда как таковых нет своих либ как и нет таких либ у опенсл.
и магия вопроса в том что хуанг не может делать документацию на либы которые с нв не имеют особого отношения... хотя за нв есть один прекрасный пример создание целого портала для разработчиков на суда - в этом согласен.

вопрос а суда кто нибудь будет изменять в угоду одного разработчика? это примерно как "мне не нравиться в ядре линукса *** переделывайте" - как минимум нужно быть уже не просто "разработчиком" и желательно быть оптовым покупателем "тесел".

у крупных разработчиков другая проблема - обычно это 10 продуктов и 10 групп работающих на этих продуктах перепрофилировать одну группу и закрыть разработку 1 продукта для крупной компании не составляет проблем. изначально крупные продукты в своей сути имеют "кор" группу и все остальные которые шлифуют продукт под конкретные задачи... так вот гонятся за новыми технологиями и тем более писать продукт с кучей "зависимостей" от внешней компании? да ладно...

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

Вообще-то RedHat по SR патчи выпускает)
Серьезный функционал и быстро, конечно предоставят только крупному заказчику, но и от остальных пожелания могут включить в план. И да, я говорил не о покупателях десятка карт Тесла.

Шутка-самосмейка?) Про упрощенный API ты вот сейчас заговорил, не я)
Я имел в виду наличие специализированной IDE и интеграцию со сторонними, сильно сокращающие число явных вызовов API разработчиком в коде.

Мне можешь не рассказывать
Дальнейшее комментировать не вижу смысла - я говорил о заказном софте и крупных заказчиках, имхо говорить о коммерческом gpgpu софте для датацентров пока рано, разве что рендеринг... но и там CUDA была первой.
Имхо вообще такой софт будет поддерживать несколько API, так как это хорошее конкурентное преимущество, с заказным же софтом проще выбрать что-то одно и сэкономить на разработке.

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

когда я вообще говорил про упращение в апи? )))

это как? если тулкит может интегрироваться в иде он уже может - "может еще лучше" это уже бред. например VS от майков поддерживает и то и другое.
при этом это какой "сильно сокращающие число явных вызовов API" бред... как это вообще должно быть реализовано? если в этом месте есть системный / или другой вызов апи он в любом случаи там будет хоть это суда хоть опенсл хоть дерект.

а я о ком? вы переставляете как создаются продукты типа "вмваре" как пример?

опять же врете сами себе.

Вы же это не серьёзно?
Никто не станет рассматривать всерьёз компоновки из двух чипов.
Из-за цены, потребления, но, главное - неэффективности в сравнении с одним чипом с примерно аналогичным числом ALU.



Ну, вдвое жирнее.



Заканчивайте.
Тесты с использованием Ирисок с еДрамом - вообще неинтересны, поскольку транзисторный бюджет там уже сравним с топами AMD/Nvidia прошлых поколений при многократном проигрыше им в производительности. Я уже о цене не говорю.
Без еДрама же, повторюсь, ни о каком размазывании речи не идёт - в лучшем случае догоняет. При цене (и, очевидно, себестоимости) в разы выше.



Платя за это себестоимостью.
Собственно, я давно говорил о том, что Intel - главный враг прогресса в отрасли. Хорошо, что сейчас их позиции ослабли.



Вас не смущает, что это приходит в голову только Вам?



Ну, разумеется!
Вы сознаёте, что в производительности x86 сегодня SIMD составляет не менее 60%? А в графике и все 80.
Как по-Вашему, сколько уйдёт лет на создание API (молчим сейчас про создание аппаратной части), который позволит ARM сравняться в этих задачах с х86 в производительности на ватт?
Я предположу, что даже в самых радужных мечтах понадобится не менее пары лет при серьёзных целевых инвестициях.



Вот в том-то и дело.
На иные ARM пока не претендует.

Демагогия утомляет.

Очевидно на уровне компилятора или уровнем чуть повыше, это лучше спросить у тех, кто разбирается в архитектуре IDE.
Я слышал, что в IDE Nvidia можно скопировать c-код и после минимальных изменений расчеты будут производиться на gpu.
Программист пишет С/С++ код и не задумывается, что пишет для GPU, ну почти. В случае с Xeon Phi вообще совсем не задумывается. А с OpenCL все немного по-другому.

Вовсе нет, это ты не желаешь видеть очевидных вещей. Коммерческий софт всегда поддерживает основные API и архитектуры, если иное не продиктовано идеологией. V-Ray использует оба этих API, а некоторые древние игрушки имели поддержку чуть ли не десятка 3D API.

VMWare - не продукт) Ты ESX/ESXi имел в виду?
Как создаются - не представляю, не имел дела с разработкой гипервизоров. Как внедряются у крупных заказчиков - еще как.
Я не знаю о ком ты, но VMWare поставляет типичный коммерческий софт.
Заказной софт - это другое, это то что нужно заказчику, а другим зачастую и даром не нужно. Такой софт используют банки, корпорации, государственные ведомства, научные учреждения и университеты.
Даже системы Бизнес-аналитики, которые весьма серьезно кастомизируются под заказчика я сюда не отношу.

a GTX 780, 980 и т.п. это OEM и IP или это что то другое?
кто то может?

Да, именно что слышал, я - не разработчик и нигде не утверждал обратное.

Я этим просто не буду заниматься, так как смотри выше.

На C++ когда-то немного побыдлокодил) На OpenCL и CUDA примеры видел, но не то чтобы они мне много рассказал
Если ты разработчик, и поработал или поэкспериментировал с этими API, я не буду спорить и доверюсь твоему мнению, что CUDA ничуть не проще для разработчиков в сравнение с OpenCL.

vSphere, в таком случае. Там полно компонентов для решения очень разных задач.

Их есть у меня ) На самом деле, их не так уж и мало, но они не на слуху. Имхо в РФ вообще большинство разработчиков работает именно в сфере заказного софта.
Да такой софт часто пишется "внутри" и не только для банков, в данном случае разработчик - департамент компании, подведомственная или дочерняя организация, даже специально под разработку юр. лица создают.
Аутсорсинг у крупных заказчиков есть. Многие были бы рады, если бы его было меньше или он отсутствовал вовсе, уж поверь
Про добавление 100 стоек, выражаясь твоим языком - на этом разговор можно заканчивать ЦОДы тоже не резиновые, очень часто нельзя просто так взять и добавить 100 стоек.
Но ты прав в том, что банки консервативны, к gpgpu они присоединятся позже. На gpu они могут считать аналитику, для транзакций, конечно, gpu не нужны.

Нет, ты! Критически взгляни на свои посты. Там полно эмоций и демагогии.
Но этот пост мне понравился - гораздо больше конструктива и аргументов.
Если отложишь в сторону желание непременно оказаться правым по всем пунктам, даже по тем, где тебе явно не достает компетенции (без обид), думаю, общение даже можно будет назвать приятным
Люблю споры, в которых рождается истина, но, к сожалению, у людей с неплохими знаниями на форумах зашкаливает ЧСВ и спор быстро скатывается в понты и флейм. Сам этим немного страдаю, чёужтам)

оно проще потому что есть понятный источник информации... на котором есть куча туториалов и описание тех или иных готовых решений. для опенсл такого нет - либо ищи сам (если оно вообще существует) либо пиши сам - что конечно часто ставит крест на применениях в продуктах разработчика.

на данный момент можно - броадвели с 22 ядрами намекают - выкидываем сервера 4-6 летней давности и ставят новые. профит.
... со временем да, но опять как показывает практика самые объемные "цоды" это холодные данные аки облака а они уж точно на гпу не перейдут (быстрей на арм)... тем более при таких размерах (не хватает одного дц) есть смысл построить их на разных концах "страны" или даже других стран. примером может служить ютуб (кстати ютуб использует гпу кодировку загружаемого видео? мне даже стало интересно...).