Warrax
тем не менее все Барселоны, все то кол-во, которое АМД могут произвести — проданы
об их дефиците не мне тебе рассказывать
На серверном рынке достаточно неплохо.
Да и то, до появления серверного варианта Nehalem-а...

Вопрос с десктопом. Там мало что светит.

кстати, знаешь кто является сейчас эксклюзивным покупателем Барселон и загребает себе 2/3 от всех произведенных?
Небось "двубуквенные мерзавцы", начинавшие делать технику в сарае?

matik
Небось "двубуквенные мерзавцы"
неа — бывший эксклюзивный бастион Intel-a — DELL

matik

Цитата:

---

А вот в хай энде и верхней части мидл энда им ловить до "Бульдозера" просто нечего.

---

А что такого интересного намечается в "Бульдозере", что так сильно скажется на его производительности в противовес Корам и уж тем более Нехалемам, которые к тому времени уже начнут тихую экспансию в десктопный сектор? Просто не вижу или туплю — чем так силён будет "Бульдозер"? Ну я понимаю, если графическое ядро к нему приклеят(хотя обещали ещё к Фенам его прилепить) — для ноутов самое то, но для десктопов-то что реально полезного? Я конечно реально уважаю AMD и сам сидел на их CPU много лет, но вот их великих планов что-то ни как не разумею

Asmodeus
А что такого интересного намечается в "Бульдозере", что так сильно скажется на его производительности в противовес Корам и уж тем более Нехалемам, которые к тому времени уже начнут тихую экспансию в десктопный сектор? Просто не вижу или туплю — чем так силён будет "Бульдозер"?
Если все получится как задумывалось — возможность перебрасывать ФУ одного ядра в помощь другому ядру (!). Точнее, это должно стать возможным даже не для ядра, а для потока (!). Аналогов такой ситуации я не знаю. Здесь огромная сложность в планировщиках, и в том, что они должны стать существенно более умными, нежели когда-либо до этого.
Ну и плюс четверной запуск (а не тройной, как у текущей Барселоны), плюс FMA (если, опять же, реализуют).
Конечно, все это важно еще и по срокам, иначе соперничать придется совсем не с текущими Нехалемами, а с чем-нибудь следующим.

Warrax
бывший эксклюзивный бастион Intel-a — DELL
Гады! Так вот из-за кого проблемы с доступностью Барселоны!

Цитата:

---

Барселоны

---

И кому она вообще нужна?

Цитата:

---

интересного намечается в "Бульдозере"

---

А с чего бы это он должен быть лучше коре? Новее — и всё?

Иван Иванович
И кому она вообще нужна?
Мне нужна Быстро работает, хорошо продается

А с чего бы это он должен быть лучше коре? Новее — и всё?
А чем таким волшебным известен Core2?
Хорошее ядро, не спорю. Но не более того Там хватает своих ограничений и "скелетов в шкафу".

Цитата:

---

Мне нужна Быстро работает, хорошо продается

---

Да, но есть процы и быстрее

Цитата:

---

А чем таким волшебным известен Core2?

---

Хорошо гониться, распостранён, хороший призводитель

Иван Иванович
Да, но есть процы и быстрее
В серверном сегменте? За те же деньги? Уверены?

Хорошо гониться
99% покупателей совершенно пофигу. Они никогда его не разгоняют.

распостранён
Воистину, достоинство микроархитектуры Core 2

хороший призводитель
Еще смешнее. Я думал, Вы про продукт — а Вы "про понты"

Цитата:

---

В серверном сегменте? За те же деньги? Уверены

---

А xeon — он подороже, но кач-во

Цитата:

---

9% покупателей совершенно пофигу. Они никогда его не разгоняют.

---

Да есть такое (сам встречался)

Цитата:

---

Воистину, достоинство микроархитектуры Core 2

---

Он не был бы распостранён если бы не был хорошим

Цитата:

---

Еще смешнее. Я думал, Вы про продукт — а Вы "про понты

---

Хорошая поддержка, заменят в случае брака

Иван Иванович
А xeon — он подороже, но кач-во
Не понял про качество Можно подробнее?

Да есть такое (сам встречался)
Оно не просто "есть" Оно есть повсеместно. А вот иногда процессоры разгоняют
Вот ТЕМ людям надо Core 2

Он не был бы распостранён если бы не был хорошим
Гы Попробуйте применить эту пословицу к П4

Хорошая поддержка, заменят в случае брака
Абсолютно ничего необычного. Брак заменяют вообще все компании. Включая VIA и даже Cyrix, когда еще был жив.

Цитата:

---

Не понял про качество Можно подробнее?

---

Качество — всмысле производительность, потенциал

Цитата:

---

Гы Попробуйте применить эту пословицу к П4

---

А почему она не подходит к core

Цитата:

---

Абсолютно ничего необычного. Брак заменяют вообще все компании. Включая VIA и даже Cyrix, когда еще был жив.

---

Главное — МЕНЬШЕ вероятность брака

Иван Иванович
Качество — всмысле производительность, потенциал
Извините, не согласен. Качество изделия никак не связано с его производительностью. Это две перпендикулярных характеристики.

А почему она не подходит к core
Потому что количество проданного товара не является характеристикой ни качества, ни даже производительности А является сложной функцией перечисленного, цены, доступности, производственных возможностей, даже моды.
В этой ситуации упирать на количество проданного как на аргумент — сомнительная затея

Главное — МЕНЬШЕ вероятность брака
Неверное утверждение. Если говорить об ошибках в процессорах, то их в Core 2 даже больше. Так что и вероятность наткнуться на ошибку больше (а там есть очень неприятные). Если говорить о браке как о неработоспособном изделии, то у обоих вендоров это исключительные, единичные случаи.

Цитата:

---

Извините, не согласен. Качество изделия никак не связано с его производительностью. Это две перпендикулярных характеристики.

---

Хорошо, не качество (которое тоже навысоте) — но производительность барселоне такая и не снилась

Цитата:

---

Потому что количество проданного товара не является характеристикой ни качества, ни даже производительности А является сложной функцией перечисленного, цены, доступности, производственных возможностей, даже моды.
В этой ситуации упирать на количество проданного как на аргумент — сомнительная затея

---

Врядли будет много куплено плохого — народ между собой информацией делиться — что плохо а что хорошо

matik
Спасибо! Теперь понял — чего там будет антиресного, ежели таки всё же реализуют во-время

Иван Иванович
но производительность барселоне такая и не снилась
В серверных приложениях все вполне нормально. На двухпроцессорном рынке до старших Зионов Барселоне действительно не дотянуться, но она значительно дешевле. Младшие и средние Зионы Барселона перекрывает.
Если говорить о рынке четырехпроцессорных систем, то Барселона там хороша во всем диапазоне, включая старшие Зионы.

Так что на серверном рынке это не очень-то верное возражение. Там у АМД все действительно неплохо.

Врядли будет много куплено плохого — народ между собой информацией делиться — что плохо а что хорошо
Да ну, перестаньте Те же P-D во времена А64 Х2 продавались только так, хотя были и более медленными, и более горячими. Как так получилось?

Asmodeus
ежели таки всё же реализуют во-время
Это да. Это вопрос.
Ну и плюс могут что-то обрезать. Тогда тоже будет не шибко хорошо...

Иван Иванович
но производительность барселоне такая и не снилась
я смотрю некоторые ссылки в этой темы нужно закреплять вверху каждой страницы
вынужден делать повтор
Scalability and performance of HP ProLiant servers in 32- and 64-bit HP Server Based Computing environments

Ага, вот и Интел начала экспериментировать с чем-то подобным 1Т-SRAM.
Интеловский вариант, похоже, понадобится для larrabee: множество мелких ядрышек вперемешку с массивами памяти...

matik, это, как я понимаю, уже не SMP, а МРР получается? Потому что арбитраж такой системы — конец всей работе..

Stranger_NN
Почему не SMP? Ты на остальные ....сумбурные мысли авторов особо внимание не обращай Тут главное то, что Интел тоже заинтересовался технологиями замены ячейки SRAM на малотранзисторные варианты.

А, сообразил, ты про Larrabee? Да, это MPP, и там явно другие методы управления понадобятся. Собственно, поэтому-то Larrabee не выводят сейчас: оно уже готово с инженерной точки зрения, но пока делать с ним нечего. Надо задумываться еще над там, как и что с ним сделать, чтобы вышел толк.

Здесь спорить о процах нельзя — форум то про амд Но как было уже сказано амд всегда плелась в хвосте. Раработок не вела — ширпотреб сплошной. А насчет ссылки — смотря с чем спавнивать

alexandrius
Здесь спорить о процах нельзя
Почему вдруг? Наоборот.

форум то про амд
А это Вы откуда взяли? Здесь форум про процессоры. В том числе про IBM Power, SUN, и т.д. Никто не требует, чтобы обсуждали только АМД.

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

Раработок не вела
Опять ерунда.

ширпотреб сплошной
Глупости сплошные.

Было бы неплохо чуток почитать для расширения кругозора.

matik, ну и как ты оцениваешь перспективы появления слабосвязанных алгоритмов? Нет, про серверы я и не говорю — я про десктопы..? Разговоры об этом я слышу очень давно, а воз и ныне там. Кстати, MPP куда как затратнее на "единицу синхронизации", чем SMP — тоже, проблема..

Stranger_NN
ну и как ты оцениваешь перспективы появления слабосвязанных алгоритмов? Нет, про серверы я и не говорю — я про десктопы..?
В ближайшем будущем — никак. Спустя пяток лет — варианты появятся. Математиков достаточно сильно сейчас нагрузили этими задачами, через пару лет будут появляться результаты.
До этого момента просто интерес был скорее академический, а сейчас прикладников нагрузили.
Думаю, будут варианты.

Все подряд, конечно, отнюдь не переедет на параллельные алгоритмы. Но кое-что (особенно ресурсоемкое) — вполне.

Кстати, MPP куда как затратнее на "единицу синхронизации", чем SMP — тоже, проблема..
Да, факт. Будут делать как в кластерах: обмен сообщениями, а не постоянная когеррентность.

matik/n
ведь форум ати а ati и amd это одна и таже фирма а здес в основном владельцы ati amd
=> перевес у амд я потому чазал.
Да с начала так было и процы первые интел, и двух ядерные первые интел а амд плагиатит

matik, хммммм... Я полгаю, что проблема более фундаментальна, чем прикладная математика.. Распараллеливание такого типа (да еще в слабосвязанной структуре) применимо, на мой взгляд, к очень ограниченному набору задач... Видео-аудио обработка, в основном. Даже моделирование физики уже проблема — с ростом количество обсчитываемых объектов количество синхросигналов растет лавинообразно.. Что еще?

Цитата:

---

Да, факт. Будут делать как в кластерах: обмен сообщениями, а не постоянная когеррентность.

---

Дык это-то понятно, но и в этом случае при более-менее значительном количестве узлов мы получим либо нев<ероят>но сложную структуру передачи — либо непредсказуемое время доставки сообщений. А это у нас что? Простои ядер..

Я, собссно, к чему: имеет ли смысл система, состоящая из более чем ...16(??) ядер?

alexandrius
ведь форум ати а ati и amd это одна и таже фирма
Что за ерунда? Какое отношение частный ресурс в интернете имеет к компаниям АМД и АТИ? Вы бы хоть на темы посмотрели, что ли?

Да с начала так было и процы первые интел, и двух ядерные первые интел а амд плагиатит
Я уже предлагал учить матчасть. Первые двухъядерные появились вообще не у АМД и не у Интел. На х86 рынке первые двухъядерные появились у АМД. И демонстрировали их на год раньше.
Что касается первого процессора, то никто не отрицает, что Интел разработала х86 архитектуру. Но АМД купила на нее лицензию, так что никакого плагиата нет и в помине: начиная с пятого поколения (Pentium у Intel и К5 у АМД), ничего общего (кроме системы команд) в процессорах двух компаний нет.
Они ПОЛНОСТЬЮ разные.
Вы бы сначала действительно почитали бы по теме, а?

Stranger_NN
Я полгаю, что проблема более фундаментальна, чем прикладная математика..
Часть последовательных алгоритмов можно заменить параллельными, это как раз чистая математика.

Распараллеливание такого типа (да еще в слабосвязанной структуре) применимо, на мой взгляд, к очень ограниченному набору задач...
Лукавая формулировка. Текущие алгоритмы действительно ограниченно распараллеливаемы. Но их почти всегда можно заменить на параллельные варианты.
Это не всегда оправдано в силу организационных или финансовых причин, факт.
Но то, что можно — тоже факт.

Дык это-то понятно, но и в этом случае при более-менее значительном количестве узлов мы получим либо нев<ероят>но сложную структуру передачи — либо непредсказуемое время доставки сообщений. А это у нас что? Простои ядер..
Почему "невероятно сложную"? Кластеры ведь как-то справляются, правда?
Насчет "непредсказуемого времени" ты тоже не прав, теория информации позволяет четко запланировать. Зависит от организации.
На самом деле вопрос в цели и затраченных усилиях.
Как ни крути, наш мозг — очень мощная параллельная машина. Так что у нас пока особого выбора не видно. Рост производительности одного потока на текущий момент уперся в ограничения.

matik

Цитата:

---

их почти всегда можно заменить на параллельные варианты.

---

Хмм. Вот тут я что-то не очень уверен.. На ограниченно параллльные в некоторых моментах — да, но чтобы легко и изящно с десятками слабосвязанных узлов, с негарантированными временными характеристиками?? Сильно сомневаюсь.

Цитата:

---

Почему "невероятно сложную"? Кластеры ведь как-то справляются, правда?

---

Будет время и ОЧЕНЬ большой лист бумаги — нарисуй структуру типа "каждый с каждым" на 16 узлов. Оцени паутинку.

Заметь, это единственный способ получить минимальное время доставки данных, но конструкция каждого узла выходит монструозной. Есть еще кольцевые шины (которые, как мо мне — так хороши), но у них свои грабли....

Цитата:

---

Насчет "непредсказуемого времени" ты тоже не прав, теория информации позволяет четко запланировать. Зависит от организации.

---

Зависит. Схема вот с коммутатором вообще не позволяет оценить задержку (трабл типа конкуренция за порт назначения при отсутствии огромных буферов в коммутаторе). Кольцо — не идеально, но хоть что-то, какие-то внятные рамки, но простой на холостом ходу, peer-to-peer — ты схемку-то разрисовал?

Цитата:

---

Как ни крути, наш мозг — очень мощная параллельная машина.

---

Еще какая!!!! Тебе напомнить про сложность системы связи между нейронами? А быстродействие нейрона, приведенное к бинарной логике (каждый нейрон сам по себе компьютер с огромным числом состояний)? Нет, такое в железе нам пока не по зубам..

Stranger_NN
Будет время и ОЧЕНЬ большой лист бумаги — нарисуй структуру типа "каждый с каждым" на 16 узлов. Оцени паутинку.
А что, кроме "точка-точка" больше никто ничего не придумал, да? Топология типа кольцевой шины или коммутатора — тоже слишком сложно?

Заметь, это единственный способ получить минимальное время доставки данных, но конструкция каждого узла выходит монструозной. Есть еще кольцевые шины (которые, как мо мне — так хороши), но у них свои грабли....
А есть еще коммутатор, который как раз в этом случае разумный компромисс.

Зависит. Схема вот с коммутатором вообще не позволяет оценить задержку (трабл типа конкуренция за порт назначения при отсутствии огромных буферов в коммутаторе)
Илья, ну что за елки-палки? Откуда "конкуренция за порт" на НЕблокирующихся матрицах, и почему нет буферов в коммутаторах? Куда они делись?
Так ведь любую мысль до абсурда довести можно....

Тебе напомнить про сложность системы связи между нейронами?
Не надо. Там нет связи "каждый с каждым".

matik

Цитата:

---

Илья, ну что за елки-палки? Откуда "конкуренция за порт" на НЕблокирующихся матрицах, и почему нет буферов в коммутаторах? Куда они делись? Так ведь любую мысль до абсурда довести можно....

---

Хмм. Хорошо, тогда объясни мне, как будет выглядеть попытка 7-8 узлов одновременно передать данные одному узлу? При объяснении не забудь учесть, что один узел передает данные, скажем, каждые 200 тактов, другой 1200 — третий 120000, но помногу.. Расскажи, а я тебе покажу, где ты ошибаешься. НЕ БЫВАЕТ "неблокирующихся матриц", точнее бывает, но это свойство исключительно самой матрицы, но никак не построенной на ней структуры.

Я с сетями именно на коммутаторах занимался ОЧЕНЬ много, чесслово — "многие-к-одному" это самая мерзкая ситуевина.

Цитата:

---

Не надо. Там нет связи "каждый с каждым".

---

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

matik
Stranger_NN
А звездообразная топология неприменима, если выделить одно специализированное ядро только для целей коммутации?
Таким образом можно сэкономить на размере кэшей ядер, сделав один большой общий на центральном коммутирующем, да и многие ненужные блоки оставить только в центральном, опять же сэкономив на размере. А кроме прочего, можно сделать две шины: коммутируемую на центральное ядро и кольцевую по остальным ядрам.

Stranger_NN
Хорошо, тогда объясни мне, как будет выглядеть попытка 7-8 узлов одновременно передать данные одному узлу?
Да элементарно: банальная "очередь сообщений". Более того, один узел все равно не сумеет сразу обработать эти 7 — 8 запросов, так что и с этой стороны проблем нет.

При объяснении не забудь учесть, что один узел передает данные, скажем, каждые 200 тактов, другой 1200 — третий 120000, но помногу..
Это совершенно безразлично: если передавать не информацию о когеррентности (мы ведь договорились, что это МРР, а не SMP), а результаты, то все останется так же, как в обычных кластерах.
То, что этот кластер в пределах кристалла, а не в виде отдельных коробочек — ничего не меняет.

НЕ БЫВАЕТ "неблокирующихся матриц", точнее бывает, но это свойство исключительно самой матрицы, но никак не построенной на ней структуры
Об этом и речь: можно сделать так, что отнюдь не коммутатор будет ограничивать передачу.

Тем не менее, количество дендритов у каждого нейрона многократно превосходит те самые жалкие 16 хвостиков, которые я попросил тебя нарисовать.
Тем не менее, ни у одного нейрона нет даже тысячи денритов, а количество нейронов — несколько миллиардов. Другими словами, нейронная сеть — достаточно бедное связями образование.
Илья, идеальной структуры нет.
Текущие способы повышения производительности одного треда практически исчерпаны.
Вариантов не видно.
Так что будут копать в эту сторону, альтернативы все равно нет.

Asmodeus
Так можно, но это годится для сравнительно небольшого числа ядер. Многие тысячи ядер так не сделаешь.

matik Ну дык я ж как раз и имею в виду перспективы на ближайшее будущее
А в отдалённом, имхо, можно создавать массивы из таких конгломератов. Оно конечно, сложно, но, имхо, иного-то пути нет.

matik

Цитата:

---

Да элементарно: банальная "очередь сообщений". Более того, один узел все равно не сумеет сразу обработать эти 7 — 8 запросов, так что и с этой стороны проблем нет.

---

Какой емкости? Ты не находишь, что ориентируясь на "общий случай" получим ОЧЕНЬ большую очередь сообщений, в народе известную под именем "ОЗУ"?

Цитата:

---

Это совершенно безразлично: если передавать не информацию о когеррентности (мы ведь договорились, что это МРР, а не SMP), а результаты, то все останется так же, как в обычных кластерах.
То, что этот кластер в пределах кристалла, а не в виде отдельных коробочек — ничего не меняет.

---

Абсолютно ничего. Кроме потерь производительности в системе передачи сообщений. Тебе придется вешать на каждое ядро довольно сложный программный стэк, управляющий очередью сообщений. Это, мягко говоря, небесплатно для производительности.

Цитата:

---

Об этом и речь: можно сделать так, что отнюдь не коммутатор будет ограничивать передачу.

---

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

Цитата:

---

Тем не менее, ни у одного нейрона нет даже тысячи денритов

---

Сравнил. Тебе напомнить, как с ростом количества "линков" растет число возможных комбинаций?

Цитата:

---

Текущие способы повышения производительности одного треда практически исчерпаны.

---

Вот тут я с тобой не соглашусь. Я бы сформулировал немного иначе: "уже непонятно, что выгоднее, пытаться выжимать производительность из одного ядра (немногих ядер) или вкладываться в разработку эффективной сильно многоядерной структуры и математики под нее". Скорее всего будут как-то совмещать.

Да, так вот, я к тому, что многотысяче(или просто сот-)-ядерные системы пока вряд ли реализуемы. Разумная сложность, как мне кажется, на нонешнем технологическом уровне — в районе 32 ядер на сокет предельно и 16 — разумно.

P.S. Понимаешь, система передачи сообщений с ростом количества абонентов усложняется и забивается совсем не в линейной прогрессии..

Stranger_NN
Тебе придется вешать на каждое ядро довольно сложный программный стэк, управляющий очередью сообщений. Это, мягко говоря, небесплатно для производительности.
Ничего подобного. "Message system" на кластерах отработана достаточно давно. Остальное прокоментирую позже, завал

matik, ты мне одно скажи только, сколько "Message system" в тактах процессора "стоит"(включая систему разделения времени между основной задачей и коммуникативной подсистемой)? Поникаешь, у тебя на каждом узле получается полномасштабная ОС, только что без GUI..

Stranger_NN
Поникаешь, у тебя на каждом узле получается полномасштабная ОС, только что без GUI..
Ничего подобного. Сообщения надо отправлять в заранее известный адресныйй диапазон. Получать сообщения от заранее известного адреса, переменная часть которого представляет собой номер запросившего ядра. Вопрос базовой системы ввода\вывода, не более того.
Никаких ОС для этого не нужно.

matik, прости, а управлять распределением времени между счетом и системой буферизации/передачи сообщений Пушкин будет? Я уж не говорю про многократные пересылки самого пакета из кэша процессора в память узла и обратно, в сторону линка.. Да и сама система передачи не так проста — поскольку обязана содержать пускай примитивную, но систему формирования пакетов, отслеживания их "судьбы", осуществлять при необходимости повторную передачу, отвечать соседним узлам о результатах приема их сообщений и т.п.

А все почему? Потому что плоский коммутатор с конфликтами на портах. Ленивые аппаратчики опять все на программистов свалят.