Конференция Radeon.ru
| Страница 2 из 2 [ Сообщений: 57 ] Версия для печати [+] | На страницу Пред. 1, 2 |
Нет, как показывают графики для двухгигагерцового квадропня, — выигрыш гораздо выше. Это доказывает лишь то, что пример с Athlon 1000 несколько некорректен. Он не способен получить все выгоды от прироста ПСП. Квадропень же увеличил свою производительность в тяжелом и требовательном приложении — практически в полтора раза. Ну как же...  Разделяемые кэши у рассматриваемого процессора. Нет. Но кто сказал, что это был предел мечтаний и окончательный идеал?  Не скажите. Когда, к примеру, у вас висит окно Skype с разговором, а вы на другом экране активно перещелкиваете приложения и что-то такое серьезное пытаетесь делать — вы очень даже ощутите разницу. Наличие большого L3 вы заметите невооруженным глазом и услышите собственными ушами.  Так чем матрица четырехпортовых коммутаторов (с вносимой на каждом "хопе" задержкой и с явной невозможностью — за неимением времени — построения оптимальных маршрутов, чтобы избежать "затыков" на портах назначения) — отличается в лучшую сторону от единой матрицы? Собственно, ничем. Хуже того, при рассмотрении высоконагруженной системы с более-менее большим количеством узлов придется признать, что если рассматривать ситуацию MISD векторов — то неизбежно образование "горячих точек" в 2D массиве кэшей. Со всеми вытекающими — или, как альтернатива, данные будут перемещаться между кэшами по конвейеру, а это ненужные накладные расходы и те же задержки. Теоретическая возможность "масштабирование задержек получается в виде квадратного корня от кол-ва узлов" получается именно что чисто теоретической. А если рассматривать систему с сотней независимых по данным потоками, — то тема "единого кэша в 45 мегабайт" вообще не существует, как класс. И надо рассматривать, как я и говорю, недоядра с крохотными кэшами. Которые при более-менее реалистичном размере данных упрутся в память намертво. Хм. Где я это предлагаю?  Я предлагаю совсем другое: не пытаться сделать микроядрышки в огромном количестве с о-очень странной схемой работы, а использовать вменяемое количество мощных ядер, обеспеченных нормальной (предсказуемой по задержкам) структурой кэшей. Скажем, где-то 16-36 самостоятельных ядер на 2-4-8 "кольцах" обмена (И объединяющее "малые" кольца — "большое" кольцо, ага). Плюс, на все оставшиеся транзисторы, WB L3 — причем, подключаемый как один абонент к "большому" кольцу — для оптимизации обмена с памятью (хотя тут возможны архитектурные варианты — скажем, без L3 и с контроллером канала памяти на каждом из "малых" колец?). Идеально было бы, чтобы "ядра на одном кольце" могли объединяться именно в MISD векторы на программном уровне. Это позволило бы некоторые критичные последовательные алгоритмы обрабатывать очень быстро.Почему кольца? Вспомните TokenRing. При малой нагрузке никакой разницы с Ethernet не было, кроме цены. Но при более-менее высокой нагрузке суммарная пропускная способность грамотно спроектированных TR-структур была почти на теоретическом пределе, а "дерево" коммутаторов (2D, ага  ) деградировало до смешных величин. Потому что "случайная" схема доступа при больших и равномерных нагрузках — не работает.  |
|
Stranger_NN
>Нет, как показывают графики для двухгигагерцового квадропня, — выигрыш гораздо выше. Ага, целых 17% в Q3 (845 vs. 845D). Да и то лишь потому, что 256Kb S-cache у Вильяма и Тандербёрда — это две большие разницы. В случае Нортвуда получили бы примерно те же 10%. Что касается CMU Sphinx, написанного целиком на C для облегчения портирования, то это воистину эталон для измерения производительности процессоров  >Квадропень же увеличил свою производительность в тяжелом и требовательном приложении — практически в полтора раза. Какие полтора раза? Калькулятор потеряли? >Разделяемые кэши у рассматриваемого процессора. Я о кэшах в Tilera пока что ничего не говорил. >Но кто сказал, что это был предел мечтаний и окончательный идеал? Ага, окончательный идеал, наверно, COMA. >Наличие большого L3 вы заметите невооруженным глазом и услышите собственными ушами. Преимущества от наличия быстрой памяти заметны везде, а не только в некоторых недооптимизированных софтинах. Потому что от DMA, сквозной записи и вынужденного чтения из памяти на x86 легко и просто не избавиться. Асинхронный тормознутый T-cache — это последнее, на что стоит тратить транзисторы. Кстати, у Фенома 2 и Бульдозера доступ к T-cache занимает ~60 тактов, а к памяти на штатной частоте со стандартными таймингами ~180 тактов. S-cache в 3-4 раза шустрее T-cache. |
А вы ждали удвоения?  Его не будет, производительность определяется не только памятью. Но, прошу обратить внимание: чем мощнее процессор — тем неприятнее для него дефицит ПСП.  SiSoft Sandra 2001: memory benchmark И еще цитатка:
Да, виноватъ... +40%. Всего.... Ок., ждем-с. Так как с ними, как рассматривать эту 2D матрицу? Хм. И где я это утверждаю?  Давайте, все-таки, спорить с моими утверждениями.  Welcome back to real world! Да. Всяческого геморроя полным-полно, и с этим приходится считаться. Но даже в идеально оптимизированных приложениях, точнее, когда их много а плавность работы имеет значение (да, именно — аудио-видеопотоки, которым изохронность критически важна) — большое количество кэша оказывается весьма и весьма полезным.  Ээээ. Ну да. Трехкратного сокращения времени выборки недостаточно???? Хотелось бы большего, конечно, но и то что есть влияет заметно.  |
|
Stranger_NN
Sandra всегда имела плохо оптимизированные бенчмарки памяти, вначале самописные, позже взятые из СТРИМа. Ладно, ближе к делу. Вот пример реального расклада, AMD-750 vs. AMD-760: CPU: AMD Duron (Morgan) 1430MHz (13x110MHz) Стоит учесть, что сравнивается PC2100 DDR на 133МГц реальных и с отличными таймингами, которую тогда ещё стоило поискать, а PC100 SDRAM на 100МГц реальных с такими же таймингами можно было найти без проблем и за гораздо более скромные деньги + немного разогнать. Самая большая разница при линейной записи, примерно в 2 раза. По чтению уже в 1,6 раза, а по подборке Copy/Scale/Add/Triad лишь 28% набежало. >Да, виноватъ... +40%. Всего.... 845 проигрывает 845D ~17% как по Q3, так и по Sphinx. Даже если сравнить с SiS или VIA при PC2100, то ~24% разницы. Найдите другой калькулятор |
А при чем тут 845D? Я не чипсеты сравниваю, а зависимость производительности ядра от доступной пропускной способности памяти. Поэтому, совершенно честно считаю (1.511/1.087-1)*100%.=39%. Что-то не так? Вопрос в соотношении запросов чтения и записи, но речь-то даже не об этом. С тех пор на один сокет стало приходиться, грубо, раз в двадцать больше производительности, а доступная ПСП (четыре канала на сокет) увеличилась (реально) едва ли в десять раз. Sandy Bridge-E, 4 х DDR3-1600 — чтение около 16ГБ/с, запись около 11-12. Дефицит-с, однако, — не зря кэши приходится на кэши наворачивать, чтобы хоть как-то выкрутится. А тут (Tilera) нам обещают еще удвоение производительности, при очень странной системе кэширования и работы с памятью. Память не позволит-с, будет как кирпич на ноге... |
|
>Поэтому, совершенно честно считаю (1.511/1.087-1)*100%.=39%. Что-то не так?
Не так. Потому что за точку отсчёта взят заторможенный интеловский недомерок с задержками почти как у 850, а сравнивается с более новым северником альтернативного производителя, обладающим более новой и быстрой памятью. Так сравните сразу уж с 865/875 и 2-канальной PC3200, вот счастье-то будет... >Content Creation 2001 показывает увеличение производительности на 28%, а Business Winstone — на целых 43%! ZDBench был настолько хорошим тестом, что уж 10 лет как ушёл во мрак. Самые высокие результаты DDR vs. SDR показывала на Вильяме, который был сильно обделён размером S-cache по технологическим причинам. Тандербёрд, Торобред и Нортвуд реагировали гораздо спокойнее, а Бартон — того меньше. Коппермайн и Туалатин вообще едва заметили разницу из-за медленной системной шины. >не зря кэши приходится на кэши наворачивать, чтобы хоть как-то выкрутится. А на что ещё эти транзисторы потратить? Толком больше не на что. >Память не позволит-с, будет как кирпич на ноге... Tilera не x86 и может себе позволить многое. |
В общем да, но уже трудно будет найти конфигурацию со старым квадропнем. А вообще, было бы показательно.Именно! Чем проблемнее с памятью, — тем важнее кэши. А при чем тут х86 или нет? Алгоритмы тех же СУБД, видеокодирования и так далее — совершенно не зависят от набора команд. Данные придется прокачивать в тех же объемах и темпе.Как бы не так. Во-первых, выше вы сами же и отметили, что когда кэша мало — то зависимость от дефицита ПСП больше, а во-вторых (в-полуторных) современные задачи растут областями локальности как на дрожжах. И если задача своей активной частью не помещается в кэши, — то ситуёвина сравнима со свопом при нехватке памяти. Производительность падает несуразно. |
|
>Именно! Чем проблемнее с памятью, — тем важнее кэши.
Важны быстрые кэши, а не асинхронные тугодумы 3-го уровня. >А при чем тут х86 или нет? При том, что x86 имеет слишком много наследственных болезней, которые отнюдь не способствуют высокому быстродействию. >Как бы не так. Когда в K10 добавляли видеоядро, что в первую очередь "пошло под нож" в Льяно? Именно T-cache. Расширять существующие ядра некуда. Что, ещё больше ядер на сокет посадить? Урезав частоту, чтоб уложиться в TDP, и попав в ещё большую зависимость от памяти? Тупик эволюции. Скоро x86 процессоры станут SoC и привет консолям. |
Кэши всякие нужны, кэши всякие важны. Если нет возможности сделать огромный и быстрый кэш, пускай будет огромный и относительно быстрый. В данном случае это не имеет никакого значения, потому что прокачка данных в большом количестве никак не зависит от системы команд. Да, х86 далеко не идеал, но много слабых ядрышек не смогут заменить мощные ядра. Вот. Именно в этом проблема, в отставании памяти. Даже четыре канала DDR3 уже недостаточны для современных х86 процессоров. Точнее, не так: сдерживающим фактором в производительности "на сокет" является уже не архитектура содержимого его "заглушки", а скорость обмена ее с внешним миров, и в первую очередь — с оперативной памятью. Из этого мы получаем два следствия: 1. Tilera, говоря о "двукратном превосходстве в производительности" слегка лукавит, выдавая теоретическую сумму производительностей за реально достижимый на практике результат. 2. Ни о каких "800-ядерных" системах говорить не приходится, потому что даже 48-ядерные системы АМД уже практически уперлись в потолок достижимого. Лимитирует, опять же, память и технологии межсокетных линков. Мы с вами же, кажется, обсуждали китайские успехи на почве MIPSостроения? Они достигли интересных результатов за совершенно смешные ватты. Возможно, путь лежит куда-то туда? А что касается технологий памяти — то помните такую идею, как FB-DIMM? Мне кажется, это был шаг в разумную сторону, но технологию сгубила сырость и необходимость ретрансляции сигнала каждым модулем (это вносило ненужные задержки и жрало энергию).. |
|
Stranger_NN
Когда, к примеру, у вас висит окно Skype с разговором, а вы на другом экране активно перещелкиваете приложения и что-то такое серьезное пытаетесь делать — вы очень даже ощутите разницу. Наличие большого L3 вы заметите невооруженным глазом и услышите собственными ушами. Извините, что вклиниваюсь, но когда у меня на стареньком нетбуке с Атомом висит окно Skype с разговором, а я рядом активно перещелкиваю приложения и что-то пытаюсь делать, то отсутствие L3 я глазами или ушами в Skype не замечаю. На совсем древнем ноутбуке с Пнём 4 ситуация такая же. Что я делаю не так? Тут, имхо, варианты: либо действительно плацебо, либо Вы "лукавите," либо Skype заторможен криворукостью настройки / другим железом, но уж никак не нехваткой L3 или ПСП. Так чем матрица четырехпортовых коммутаторов (с вносимой на каждом "хопе" задержкой и с явной невозможностью — за неимением времени — построения оптимальных маршрутов, чтобы избежать "затыков" на портах назначения) — отличается в лучшую сторону от единой матрицы? Отвечу Вашими словами:
Либо мы друг друга совсем не понимаем, либо Вы продолжаете дискуссию только ради продолжения дискуссии, не соглашаясь даже со своим предыдущим сообщением. Хуже того, при рассмотрении высоконагруженной системы с более-менее большим количеством узлов придется признать, что если рассматривать ситуацию MISD векторов — то неизбежно образование "горячих точек" в 2D массиве кэшей. Флудите? Вот на такой архитектуре MISD векторы только и могут быть — данные от одного ядра к следующему в колонне будут просто пасоваться, за один "хоп." Какие "горячие точки?" К слову, опишите, как этот процесс пойдёт на 80-ти Нехалемах в ccNUMA.  Со всеми вытекающими — или, как альтернатива, данные будут перемещаться между кэшами по конвейеру, а это ненужные накладные расходы и те же задержки. Альтернатива чему? MISD векторы:  А если рассматривать систему с сотней независимых по данным потоками, — то тема "единого кэша в 45 мегабайт" вообще не существует, как класс. И надо рассматривать, как я и говорю, недоядра с крохотными кэшами. Которые при более-менее реалистичном размере данных упрутся в память намертво. Во-первых, я там писал о развитии процессоров в целом, а не конкретно о Tilera (представьте себе сотню Sandy Bridge, например). Во-вторых, если хочется обуждать именно Tilera Tile-Gx, то, пожалуйста, забудьте уже про SQL и т.п. — не для таких задач этот процессор интересен. Хм. Где я это предлагаю? Вы ничего совсем не предлагали. Получается, что предлагаете совсем ничего не делать, остановить прогресс. Хотя, чуть ниже уже вижу:
Я предлагаю совсем другое: не пытаться сделать микроядрышки в огромном количестве с о-очень странной схемой работы, а использовать вменяемое количество мощных ядер, обеспеченных нормальной (предсказуемой по задержкам) структурой кэшей. Скажем, где-то 16-36 самостоятельных ядер на 2-4-8 "кольцах" обмена (И объединяющее "малые" кольца — "большое" кольцо, ага). Никто микроядрышки сделать не пытается. P54C использовались для изучения будущего многоядерного чипа, имея существующий техпроцесс. К слову, многоядерными процессоры становятся, как раз, при более ~30-40 ядер — топология там нужна совсем другая. Да и при 32 ядрах кольцо у меня восторга не вызывает — до 16-ти "хопов" в один конец, задержки высоковаты будут. Плюс, на все оставшиеся транзисторы, WB L3 — причем, подключаемый как один абонент к "большому" кольцу — для оптимизации обмена с памятью Ой. Даже комментировать не буду. (хотя тут возможны архитектурные варианты — скажем, без L3 и с контроллером канала памяти на каждом из "малых" колец?). Идеально было бы, чтобы "ядра на одном кольце" могли объединяться именно в MISD векторы на программном уровне. Это позволило бы некоторые критичные последовательные алгоритмы обрабатывать очень быстро. Т.е. городите именно то, что критикуете, подменив название на "малые кольца?" Запатентуйте.  Вспомните TokenRing. При малой нагрузке никакой разницы с Ethernet не было, кроме цены. И ползания по всему зданию в поисках перегнутого кабеля, когда вся сеть лежала... Потому что "случайная" схема доступа при больших и равномерных нагрузках — не работает. Протокол описан и выполнен в "железе." Ничего случайного: "The Tilera networks use a dimension-ordered routing policy, where packets always travel in the X direction first, then the Y-direction. The TilePro family of processors allow each network to be configured to either route X first, or Y first." Вообще, к чему, конкретно, претензии? А как 100 ядер будут ждать свой токен, вместо того, чтобы просто общаться — это шутка что-ли? И Ethernet — это совсем не пример о больших и равномерных нагрузках, он с ними по определению несовместим. Tilera, говоря о "двукратном превосходстве в производительности" слегка лукавит, выдавая теоретическую сумму производительностей за реально достижимый на практике результат. В теории там раз в 10 превосходство. Двукратное/трёхкратное — это в реальных задачах, не в бенчмарках даже. На всякий случай — нет, я не про СУБД и т.п. даже 48-ядерные системы АМД уже практически уперлись в потолок достижимого. Лимитирует, опять же, память и технологии межсокетных линков. Гы. обсуждали китайские успехи на почве MIPSостроения? Они достигли интересных результатов за совершенно смешные ватты. Возможно, путь лежит куда-то туда? С китайскими я незнаком, но Tilera — тоже на почве MIPS. А что касается технологий памяти — то помните такую идею, как FB-DIMM? Мне кажется, это был шаг в разумную сторону, но технологию сгубила сырость и необходимость ретрансляции сигнала каждым модулем (это вносило ненужные задержки и жрало энергию).. DDR4 пошло в противоположном от этого направлении... и правильно. |
У меня дома есть несколько практически идентично настроенных компьютеров — разница есть. Что я делаю неправильно? Может быть, залезть в архив весом в пару сотен метров и открыть оттуда пдфку (покрутить ее туда-сюда в поисках нужной страницы) или заняться (пока идет разговор) сжатием папок в громоптахе — дело в каких-то руководствах по скайпу запрещенное? Цитируйте целиком. Или придется терпеть "горячие точки" с нарастающими задержками обращения к ним, или придется прокачивать данные из кэша в кэш, и тогда — как вы это предлагаете — суммировать их емкость несколько некорректно. С удовольствием забыл бы, но по мере исключения потенциальных применений интересного остается все меньше и меньше... Простите, но: 1. не надо одно кольцо на 32 абонента. Надо 4 кольца по 8 и объединяющее их пятое. В проводах это очень несложно, можете нарисовать. 2. передача пустого маркера в кольце, равно как и получение данные абонентом, — занимает гораздо меньше времени, чем прокачка через коммутатор с буферизацией. Опять же, конкуренция за порт назначения исключена у кольца в принципе, а значит нет и необходимости в промежуточный буферизации. Никогда. В пресловутой 2D-матрице каждый коммутатор должен иметь возможность буферизовать хотя бы 1-2 пакета на каждом направлении. Плюс к тому, даже без дополнительных потерь и "вылеживания" пакетов в буфере — store-and-forward увеличивает задержку на время "прокачки" пакета. На каждом "хопе" А что, в железе заранее предсказано, в каком узле "объединенного" кэша и в каждый момент времени будут находиться данные любой потенциальной задачи?? Ах, нет..... Где я пишу про 100-узловое кольцо? Для 100 узлов разумно создание 10 колец по 10 узлов (и MISD вектора организуются только в рамках одного "малого" кольца). Причем, "разделяемым" является только кэш в пределах одного кольца — и даже при конвейерной обработке прокачивать данные из кэша в кэш не надо. 10 абонентов вас не пугают? Вах! Коммутируемый Ethernet, значит, с высокой нагрузкой несовместим, а матрица коммутаторов, работающая по жестким маршрутам — совместима??? Ор-р-ригинально!  Я понимаю, что регулярная структура и унифицированное ядро с коммутатором несколько проще с т.з. масштабирования (не в транзисторах и работе), чем структура с несколькими кольцами. Лепи регулярную решетку и нарезай квадраты желаемого размера, не надо пересматривать логику и топологию. Но не надо и выдавать нужду за добродетель. Да, но китайцы не пытаются повесить сто ядер на четыре канала памяти. В дешевом, допускающем быстрые результаты — но тупиковом, в итоге.  DDR <много-много>, как раз, требуют все более и более емких и хитровымудренных кэшей, которые выедают площадь кристаллов и TDP. |
Эти несколько компьютеров отличаются только размером L3? У меня Скайп нормально работает на системах совсем без L3 и с одно-канальной древней памятью. Громоптахи у меня нет. Залезть в архив и оттуда открыть и покрутить тоже не удалось — файлы сами сначала в папку временных копируются и оттуда открываются (за менее секунды, из любого размера архива, 7zip).
OK. В том-то и дело, что или. Или MISD векторы, где данные прокачиваются из кеша в кеш, и общий кеш даром не нужен (см. Larrabee), т.к. данные на входе каждый раз разные. Или что-то другое, где суммировать ёмкость вполне корректно. О "горячих точках" — в MESI с ними дела хуже обстоят, разве нет?
1. Теперь понял. Хорошо. Но (условно пронумерую 32 абонента слева-направо и потом сверху-вниз, по 8 в строке) если 1-ый хочет с 9-м пообщаться, то тут до 9 "хопов" получается, и по трём разным кольцам, вместо одного "хопа" в Tilera. Плюс, всё пятое кольцо станет "горячей точкой." 2. Конкуренция за порт назначения у кольца исключена, а за право выхода на кольцо — нет. И это на каждое кольцо — тут уже при 32-х абонентах на трёх кольцах ждать придётся. Шило на мыло, имхо. О времени прокачки пакета на каждом "хопе:"
Теперь про "малые" кольца понятно. Замяли все эту идею, видимо. В Aubrey Isle сейчас 32 ядра и обычные кольца, больше 32-х абонентов. В других многоядерных — 2D-mesh.
Разницу между деревом (жёсткий маршрут через ветви, которые ближе к корню становятся всё загруженнее) и этой матрицей 5-ти портовых равнонагруженных коммутаторов не видно?
У FB-DIMM был хоть какой-то плюс в сравнении с DDR4 + LR-DIMM? "В дешёвом" — это в том смысле, что один общий коммутатор вместо "AMB" на каждом модуле? Или в том, что канал не должен на заоблачных частотах работать (4 GHz уже для DDR2-667 было, и даже там для записи не хватало ). |
Менее секунды раскрутка 200-мегабайтового архива?! Да он у меня с винчестера дольше читается. И, почему-то, индикатор загрузки процессора прыгает к 70%... На некоторых процессорах в это время происходит затык видео, на некоторых нет.. Не происходит его, отчего-то, у процессора имеющего 2х512к + 4 метра общего L3, а вот процессор с 4х1м — спотыкается... Да и обработка почты, некоторые файлы в которой уже перешагнули гигабайт — тоже несколько отличается... Фокус в том, что у кольцевой архитектуры в принципе нет понятия "хопа", как задержки процедуры "store-and-forward" у коммутаторов. Потому, что передача данных (и маркера) по кольцу — логическая а не физическая. Просто абоненты поочередно получают право на передачу, и либо реализуют ее, либо "пропускают ход". Данные же выставляются на общую шину и читаются всеми абонентами одновременно, просто реагирует на них тот, чей адрес в заголовке. Таким образом, передача данных в кольце занимает одно и то же время, независимо от "расстояния". Это время фиксировано и не может превышать некоторого максимума, заранее известного и определенного. Равно как и размер буфера не будет больше некоторого заранее известного размера.В то время, как у произвольно нагруженной 2D матрицы размер потребного буфера заранее рассчитать невозможно. Читал, знаете ли, читал. И даже нарисовал. И без проблем нарисовал глухой затык, предположив, что данные затребованные несколькими ядрами находятся в кэше одного (желательно, удаленного) ядра. И что желающие странного тех данных "случайно" оказались на том же маршруте. Ну, плюс задержки хопов. На самом деле, размер кольца (ширину, частоты, длины проводников и так далее) надо считать каждый раз отдельно, в то время как 2D сеть позволяет "не думать" и просто наращивать размерность, лимитируясь только выходом годных кристаллов. Надеясь, что суммарная производительность справится с нарастающей перегрузкой матрицы и с растущими задержками. Брутфорс, своего рода — чистый тупик.. Нет. Поскольку в каждом отдельном случае (когда несколько ядер совместно используют чей-то кэш или маршрут к вводу-выводу) мы получаем именно это дерево с "корнем", просто таких "деревьев" на матрице может быть в один момент много и они запросто будет пересекаться (особенно "приятно" — частично совпадать) "ветками" и "корнями". В этих случаях (совпадения маршрутов "корней") будет особенно грустно. Да. Фактически, вынесенный на модуль контроллер памяти. Если бы не странное решение с промежуточной буферизацией пакетов — запрос мог параллельно обрабатываться несколькими модулями, что радикально уменьшило бы задержки и повысило линейную ПСП. ДА и с типами памяти на модулях можно было развлекаться сколько угодно. Вплоть до разных типов самих микросхем на разных модулях |
|
Stranger_NN
>Если нет возможности сделать огромный и быстрый кэш, пускай будет огромный и относительно быстрый. Возможность есть, но дорого. Внешний SRAM или eDRAM. Межделмаш уже давно этим развлекается, но в x86 мэйнстрим это не пойдёт, а если не будет в x86 мэйнстриме, то не будет и в x86 серваках. Выгоднее делать то, что уже делается. >Даже четыре канала DDR3 уже недостаточны для современных х86 процессоров. >А что касается технологий памяти — то помните такую идею, как FB-DIMM? Проблема не в каналах, а устаревшей концепции. Физические размеры модулей, расстояние между ними и контроллером, проблемы разводки многочисленных параллельных линий передачи не позволяют добиться высоких тактовых частот как в видеокартах. Модули должны стать меньше, а приёмопередающую и управляющую логику следует разместить рядом с ними. FB-DIMM и RDRAM решали эту проблему по-своему, но оба привели к чрезмерному тепловыделению и увеличенным задержкам. AMD пыталась продвинуть G3MX, размещая контроллеры памяти отдельными микросхемами на материнке в непосредственной близости от модулей памяти (по 4 модуля на контроллер), связываясь с процессором высокочастотными дифференциальными линками, но не нашла поддержки и свернула затею. Размещать обычные модули близко к процессору нельзя из-за ограничений, налагаемых системами охлаждения, а ведь каждый сантиметр важен. >Когда, к примеру, у вас висит окно Skype с разговором, а вы на другом экране активно перещелкиваете приложения и что-то такое серьезное пытаетесь делать — вы очень даже ощутите разницу. Наличие большого L3 вы заметите невооруженным глазом и услышите собственными ушами. Недавно ковырял клиентский ноут с Athlon II X2 M300. 2x 512Kb S-cache, всё летало. В реальной жизни польза от замены механического харда на быстрый SSD часто гораздо ощутимее, чем от апгрэйда подобного 2-ядерника на 4- или 6-ядерник с большим T-cache. |
|
Stranger_NN
650-700 мегабайт у меня архивы (rar). Совсем не надо читать весь архив, достаточно прочесть структуру директории внутри и вытащить один файл. Да, менее секунды с обычными pdf в 2-3 мегабайта — окно 7-zip только мелькнуть на экране успевает, индикатор загрузки процессора никак не меняется. С pdf в 50 МБ — где-то около секунды висит окошко 7-zip и на графике загрузки одного ядра появляется тоненький пик до 70%.
На работе у меня Outlook и несколько гигабайт почты. Только вот идеи её архивировать во время разговора ни разу не приходило. Во-первых, во время разговора быстрый доступ к архиву почты нужен, как никогда. Во-вторых, подобные задачи я вообще только в пятницу включаю перед выходом, чтобы всё само за выходные выполнилось, мне не мешая.
Такой фокус может быть только в альтернативной вселенной. Зависимость от "расстояния" (кол-ва "хопов") в теории линейная, как Вы и сам уже тут писали. На практике задержки изменяются только в худшую сторону. Одновременно на кольце могут находиться несколько пакетов, хоть на каждом сегменте. Могут быть от разных абонентов, могут быть "поезда" от одного абонента. Право на передачу часто просто определяется знанием о том, пришло ли уже что-то от абонента выше по потоку. Вы тут описали token bus протокол, почти уже совсем мёртвый по ряду причин.
Тут вообще нет никакой разницы между двумя топологиями. В обеих могут быть глухие затыки, в обеих они обходятся спец. условиями протоколов. В Tilera обслуживание входных портов чередуется, каждый вх. порт держит до 3-х пакетов, при заполнении ничего на него не отправляется.
Лучшую альтернативу из этого мира можете предложить?
Единственный плюс сомнительной полезности — потенциально, разные типы памяти на модулях. На фоне всех минусов FB-DIMM это ничто. ПС последовательного канала к FB-DIMM даже для покрытия ПСП одного модуля не хватало, даже при частоте 4.8 ГГц. LR-DIMM решают все их проблемы. DDR4 позволяет повесить более одного модуля на свитч. |
К сожалению, у меня нет таких процессоров (и SSD дисков тоже)... Все очень даже ощутимо. Могу даже видео записать...Хм. Мне кажется, или я вижу в центре картинки коммутатор? А это уже как смотреть — надо ли придумывать структуру с передачей нескольких маркеров одновременно, с целью повышения КПД сверхдлинного кольца — или уменьшить кольцо до размера, допускающего использование одного тайм-слота на все кольцо и минимальные задержки. Если, конечно, делать кольца на сотни абонентов — то тут надо гонять много маркеров по кольцу сразу и получать прелести промежуточной буферизации. А можно делать несколько небольших колец с минимальной латентностью. Угу. Это как совместить худшие черты обеих топологий — максимально большие задержки при соединении цепочек в десятки хопов — и лишние задержки при малой загрузке. Правда, количество неблокирующихся коннектов может быть бесконечным, но суммарные задержки на длинных маршрутах в загруженной матрице будут чудовищными.Да. Разумной длины простые кольца и разумной длины объединяющее кольцо. Не надо закладываться на бесконечное масштабирование, только и всего. А что,я где-то ограничивал ширину канала?? Так что с пропускной способностью все в порядке будет. |
Системы у меня есть в профиле — нет ни SSD, ни L3. Ну, на нетбуке с процессором Atom N455 (L2 512 KB, одно ядро) и НЖМД Samsung HM250HI (5400 RPM) pdf в 50 МБ открывался две секунды (вместо менее одной на C2D E8600 и WD VelociRaptor WD3000GLFS), и загрузка проца была 70% всё это время. В скорость диска или сети (пробовал по Wi-Fi тоже) это упирается, а не в кеш процессора. При быстрой прокрутке pdf загрузка ядра выше ~60% не поднималась.
Угу. Я там забыл там заголовок для картинки написать — одна остановка того, что обычно подразумевается под ring bus (кольцевая шина, двунаправленная в данном случае).
Это ведь уже давно пройденный этап (PCI vs PCIe вспоминается) — шины, которые на общих для всех абонентов проводах (один тайм-слот), уткнулись в физические ограничения (возможные тактовые частоты и т.п.). Подробности уже не помню. Вот нашёл один анализ: A comparison of Network-on-Chip and Busses.
FB-DIMM — 14 бит на чтение модуля и 10 на запись, по спецификации. А если расширять, то получается LRDIMM. |
| Новая тема Ответить | Страница 2 из 2 |
[ Сообщений: 57 ] | На страницу Пред. 1, 2 |
Кто сейчас на конференции |
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0 |
| Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения |
