crsib
> C PIV уже не предпочитает.
На P4 ещё как предпочитает, посмотри внутреннюю архитектуру. P4 это вобще убожество, которое долго подпирали как только можно, но в результате оно закономерно скопытилось. Заместо имеем CORE от дочернего отделения, взглянув на который можно увидеть, фактически те-же решения, что и у AMD десятилетней давности только на новом уровне и в большем количестве.
>Ты еще вспомни, что до 486DX
В 80486 сопроцессор был уже интегрирован.
>Что значит одно устроиство?
Значит, что команды FPU и SSE выполняются на одних и тех же float point unit.
AMD фан детехтед. Тему срочно во флейм
doc.
> посмотри внутреннюю архитектуру
Она была убогой из-за того, что была длино-конвейерной (31 стадия, если быть точным). При этом любой бранч мисс приводил к сбросу конвеера в начальное состояние. На Core и AMD конвейер имеет длину не более 12.
doc.
> В 80486 сопроцессор был уже интегрирован
Учимся читать: до. В 486SX, к слову, это был отдельный чип.
doc.
> Значит, что команды FPU и SSE выполняются на одних и тех же float point unit
Я не знаком с архитектурой AMD. Но на интелах вообще нет различия между фпу и алу.
crsib
>AMD фан детехтед.
Архитектура K7 объективно лучше чем NetBurst, хотя бы в силу того (если не устравают другие причины), что последняя умерла так ничего и не породив.
> Она была убогой из-за того, что была длино-конвейерной
И это тоже. Хорошей иллюстрацией того "как делает Intel" может служить например времена латентности для MMX команд.
>Я не знаком с архитектурой AMD.
Обе схемы "в разрезе":
http://www.gigamark.com/content/view/108/100/
>Но на интелах вообще нет различия между фпу и алу.
Различия есть. Просто у CORE к одним и темже портам подвешены устройства FPU и ALU, а у AMD висят на разных "портах" если в тех же терминах.
http://en.wikipedia.org/wiki/File:Intel_Core2_arch.svg
crsib
Все эти сравнения - пластмассовая ахинея для маркетологов. Реальные замеры дают несущественную разницу на сравнительно небольшом наборе данных. SSE рулит на обработке больших массивов (видеокодирование, к примеру), на умножениях матриц не выедешь. Не считая того, что до тех пор, пока умножение матриц не будет узким местом, все эти пляски вокруг SSE - полная фигня. А это надо хорошо в архитектуре 3Д-движка постараться чтобы упереться в умножение матриц.
doc.
> Архитектура K7
K7 - не спорю. А вот К10 - провал
Necrys
> Реальные замеры дают несущественную разницу на сравнительно небольшом наборе
> данных
Ровно как и любимая многими на этом форуме разница в стоимости виртуальной и не виртуальной функции. Однако, если очевидно, как сделать код быстрее (пусть и не самую критичную секцию), то почему бы этого не сделать?
Necrys
> 3Д-движка постараться чтобы упереться в умножение матриц
Вот не надо обобщать, это сильно зависит от платформы.
crsib
> Ровно как и любимая многими на этом форуме разница в стоимости виртуальной и не
> виртуальной функции. Однако, если очевидно, как сделать код быстрее (пусть и не
> самую критичную секцию), то почему бы этого не сделать?
Потому что в этом нет смысла, если программа утыкается в производительности совсем в другом месте, то нужно бросать силы на оптимизацию этого места, а не тратить время на сферическую производительность в вакууме.
crsib
> Однако, если очевидно, как сделать код быстрее (пусть и не самую критичную
> секцию), то почему бы этого не сделать?
если это не сказывается заметным образом на производительности - надо выбирать вариант более читабельный, красивый и понятный, а главное надежный!
crsib
> А вот К10 - провал
С чего это вдруг? K10 это всё таже K7 только несколько форсированная. При прочих равных у CORE больше исполнительных устройсв - он и показывает большую производительность. Вот если K11 не будет показывать большую производительность чем CORE2 вот это будет провал т.к. речь будет идти о новой архитектуре, а не модификации старой.
Necrys
> то нужно бросать силы на оптимизацию этого места, а не тратить время на
> сферическую производительность в вакууме.
Большая часть времени все равно уходит на архитектуру, а не на реализацию. А хорошо знание платформы, под которую пишешь, однозначно не является помехой. В дальнейшем сильно помогает...
Kloun
> если это не сказывается заметным образом на производительности
Я уже говорил, что есть платформы, где это не так. Не везде есть мощные гпу, для которых умножение матрицы с хороший точность - раз плюнуть. И уж тем более, не везде есть возможность получить все что нужно на гпу. А вот векторные сопроцессоры более менее везде похожи. И я не вижу, по чему бы не потренироваться на кошках (когда это занимает максимум два рабочих дня), а заодно почти гарантированно исключить потенциальный ботлнек из кода.
Kloun
> а главное надежный
Не вижу, как надежность векторизированного кода отличается от надежности заведомо плохого варианта с двумя циклами. А читаемость - дело вкуса и привычки.
doc
> Вот если K11 не будет показывать большую производительность чем CORE2
Ты, пропустил выход нехалемов. Причем значительного числа разных процессоров, включая дешевые и мощные clarkdale. K10 - если уж на то пошло, это развитие К8, которое, в свою очередь - развитие K7. Цепочка слишком длинная, что бы быть конкурентоспособной... Амд сейчас отличается абсолютно гениальным маркетингом (круче только яблоки и нвидиа). Они штампуют новые процессоры на старых ядрах и пытаются всех убедить, что это круто...
crsib
> заодно почти гарантированно исключить потенциальный ботлнек из кода.
если ботлнек в перемножении матриц, оптимизацией умножения ты его лишь слегка уменьшишь, но не измбежишь!
по поводу остальных наездов - я прокомментировал одну конкретную фразу, про оптимизацию в вакууме, а не про умножение матриц.
crsib
> Ты, пропустил выход нехалемов.
Да тоже CORE по сути. Ситуация аналогична K7 -> K10.
>K10 - если уж на то пошло, это развитие К8, которое, в свою очередь - развитие K7.
Это не принципиально - последовательные модернизации при неизменной общей структуре породили K10 из K7.
>Цепочка слишком длинная, что бы быть конкурентоспособной...
Да нет, тут просто всё уперлось в принципиальное ограничение архитектуры - осталось только добавлять исполнительные устройства, а это уже влечет за собой полную переработку.
>Они штампуют новые процессоры на старых ядрах и пытаются всех убедить, что это круто...
Тут всё определяет цена/производительность.
Kloun
> но не измбежишь
Его не всегда можно избежать. А вот эффект от него можно снизить значительно. В общем, дискуссия зашла в тупик. Я далеко не сторонник преждевременной оптимизации. Но и отнюдь не сторонник пессимизации кода. И если можно сравнительно просто и быстро поднять производительность часто используемых операций, то я не вижу смысла писать потенциально медленный код. Кстати, мой первый пост был лишь попыткой не дать ввести топик-стартера в заблуждение о том, что fpu эффективней sse. На интелах это не так, даже в случае применения скалярных инструкций. И, кстати, приличный компилятор при наличии свитчей sse/sse2 будет минимизировать использование фпу в принципе. Однако, некоторое количество людей, не смотря на аргументированость моего поста, сначала начали убеждать меня что я не прав, и все православные люди используют только фпу (в начале (до моего поста) даже поступали предложения писать математику на ассемблере, но с использованием фпу). Когда аргументация этих людей кончилась, мне начали активно рассказывать, что я не прав из-за того, что потратил суммарно около 8 часов на написание и отладку кода часто используемых мат. функций с использование интрисинков. И наконец, мне начали приписывать чужие фразы, говорить что я на всех наезжаю, и убеждать, что приложение всегда можно соптимизировать исключительно на высоком уровне.
Помимо этого, меня активно пытаются втянуть в холивар intel vs AMD, рассказывая всякие веселые истории про цена/производительность, приводя статьи, которые это опровергают и показывая диаграммы, на которые я и сам ссылался.
Однако, давайте же наконец обратим внимание, что тема находится не во флейме и мы слишком сильно отклонились от темы. Топик-стартер так вообще исчез из нашей милой дискуссии
Да уш... видимо и впрямь тупик.
лично у меня тесты на AMD и завтра попробую через 3dNow, но честно говоря, не очень рассчитываю на достаточно хороший результат по быстродействию =\
crsib
> Однако, некоторое количество людей, не смотря на аргументированость моего
> поста, сначала начали убеждать меня что я не прав, и все православные люди
> используют только фпу (в начале (до моего поста) даже поступали предложения
> писать математику на ассемблере, но с использованием фпу). Когда аргументация
> этих людей кончилась, мне начали активно рассказывать, что я не прав из-за
> того, что потратил суммарно около 8 часов на написание и отладку кода часто
> используемых мат. функций с использование интрисинков.
Повторю ещё раз, если не дошло с первого раза - прямой нормальный тест, с пристальным разглядыванием
ассемблера сгенерённого компилятором не показал тотального превосходства sse, местами провалы, по крайней мере
именно в области умножения матриц. На интеловском процессоре, да.
правка: правка
FearOfTheDark
> лично у меня тесты на AMD
Моя догадка (из №44) оказалась верна.
Necrys
> не только не показал тотального превосходства sse, по крайней мере
> именно в области умножения матриц.
Ошибка компиляции фразы. Отсутствует конец. Не ясен контекст последующей фразы.
Тема в архиве.