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

[thesz]

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

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

Comments

[kashnikov]

Похоже на то: http://www.mips.com/android

Кстати, а вы читали книгу Computer Architecture: A Quantitative Approach . Как оцениваете?

[thesz]

Мне MIPS интересней в серверах. Во встраиваемых системах-то он давно применяется.

Просмотрел первое издание, на citeseer. Более-менее. Кое-где они кое-что упростили так, что даже не очень хорошо получилось. В системах команд, например, стековые архитектуры не сильно отличаются от регистровых, что неправда.

[ramlamyammambam]

Что касается противоречия между длинным конвейером и синхронизацией нитей - существует архитектурное решение, где такой проблемы нет. Называется MIPS MT ASE: Multi-Threading Application-Specific Extension. Конвейер устроен таким образом, что на выполнении находится "одновременно" несколько нитей. На каждом такте аппаратный планировщик решает, какую из нитей будем продвигать. Синхронизация между нитями делается через запись-чтение специальных областей памяти, служащих семафорами или FIFO.

Плюс к этому, достигается вход в прерывание "за 0 тактов". Нить выполняет специальную инструкцию ожидания внешнего сигнала, и её конвейер приостанавливается. При появлении нужного сигнала нить начинает обработку прерывания со следующего такта. С учётом влияния кэшей, конечно, но это уже мелочи.

[thesz]

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

А я про это не говорил. То, что вы описываете, это улучшение загрузки процессора за счёт выполнения нескольких потоков команд. Процессор XBox, Niagara T*.

Это не улучшает работу однопоточной программы анализа.

[ramlamyammambam]

Понятно, почему внеочередное выполнение сейчас не в моде: можно переложить проблему на разработчиков компиляторов и сэкономить несколько милливатт потребления. :)
Скорость однопоточной программы можно было бы улучшать, удлиняя конвейер, если бы не ветвление. Я где-то слышал, что средняя длина линейного участка - несколько десятков инструкций. Дальше растягивать конвейер нет смысла. Ну и предсказание ветвления тут обязательный элемент.

[thesz]

>Я где-то слышал, что средняя длина линейного участка - несколько десятков инструкций.

Каждая пятая инструкция переход, по моим сведениям. ;)

Там выше дали ссылку на книгу на Амазоне, в ней в этой копии на графике B.13 указана частота условных переходов в 20%.

>Понятно, почему внеочередное выполнение сейчас не в моде: можно переложить проблему на разработчиков компиляторов и сэкономить несколько милливатт потребления. :)

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

[blueher]

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

[nicka_startcev]

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

[cormix]

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

[nicka_startcev]

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

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

[thesz]

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

[cp_poster]

> Длинный конвейер даёт нам высокую частоту процессора, но и уменьшает возможный параллелизм.
> Правда, это мои теоретические соображения. На практике не проверял.
На практике это было хорошо видно во времена Pentium 4 и Athlon XP. В синтетике первый был очень неплох. А в реальных приложениях ничего не мог. Хотя частота больше. А все (наверное) из-за длиннющего (20 ступенчатого?) конвеера, который видимо срывался из-за prediction miss'ов и приходилось все начинать сначала.