Молодцы AMD! Если всё сложится хорошо, то остальным придётся подвинуться.

AMD-шники начинают опять выстреливать, как в своё время с х64...

Добавлено спустя 4 минуты 49 секунд:
Infinite_madness

ЖЖОШЬ тонко и красиво... респект!!!!

А чо происходит? Чо за "хурма"?

это совсем не то? речь о едином доступе ко ВСЕЙ памяти, что решает один из самых неприятных минусов расчетов на GPU - сейчас же мы на CPU готовим исходные данные в памяти, копируем их в память GPU и отправляем задачу на обработку, потом копируем данные из памяти GPU обратно в обычную память и продолжаем работать с ними на CPU... В некоторых задачах это не критично, когда нет необходимости часто перекидывать работу с одними и теми же данными туда-сюда, а есть задачи в которых это происходит достаточно часто (прорисовка кадра раз в 30 секунд, например) и там это копирование становится узким местом, именно потому сейчас GPU не может заменить FPU, потому данный шаг с общей памятью это важнейший скачек на пути переноса работы FPU на GPU

drin как вы думаете, насколько крупный профит от этого получат технологии вроде WPF? Судя по описанию огромный

В CUDA (если говорить только по теме статьи о вычислениях) уже как два года реализовано унифицированное адресное пространство(когда адресация ЦП и ГП совпадает). При этом ещё раньше(примерно пять лет назад), как только CUDA появилась, копировать данные в память ГП часто было нежелательно, поэтому можно было выделить участок виртуальной памяти ЦП, который становился общими для ЦП и ГП. ГП мог считывать из этого участка данные и записывать в него, не копируя данные в свою память(когда затраты на "копируем данные из памяти ЦП в память ГП" и "копируем данные из памяти ГП обратно в память ЦП" соизмеримы со временем вычислений на ГП, это копирование просто не выполняется).
Ну и GPU сейчас не может заменить FPU далеко не из-за узкого места в памяти. Даже без этого узкого места использовать современные ГП вместо FPU нельзя, т.к. преследуют они разные цели.

А в чем проблема? На 64-битных системах тот же проржавевший x87 не используют, вместо него всё считают на SSE.

1. Как разрядность вычислительной системы связана с используемыми командами? Если я вам назову несколько вычислительных систем и разрядность их шин адреса и данных, вы мне сразу сможете сказать, какие команды на них используются, как они реализованы и преимущества одних над другими?
2. ЦП - это универсальное устройство. Как мы знаем, чем больше функций добавляется в устройство, тем оно становится все более громоздким и медленным. Т.е. устройство, которое умеет делать всё - медленное и плохое. И наоборот - узкоспециализированное устройство обычно не имеет ничего лишнего, в нём только самое нужное для максимального эффективного выполнения одной функции(энергоэффективность высокая, аппаратурные затраты низкие, производительность максимальная). ГП - это как раз узкоспециализированное устройство (он прямо так и называется "графический" процессор, а не универсальный). Именно поэтому ГП в задачах параллельных по выходным данным так сильно обходит универсальные процессоры. Чтобы убрать из ЦП FPU, и перенести их функционал на GPU, ЦП придется сильно потерять в своей универсальности, а ГП в своей узкой направленности.
3. Как говорится изучить программирование легко тому, кто не знает слово "производительность". Например, школьник, написав, функцию read чувствует, что знает все и реализовать сможет все и то, что он сейчас написал - идеально быстро и по другому это реализовать никак нельзя, а профессиональный программист знает, что эту функцию можно запустить пятью разными способами (например, синхронно, асинхронно, с блокировкой и т.д.), а чтобы узнать какой способ лучше, надо ещё и архитектуру конкретного процессора изучить, поэтому, если он все варианты во всех возможных случаях не проверит, то он не будет уверен, что выбрал самый быстрый вариант. Аналогично и при проектировании процессоров. ЦП - это не просто АЛУ, выполняющее операции. ЦП выполняет, например, такие функции, как защита кода, защита вв/выв, защита памяти(пределы, уровни доступа, запись, чтение, режимы системы и пользователя и т.д.), анализ кода, переупорядочивание кода, предсказание поведения программ, переключение между потоками, прерывания, синхронизацию, гибкую адресацию. Операции над числами - это всего одна из множества важных функций, которые процессор выполняет. Например, если начинает глючить ICQ, что не дает ей залезть в системную память напортачить там, убить другие приложения и всю систему? Почему она только сама себе хуже делает? Потому что остальные программы аппаратно защищаются процессором, и эта функция защиты ни чуть не менее важна, чем выполнение операций на FPU. В ГП большинство этих функций не реализовано (либо они там на примитивном уровне), т.к. на ГП самая основная и важная функция - вычисления и нет ничего важнее этого. Любая дополнительная функция замедляет ГП и делает его медленнее и менее эффективным. Кроме того FPU в ЦП и ГП работают по разному (использовать векторные операционные устройства ГП для выполнения скалярных операций на ЦП не очень целесообразно). Т.е. вопрос объединения настолько разных устройств намного сложнее, чем просто ликвидация узкого места в памяти. Т.е. если вы заранее знаете, что 99% ваших вычислений будут параллельными по выходным данным, то используйте мощный ГП - он будет эффективнее любого гибрида (т.к. он узкоспециализированное устройство и выполняет только одну функцию). Если мы хотим универсальное устройство под любые задачи, то гибрид под вопросом с многих направлений.

vodimitriy просто нужно убирать все эти костыли, вроде колец защиты, переключение контекста из режима ядра и обратно, аппаратная защита и прочее, а использовать нормальные сипы (Software Isolated Processes). И все. Скорость возрастет не на порядки конечно, но довольно ощутимо.

Проблема в том, что сейчас интелу толкать что-то действительно мощное - экономически невыгодно. А раз так, будь оно в миллион раз лучше, никто не пропустит, пока отдел маркетинга не одобрит... А от АМД сейчас ждать инноваций в области x86 глупо имхо, они мне кажется будут копать в сторону ARM и других альтернатив.

для этого существуют профайлеры и планы выполнения. Синхронные методы в асинхронные превращаются элементарно (когда идет работа с массивами данных, а это 90% всех длительных операций), поэтому проверка не составляет никакого труда. Что касается "асинхронно, с блокировкой" - 99,999% случаев асинхронно == double-checked locking, случаи асинхронного доступа без критических секций можно пересчитать по пальцем одной ампутированной руки.

Еще раз повторю, что ЦП должен реализовать эти функции в любом случае. О том, насколько хорошо они реализованы ваш уровень вам оценить точно не позволит. Для вас опять все просто - завтра заменим их на что-то другое и все проблемы исчезнут. А на самом деле проблема останется.


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


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

Зачем ЦП должен реализовывать эти функции? Ведь можно создать процессор, который будет оперировать родным языком каким-нибудь ПЯВУ, например, С/С++, но никто этого не делает. Потому что усложнять незачем уже и так сложное устройство. Если софт возьмет на себя часть задач, процессору незачем аппаратно делать то же самое.

В данный момент наблюдается практически монополия интел в области миддл-хайэнд сегмента ПК, офк это далеко не весь рынок, но тоже показатель. И видя, что они практически топчутся на месте (архитектурно), улучшая исключительно ГП (транзисторный бюджет на ЦП все тот же, однако архитектура +5% в бенчах это не очень круто) не могу сказать, что они во что-то вкладываются (исключая попытки воткнуть атомы в телефоны). Остается смотреть на шоу, кто раньше куда войдет: АРМ в десктоп или интел/амд в мобайл.

ок, дефайню: железо - исключительно PC, ОС - винда/линукс, платформа: .Net/Mono, настройки компилятора - определяются ECMA-335.

Зачем? Чтоб примерно понять почитайте развитие архитектуры x86, изначально в которой этих функций аппаратно реализовано не было и всё выполнялось программно. Например, зачем при появлении многопользовательских, многозадачных ОС, в которых одновременно могут работать множество пользователей и могут одновременно выполняться несколько сотен потоков, аппаратно реализовали защиту, а не оставили на программном уровне. Также почитайте почему ЦП появились другие усложнения. Специалисты, работающие в intel и amd очень глупые: и аппаратно реализовали те функции, которые программно работают быстрее и усложнили процессор, хотя это тоже невыгодно (и не оказалось у них такого специалиста, как Psilon, чтоб им объяснить, что они ничего не понимают в проектировании вычислительных систем). Да и другие производители, например, Nvidia, AMD, тоже должны были реализовать openGL и DirectX программно, а не на аппаратном уровне, ведь так быстрее и устройство будет проще.
Кстати, если вы чего-то не знаете и не умеете, это не значит, что все такого же уровня, как и вы. Делают специализированные процессоры, оперирующие ЯВУ. Если так случилось, что до сих пор вы о них не слышали, то не показывайте так уверенно свою ограниченность, говоря "никто этого не делает".

Вы, молодец, уже объективнее и понятнее. Осталось для полного "дефайна" привести полную спецификацию ПК(каждого из его устройств, но к сожалению вам их никто не даст), версию ОС, версию языка программирования, определить все внешние и внутренние воздействия, весь набор вх/вых данных ... и т.д. ... и написать конкретный "кусок" кода и .... Но я к большому сожалению сразу поставил перед вами невыполнимую задачу(но главная проблема даже не в том, что вы это не заметили). Очень жаль, что вы не поняли, что говоря про read, я не пытался дать вам шанс показать свои "меганавыки" в программировании(или в "троллинге"). Прочитайте ещё раз тот пост. Там я пишу о том, что человек с плохими знаниями не может понять всю глубину проблемы, считая её простой (read использовал только как показательный пример, но своими постами вы только подтвердили эту идею).

почитайте про Singularity и почему там не нужна половина "защит" современных процессоров

Ок, буду знать, спс за информацию

Я пишу код, который компилируется в байт-код виртуальной машины - JVM ли CLR ли мне не важно. И на какой конкретной железке оно будет запускаться: хоть на ксеоне, хоть через Xamarin на телефоне - по большому счету все равно. Если приложение не тяжелое, а например, клиент для веба, то при правильном проектировании один и тот же экзешник пойдет и там и там.

Я считаю, что абстракция >> производительности => нужно по возможности абстрагироваться от конкретной реализации. Принцип инверсии зависимостей, слышали наверное? Объекты должны зависеть от абстракций/интерфейсов, а не наоборот.

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

Как об стенку горохом. Вы знаете, что такое аппаратная и программная реализация? Знаете какая из них быстрее и эффективнее? Как можно быть таким нелепым, чтоб противопоставить ПО и аппаратуру(в Windows программный и аппаратный уровень защиты дополняют друг друга, в Singularity аналогичная ситуация). Я вам гарантирую, что функции любой эффективной и производительной ОС должны поддерживаться аппаратно (неважно как реализована защита информации, если в вычислительной системе есть аппаратная поддержка этой защиты, то она будет работать быстрее и эффективнее). Ещё раз говорю, прочитайте историю развития x86, проанализируйте и увидите, как развивались аппаратура и ПО, и почему были приняты те или иные решения. Вы очень удивитесь, что многие из архитектурных решений не были навязаны системой команд. Если вы продолжите настаивать на том, что аппаратные средства защиты работают медленнее, чем программные, то интерес к такой беседе быстро угаснет. Есть базовые принципы, которые за пол века никак не изменились, и какую бы новую ОС вы не стали реализовывать, вы их также будете использовать. Если ОС будет выполняться на ЦП, то он будет аппаратно поддерживать часть её функционала. Попытайтесь представить реализацию любой функции(ну хоть переключение с одной задачи на другую) в "Singularity" без аппаратной поддержки(когда, как вы хотите сделать, процессор будет представлять только АЛУ и никаких других функций выполнять не будет) и с аппаратной поддержкой и оцените эффективность.
И опять 25, изначально я вам пытался объяснить в чем сложность интеграции узкоспециализированного ГП в универсальный ЦП, а вы ничего не поняли из сказанного, и опять начали "на самом деле все просто, все проблемы вычислительной техники из-за х86, как только мы её ликвидируем, все проблемы сразу исчезнут". А далее ещё хуже, стали противопоставлять аппаратную защиту современных ЦП программной. Изначально вся проблема у вас была в узком месте - памяти. После небольшого разговора, все стало сложнее, и уже появились две проблемы: x86 и память. Думаю через пару месяцев вы выявите ещё 20 проблем, и я окажусь прав в том, что там все было намного сложнее, чем вы думали изначально, но боюсь вы этого не признаете.


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


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

Начну с конца, так будет логичнее

никто никого никуда не уводил

Жаль

ок, неправильно понял.

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

Я такого нигде не говорил. Перефразирую: в x86 куча костылей (Как и в Вин), призванных обеспечить максимальную совместимость с древним старьем (386).

Окей, в этом вопросе вы правы, я - неправ. Раз топик был об этом - вопрос закрыт. Удачи

Только скорости это не прибавило. В основном всё упирается в PCI-E. Кстати, как там у AMD c PCI-E 3.0 и числом линий? Т.е. 40 линий PCI-E у x79 Интел это мало.

Добавлено спустя 54 минуты 50 секунд:
Обычно гетерогеные вычисления подрузамевают алгоритмы, разные части которых выполняются на разных аппаратных платформах, а термин "разнородные вычисления" не понятно что означает.

Так, если у нас имеется часть программы выполняющаяся на CPU и часть - для GPU, то как им может быть безразлично на какой платформе выполняться. В крайнем случае, можно выполнить всё на CPU, если нет GPU, как в эру до gpgpu. Или можно использовать векторное расширение CPU, например, SSE или несколько ядер CPU, но это совсем разные вещи и тем более это не GPU. Поэтому что там задумала AMD не ясно.