|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 05 Dec 2003 23:59:38
To : Valentin Nechayev
Subject : Re: Хочу купить комп домой. Что лучше взять Athlon XP 2400 или Celeron
--------------------------------------------------------------------------------
Hello!
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
OD>>>> В смысле от каждого проца отдельный "шланг" и все к той же самой памяти?
OD>>>> И как ты себе это представляешь?
VN>>> Hу, технически такое давно сделано. Общий массив памяти с несколькими
VN>>> "шлюзами", синхронизация доступа на уровне простейшей сериализации,
OD>> Э? Сериализации чего? запросов?
VN> Да.
OD>> Так а чем это от одной общей
OD>> шины отличается тогда? тем что она спрятана там внутри?
VN> Hу вот возьмём типичную общую шину. Тайминги в примере будут произвольные,
VN> но картину они отражают, думаю, адекватно.
VN> Такт 1: процессор 1 послал запрос чтения по адресу 0001.
VN> Такт 2: процессор 2 захотел прочитать память. Шина занята => он ждёт.
VN> Такты 2-5: спим, ждём ответа.
VN> Такт 6: пришёл ответ. Отработали. Шину освободили.
VN> Такт 7: процессор 2 послал запрос чтения по адресу 0022.
VN> Такты 8-11: спим, ждём ответа.
VN> Такт 12: пришёл ответ. Отработали. Шину освободили.
VN> И так далее. Итого 6 тактов на одно чтение из RAM. Похоже?
VN> Если что-то тут принципиально неверно, говори сразу.
Похоже, но учитывая всякие механизмы префетчей и тп, вполне может быть ситуация,
когда в процессе ожидания данных от памяти (в кеш), процессов выполняет
какие-то инструкции, а не спит.
VN> Теперь представим себе, что было бы, если бы было две шины. Уже не 12
VN> тактов, а 7. (Предполагая, что они не лезут в одно и то же место в памяти.)
VN> За такты 1-6 первый процессор получает ответ, за 2-7 - второй.
Hо я так подозреваю чип получится значительно сложнее в результате.
Опять же возможно из-за этого он будет перегреваться и его прийдется
пускать н аменьшей частоте.
VN>>> несколько параллельных шин и использование одним процессором только одной
VN>>> такой шины. Так как передача команды чтения/записи сейчас происходит
VN>>> значительно быстрее, чем реальное чтение/запись.
OD>> Hепонял логики. То есть по твоему мнению, если к винту прицепить два
OD>> шолейфа и гнать по обоим запросы (случайные, само собой), то все станет в
OD>> два раза быстрее?
VN> Аналогия с винтом неудачна. У него последовательный доступ в том смысле,
VN> что одновременно может читаться только один цилиндр. У RAM не так,
Согласен.
VN> Hо, кстати, и в случае винта не всё так просто. Вспомни TCQ - такая
VN> себе простая аналогия нескольких шин. В его случае, пока результат одного
Hет. TCQ в основном работает за счет наличия кеша.
У процессора тоже есть кеш который выполняет сходные функции.
VN> чтения лежит в буфере и начинает передаваться контроллеру, винт уже
VN> может заниматься выполнением следующей команды. Вряд ли это даст
VN> больше пары десятков процентов скорости, но тоже ведь на дороге не
VN> валяется...
Зависит от workload. У процессора, как известно, кеш дает значительный выигрыш.
EBB>>>>> когерентности кэшей. Которое обязано быть синхронным и надежным.
OD>>>> Даже если принять во внимение возможность такого варианта, мои слова не
OD>>>> перестают быть менее верны, потому что тогда кеши и шина по которой они
OD>>>> синхронизируются и есть та самая узкая дырка ;)
VN>>> Её можно расширить, хоть и не самым дешёвым путём.
OD>> Так и память можно ускорить ;)
OD>> И эффект будет значительней.
VN> Это дороже. Статическая память значительно быстрее (раз в 10), но и в ~10
VN> раз дороже. Это можно увидеть по любому прайсу на модули или на микросхемы.
VN> А вот сколько бы стоило построение схемы с параллельным доступом к
VN> динамической памяти хотя бы с двух сторон, я не представляю себе даже
VN> приблизительно.
Именно, поэтому рассматривать вариант отдельной шины доступа к (той же)
памяти н акаждый процессор можно лишь теоретически.
Bye,
Oleg
--- ifmail v.2.15dev5.1
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
