640 килобайт таки мало

lexa - 27/Мар/2010 12:04
Капитан Очевидность Я в свое время почти угадал.

В том смысле, что я предсказывал 64-битную адресацию, она физически стала 40-битной. Хотя размер индекса в одном массиве остается 32-битным (собственно длинных int нету).

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

Сама же G200 GF100 (представленная вчера в виде GTX470/480) выглядит черезвычайно вкусно. Всяких текстов в сети навалом, сам я отпишусь когда куплю, жевать чужие тексты довольно бессмысленно.

Comments

mrshurik (not verified) - 27/Мар/2010 15:17

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

mrshurik (not verified) - 27/Мар/2010 15:27

производители CPU это давно проходили. чтобы наращивать производительность простым масштабированием (частоты или кол-ва чего-то) нужно масштабировать все компоненты синхронно, а так не получается, прежде всего с памятью. вот и начинают придумывать кэши, префетчи, прочие хитрости.
с GF100 наблюдаем как раз это. всё упёрлось в память (пропускная способность у неё на уровне GF200), вот и пришлось усложнять архитектуру.
про 64-битную адресацию. мне кажется, что реально (логически) она так и осталась 32-битной. 40 бит = 32 бит + 8 бит (выбор страницы). понятно, что такой адрес можно сконвертировать в 64 бит. введение реальной логической 64-битной адресации потребовало бы 64-битные ALU, во-первых, а во-вторых лишние 64-битные адресные вычисления (медленнее).
ИМО честная 64-битная адресация имеет смысл когда нужен произвольный доступ к области больше 4 Гб. у видеокарты памяти может быть и больше 4 Гб, но "прыгать" шире, чем 4 Гб не нужно, ибо размер текстур и прочих буферов меньше. а значит можно эффективно использовать страницы.

atemik (not verified) - 27/Мар/2010 15:40

Как только мы начнем считать, а не рисовать - тут же потребуются offset'ы на >4G.
Да, и с какой стати 64-бит вычисления медленнее? (если не учитывать увеличение требуемой памяти)

lexa - 27/Мар/2010 16:11

64-битные плавающие вычисления на данной архитектуре - аккурат вдвое медленнее.
С целыми будет примерно так же, я думаю (или как в предыдущих версиях - 24-битные целые быстрые, а 32-битные - медленные, умножаем на два).

atemik (not verified) - 27/Мар/2010 21:07

Не, ну очевидно-же, что это проблема конкретной реализации (АЛУ узкие) и отсутствия жесткой необходимости. Архитектурные и принципиальные ограничения вряд-ли есть.

lexa - 27/Мар/2010 21:41

Ну в одном и том же количестве транзисторов можно сделать 2 32-битных АЛУ или адын 64-битный.

Я утрирую немного, но в первом приближении это так.

lexa - 27/Мар/2010 21:45

Кстати, на SSE та же фигня - за один раз обрабатывается 128 бит, а что туда напихали, 4 float или 2 double - это уже дело программиста.

Ну и масса других проблем, скажем сами данные вдвое больше, их меньше влезает в кэши, нужно больше читать-писать.

Не, 64 бита (что целые, что плавающие) - нужно по месту использовать, не допускать разбазаривания битов.

atemik (not verified) - 27/Мар/2010 22:28

А. В том смысле, что если мы умеем использовать сразу все "половинки" или "четвертинки" широкого АЛУ, то да 32 бита будут в 2 раза быстрее 64-х. Векторные особенности :)

lexa - 27/Мар/2010 23:14

Да даже без векторного ALU:
a[i] = b[i]*c[i]
Просто требует вдвое большей полосы по памяти. А память - узкое место. Да и кэши - не широкое.

lexa - 27/Мар/2010 16:12

Оффсеты есть, кстати.
Данные 4-байтовые (если интересует результат :), поэтому 32-битным интом можно 16 гигабайт адресовать. Пока - достаточно.

mrshurik (not verified) - 27/Мар/2010 17:27

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

atemik (not verified) - 27/Мар/2010 21:09

Блин. Больше вычислений-то откуда? Или мы все биты не параллельно считаем? Локальность данных и усложнение предсказания - вообще бред.

mrshurik (not verified) - 27/Мар/2010 22:39

бред - не бред, а факт. учите матчасть.
про локальность Алексей уже сказал, при равном объеме буферов/кэшей в них влазит меньше 64-битных указателей. 64-битных int ALU в GPU вообще нет.
про усложнение предсказаний (в GPU их пока нет), а на CPU к примеру на Core2 в 64-битном режиме производительность хуже, отключается micro-ops fusion, ну и др. по мелочам.

lexa - 27/Мар/2010 23:09

Там что-то хуже, что-то лучше. Регистров в 64-битном режиме больше, это вот плюс. Например.

atemik (not verified) - 28/Мар/2010 20:29

Читаем внимательно первоначальное утверждение. С памятью все понятно. А про усложнение предсказания переходов таки интересно. Да, и

> отключается micro-ops fusion

а цитату можно? Желательно из интеловских док :)

lexa - 28/Мар/2010 20:59

Ну, в 2006-м, как показало гугление, отключалось macro-ops fusion.

Возможно, с тех пор интел и починил, я не вдавался.

lexa - 28/Мар/2010 21:01

Как показало дальнейшее гугление, в i7 починили, соответственно в core2duo было именно так (именно macro fusion не работала в 64-битном режиме)

atemik (not verified) - 29/Мар/2010 13:00

Судя по тому-же гуглу, в Nehalem это починили. Так что детские проблемы реализации потихоньку лечат.

lexa - 28/Мар/2010 21:04

Да и просто "память" - интересный такой аргумент.

Я тут как-то насчитал (наоценивал) что в одном проекте на 500Мб входных данных должно получиться мегабайт 700 одних указателей. Прослезился.

lexa - 27/Мар/2010 16:14

Я не знаю, сколько памяти будет на новых теслах, но не исключаю что больше 4 гигов. Она, естественно, может понадобиться вся.

Сегментировать - неудобно (вот OpenCL с ограничением в размер объекта - ужасно же ж).

mrshurik (not verified) - 27/Мар/2010 17:35

всё же видеокарта прежде всего для графики. для графики пока 64 бит не надо. поэтому нет смысла терять в производительности ради GPGPU. тем более, что в прикладных проблемах (не научные расчёты) необходимость массива (объекта) больше 4 Гб сильно сомнительна.

lazybird_ru (not verified) - 27/Мар/2010 21:50

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

lexa - 27/Мар/2010 22:36

А откуда данные?

Я вот вот что нашел: http://www.xbitlabs.com/news/video/display/20090113111639_Sales_of_Graph...

GPU - половина, чипсеты и professional - по 22%.

Это sales, как делить прибыльность - вообще неясно т.к. в professional идут те же чипы (или почти те же), что и в топ GPU.

lazybird_ru (not verified) - 27/Мар/2010 23:55

http://www.overclockers.ru/hardnews/36136/Bolshe_vsego_NVIDIA_zarabatyva... -- а там есть вроде ссылка на авторов.

lexa - 28/Мар/2010 00:39

А я не поленился и сходил почитал авторов.

We estimate that the average price of an Nvidia Pro Graphics card in 2009 was $146 and that this will decline to $123 over the Trefis forecast period. In comparison, we estimate that the average discrete GPU price was $21 in 2009 and that this will decline to less than $19 over our forecast period.

Да, похоже нолик потеряли.... но из дальнейшего чтения, вытекает что есть еще "High professional graphics market share" и все становится на свои места:

discrete - это "ноутбучные" карты и прочее подобное, что паяется отдельным чипом, но не отдельной картой. А Professional - это отдельные карты в PC, для геймеров и т.п.
И именно Professional приносит основной профит - что и так известно.

Мораль - не читайте переводов.

lazybird_ru (not verified) - 28/Мар/2010 16:40

Ну мне надо было сказать "я слышал". :) А что до не читать переводов -- так жизни не хватит. Будем знать теперь.

lexa - 28/Мар/2010 17:11

Ну если уж читать IT-новости, то на языке оригинала.

У меня вот engadget копится неделю, потом в выходные читаю. А читать то же самое в переводе - сплошное огорчение.

froll (not verified) - 27/Мар/2010 15:55

Можно идти по пути Apple - вылизывать приложения.
Маки по сравнению с аналогичными ВинТелями как Селероны против Пентиумов.

lexa - 27/Мар/2010 16:16

По мне, так один хрен.

Точнее, виндовый фотошоп - очевидно быстрее маковского на современном железе. Уж не знаю, что они в Apple вылизывали, но нужных API для 64-битного фотошопа - не вылизали.

froll (not verified) - 27/Мар/2010 16:18

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

lexa - 27/Мар/2010 16:26

Да нет, на одном и том же железе.

Просто Apple пообещал Адобу 64-бит Carbon и не сделал (http://blogs.adobe.com/jnack/2008/04/photoshop_lr_64.html )

Что касается интерфейса - мы же не его обсуждаем? Мне примерно одинаково комфортно под Win7 и под маком, но чтобы на эту тему зря не спорить, я согласен что у Эппла интерфейс вылизан на 43% больше.

froll (not verified) - 27/Мар/2010 16:29

А, вот даже так, на одном и том же железе...

Ну это вообще "замечательно".

Про интерфейс - согласен :). Мне отнюдь неодинаково комфортно под W7 и Мак, но выбираю-то я W7, поскольку привык :))) и я тоже согласен на 43% чтобы не спорить ;))).

lexa - 27/Мар/2010 16:53

Возвращаясь же к вылизыванию приложений, причем конкретно под GPU, тут вот какая штука: CUDA позиционировалась как легко масштабируемое на будущих устройствах решение. Дескать, делайте тредов побольше и на всех будущих железках будет счастье.
Для начала, это оказалось совсем не так: бинарное представление (CUBIN) просто несовместимо, псевдокод (PTX) - да, совместим.

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

Никакого особого удивления у меня это не вызывает, просто еще одно напоминание, что к к обещаниям производителя (о будущем) нужно очень аккуратно относиться.

ostapru (not verified) - 28/Мар/2010 05:53

> Маки по сравнению с аналогичными ВинТелями как Селероны против Пентиумов.

Миф.