Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Вас всех совершенно напрасно волнуют задержки синхронизации. Ответ на эти проблемы у производителей сейчас простой — аппаратная многопоточность. Черт с ней, большой задержкой на операцию — в это время запускается другой аппаратный поток. Каждый отдельный поток протормозит, но вместе они нагрузят одно ядро на процентов 70-80. При поддержке аппаратной многопоточности вполне реально сделать объединенный кэш L2 — пусть он будет высоколатентный — это не важно, с латентностью и задержками эффективно борется аппаратная многопоточность. C>Только вот куча задач у нас реально однопоточна — поэтому жуткие замедления на синхронизации будут убивать производительность. А если выкидывать все примитивы синхронизации — то тогда получаем и полную невозможность использовать многопоточность.
Ты подумай над тем, что ты сказал Если у тебя куча задач однопоточна — то в них нечего синхронизировать, и не будет жутких заедлений на синхронизации. Если у тебя задача сильно многопоточна, и эта куча потоков нагружает ядро процентов на 80% — то эта куча потоков в совокупности будет работать настолько быстро, насколько возможно, и не важно, какая задержка синхронизации будет на каждом из потоков.
C>Причем, это не теория — а вполне себе реальная практика с HyperThreading'овыми CPU.
HyperThreading — крайне неудачная технология, которая имеет мало общего с современной аппаратной многопоточностью. Аппаратные потоки в ниагаре и в процах интела, которые готовятся к выпуску, совсем другие. Так что эта "практика" никак не соотносится с "теорией".
Нормальльная, настоящая практика — это работа Ниагары, доступ к которой у тебя как ты пишешь есть.
C>Там как раз та же ситуация, но по другой причине — длинный pipeline делал синхронизацию очень дорогой, и в качестве метода борьбы использовали переключение потоков. В результате, очень часто получали ЗАМЕДЛЕНИЕ вместо ускорения.
Длинный пайплайн — проблема архитектуры P4. В современных многопоточных процах конвейр короткий. В ниагаре если мне не изменяет память всего 7 стадий конвейра. И аппаратные потоки там совсем другие.
C>>>Более того, скорее всего будут еще и механизмы, позволяющие разбивать набор процессоров на группы, чтобы барьер в одной группе не останавливал остальные процессоры. В общем, как раз все будет устроено как в некоторых суперкомпьютерах G>>Зачем так делать, если можно увеличить количество аппаратных потоков, и сделать высоколатентный, но централизованный кэш L2. C>См. выше.
Не аргумент ИМХО. Аппелировать к гипертредингу — некорректно.
Re[18]: Immutable data structures are the way of the future
Здравствуйте, Gaperton, Вы писали:
C>>Только вот куча задач у нас реально однопоточна — поэтому жуткие замедления на синхронизации будут убивать производительность. А если выкидывать все примитивы синхронизации — то тогда получаем и полную невозможность использовать многопоточность. G>Ты подумай над тем, что ты сказал Если у тебя куча задач однопоточна — то в них нечего синхронизировать, и не будет жутких заедлений на синхронизации.
Дело в том, что множество задач — преимущественно однопоточны. Самый тупой пример — GUI с worker-thread'ами для длительных задач.
C>>Причем, это не теория — а вполне себе реальная практика с HyperThreading'овыми CPU. G>HyperThreading — крайне неудачная технология, которая имеет мало общего с современной аппаратной многопоточностью. Аппаратные потоки в ниагаре и в процах интела, которые готовятся к выпуску, совсем другие. Так что эта "практика" никак не соотносится с "теорией".
Чем они другие?
G>Нормальльная, настоящая практика — это работа Ниагары, доступ к которой у тебя как ты пишешь есть.
А в чем у нас там будут фундаментальные различия?
C>>Там как раз та же ситуация, но по другой причине — длинный pipeline делал синхронизацию очень дорогой, и в качестве метода борьбы использовали переключение потоков. В результате, очень часто получали ЗАМЕДЛЕНИЕ вместо ускорения. G>Длинный пайплайн — проблема архитектуры P4. В современных многопоточных процах конвейр короткий. В ниагаре если мне не изменяет память всего 7 стадий конвейра. И аппаратные потоки там совсем другие.
Длинный пайплайн, в данном случае, это просто причина подобного эффекта. В 80-процессорной машине у нас будут задержки из-за необходимости обеспечения когерентности, а в P4 были задержки из-за срывов pipeline'а.
C>>См. выше. G>Не аргумент ИМХО. Аппелировать к гипертредингу — некорректно.
Это тот же самый механизм, придуманый для лечения подобных же эффектов. Так что, ИМХО, вполне корректно.
Sapienti sat!
Re[17]: Immutable data structures are the way of the future
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Вас всех совершенно напрасно волнуют задержки синхронизации. Ответ на эти проблемы у производителей сейчас простой — аппаратная многопоточность. Черт с ней, большой задержкой на операцию — в это время запускается другой аппаратный поток. S>Погоди, тут я чего-то не понимаю. Мы говорим про thread context switch или про что? S>Переключение потока, вроде бы, тоже не сахар. Поскольку у потока как минимум свой стек, переключение нарушит локальность и с высокой вероятностью приведет к сбросу кэша. А это опять сбегать в основную память.
Нет, речь, разумеется, не о переключении контекста. Аппаратный мультатрединг работает так.
У тебя в одном процессорном ядре есть, допустим, один конвейр и кластер арифметики, но 4 независимых копии регистрового файла, и четыре независимых program counter. Конвейр ядра при этом крайне простой — он может выдавать одну инструкцию за такт. На каждый такт ядро выбирает инструкцию по другому program counter. Таким образом, у тебя 4 независимых потока выполнения, переключающихся на каждом такте по кругу, без какого-либо оверхэда — выглядит это для софта как 4 независимых ядра, на самом же деле аппаратно это одно ядро. При этом, потоки могут быть в двух состояниях — готовы к выполнению, и не готовы к выполнению. Поток не готов к выполнению, если он ждет какого-нибудь события, в частности (но не исчерпывающе):
1) Завершения конвейеризованной арифметической операции, например целочесленного умножения или деления, или операции с плавающей запятой.
2) Ждет, пока завершится операция с памятью при случае промаха в кэш.
3) Ждет когда прочухает синхронизация.
По кругу переключаются только готовые к выполнению потоки.
Зачем так делать? Затем, что данная схема позволяет очень дешевым образом по сравнению с суперскалярными процессорами поддерживать исполнительный конвейр ядра в наполненном состоянии, и эффективно бороться с задержками в интерфейсе с памятью. Промах в кэш уже не так страшен — размер кэша уже не так критичен для производительности как при суперскалярном дизайне, поэтому размер кэшей L1 можно уменьшить. Задержки при обращении в память уже не так критичны — поэтому можно совершенно спокойно делать объединенный кэш L2. Всю цепочку обращения к памяти можно удлиннить и конвейеризовать — и все будет в порядке, чтобы компенсировать негативное влияние задержки достаточно увеличить количество аппаратных потоков.
Второй положительный момент — и это используется в ниагаре 2 — увеличив количество потоков можно хорошо загрузить конвейеризованную плавающую запятую. Вторая ниагара — один из самых быстрых процов в мире на данный момент.
Третий положительный момент — при таком дизайне существенно сокращается площадь кристалла для одного ядра, и их можно засунуть в кристалл МНОГО. Все анонсированные процы всех производителей, в которых большое количество ядер, будут по принципам архитектуры и свойствам напоминать Ниагару. А именно — очень простые ядра single-issue, с большим количеством аппаратных потоков. Почитай вот это
и вот это http://en.wikipedia.org/wiki/UltraSparc_T1
G>>Возьми XBox 360 — да, у него большая задержка на атомарный инкремент, однако он имеет возможность трижды переключится на другой аппаратный поток во время этой задержки — ядро продолжит работу. S>Чего-то я фундаментально не понимаю.
А теперь?
Re[19]: Immutable data structures are the way of the future
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Только вот куча задач у нас реально однопоточна — поэтому жуткие замедления на синхронизации будут убивать производительность. А если выкидывать все примитивы синхронизации — то тогда получаем и полную невозможность использовать многопоточность. G>>Ты подумай над тем, что ты сказал Если у тебя куча задач однопоточна — то в них нечего синхронизировать, и не будет жутких заедлений на синхронизации. C>Дело в том, что множество задач — преимущественно однопоточны. Самый тупой пример — GUI с worker-thread'ами для длительных задач.
Суть дела это не меняет — в преимущественно однопоточной задаче не будет жутких замедлений на синхронизации, за преимущественно отсутствием таковой. В случае гуя так это вообще пофигу — там человек не заметит никаких задержек даже на тысячу тактов.
C>>>Причем, это не теория — а вполне себе реальная практика с HyperThreading'овыми CPU. G>>HyperThreading — крайне неудачная технология, которая имеет мало общего с современной аппаратной многопоточностью. Аппаратные потоки в ниагаре и в процах интела, которые готовятся к выпуску, совсем другие. Так что эта "практика" никак не соотносится с "теорией". C>Чем они другие?
Тем, что в ниагаре потоки переключаются каждый такт, их много на одно ядро, и основная их задача — борьба с задержками при обращении в память. И они с этой задачей великолепно справляются, так как вокруг этой идеи спроектирована вся Ниагара.
У пня — длинный конвейр и суперскалярное выполнение. Его несчастных два аппаратных потока переключаются не каждый такт (иначе суперскаляр не будет работать), переключение их дороже чем в ниагаре, и это, с одной стороны, никак не помогает в борьбе с задержками при обращении к памяти, более того — усугубляет проблему вытеснением данных из кэшей — два аппаратных суперскалярных потока работая подолгу конкурируют за один разделяемый кэш мешая друг другу, а кэш в силу их суперскалярности для них как воздух — их производительность очень критична к хитам в кэш.
В результате, суперскалярному пню этот гипертрединг — как собаке пятая нога, толку от него практически ноль. А в дизайне Ниагары наоборот — никакого суперскаляра, очень простые ядра, и все построено вокруг аппаратных потоков — поэтому в Ниагаре этих ядер 8 штук, а аппаратных потоков 32. А в пне — одно ядро, и два потока. Разницу в цифрах чувствуешь? Глядя на одни цифры уже можно понять, насколько это разные технологии.
Взять синхронизацию — в ниагаре у тебя TSO, в P4 у тебя ацкое переупорядочивание записей (что дает дикий оверхэд на синхронизацию). Отличий дофига — нет в мире более разных процов, чем Ниагара и P4. Между ними вообще общего ничего нет.
G>>Нормальльная, настоящая практика — это работа Ниагары, доступ к которой у тебя как ты пишешь есть. C>А в чем у нас там будут фундаментальные различия?
См выше.
C>>>Там как раз та же ситуация, но по другой причине — длинный pipeline делал синхронизацию очень дорогой, и в качестве метода борьбы использовали переключение потоков. В результате, очень часто получали ЗАМЕДЛЕНИЕ вместо ускорения. G>>Длинный пайплайн — проблема архитектуры P4. В современных многопоточных процах конвейр короткий. В ниагаре если мне не изменяет память всего 7 стадий конвейра. И аппаратные потоки там совсем другие. C>Длинный пайплайн, в данном случае, это просто причина подобного эффекта. В 80-процессорной машине у нас будут задержки из-за необходимости обеспечения когерентности, а в P4 были задержки из-за срывов pipeline'а.
Когерентность обойдется гораздо дешевле при дизайне а-ля Ниагара, и Ниагара устроена так, чтобы задержки были пофигу. Ты вообще читал мои объяснения про аппаратную многопоточность? Для кого пишу, блин?
G>>Не аргумент ИМХО. Аппелировать к гипертредингу — некорректно. C>Это тот же самый механизм, придуманый для лечения подобных же эффектов. Так что, ИМХО, вполне корректно.
Похожий механизм (общее там только то, что и там и там два контекста выполнения аппаратно хранятся, все остальное — различия), работающий в совершенно другом контексте, решающий другие проблемы, и создающий новые проблемы. Так что некорректно совершенно.
Re[20]: Immutable data structures are the way of the future
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Cyberax, Вы писали: C>>>Это решается созданием нескольких кэшей — по штуке на поток. Хотя, AFAIR, в P4 только L1 переключался. S>>8-0 Это как? У нас в системе живет несколько тысяч (если не десятков тысяч) потоков. Сколько-сколько кэшей мы собираемся создать??? C>Два на одно вычислительное ядро Для ОС одно физическое ядро будет видно как два логических CPU.
Ты чо Синклера пугаешь? Какие нафиг два кэша на одно ядро? Ты так собрался бороться с вытеснением данных из кэша штоли? Так это проще делается — аппаратные потоки переключаются каждый такт, и все. Как и сделано в Ниагаре. Чтобы снять вопросы об эффективности такого подхода — в Ниагаре размеры кэшей L1 меньше, чем у любого из современных серверных процов, и при этом
At the time of its release in December of 2005, a single chip, eight core, 32-thread, 1.2 GHz UltraSPARC T1 server performed similarly to a two-socket, four-core, eight-thread, 1.9 GHz IBM POWER5 server, performed similarly to a four socket, eight-core, sixteen-thread 3.0 GHz Intel Xeon "Paxville MP" server, and exceeded the performance of a four socket, four-core, four-thead 1.6 GHz Intel Itanium server. Arguably, this made the UltraSPARC T1 the world's most powerful general-purpose commercial server processors, when considering multithreaded commercial workloads.
Re[18]: Immutable data structures are the way of the future
G>Третий положительный момент — при таком дизайне существенно сокращается площадь кристалла для одного ядра, и их можно засунуть в кристалл МНОГО. Все анонсированные процы всех производителей, в которых большое количество ядер, будут по принципам архитектуры и свойствам напоминать Ниагару. А именно — очень простые ядра single-issue, с большим количеством аппаратных потоков.
Чуть подробнее о том, почему будут делать именно так.
Для начала — простой принцип, позволяющий сравнивать разные архитектуры.
1) Как вычисляется пиковая производительность процессора. Во-первых, интересны в этом деле полезные операции, то есть арифметика. С этим все просто — это тактовая частота умноженная на количество всех АЛУ на кристалле, которые могут работать в параллель.
2) Реальная производительность определяется процентом загрузки АЛУ (опять же — потому, что нас интересуют только полезные операции). Процессорное ядро, кэша, интерфейс с памятью — это обвязка, случащая цели эффективно нагрузить АЛУ полезными операциями. Простои АЛУ должны быть минимизированы, идеально — АЛУ должно выдавать результат на каждом такте.
3) Внимание — самое интересное. Какая архитектура будет лучше? Та, которая при минимальной площади сможет нагрузить АЛУ по максимуму. Почему так? Потому что кристаллы имеют ограниченную площадь (она связана с ценой и процентом выхода годных), и чем больше [хорошо нагруженных АЛУ мы туда поместим, тем больше будет реальная производительность. Поэтому, лучшей будет та архитектура, которая при прочих равных будет давать меньшую площадь управления и обвязки вокруг АЛУ. Это автоматически означает большую производительность процессора.
Традиционно до последнего времени это решалось подъемом тактовой частоты (за счет углубления конвейра процессора и улучшения техпроцесса) и суперскалярным выполнением (возможностью выдавать несколько инструкций на АЛУ (или, если точнее, кластер арифметики) одновременно за один такт. В чем тут проблема? Для того, чтобы заполнять дырки в конвейре при промахе в кэш, надо иметь
1) большой размер кэша инструкций и большое "окно просмотра", в котором мы ищем независимые по регистрам инструкции, фактически восстанавливая граф зависимостей по регистрам. Процессор параллелит вашу программу на лету — современные процы имеют пять каналов арифметики, то есть умеют выдавать до 5 инструкций за такт.
2) Внеочередное выполнение инструкций. Инструкции должны выдаваться на АЛУ в порядке готовности аргументов, а не в том порядке, в котором они идут в программе.
Внеочередное выполнение, которое позволяет компенсировать задержки, создает массу неочевидных на первый взгляд технических проблем — например, точная обработка исключений, дорогое переключение контекста, неупорядоченная запись в память (это, в принципе, хорошо с одной стороны, но это выходит боком при синхронизации параллельных процессов).
Далее — чем быстрее становится процессор, тем больше будет разница в быстродействии процессора и внешней памяти. Память то у нас быстрая, но у нее офигенная латентность по выполнению запросов. Поэтому, приходится увеличивать размеры кэшей и окон просмотра. Короче говоря, управление процессора при росте проиводительности становится все сложнее и сложнее, оно пухнет, и занимает все больше площади.
Сан пошел другим путем. Как решить проблемы высокой латентности памяти, и при этом максимально упростить управление и обвязку? Выход — аппаратная многопоточность. Полный отказ от суперскаляра. Максимально простое управление — как в микропроцах начала 90-х годов. Такой подход позволяет увеличить относительную площадь АЛУ к управлению и обвязке на кристалле, одновременно — снизить требования к размеру кэшей, снизить энергопотребление и тактовые частоты, и в результате снять с кристалла той же площади существенно больше полезных операций в секунду. Короче, такой подход решает практически все проблемы. Только он позволяет иметь на кристалле в районе десятка процессоных ядер (видимых софту как сотня, потому что в каждом из них десяток аппаратных тредов). Но создает новую — придется научиться писать сильно параллельные программы. Но придется привыкать — данная архитектура является оптимумом с точки зрения разработчиков микросхем. Ничего лучше по удельной производительности на квадратный миллиметр человечество пока не придумало.
Хотя, есть еще reconfugurable computing, находящийся в данный момент в зачаточном состоянии — он выстреллит лет через 7-10.
И еще есть stream computing, который, на самом деле уже здесь. nVidia уже продает Tesla — суперкомпьтеры построенные на потоковой модели, ну и Cell тут припоминали под видом nccNUMA, а на самом деле Cell конечно же тоже заточен на потоковую обработку. Stream computing имеет хороший шанс попасть в мйнстрим уже в течении 2-3 лет. Это радикально другая парадигма программирования, там вообще надо по другому писать.
Средства параллельного программирования должны быть радикально упрощены. Что и произойдет в ближайшем будущем — мы сейчас находимся в переломной точке.
А вы, пнимаешь, хромой гепертрединг у P4 вспоминаете. Да технологии суперкомпьютеров 20-летней давности. Времена, когда передовые идеи опробировались на суперкомпьютерах безвозвратно ушли. Сейчас основным источником идей являются 3D видеоускорители, сделавшие за последние 10 лет прорыв в удельной производительности на миллиметр кристалла (stream computing). Еще один прорыв удалось сделать Sun — сейчас в интелах и АМД лихорадчно изучают дизайн Ниагары, выложенный под GPL. Процессоры будущего не будут иметь ничего общего со старыми суперкопьютерами. Они будут проще архитектурно, и будут совершенно по другому программится.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Кроме того. Если ты глянешь на архитектуру UltraSPARC T1 (а это первый из сильно многоядерных процов), то можно обратить внимание, что он не выполняет переупорядочивания записей (из-за которого возникает недетский геморрой и тормоза при синхронизации). Total Store Order там — это кроме прочего еще и снижает количество требуемых инструкций для синхронизации. И один кэш L2 на 8 ядер, зацепленный за коммутатор кроссбар. Это все в сумме означает мегадешевый interlocked increment (он из-за Relaxed Store Order такой дорогой у intel и ibm, собственно), и удешевление остальных примитивов синхронизации. C>Так вот только сами по себе ядра в SPARC'ах никогда особым быстродейтвием не отличались. Для массивно-параллельных задач типа жуткого сервера с кучей потоков — оно рулит, но вот матетематика с числодробилками на нем часто сосет.
Первая ниагара имеет одно FPU на восемь ядер, она не для числодробления презназначена, а для enterprise servers. А вот вторая ниагара (ultrasparc t2) на плавающей запятой порвет все xeon-ы и core duo на кровавые ошметки — там у каждого из ядер свое FPU.
C>Я сейчас как раз работаю (удаленно) с машинкой с UltraSparc T1 (на днях должны UltraSparc T2 привезти — жду с нетерпением). Сервера на нем вообще просто великолепно работают, а та же перекомпиляция ядра — медленнее, чем на моей скромной домашней Core 2 Duo машине.
Ничего удивительного тут нет. Во первых, "скромный" core 2 duo — самый совершенный суперскалярный (рассчитанный на однопоточные приложения) проц за всю историю человечества. Перекомпиляция ядра — однопоточное приложение. UltraSparc T1 предназначен для эффективного выполнения параллельных программ. При частоте 1.2 Мгц эффективная частота одного виртуального проца будет 300 Мгц. Так как он single issue — то он работает чуть ли не медленнее второго пня. Однако, скажем, mysql запущенный на ультраспарке и хорошо нагруженный запросами обойдет твой коре дуо раз в десять.
Далее. Если ты воспользуешься параллельным билдом — есть такие средства, то твой коре дуо также начнет сосать.
G>>Кроме того, он выполняет переключение потока при синхронизации, накладывая на нее выполнение другого потока — о чем я и говорил. Поэтому задержка на синхронизации вобще не важна — throughput процессорного ядра она не уменьшит. C>Ну это сказки — на практике будет cache thrashing, уже наблюдали такое с HyperThreading. Хотя как оптимизация — действительно работает неплохо.
Это реальность. А гипетрединг — относится к аппаратной многопоточности ниагары как наручные часы к многоквартирному дому. Посмотри бенчмарки — Ниагара самый быстрый проц в мире на целочисленных операциях, и кэша у нег меньше. А вторая ниагара — самый быстрый проц на плавающей запятой. http://rsdn.ru/forum/message/2697806.1.aspx
G>>Именно таким образом будут выглядеть процы ближайшего будущего, дружище. Вот оно, будущее. Все просто, и никаких извратов. G>>http://opensparc-t1.sunsource.net/specs/UST1-UASuppl-current-draft-HP-EXT.pdf C>Можно чуть дальше в прошлое на Cray'и с их кучей fine-grained барьеров посмотреть (могу найти PDFку с описанием). Не секрет, что настольные PC примерно на 20 лет отстают от суперкомпьютеров. Так что, скоро nccNUMA будет дальше появляться.
О чем ты? Нет никаких таких суперкомпьютеров. Все суперкомпьтеры давным давно, уже лет 10 как минимум, собираются на мэйнстримовых микропроцессорах (стойки соедняются через merynet или infiniband), Крэй сто лет назад раззорился и был выкуплен силикон графиксом, и делает свои сервера на Оптеронах. Это уже давно не так. Даже мйнфреймы сейчас работают на кастомизированной версии проца Power 5 с микропрограмной поддержкой. На этот старый crap 20-летней давности уже сейчас никто не смотрит. Основных направлений исследований по данной теме сейчас четыре.
1) fine-grain hardware multithreading.
2) stream processing (суперкопьютеры 20-летней давности сосут — идеи идут от современных 3D ускорителей, совершивших технологический прорыв)
3) reconfigurable computing (идеи идут от FPGA — совершивших технологический прорыв)
4) Перспективные модели параллельного программирования и их аппаратная поддерджка (transactional memory, kernel-stream model, lock-free datastructures, etc)
Здравствуйте, Gaperton, Вы писали:
C>>Два на одно вычислительное ядро Для ОС одно физическое ядро будет видно как два логических CPU. G>Ты чо Синклера пугаешь? Какие нафиг два кэша на одно ядро?
Я про P4 говорил.
Sapienti sat!
Re[22]: Immutable data structures are the way of the future
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Два на одно вычислительное ядро Для ОС одно физическое ядро будет видно как два логических CPU. G>>Ты чо Синклера пугаешь? Какие нафиг два кэша на одно ядро? C>Я про P4 говорил.
Ну тогда извини .
Re[20]: Immutable data structures are the way of the future
Здравствуйте, Gaperton, Вы писали:
C>>Дело в том, что множество задач — преимущественно однопоточны. Самый тупой пример — GUI с worker-thread'ами для длительных задач. G>Суть дела это не меняет — в преимущественно однопоточной задаче не будет жутких замедлений на синхронизации, за преимущественно отсутствием таковой. В случае гуя так это вообще пофигу — там человек не заметит никаких задержек даже на тысячу тактов.
Фига, будет. Банальные мутирующие строки будут требовать захватывать мьютекс при каждом обращении (или заставлять пользователя вручную проверять, что работа со строками прикрыта каким-то мьютексом). Так как мы не знаем точно, есть ли у нас в данный момент конкуррентный поток (и пофиг, что в большинстве случаев его не будет).
Ты еще учти, что скорее всего не удастся сохранить производительность текущих процессоров при записи в память при увеличении количества ядер. На Sparc'е с его 32 (AFAIR) регистрами это еще не так плохо, а вот на x86 — будет очень даже заметно.
C>>Чем они другие? G>Тем, что в ниагаре потоки переключаются каждый такт, их много на одно ядро, и основная их задача — борьба с задержками при обращении в память. И они с этой задачей великолепно справляются, так как вокруг этой идеи спроектирована вся Ниагара.
Переключение каждый такт — это непринципиально.
G>У пня — длинный конвейр и суперскалярное выполнение. Его несчастных два аппаратных потока переключаются не каждый такт (иначе суперскаляр не будет работать), переключение их дороже чем в ниагаре, и это, с одной стороны, никак не помогает в борьбе с задержками при обращении к памяти, более того — усугубляет проблему вытеснением данных из кэшей — два аппаратных суперскалярных потока работая подолгу конкурируют за один разделяемый кэш мешая друг другу, а кэш в силу их суперскалярности для них как воздух — их производительность очень критична к хитам в кэш.
В P4 оно тоже используется для борьбы с задержками при промахе по кэшу (и срывами pipeline'а) — у каждого логического ядра свой L1-кэш.
G>В результате, суперскалярному пню этот гипертрединг — как собаке пятая нога, толку от него практически ноль. А в дизайне Ниагары наоборот — никакого суперскаляра, очень простые ядра, и все построено вокруг аппаратных потоков — поэтому в Ниагаре этих ядер 8 штук, а аппаратных потоков 32. А в пне — одно ядро, и два потока. Разницу в цифрах чувствуешь? Глядя на одни цифры уже можно понять, насколько это разные технологии.
Ты на цену посмотри еще Понятно, что T1 — это процессор для больших серверов, а P4 — десктопный. Поэтому и такая разница в количестве ядер.
C>>Длинный пайплайн, в данном случае, это просто причина подобного эффекта. В 80-процессорной машине у нас будут задержки из-за необходимости обеспечения когерентности, а в P4 были задержки из-за срывов pipeline'а. G>Когерентность обойдется гораздо дешевле при дизайне а-ля Ниагара, и Ниагара устроена так, чтобы задержки были пофигу. Ты вообще читал мои объяснения про аппаратную многопоточность? Для кого пишу, блин?
Читаю. Кстати, ты еще учти, что во время выполнения Interlocked — у тебя ВСЕ ядра будут курить бамбук при попытках обращения к памяти (шина-то блокирована, однако).
Здравствуйте, Gaperton, Вы писали:
C>>Так вот только сами по себе ядра в SPARC'ах никогда особым быстродейтвием не отличались. Для массивно-параллельных задач типа жуткого сервера с кучей потоков — оно рулит, но вот матетематика с числодробилками на нем часто сосет. G>Первая ниагара имеет одно FPU на восемь ядер, она не для числодробления презназначена, а для enterprise servers. А вот вторая ниагара (ultrasparc t2) на плавающей запятой порвет все xeon-ы и core duo на кровавые ошметки — там у каждого из ядер свое FPU.
Я имею в виду целочисленные задачи. Как результат — не рвет на всех задачах. Сказывается примитивность отдельно взятого ядра — достаточно чтобы в вычислении были непараллелизуемые участки, и производительность уходит в пол.
C>>Я сейчас как раз работаю (удаленно) с машинкой с UltraSparc T1 (на днях должны UltraSparc T2 привезти — жду с нетерпением). Сервера на нем вообще просто великолепно работают, а та же перекомпиляция ядра — медленнее, чем на моей скромной домашней Core 2 Duo машине. G>Ничего удивительного тут нет. Во первых, "скромный" core 2 duo — самый совершенный суперскалярный (рассчитанный на однопоточные приложения) проц за всю историю человечества. Перекомпиляция ядра — однопоточное приложение. UltraSparc T1 предназначен для эффективного выполнения параллельных программ.
Перекомпиляция ядра — параллельный процесс (make -jN, где N — количество параллельных задач, встроено в сам make). На моем Core 2 Duo максимум производительности у меня при N=3, на T1 — при N=6. Тем не менее, все равно Core 2 Duo работает быстрее.
G>О чем ты? Нет никаких таких суперкомпьютеров. Все суперкомпьтеры давным давно, уже лет 10 как минимум, собираются на мэйнстримовых микропроцессорах (стойки соедняются через merynet или infiniband), Крэй сто лет назад раззорился и был выкуплен силикон графиксом, и делает свои сервера на Оптеронах. Это уже давно не так. Даже мйнфреймы сейчас работают на кастомизированной версии проца Power 5 с микропрограмной поддержкой. На этот старый crap 20-летней давности уже сейчас никто не смотрит. Основных направлений исследований по данной теме сейчас четыре.
Кстати, ты про суперкомпьютерные кластеры очень хорошо напомнил — это как раз nccNUMA, точнее NORMA (No Remote Memory Access). Там обращение к памяти соседнего узла стоит очень дорого — поэтому даже и не пытаются заниматься фигней вроде автоматической когенрентности памяти, а сразу используют явную передачу сообщений.
Sapienti sat!
Re[21]: Immutable data structures are the way of the future
Здравствуйте, Cyberax, Вы писали:
C>>>Дело в том, что множество задач — преимущественно однопоточны. Самый тупой пример — GUI с worker-thread'ами для длительных задач. G>>Суть дела это не меняет — в преимущественно однопоточной задаче не будет жутких замедлений на синхронизации, за преимущественно отсутствием таковой. В случае гуя так это вообще пофигу — там человек не заметит никаких задержек даже на тысячу тактов. C>Фига, будет. Банальные мутирующие строки будут требовать захватывать мьютекс при каждом обращении (или заставлять пользователя вручную проверять, что работа со строками прикрыта каким-то мьютексом). Так как мы не знаем точно, есть ли у нас в данный момент конкуррентный поток (и пофиг, что в большинстве случаев его не будет).
Мутирующие строки — это не мьютекс, а легковесная критическая секция в юзер-моде. Которая 1) будет быстрее, чем в x86 из-за total store order, 2) будет быстрее, чем откопировать строку, и 2) на захват которой наложится один из 3-х аппаратных потоков, и в реальности будет пофиг. Конкурирующий поток, разумеется, будет присутствовать в правильно написанном параллелном приложении — в большинстве случаев он будет. А если мы знаем, что его в большинстве случаев не будет, то и fine-grain синхронизацию на объекте типа строка делать — это идиотизм, нашпигованные мьютексами строки это просто плохой дизайн.
C>Ты еще учти, что скорее всего не удастся сохранить производительность текущих процессоров при записи в память при увеличении количества ядер. На Sparc'е с его 32 (AFAIR) регистрами это еще не так плохо, а вот на x86 — будет очень даже заметно.
Удастся. Я с дизайном процов несколько так знаком — и как раз с этим я вообще никаких проблем не вижу. Я вообще не понимаю твоих абстрактных теоретических рассуждений, когда у тебя есть под рукой UltraSPARC T1, и доступны тесты SPEC и TPC к нему. Сосут текущие процы, сосут.
C>>>Чем они другие? G>>Тем, что в ниагаре потоки переключаются каждый такт, их много на одно ядро, и основная их задача — борьба с задержками при обращении в память. И они с этой задачей великолепно справляются, так как вокруг этой идеи спроектирована вся Ниагара. C>Переключение каждый такт — это непринципиально.
Это принципиально, что совершенно очевидно. Один поток не сможет отработать достаточно долго, чтобы вытеснить из кэша данные второго потока, если они переключаются на каждый такт. Опять же, странно слышать такие умозрительные рассуждения при доступности бенчмарков и спецификаций доказывающих обратное.
16 KB primary instruction cache per core
— Parity protected and single-bit error recoverable
— 4-way set-associative
8 KB primary data cache per core
— Parity protected and single-bit error recoverable
— 4-way set-associative
3 MB unifed level 2 cache
— 12-way set associative, 4 banks
— ECC
Вопросы есть по размерам общих кэшей L1на одно ядро? Думаешь идиоты в сане сидят, и они перформанс не моделировали, когда общие кэша ставили на ядра небольшого размера, да? И тестам тоже не веришь, да, весь мир тебя обманывает?
G>>У пня — длинный конвейр и суперскалярное выполнение. Его несчастных два аппаратных потока переключаются не каждый такт (иначе суперскаляр не будет работать), переключение их дороже чем в ниагаре, и это, с одной стороны, никак не помогает в борьбе с задержками при обращении к памяти, более того — усугубляет проблему вытеснением данных из кэшей — два аппаратных суперскалярных потока работая подолгу конкурируют за один разделяемый кэш мешая друг другу, а кэш в силу их суперскалярности для них как воздух — их производительность очень критична к хитам в кэш. C>В P4 оно тоже используется для борьбы с задержками при промахе по кэшу (и срывами pipeline'а) — у каждого логического ядра свой L1-кэш.
Не сильно это поможет суперскалярному процу. Что и видно по тестам. Херовый там гипертрединг. А в ниагаре L1 кэш общий, он маленький, и работает при этом она быстрее. Смотри бенчмарки.
G>>В результате, суперскалярному пню этот гипертрединг — как собаке пятая нога, толку от него практически ноль. А в дизайне Ниагары наоборот — никакого суперскаляра, очень простые ядра, и все построено вокруг аппаратных потоков — поэтому в Ниагаре этих ядер 8 штук, а аппаратных потоков 32. А в пне — одно ядро, и два потока. Разницу в цифрах чувствуешь? Глядя на одни цифры уже можно понять, насколько это разные технологии. C>Ты на цену посмотри еще Понятно, что T1 — это процессор для больших серверов, а P4 — десктопный. Поэтому и такая разница в количестве ядер.
Слушай, ну хватит, смешно уже. Такая разница в количестве ядер не потому, что ниагара серверная, а пень — десктопный, а потому, что одно ядро Ниагары вместе с кэшом L1 занимает 12 мм2 на техпроцессе 0.90. На, полюбуйся на floorplan ниагары.
Сравни с ядром четвертого пня, которое без кэшей занимает более 135 мм2. Обрати внимание — ядро prescott занимает примерно 80 мм2 на том же техпроцессе.
Сравнивать, конечно, с несчастным p4 неспортивно. Надо с серверными процами от интела — которые имеют жирные кэша и сравнимую площадь кристалла. Ниагара у нас
performed similarly to a four socket, eight-core, sixteen-thread 3.0 GHz Intel Xeon "Paxville MP" server.
exceeded the performance of a four socket, four-core, four-thead 1.6 GHz Intel Itanium server.
Ай-ай-ай. Что-то не помогает "серверность" ни итаниумам, ни ксеонам. Сосут, пнимаешь. И посмотри, конечно же, на цену .
C>>>Длинный пайплайн, в данном случае, это просто причина подобного эффекта. В 80-процессорной машине у нас будут задержки из-за необходимости обеспечения когерентности, а в P4 были задержки из-за срывов pipeline'а. G>>Когерентность обойдется гораздо дешевле при дизайне а-ля Ниагара, и Ниагара устроена так, чтобы задержки были пофигу. Ты вообще читал мои объяснения про аппаратную многопоточность? Для кого пишу, блин? C>Читаю. Кстати, ты еще учти, что во время выполнения Interlocked — у тебя ВСЕ ядра будут курить бамбук при попытках обращения к памяти (шина-то блокирована, однако).
Блин, нифига ты не втыкаешь. Что надо сделать, чтобы объяснить еще понятнее? Откуда ты вообще это дикое, не побоюсь этого слова, предположение взял?
1) Какая нахрен шина. НЕТ у ниагары никакой шины памяти — процы зацеплены между собой и кэшем через коммутатор типа "кроссбар", который обеспечивает неблокирующий обмен данными во все направлениях, плюс возможность broadcast рассылки за то же время, что и передача point-to-point. В центре кристалла такой прямоугольничек — посмотри. Тэги кэша L2 (посмотри на картинку еще раз) хранятся рядом с каждым ядром, данные о блокировках будут лежать в них.
2) Блокировка является асинхронной операцией, которая временно приостановит поток, который ждет блокировки, и все. Все остальные потоки того же ядра продолжат работу. Все потоки всех остальных ядер этого вообще не заметят.
G>Сравни с ядром четвертого пня, которое без кэшей занимает более 135 мм2. Обрати внимание — ядро prescott занимает примерно 80 мм2 на том же техпроцессе.
Разумеется, с кэшами занимает ровно 135 мм2. Очепятка. Без L2 кэша — 80 мм2. G>
Здравствуйте, Cyberax, Вы писали:
C>>>Так вот только сами по себе ядра в SPARC'ах никогда особым быстродейтвием не отличались. Для массивно-параллельных задач типа жуткого сервера с кучей потоков — оно рулит, но вот матетематика с числодробилками на нем часто сосет. G>>Первая ниагара имеет одно FPU на восемь ядер, она не для числодробления презназначена, а для enterprise servers. А вот вторая ниагара (ultrasparc t2) на плавающей запятой порвет все xeon-ы и core duo на кровавые ошметки — там у каждого из ядер свое FPU. C>Я имею в виду целочисленные задачи. Как результат — не рвет на всех задачах. Сказывается примитивность отдельно взятого ядра — достаточно чтобы в вычислении были непараллелизуемые участки, и производительность уходит в пол.
Ну, батенька, параллелить же надо. Понятно что отдельное ядро там тупое до безобразия — в этом вся и штука.
C>>>Я сейчас как раз работаю (удаленно) с машинкой с UltraSparc T1 (на днях должны UltraSparc T2 привезти — жду с нетерпением). Сервера на нем вообще просто великолепно работают, а та же перекомпиляция ядра — медленнее, чем на моей скромной домашней Core 2 Duo машине. G>>Ничего удивительного тут нет. Во первых, "скромный" core 2 duo — самый совершенный суперскалярный (рассчитанный на однопоточные приложения) проц за всю историю человечества. Перекомпиляция ядра — однопоточное приложение. UltraSparc T1 предназначен для эффективного выполнения параллельных программ. C>Перекомпиляция ядра — параллельный процесс (make -jN, где N — количество параллельных задач, встроено в сам make). На моем Core 2 Duo максимум производительности у меня при N=3, на T1 — при N=6. Тем не менее, все равно Core 2 Duo работает быстрее.
На шести параллельных задачах t1 никак не сможет обогнать core 2 duo — это технически невозможно. Почему он медленнее на 32-х, или хотя бы восьми? Задачи то совершенно независимы.
G>>О чем ты? Нет никаких таких суперкомпьютеров. Все суперкомпьтеры давным давно, уже лет 10 как минимум, собираются на мэйнстримовых микропроцессорах (стойки соедняются через merynet или infiniband), Крэй сто лет назад раззорился и был выкуплен силикон графиксом, и делает свои сервера на Оптеронах. Это уже давно не так. Даже мйнфреймы сейчас работают на кастомизированной версии проца Power 5 с микропрограмной поддержкой. На этот старый crap 20-летней давности уже сейчас никто не смотрит. Основных направлений исследований по данной теме сейчас четыре. C>Кстати, ты про суперкомпьютерные кластеры очень хорошо напомнил — это как раз nccNUMA, точнее NORMA (No Remote Memory Access). Там обращение к памяти соседнего узла стоит очень дорого — поэтому даже и не пытаются заниматься фигней вроде автоматической когенрентности памяти, а сразу используют явную передачу сообщений.
Ну если ты считаешь передачу сообщений nccNUMA, то тогда я с тобой соглашусь. Асинхронные сообщения — это хорошо и удобно, ничего против не имею. Только необходимости применять это внутри кристалла пока вроде как нет — и так пока справляются. Ты в кристалл все равно слишком много ядер не засунешь — коммерческая площадь кристалла не зависит от применяемого техпроцесса, и составляет около 200 мм2 плюс-минус 50 — если экстремальные случаи не рассматривать.
Далее — одно простое 64-битное процессорное ядро вместе со скромным кэшом L1 будет занимать примерно 8-15 мм2 на техпроцессе 0,09 в зависимости от наворотов, тут ты ничего не сделаешь. Я говорю о реально простом ядре, без векторных операций типа SSE, и без особо навороченной плавающей запятой. Дальше — считай. Половину кристалла можно будет отдать под кэш, плюс потребуется сложный многопоточный контроллер памяти и внутрикристальный коммутатор. Реальное количество ядер на кристалле будет около 10 штук плюс-минус, на тонких техпроцессах будет максимум 16 ядер. С таким количеством ядер на кристалле вполне хватит аппаратной многопоточности — вводить nccNUMA внутри кристалла смысла особого нет.
Здравствуйте, Gaperton, Вы писали:
C>>Я имею в виду целочисленные задачи. Как результат — не рвет на всех задачах. Сказывается примитивность отдельно взятого ядра — достаточно чтобы в вычислении были непараллелизуемые участки, и производительность уходит в пол. G>Ну, батенька, параллелить же надо. Понятно что отдельное ядро там тупое до безобразия — в этом вся и штука.
Ну так, батенька, не все же можно распараллелить.
C>>Перекомпиляция ядра — параллельный процесс (make -jN, где N — количество параллельных задач, встроено в сам make). На моем Core 2 Duo максимум производительности у меня при N=3, на T1 — при N=6. Тем не менее, все равно Core 2 Duo работает быстрее. G>На шести параллельных задачах t1 никак не сможет обогнать core 2 duo — это технически невозможно. Почему он медленнее на 32-х, или хотя бы восьми? Задачи то совершенно независимы.
А х.з., не может оно нагрузить больше 6-8 процессоров.
Вот, кстати, тоже не очень лестный benchmark: http://tweakers.net/reviews/649/10/database-test-sun-ultrasparc-t1-vs-amd-opteron-pagina-10.html
C>>Кстати, ты про суперкомпьютерные кластеры очень хорошо напомнил — это как раз nccNUMA, точнее NORMA (No Remote Memory Access). Там обращение к памяти соседнего узла стоит очень дорого — поэтому даже и не пытаются заниматься фигней вроде автоматической когенрентности памяти, а сразу используют явную передачу сообщений. G>Ну если ты считаешь передачу сообщений nccNUMA, то тогда я с тобой соглашусь. Асинхронные сообщения — это хорошо и удобно, ничего против не имею. Только необходимости применять это внутри кристалла пока вроде как нет — и так пока справляются.
Message passing — это вырожденная nccNUMA, мы просто вообще убираем общую память. Обычная nccNUMA — это промежуточный вариант, у нас все еще есть общая память, но доступ к ней уже требует определенных дополнительных действий (барьеры и т.п.). Кстати, транзакционная память вообще идеально к nccNUMA подходит.
G>Ты в кристалл все равно слишком много ядер не засунешь — коммерческая площадь кристалла не зависит от применяемого техпроцесса, и составляет около 200 мм2 плюс-минус 50 — если экстремальные случаи не рассматривать.
Ты закон Мура помнишь? По прогнозам, он будет работать до 2015 года минимум. Если взять сегодняшний Core Quatro, то к 2015 он как раз станет где-то Core 64 просто благодаря увеличению плотности. Ну а дальше возможно будут многослойные ядра и прочая магия.
У меня вообще очень простая логика — ни одна Ниагара не сможет поднять однопоточную производительность без введения out-of-order исполнения, предикторов и больших кэшей. Однако, эти фичи сделают TSO и глобальную когерентность кэшей непомерно дорогими. Значит придется как-то с этим бороться — ну а тут ничего лучше nccNUMA пока не придумали.
Здравствуйте, Cyberax, Вы писали:
C>>>Я имею в виду целочисленные задачи. Как результат — не рвет на всех задачах. Сказывается примитивность отдельно взятого ядра — достаточно чтобы в вычислении были непараллелизуемые участки, и производительность уходит в пол. G>>Ну, батенька, параллелить же надо. Понятно что отдельное ядро там тупое до безобразия — в этом вся и штука. C>Ну так, батенька, не все же можно распараллелить.
Пример пожалуйста. Ща будем параллелить.
C>>>Перекомпиляция ядра — параллельный процесс (make -jN, где N — количество параллельных задач, встроено в сам make). На моем Core 2 Duo максимум производительности у меня при N=3, на T1 — при N=6. Тем не менее, все равно Core 2 Duo работает быстрее. G>>На шести параллельных задачах t1 никак не сможет обогнать core 2 duo — это технически невозможно. Почему он медленнее на 32-х, или хотя бы восьми? Задачи то совершенно независимы. C>А х.з., не может оно нагрузить больше 6-8 процессоров.
C>Вот, кстати, тоже не очень лестный benchmark: http://tweakers.net/reviews/649/10/database-test-sun-ultrasparc-t1-vs-amd-opteron-pagina-10.html
Ну не знаю. Вот бенчмарки SPEC. http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2657&p=4
C>>>Кстати, ты про суперкомпьютерные кластеры очень хорошо напомнил — это как раз nccNUMA, точнее NORMA (No Remote Memory Access). Там обращение к памяти соседнего узла стоит очень дорого — поэтому даже и не пытаются заниматься фигней вроде автоматической когенрентности памяти, а сразу используют явную передачу сообщений. G>>Ну если ты считаешь передачу сообщений nccNUMA, то тогда я с тобой соглашусь. Асинхронные сообщения — это хорошо и удобно, ничего против не имею. Только необходимости применять это внутри кристалла пока вроде как нет — и так пока справляются. C>Message passing — это вырожденная nccNUMA, мы просто вообще убираем общую память. Обычная nccNUMA — это промежуточный вариант, у нас все еще есть общая память, но доступ к ней уже требует определенных дополнительных действий (барьеры и т.п.). Кстати, транзакционная память вообще идеально к nccNUMA подходит.
Что-то я не понимаю, а чем то отличается от обычной памяти в любом современно многоядерном проце? У тебя и в ниагаре есть общая память, но доступ к ней тоже тебует дополнительных действий. Тот же самый MEMBAR надо выставить. Можешь и не высталвять пожалуйста. Когерентность кэшей L1 практически нигде автоматом не поддерживается, знаешь ли, это технически сложно, и дает большую просадку даже для двух ядер. Везде надо специальные инструкции выдавать.
G>>Ты в кристалл все равно слишком много ядер не засунешь — коммерческая площадь кристалла не зависит от применяемого техпроцесса, и составляет около 200 мм2 плюс-минус 50 — если экстремальные случаи не рассматривать. C>Ты закон Мура помнишь? По прогнозам, он будет работать до 2015 года минимум. Если взять сегодняшний Core Quatro, то к 2015 он как раз станет где-то Core 64 просто благодаря увеличению плотности. Ну а дальше возможно будут многослойные ядра и прочая магия.
Закон мура перестал работать примерно в 2003 году. Я еще полтора года назад в свои презентации графики вставлял, которые это показывают. Посмотри на графики роста тактовой частоты и как они кореллируют с техпроцессом — не растет уже тактовая частота, проблемы с этим. Не заметил, что частоты у процов понизились?
Core 64 ты утончением техпроцесса не получишь. Можешь просто посчитать, насколькр больше таких ядер влезет на техпроцесс 20нм, если сейчас core 2 duo делается на 65 нм. Мало запихать в один кристалл много ядер. Надо решать проблемы общего доступа к памяти (количество ног у микросхем не подчиняется закону мура, извини), суметь накормить данными эти ядра, и решить вопросы синхронизации. Суперскалярные процы типа Core Duo будут иметь большие проблемы при увеличении количества ядер.
C>У меня вообще очень простая логика — ни одна Ниагара не сможет поднять однопоточную производительность без введения out-of-order исполнения, предикторов и больших кэшей. Однако, эти фичи сделают TSO и глобальную когерентность кэшей непомерно дорогими. Значит придется как-то с этим бороться — ну а тут ничего лучше nccNUMA пока не придумали.
Во первых, ты не прав. out-of-order совершенно не нужен при многопоточном дизайне проца — они будут только мешать друг другу и не будет никакой пользы. Это взаимоисключающие вещи, поэтому собственно гипертрединг и сосет. Суперскаларное выполнение при этом вводить вполне можно (выполнять подряд идущие инструкции впараллель) — но инструкции переупорядочивать глупость. К сожалению, для того, чтобы это объяснить, мне придется целую статью здесь написать, начав издалека, с устройства типового суперскалярного проца и типичных проблем, которые там возникают. А на это у меня нет ни времени ни сил. Могу порекомендовать книгу Танненбаума по архитектуре ЭВМ — лучшее введение в вопрос для программистов.
Во-вторых, считать можно все, что угодно, однако твоя логика расходится с логикой разработчиков аппаратуры. Видишь ли, лучший способ поднять производительность однопоточной программы — это современные навороченные суперскалярные процы. И это тупиковый путь, разработчики процессоров от него отказываются. Их, строго говоря, сейчас не особо волнует однопоточная производительность, их больше волнует удельная производительность на миллиметр кристалла. Логику аппаратчиков я достаточно подробно описал здесь
. in-order выполнение и отказ от предсказания переходов сделан специально — все это компенсируется аппаратной многопоточностью. Таким образом у тебя удельная производительность кристалла будет выше.
Обрати внимание, как устроен проц XBox 360 — предназначенный для наиболее требовательных "настольных" приложений — компьютерных игр. in-order execution + 3 ядра + аппаратная многопоточность (по 2 потока на ядро), общий кэш L2. Итого — 6 аппаратных потоков. Потому что делать так — дешевле, чем суперскаляр. Производительность одного потока там примерно 20% от скорости core duo. И ничего — в майкрософт выбрали такой дизайн, хотя вполне могли опять заказать проц интелу, как для первого XBox.
Здравствуйте, Gaperton, Вы писали:
G>... out-of-order совершенно не нужен при многопоточном дизайне проца — они будут только мешать друг другу и не будет никакой пользы. Это взаимоисключающие вещи, поэтому собственно гипертрединг и сосет. Суперскаларное выполнение при этом вводить вполне можно (выполнять подряд идущие инструкции впараллель) — но инструкции переупорядочивать глупость. К сожалению, для того, чтобы это объяснить, мне придется целую статью здесь написать, начав издалека, с устройства типового суперскалярного проца и типичных проблем, которые там возникают. А на это у меня нет ни времени ни сил. Могу порекомендовать книгу Танненбаума по архитектуре ЭВМ — лучшее введение в вопрос для программистов.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Gaperton, Вы писали:
G>>... out-of-order совершенно не нужен при многопоточном дизайне проца — они будут только мешать друг другу и не будет никакой пользы. Это взаимоисключающие вещи, поэтому собственно гипертрединг и сосет. Суперскаларное выполнение при этом вводить вполне можно (выполнять подряд идущие инструкции впараллель) — но инструкции переупорядочивать глупость. К сожалению, для того, чтобы это объяснить, мне придется целую статью здесь написать, начав издалека, с устройства типового суперскалярного проца и типичных проблем, которые там возникают. А на это у меня нет ни времени ни сил. Могу порекомендовать книгу Танненбаума по архитектуре ЭВМ — лучшее введение в вопрос для программистов.
К>Ты вот эту книжку имеешь в виду?
Ну то прям жостко как-то. Не. Ничего из того, что трудно купить, достать, прочитать и понять.
Вот это — не танненбаум, существенно менее попсово — эту книгу писали аппаратчики. Вот это, пожалуй, по детальности изложения — оптимум для программиста, который хочет глубоко понять принципы аппаратного дизайна, но при этом не собирается переквалифицироваться в RTL-инженера. http://www.ozon.ru/context/detail/id/1374858/
Здравствуйте, Gaperton, Вы писали:
C>>Ну так, батенька, не все же можно распараллелить. G>Пример пожалуйста. Ща будем параллелить.
Вот недавно занимался фиксами непараллельных методов в JBoss Cache Попробую набросать пример завтра (сейчас спать хочется).
C>>А х.з., не может оно нагрузить больше 6-8 процессоров. C>>Вот, кстати, тоже не очень лестный benchmark: http://tweakers.net/reviews/649/10/database-test-sun-ultrasparc-t1-vs-amd-opteron-pagina-10.html G>Ну не знаю. Вот бенчмарки SPEC. G>http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2657&p=4
Бенчмарки и реальная ситуация — не всегда друг другу соответствуют. Особенно в многоядерных системах, где bottleneck'и могут оказаться в самых интересных местах.
G>Что-то я не понимаю, а чем то отличается от обычной памяти в любом современно многоядерном проце? У тебя и в ниагаре есть общая память, но доступ к ней тоже тебует дополнительных действий. Тот же самый MEMBAR надо выставить. Можешь и не высталвять пожалуйста. Когерентность кэшей L1 практически нигде автоматом не поддерживается, знаешь ли, это технически сложно, и дает большую просадку даже для двух ядер. Везде надо специальные инструкции выдавать.
nccNUMA отличается тем, что у нас явно выделена локальная память. Причем есть возможности ее явно синхронизировать с "общей" памятью. Точнее, "общая" память формируется из локальной памяти каждого ядра.
Соответственно, работа по поддержанию когерентности уже ложится на программиста.
C>>Ты закон Мура помнишь? По прогнозам, он будет работать до 2015 года минимум. Если взять сегодняшний Core Quatro, то к 2015 он как раз станет где-то Core 64 просто благодаря увеличению плотности. Ну а дальше возможно будут многослойные ядра и прочая магия. G>Закон мура перестал работать примерно в 2003 году. Я еще полтора года назад в свои презентации графики вставлял, которые это показывают. Посмотри на графики роста тактовой частоты и как они кореллируют с техпроцессом — не растет уже тактовая частота, проблемы с этим. Не заметил, что частоты у процов понизились?
Ай-ай-ай. В законе Мура нет ничего про тактовую частоту, а есть про плотность транзисторов. В первом приближении можно считать, что можно наращивать количество ядер пропорционально количеству транзисторов.
G>Core 64 ты утончением техпроцесса не получишь. Можешь просто посчитать, насколькр больше таких ядер влезет на техпроцесс 20нм, если сейчас core 2 duo делается на 65 нм. Мало запихать в один кристалл много ядер. Надо решать проблемы общего доступа к памяти (количество ног у микросхем не подчиняется закону мура, извини), суметь накормить данными эти ядра, и решить вопросы синхронизации. Суперскалярные процы типа Core Duo будут иметь большие проблемы при увеличении количества ядер.
Почему-то мне кажется, что инженеры в Intel'е найдут решения этих проблем. Есть у меня вот такая железная уверенность, ну может будет не 64-ядерный, а 32-ядерный Core 32.
Собственно, четырехсокетный сервер с Core 2 Quadro уже дает нам 16 ядер.
G>Во первых, ты не прав. out-of-order совершенно не нужен при многопоточном дизайне проца — они будут только мешать друг другу и не будет никакой пользы. Это взаимоисключающие вещи, поэтому собственно гипертрединг и сосет. Суперскаларное выполнение при этом вводить вполне можно (выполнять подряд идущие инструкции впараллель) — но инструкции переупорядочивать глупость.
КАК еще ты добьешся увеличения однопоточной производительности?
G>К сожалению, для того, чтобы это объяснить, мне придется целую статью здесь написать, начав издалека, с устройства типового суперскалярного проца и типичных проблем, которые там возникают. А на это у меня нет ни времени ни сил. Могу порекомендовать книгу Танненбаума по архитектуре ЭВМ — лучшее введение в вопрос для программистов.
Я примерно представляю как работают предикторы, спекулятивное исполнение и т.п.
G>Обрати внимание, как устроен проц XBox 360 — предназначенный для наиболее требовательных "настольных" приложений — компьютерных игр. in-order execution + 3 ядра + аппаратная многопоточность (по 2 потока на ядро), общий кэш L2. Итого — 6 аппаратных потоков. Потому что делать так — дешевле, чем суперскаляр. Производительность одного потока там примерно 20% от скорости core duo. И ничего — в майкрософт выбрали такой дизайн, хотя вполне могли опять заказать проц интелу, как для первого XBox.
Ну так я не спорю, что оно им так дешевле получилось — разработчикам-то особого выбора нет. А если бы у покупателей был выбор что взять: крутой параллельный процессор или крутой однопоточный — это был бы другой вопрос.
Если у тебя куча задач однопоточна — то в них нечего синхронизировать, и не будет жутких заедлений на синхронизации. 
пожалуйста. Когерентность кэшей L1 практически нигде автоматом не поддерживается, знаешь ли, это технически сложно, и дает большую просадку даже для двух ядер. Везде надо специальные инструкции выдавать.
Попробую набросать пример завтра (сейчас спать хочется).