Comments | thesz: Замечательная статья про закон Амдаля.

thesz

Замечательная статья про закон Амдаля.

Jul 03, 2011 01:54

Почему в гугле предпочитают быстродействующие процессора экономичным.

Закон Амдаля: S=1/((1-P)+P/S). S - общее ускорение, P - доля ускоряемого кода в коде программы (доля времени выполнения), S - ускорение этого самого ускоряемого кода. Коротко P и (1-P) можно называть "обработкой" и "анализом ( Read more... )

процессоры, google, mips

Leave a comment

Back to all threads

nicka_startcev July 3 2011, 09:59:55 UTC

х86 привычнее, под него больше разработчиков, под него быстрее найти персонал, итого, разработка быстрее.

cormix July 3 2011, 16:12:47 UTC

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

nicka_startcev July 3 2011, 16:26:13 UTC

Кроме ассемблера еще есть периферия и драйвера. На винтеле оно готовое, на х86-линух -- много готового, на прочих платформах сложнее.

Для прикладух -- да, почти пофиг. Разве что надо бы прикидывать, как эта прикладуха будет оптимизироваться с учетом особенностей железа. Например, банально переколбасить алгоритм так, чтоб компилятор переложил его на какой-нибудь SSE/MMX/Neon/итп.

thesz July 3 2011, 16:46:54 UTC

Кстати, отсутствие out-of-order сказывается на оптимизации программ и заставляет протекать абстракции сильнее, чем в присутствии o-o-o.

nicka_startcev July 3 2011, 16:53:28 UTC

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

thesz July 3 2011, 17:57:03 UTC

Да ничего подобного же, ну что вы мне говорите ( ... )

nicka_startcev July 3 2011, 18:20:25 UTC

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

thesz July 3 2011, 18:48:57 UTC

>А в геймдеве просто железо чуть послабже, а критерии чуть пожестче -- фирма-изготовитель приставки не допустит до продаж шутер с фпс 1..3..10 ( ... )

nicka_startcev July 3 2011, 19:09:19 UTC

>>А в геймдеве просто железо чуть послабже, а критерии чуть пожестче -- фирма-изготовитель приставки не допустит до продаж шутер с фпс 1..3..10

>Послабже, ага. IBM Cell BE с его 8*8*3,6 = 230 Gflops без видеокарты супротив распоследнего пентиума с его 4*3,6 = 14,4 Gflops. Или процессор Xbox 360 с альтивеком на три ядра и теми же 3,6 GHz, 45 Gflops.

А вы не с пентиумом, а с гефорсом сравнивайте. Тогда будет корректно.
Кстати, под шейдеры тоже надо хитро выравнивать, ну, или, делать как попало и скармливать драйверу OpenGL, который переразложит всё как надо и куда надо.

thesz July 3 2011, 19:23:10 UTC

>А вы не с пентиумом, а с гефорсом сравнивайте. Тогда будет корректно.

У PS3 и XBox 360 вполне приличные (на то время) видеокарты.

Проблемы с обходом дерева форм столкновений находятся не на "гефорсе", а на процессоре. Это необходимо для общей скорости работы. И это задача уровня gcc, на которой всё и тормозит. И которую оптимизируют.

Как и передачу моделей и прочего на отрисовку.

Ещё раз - я там работал, я знаю, что к чему. Например, мой коллега добился 360 fps на типичных сценах нашей игры за счёт того, что комбинировал статические модели в одну. Это, как раз, уровень логики, анализа, а не параллельной обработки. А вот после включения звука, физики и прочего получались стандартные 30-60 fps. И оптимизировали мы физику (анализ), а не отрисовку.

Так что я аргументы про "гефорс" не приму.

nivanych July 4 2011, 03:09:00 UTC

> Понятно что любая сверхвысокая абстракция
> местами криво ложится на реальное железо

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

permea_kra July 20 2011, 15:25:48 UTC

Присутствие ooo добавляет транзисторов в кристалл. Поэтому если есть возможность жить без него (с помощью умного компилятора) - лучше жить без него.

thesz July 20 2011, 19:54:42 UTC

Умный компилятор не может правильно соптимизировать код задач типа gcc. Все in-order процессоры значительно отстают на gcc от ooo.

К задачам типа "gcc" относятся и более практичные нагрузки, например, обход списков в ядре линукса и тому подобное.

Мне известны исследования, в которых прямо утверждается, что много параллельных процессов проще выполнять на in-order, но когда дело дошло до анализа, то лучше иметь процессор с хорошим ILP, а это - барабанная дробь! - обязательно out-of-order.

"Ум" компиляторов хорошо показал Itanium, который обгоняет x86 только в присутствии громадного кэша.

thesz July 20 2011, 19:55:51 UTC

И, кстати, in-order требуют большого кэша, больше, чем ooo. И уж кэш съедает транзисторов поболее любой ассоциативной памяти.

permea_kra July 20 2011, 20:23:55 UTC

ИМХО, in-order требует поддержки инструкций по префетчу в кеш и отложенной загрузке и явного понимания компилятором, что вот этот результат будет в этом регистре через пять тактов (без отслеживания в самом процессоре зависимостей между результатами), плюс VLIW. Альтернатива - разделение АЛУ между несколькими потоками выполнения для массово-параллельных задач. Во всяком случае то очень немногое, что я читал про процессорные архитектуры, создало именно такое впечатление ( ... )

thesz July 20 2011, 21:05:36 UTC

>ИМХО, in-order требует поддержки инструкций по префетчу в кеш и отложенной загрузке и явного понимания компилятором, что вот этот результат будет в этом регистре через пять тактов (без отслеживания в самом процессоре зависимостей между результатами), плюс VLIW. Альтернатива - разделение АЛУ между несколькими потоками выполнения для массово-параллельных задач. Во всяком случае то очень немногое, что я читал про процессорные архитектуры, создало именно такое впечатление ( ... )

Back to all threads