Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

miShutka

1) НИЧЕГО ПОДОБНОГО
2) тоже глупость
3) Почти верно, не имело смысла увеличение кэша, ибо не давало прироста почти совсем, пэтому модели с большим кэшем сняли с производства, как экономически менее выгодные

Меня еще вот что удивляет. Ну пусть на 4-ядерниках сделали 512 кэша на ядро и 2м общего, допустим больше мешает ТДП и прочие онраничения. Но почему бы на 2-ядерники 4М не поставить? Ведь у него на 512*2+128*2= полтора мегабайта меньше кэша л1-л2, да еще на 2 ядра меньше, то есть по транзисторам 4ядерник с 2 метрами л3кэша даже труднее сделать чем 2ядерник с 4-мя. Так почему?

P.S. Отмазка, что 4 метра л3кэша ничем не лучше 2 не прокатывает, т.к. у 6600 прирост от лишнего кэша хорошо заметен по сравнению с 6400, особенно в играх

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


Начиная с тхандерберда АМД не сделала еще ни одного тупого шага. Если инженеры IBM сказали, что 6 мб будет в самый раз, значит в самый раз.


Откуда такие данные, о гордый обладатель мегапроцессора пентиум Д, разогнанного на рекордные 23%? Не уж то "всемогущие" аналитики мосада раздобыли их и выслали вам на мыло в качестве компенсации за позорное сидение на ddr1 (да простят меня просветленные владельцы сокет а и 939_х)?


Для справки: х2 с одним FPU на проц дышит в затылок, конуре с аналогичной ценой, у которого к стати, 2 FPU на проц. С добавлением 2_го FPU на К8Л рвет конуру, как тузик грелку, это очевидно. Добавим сюда новые частоты + любовь с Microsoft до гробовой доски и получим рваный в дымину интел. Виста не знает ни конроев ни нахаленков, но знает А64. Выводы о производительности при компиляции под other cpu делаем сами.


Да.... нахаленок еще та новая архитектрура - то же яйцо, вид с боку в 2х кратном зуме. Читаем мат. часть.


Не знаю как там у вас, а у нас в Москве, 939 пошел на ура, т.к. в конкурентах был только мертворожденный прескот. На АМ2 пересели те, кто устал от прескота или неудовлетворяла производительность сокет А. Конрой вышел слишком поздно.


Зачем мне дома оптерон????

Shadow_7

Чушь. Там где действительно используется этот "второй fpu" (то есть векторные SSE2/SSE3 инструкции) там K8 не то что не дышит Core, он просто отстаёт на несколько кругов. Например в перемножении матриц К8 отстаёт почти в 2 раза. Большинство современных приложений не поддерживают векторный SSE2, толку там от удвоенного FPU - ноль. Поэтому Коре превосходит в них К8 за счёт других улучшений (некоторых не будет в барселоне).

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

Afx

А рaзаве я с этим спорил? K8L видимо догонит Коре в векторном SSE2 (может быть даже кое-где перегонит на несколько процентов). Но никакого "рвет конуру, как тузик грелку," не будет. Это очевидно.

TyyOx91

Понятие "рвет как тузик грелку" крайне растяжимое. Некоторые и 5% разницы могут так назвать . Думаю, 40% преимущество над к8, как говорили в начале - вполне реальная цифра. Т.е. преимущество над равночастотным коре будет таким же, как щас преимущества равночастотной коры над к8. Другое дело что Интел может еще свои процы подразогнать, а там и 45-нм на носу. Может сложится такая же ситуация как и во времена носвуд/АХР, когда несмотря на больее высокую производительность на мегагерц АХР недотягивали до Р4.

В ОС-х версий х64, за которыми однозначно будущее, никакого ссе нету, т.е. либо ссе, либо х64, на к8 режим х64 уже дёргает ссе, на к8л будет дёргать подавно...

rzgd

Бред. Учите мат. часть. В х86-64 как раз только и остаётся SSE. Классический стековый FPU практически не поддерживается (не сохраняется контекст регистров при переключении задач).

Да там только SSE и используется. Кстати несколько интересных тестов расчёта DFT (Fourier transform) с помощью библиотеки FFTW оптимизированной для 64 бит (LINUX):
Дуал-кор Оптерон 2.2 ГГц:
http://www.fftw.org/speed/opteron-2.2GHz-64bit/
Xeon 5160:
http://www.fftw.org/speed/CoreDuo-3.0GHz-icc64/
На многих рассчётах Xeon быстрее до 3 раз (разница в частоте 36%).

Afx

Смотрите выше (тест рассчёта DFT). Вот это я называю - "как тузик грелку" .

Че то я ниче в тех ссылках не понял.Что такое DFT?

Afx

Рассчёт Fourier transform для различных размеров матриц с использованием различных библиотек. (В данном случае интересует библиотека fftw3 - как самая быстрая 64-битная с поддержкой SSE/SSE2)

Некоторых важных улучшений имеющихся Барселоне нету в Коре2 :D

VS 2005 отказывается компились под венду на платформу амд64 с ссе) т.е. оно предлагает выбрать архитектуру для платформы х32 - ссе, ссе2 и тп, или просто выбирается платформа х64.

А это то тут причём? Если в х64 модах используются симд неявно, ну и пусть, просто не надо указывать, что я хочу ссе1, ссе2, ссе3 или ссе4...указать надо что нужна платформа х64 и всё будет работать не зависимо от того есть в проце поддержка ССЕхх или нет
Добавлено спустя 10 минут, 12 секунд
уже и линуха в дело пошли, ещё в мак оси осталось всех порвать и тогда полная окончотельная победа
Добавлено спустя 1 час, 51 минуту, 26 секунд
вариант откомпилиный под х64 дёргает вариант под х32-ссе2, на моём компе в моём приложении)

Именно позволило) а Intel не может позволить себе уменьшить объем L2 кэша (что значительно снизило бы себестоимость процессоров), т.к. производительность упала бы существенно)

Более высокая производительность 90-нм K8 относительно их 65-нм аналогов никак не связана с размером кэша L2 (для младших 90-нм и 65-нм моделей он одинаков). Изучите этот вопрос подробнее)
Кроме того, AMD отказалась от выпуска моделей с 512 Кб кэша L2 на ядро еще летом, и касалось это существующих 90-нм моделей нижнего и среднего ценовых сегментов (младших Athlon 64 X2 и всех Athlon 64).
И этот шаг был продиктован исключительно экономическими соображениями, т.к. модели с 512 Кб L2 отличались от процессоров с 1 Мб L2 на ядро незначительным снижением производительности (и то не во всех задачах), а вот себестоимость падала существенно.
Если бы кэш L2 более 1 Мб на ядро значительно повышал производительность процессоров K8, незначительно повышая себестоимость, AMD бы напротив увеличила его.
В свою очередь, на производительность существующих процессоров Intel размер кэша L2 играет более значительную роль, что собственно отразилось на этой характеристике.

Уровень TDP не помешал AMD выпускать старшие модели своих процессоров именно с 1Мб кэшэм L2 на ядро, постигая при этом все более высокие тактовые частоты, а при отказе от 512 Кб L2 кэша для младших моделей процессоров, уровень выхода годных кристаллов на хорошо отлаженном тогда 90-нм техпроцессе был очень достаточно высок.

А вот это похоже на правду)

rzgd

Естественно, что отказалась предлагать выбор. Просто выбора нет - x87, ММХ и 3DNow не используются в 64-битном режиме.
http://msdn2.microsoft.com/en-us/library/bb147385.aspx
The x87, MMX, and 3dNow! instruction sets are deprecated in 64-bit modes. The instructions sets are still present for backwards compatibility for 32-bit mode, but to avoid compatibility issues in the future, their use in current and future projects is discouraged.

Читаем AMD Optimization Manual:
In general, 64-bit operating systems support the x87 and 3DNow! instructions in 32-bit threads; however, 64-bit operating systems may not support x87 and 3DNow! instructions in 64-bit threads. To make it easier to later migrate from 32-bit to 64-bit code, you may want to avoid x87 and 3DNow! instructions altogether and use only SSE and SSE2 instructions when writing new 32-bit code.


*никсы обзавелись поддержкой 64 бит, когда винда ещё в пелёнках лежала. И всё что связано с 64 битами (memory management, длинные целые и т.д.) там вылизано лучше чем в недоделке WinXP-64. Да и собственно, какая разница? Процессорные инструкции от ОС не зависят, поэтому и разница в производительность будет пропорциональной.


Вы хотели сказать: вариант откомпилиный под х64-ссе2 дёргает вариант под х32-ссе2, на моём компе в моём приложении)? Ну и дальше что?

я хотел сказать именно то что сказал.

могу подробнее:
1)при задании целевой платформы х32, возможно задать опцию компилятора "/arch:sse...", если не задать, то ессно оно не будет задействовано.
2) при задании платформы х64, на опцию "/arch" компилятор (cl.exe) пишет что он такой не знает (анкноун опшн), однако
появляются другие, недоступные для х32

я щас не помню, но по моему те дополнительные регистры в х64 (8 штук), в режиме х32 используются как раз для ссе

rzgd

Ещё раз повторю - для 64-битного кода компилятор не предоставляет возможности выбора архитектуры просто потому, что выбирать не из чего. В частности при генерации 64-битного кода для вычислений с плавающей запятой используются только SSEx инструкции.


Там есть 8 дополнительных целочисленных 64 битных регистров общего назначения и 8 дополнительных 128-битных ХММ регистров (используемых SSEx инструкциями).

Это где такое написано?
В приведёном вами отрывке по китайски, написано про миграцию старых х32 программ с кодом х87 и 3днав на платформу х64, и если предполагается код оставить 32-х битным, то х87 и 3днав! надо заменить на ссе, и всё.
Кстати рон-ов в атлоне в режиме х64 всё таки 16 64-х битных. 128-ми битных нету, для хранения одной 128-ми битной инструкции ссе используется два "внутренних" 64-х битных регистра фпу.

rzgd

Я привел две ссылки. В одной АМД не советует использовать х87 и 3DNow так как они могут не поддержваться 64-битными ОС. Во второй - подтверждение от MS что эти наборы инструкций не поддерживаются в 64-битной винде.
Впрочем, если вам этого не достаточно, надеюсь, что ответ одного из разработчиков VC++ убедит вас в том, что 64-битный VC++ не генерит х87 и 3DNow код:
http://forums.microsoft.com/MSDN/ShowPo ... 9&SiteID=1

Ну и? Если вы не внимательно читали, то обратите внимание сейчас - я говорил о 8 дополнительных регистрах. Остальные 8 пришли из х86 получив расширение до 64 бит.

Я не совсем понял к чему вы это сказали? Имелось в виду, что набор инструкций х86-64 получил дополнительные 8 ХММ регистров (относительно х86-32). Если же говорить о внутреннем устройстве процессоров, то х86 совместимые процессоры не исполняют на прямую х86 код (начиная с P-Pro), а транслируют его во "внутренний" risc-подобный. При этом ХММ регистры динамически переадрессуются на "свободные" места во внутреннем регистр-файле. При переходе с х86 на х86-64 здесь ничего не изменилось для ССЕ. Целочисленный регистр-файл стал 64-битным.