В Интел начиная с Санди(если не раньше)
И ИНтел и АМД имеется, но пока было без единого(общего) адресного пространства

Полноценное ядро - целочисленное, без него никак, так как адресация данных целочисленная, FPU лишь опциональный сопроцессор, обязательный далеко не во всех архитектурах/процессорах и не сразу был даже в Интел-процах
В тестах/приложениях где применяется AVX256 нет прироста от НТ и там i5=i7
А так и есть, количество FPU в i5, i7 и FX одинаково (только в Хасвеле кажись они удвоили ширину) а оптимизации компиляторов на стороне Интел

Угу, в микробенчмарках. Когда в бенче разница в 2-3 раза, а на деле в реальном приложении 5-6 процентов.

Renegade1979

почитай, просветлеешь

http://www.osp.ru/os/2013/08/13037850/

Ещё можешь глянуть материалы с недавней APU13, где Kaveri называют не иначе как first HSA support.

Вы сравнили картошку и апельсины "ибо и то и то круглое" и на основании своего неверного сравнения сделали совершенно неверный вывод. Модуль AMD это не одно и тоже что и ядро Intel. Поэтому сравнивать их на основании равенства чего-то это глупо. Модуль это два ядра с общими некоторыми блоками. Претензия к модулю AMD что он не использует все ресурсы модуля, сродни претензии к Intel что в однопотоке они не используют ресурсы всех 4-х ядер процессора.
Ядро Intel быстрее ядра AMD в однопотоке? Так никто и не спорит. Да, быстрее. Одна из причин как раз в том что у AMD на одно ядро АЛУ в два раза меньше чем у Intel.

Тех же, кто считает что ядра считаются по кол-ву FPU - я отправляю на несколько десятилетий назад, в начало 80-х, во времена 8086, 80286, 80386. И напоминаю что процессор, ядро процессора, это изначально были блоки для чисто целочисленных вычислений. Со-процессор для вычислений с плавающий точкой это была отдельная микросхема (8087, 80287, 80387), которой в компе могло и не быть. Во внутрь процессора сопроцессор переехал только с 80486DX, но это не значит что ядро без сопроцессора перестало быть ядром. Тогда, если кто забыл, не было никакой многоядерности и одно ядро процессора с одним сопроцессором под одной крышкой, на одной микросхеме это было логично. Так же как в последствии стало логично перенести на процессор северный мост и прочее. Сейчас же, в эпоху многоядерности, AMD сделала очень интересны и вполне логичный ход, сократив кол-во "со-процессоров" вдвое от количества ядер. Логично рассудив что большая часть кода, это целочисленные операции и один со-процессор может удовлетворить нужды двух процессорных ядер.
Соответственно ядро - это ядро. Модуль - это модуль. И сравнивать их между собой это невежество.
Ядро Замбези\Вишеры содержит меньше АЛУ чем Феном - да. Потому что AMD рассчитывала покрыть эту разницу повышенной частотой.

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

Да ладно. Ткни их носом в UltraSparc T1. 1 FPU на 8 ядер.



К сожалению, в реальности прирост от перехода AVX256 -> AVX128 примерно 3-4%, потому что выше головы не прыгнуть. Либо в 2 раза быстрее, либо в 2 раза шире.
Не стоит забывать, что Intel тоже умеет AVX128 и таки да, оно и у них ВНЕЗАПНО тоже исполняется быстрее.

Дело в том что Санди умел исполнять своим 256-битным FPU одинаковое количество AVX256/AVX128, а бульдозер может AVX128 исполнять в два раза больше AVX256 так как FPU разделяемое

Учту, не знал.



Только профита от этого чуть.



Это, к слову, разработчики GCC.

Просто в некоторых случаях данные могут быть порциями в 128 бит, и использовать для этого AVX256 не рационально(если они с одного потока то можно упаковать в одну 256, а если с разных?...), и как раз тогда AVX128 оказывается в выигрыше. В случае 256бит порций, без разницы что запускать, 2*128 или 1*256(но и так нашлось пару процентов)

Там эта пара процентов из-за меньшей порции данных, сильнее забиваются конвееры и меньше простоев из-за подгрузки данных из памяти/кэша.



Скажем так, сильно узкая направленность. Вообще, ситуация мне не нравится - куча расширений SSEx/AVX/FMA/XOP/TBM, а используются чуть.

если всё так просто, и поддержку ускорения вычислений видяхой для проца на HSA и hUMA можно будет организовать даже на 7970 и Вишере, переписав код, Нвидиа напишет свой аналог для Кеплера, CUDA 6.0 для этого и предназначена. Если же потребуется именно какая-то сугубо желазная архитектура APU, вдобавок придётся переписывать ядро ОС, всяческие HSA отправляются в консольки и под них напишут аналог физюхса на OpenCL, а на ПК это разумеется не портируется, так как японцам лень (боксван разумеется не потянет, аналог 7790, да)

Бред, у обоих своя отдельная память.

в играх 8350 обычно и показывает то же, что и тесты FPU в Aida64, то есть идёт в районе i5 2300, таких игр чтобы 8350 взлетал под 3770К, как в тесте CPU AES или CPU Hash, просто нет, значит FPU в играх важен чуть ли не более, чем целочисленные операции. Если такие игры есть, где FPU не важно, то они от ЕА, получивших взятку, и нагрузка там фэйковая, и они обычно являются насквозь забагованными клонами Крусис 2, который теперь чудом стал при той же нагрузке требовать все 16 потоков, и Батлы 3, в которой традиционно 6970 сливает 570й, даже спустя 2 года, а для достижения заветного слива Кеплеров и Интела DICE наделали столько багов, что патчить будут ещё год, и уже сейчас видно, что грофоннн там как был из 3й Батлы, так и осталсяя сказал "если", я и сам не верю в "расчудесное будущее всяческого HSA" (вот это действительно бред), которое работает только на APU от АМД - много ли наускоряешь вычислений встройкой? Физикс и волосикс у нас уже есть, и много где используется, а тут отнюдь не примочка для ускорения физики и волосики, а переписывать всё приложение, после чего его даже на ПК не портнуть. А ведь Kaveri кажется такая себе десктопная архитектура? И значит будет под неё Венда, и в Венде будет C++ и проги будут лагать. А если прогу напишет киевское отделение Убийсофт, лагать будет даже на топовых i7, пока не разгонят до минимум 4,8

Renegade1979



Теперь по буквам:

1. HSA не зависит от ядра ОС и его драйверов под GPGPU вычисления!!! Смотри HSAIL по ссылке. Главное, что бы софтина сама по себе поддерживала HSA, остальное не важно. HSA без проблем запиливается на любой процессор, хоть ARModroid.
2. Если верить старым роадмапам AMD когда программа ещё называлась Fusion (потом эту торговую марку у них отсудили, так как она уже была зарегистрирована), то в 2014 году нас ждут дискретные видеокарты с поддержкой HSA. То есть, на 7970 это не реализуемо. На Vishera возможно только вместе с дискреткой.
3. Консоли это консоли, а Kaveri как мы знаем ещё и в ноуты ставиться будут. Так что география распространения гораздо шире. Я вам больше того скажу, Mali T600 уже поддерживает HSA в виде HUMA. Так что вы и в планшетах-смартфонах её увидите.
4. nVidia для начала неплохо было бы обзавестись лицензией на х86 набор команд, что возможно только в принудительном порядке. Тогда да, они смогут сделать свой APU, а единое адресное пространство с процессором они то же обещают в 2014 году уже в Maxwell, только кому нужна проприетарная CUDA, когда есть поддерживаемый всеми производителями железа OpenCL, который например может использоваться в HSA как и Direct Compute.

Добавлено спустя 7 минут 1 секунду:


Вы знаете порядок цифр производительности вычислений CPU и GPU в гигафлопсах? Я вам скажу, разница там в разы, в пользу GPU конечно.


Чем занимается Coral и Adobbe знаете?

на самом деле в Максвелл обещается только новая архитектура, ускоряющая и облегчающая доступ, а поддержка унифицированной памяти начинается уже с Кеплеров, и в списке поддерживаемых API у них OpenCL 1.1, так что при желании могут использовать и всяческий HSA под OpenCL. А вот старьё 2011 года нужно будет апгрейдить.

Ммм... Нет. В документации явно указывается необходимость в новом IOMMU для hUMA.



Вот только HSA - это уже OpenCL 2.0 по Кроносу.

[quote="Renegade1979"][

http://www.overclockers.ru/hardnews/533 ... xwell.html

Впрочем, кое-что о преемнике Kepler компания NVIDIA уже успела рассказать. Например, известно, что в процессоры с архитектурой Maxwell будут добавлены вычислительные ядра общего назначения с архитектурой ARMv8, известные под кодовым именем Denver. Совсем недавно стало известно, что начиная с решений поколения Maxwell NVIDIA планирует использовать технологию виртуальной памяти, в рамках которой центральному и графическому процессору будет предоставлен параллельный доступ к общей памяти.

наускорять c 0,856 TFLOPS можно, это чуть больше чем в третьей плойке, главное, что именно и как опять же - APU для того и создан, чтобы не покупать дискретку, значит карта будет как минимум занята дисплеем или рендером Бэтмана (на минималках в 720р), а не ускорениями CPU, а всякий физикс железяка вроде PS3 просто не потянет... гтс450 может потянет и выше, так что серьёзного буста вряд ли выйдет даже в теории в Винраре, и придётся писать HSA виндар на OpenCL 2.0, который никто не поддерживает, кроме некстген консольков, соотв. разрабы Винрара могут послать эти Кавери к чоррту
ЗЫ за встроенные Денверы ещё бабка надвое сказала, пусть сам Wang выйдет на сцену и скажет, что будет где-то кроме Тегры, АРМ в десктопе и HPC, странное сочетание... Тесла обычно не ставят на сервера с Ведроидом, а в десктопе тем более ARM не надо, что ядра будут делать это вопрос
http://devblogs.nvidia.com/parallelfora ... in-cuda-6/ тут написано где и как будут применять, сам 6.0 ещё только разрабатывают. Выйдет как всегда, у АМД HSA, у Нвидии CUDA и каждый будет в своём, на консолях и в Тесла. Га ноутбуках с Кавери будет Венда, а в ней С++, как обычно.

Вот только для ПК пользы минимум.

Это те у которых 8 ядер планируются? Ога, все прямо побегут яву под HSA точить, когда можно не париться и юзать те 8 ядер.

Ребят, список участников HSA foundation то гляньте.
"Никто не будет поддерживать", ля-ля и так далее.
Куда денутся, будут как миленькие.