Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница?
Современный многопроцессорный компьютер вероятно построен по NUMA архитектуре. Это и даёт главную особенность таких компьютеров — доступ к большей части памяти нелокальный, то есть осуществляется заметно медленнее чем к собственной памяти процессора (пример как это выглядит).
S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Для прикладного программирования поддерживать многопроцессорность сложнее. Сложность не в правильности работы программы — любая параллельная программа без проблем запустится и на NUMA-компьютере. Сложность заключается в сохранении скорости работы — если некоторые потоки будут запущенны на удалённых NUMA-узлах, то они будут работать медленнее при попытке доступа к уже нелокальной для них памяти. То есть для многопроцессорного компьютера мало распараллелить работу над задачей, нужно ещё организовать потоки таким образом, чтобы они как можно реже обращались к другим NUMA-узлам.
В случае одного многоядерного процессора всё проще — память однородна. Главное в чужой кэш не писать, а читать быстро можно откуда угодно.
Собственно, дальше проблему "многоядероность vs. многопроцессорность" можешь рассматривать как "SMP vs. NUMA". Конечно, раньше SMP были многопроцессорными, и этот термин придуман не для многоядерности, но если смотреть на современные процессоры, то будет примерно так.
Здравствуйте, Doom100500, Вы писали:
D>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности.
Есть реализации с раздельным кэшом (более того, L1 предпочитают делать персональным для каждого ядра).
Но многопроцессорность требует поддержки в чипсете, а сейчас это сильно дороже, чем в процессоре. Поэтому её очень мало. Предпочитают держать один процессор, но расширять его общение с системой.
S>Есть еще разница? S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Плюсы — что можно в случае нескольких задач, каждая из которых критична к использованию кэшей, разделить их по ядрам (процессорам). Минусы — это всё параллельность, которую сложнее реализовывать, чем последовательное исполнение.
Но, учитывая, что даже для дешёвых домашних систем процы в основном по 2 ядра, первый ряд граблей уже пройден.
Здравствуйте, snaphold, Вы писали:
N>>Для системного — иное управление, отличия политики шедулинга.
S>а для чайников можно объянсить
Я думаю, что имелось в виду следующее:
Для прикладных программистов уже существуют разработанные примитивы для распаралеривания задач в самом языке ( например asyn/await в C# ) или библиотеках ( упомянутая выше ipp ). Прикладной программист просто будет оперировать тасками, создавать их, ожидать, раздавать приоритеты ( может быть ). И не задумываться ни о кеше, ни о шине ни, даже о количестве процессоров, и уж , тем более, ни о том разные это процессоры или разные ядра.
Ну а если ты хочешь предоставить эти примитивы, то тогда уже интересуйся железными технологиями и предусмотри все возможные варианты.
Сдаётся, мне вопрос не филосовский. На высоком уровне программисту не надо знать ничего о внутреннем устройстве железа. Низкий уровень тоже к философии программирования не имеет отношения.
Здравствуйте, snaphold, Вы писали:
S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница?
Многоядерность — это многопроцессорность в одном корпусе.
А бывает еще hyperthreading — это когда один процессор прикидывается двумя. Разница гипертрединга от двух настоящих процессоров становится заметна, если оба из них нагрузить — в случае гипертрединга суммарная производительность будет не двойная, а заметно меньше.
S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
На поверхностном уровне можно вообще про это не думать. Если хочется выжать максимум производительности, то к каждому зверю из этого зоопарка надо подходить индивидуально, и чем больше разных вариантов, тем сложнее их все поддержать.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, samius, Вы писали:
S>>>Многопоточность (hyper-threading) требует поддержки в чипсете, а это не производительнее и труднее S>>>чем отдельные простенькие ядра. Пример — ht от интел. Как я понял, от этой идеи они отказались.
S>>Откуда видно что они отказались? S>>http://ark.intel.com/search/advanced/?s=t&HyperThreading=true
S>Угу, погорячился... S>В любом случае на вики пишут, что ARM отказались от.
Не октрывал ссылку, но думаю что причины могут быть в других приоритетах компании, в политике, или может быть в том, что пока не достигли значительных успехов на этом фоне, не стоит втыкать HT в линейку продуктов. Интел ведь тоже начинал с 1-2% увеличения производительности на специфичных задачах. У меня стоял один из первых камней Интела с HT. Я мерил производительность так и сяк, и все думал, ну нафига это надо было? голый маркетинг!
S>>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
D>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
Здравствуйте, ML380, Вы писали:
ML>Здравствуйте, Doom100500, Вы писали:
D>>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
ML>тынц
А кто с этим спорит? Если топик в философии, то я озвучиваю свои хотелки. А мне, решающему, в большинстве случаев, прикладные задачи хотелось бы, чтобы мой new , вызванный в контексте определённого потока пришёл в VirtualAlloc, в случае с NUMA. Я, как прикладной программист не хочу устанавливать AffinityMask. Создать группу различных тасков, вызвать их параллельно и получить уведомление об их завершении. Я хочу писать parallel_foreach и не заниматься разбором сколько у меня сейчас процессоров и на какой шине лежит его память. И даже не хочу задумываться о том, как мне придётся менять свой код, когда появится многопроцессорная материнка без NUMA, а с чем-нибудь другим, новым и передовым. Интуитивный интерфейс для моей прикладной задачи должен предоставить разработчик этого нового и передового. А мне только останется вызвать new.
Привет
Что то не до конца понимаю разницу.
Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности.
Есть еще разница?
Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница?
S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
D>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
D>>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
D>Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
люди разрабатывавшие IPP library все-таки скорее программисты, чем железячники
Здравствуйте, dilmah, Вы писали:
D>>>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
D>>Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
D>люди разрабатывавшие IPP library все-таки скорее программисты, чем железячники
И что, есть разные сборки под разные материнские платы? Кстати, IPP — интеловская либа вроде.
D>>люди разрабатывавшие IPP library все-таки скорее программисты, чем железячники
D>И что, есть разные сборки под разные материнские платы?
не разные сборки, а в зависимости от процессоров и кэшей:
(1) принимаются решения какую ветвь кода выполнять
(2) настраиваются константы и может выполняется та или иная ветвь
D> Кстати, IPP — интеловская либа вроде.
Apple, (ex-)SUN и IBM это тоже железячные компании в своем ядре. Ты хочешь сказать, что там мало программистов? Или может быть виртуальную машину Java не программисты делали?
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница? S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Вот в этой книжке: http://www.ozon.ru/context/detail/id/5137578/
прекрасно все изложено.
Много чего практически интересного о параллельном программировании тоже приводится.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, snaphold, Вы писали:
S>>Привет S>>Что то не до конца понимаю разницу. S>>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности.
N>Есть реализации с раздельным кэшом (более того, L1 предпочитают делать персональным для каждого ядра).
N>Но многопроцессорность требует поддержки в чипсете, а сейчас это сильно дороже, чем в процессоре. Поэтому её очень мало. Предпочитают держать один процессор, но расширять его общение с системой.
т.е. разницы между многопроцессорностью и многоядерностью почти нет, кроме кэша?
Здравствуйте, Doom100500, Вы писали:
D>Здравствуйте, snaphold, Вы писали:
S>>Привет S>>Что то не до конца понимаю разницу. S>>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>>Есть еще разница?
S>>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
D>По-моему, эти понятия к программированию не имеют вообще никакого отношения.
Хорошо. Поставлю вопрос так: какая разница между многопроцессорностью и многоядерностью с точки зрения программирования?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, snaphold, Вы писали:
S>>т.е. разницы между многопроцессорностью и многоядерностью почти нет, кроме кэша?
N>Для прикладного софта — именно так.
а разве у многопроцессорности нет своей шины с перефирией? т.е. в многоядерности, по моим представлениям всё может упираться в то, что шина будет тормозом
а вот в случае многопроцессорности задачи реально параллеляться.
зы. хочу понять просто что лучше
N>Для системного — иное управление, отличия политики шедулинга.
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, watch-maker, Вы писали:
WM>>Здравствуйте, snaphold, Вы писали:
WM>>В случае одного многоядерного процессора всё проще — память однородна. Главное в чужой кэш не писать, а читать быстро можно откуда угодно.
S>а если рассматривать 2 процессора по 2 ядра каждый на одной материнке? S>в чем будет разница по сравнению с одним 4-х ядерным процессором?
И опять хочу высказать по этому поводу своё скромное мнение.
Это зависит полностью от производителя данной конкретной материнки. Сегодня мы знаем о NUMA, завтра может появиться что-то ещё. Разруливать это должны драйвера.
Здравствуйте, snaphold, Вы писали: S>Хорошо. Поставлю вопрос так: какая разница между многопроцессорностью и многоядерностью с точки зрения программирования?
В первом приближении никакой разницы. Каждое ядро считается отдельным процессором. Так, в java вызов Runtime.availableProcessors() дает число ядер.
В следующем приближении можно заметить, что у ядер общий кэш и это снижает производительность. С этим можно бороться с помощью Processor_affinity.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, snaphold, Вы писали:
S>>Что то не до конца понимаю разницу. S>>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>>Есть еще разница?
Pzz>Многоядерность — это многопроцессорность в одном корпусе.
Pzz>А бывает еще hyperthreading — это когда один процессор прикидывается двумя. Разница гипертрединга от двух настоящих процессоров становится заметна, если оба из них нагрузить — в случае гипертрединга суммарная производительность будет не двойная, а заметно меньше.
т.е. многоядерность будет производительней hyperthreading в общем случае?
Здравствуйте, netch80, Вы писали:
N>Есть реализации с раздельным кэшом (более того, L1 предпочитают делать персональным для каждого ядра).
L1 предпочитают шарить между ядрами.
N>Но многопроцессорность требует поддержки в чипсете, а сейчас это сильно дороже, чем в процессоре. Поэтому её очень мало. Предпочитают держать один процессор, но расширять его общение с системой.
Многопоточность (hyper-threading) требует поддержки в чипсете, а это не производительнее и труднее
чем отдельные простенькие ядра. Пример — ht от интел. Как я понял, от этой идеи они отказались.
Здравствуйте, Sharov, Вы писали:
S>Многопоточность (hyper-threading) требует поддержки в чипсете, а это не производительнее и труднее S>чем отдельные простенькие ядра. Пример — ht от интел. Как я понял, от этой идеи они отказались.
Здравствуйте, samius, Вы писали:
S>>Многопоточность (hyper-threading) требует поддержки в чипсете, а это не производительнее и труднее S>>чем отдельные простенькие ядра. Пример — ht от интел. Как я понял, от этой идеи они отказались.
S>Откуда видно что они отказались? S>http://ark.intel.com/search/advanced/?s=t&HyperThreading=true
Угу, погорячился...
В любом случае на вики пишут, что ARM отказались от.
In 2010, ARM said that it might include simultaneous multithreading
in its chips in the future,[17] however this was rejected for their 2012 64 bit design.[18]
Далее, с подачи Sony компания AMD внесла три изменения в архитектуру APU. Во-первых, это некая новая шина для чтения данных графическим ядром непосредственно из системной памяти, минуя кэш L1 и L2. Для "небольшого объёма" данных, который подпадает под "скорострельность" этой шины, равной 20 Гбайт/с, процессы синхронизации кэшей и данных не нужны, что устраняет кучу процессов для обмена информацией между GPU и CPU.
Во-вторых, для запуска одновременных процессов по обработке графики и по обработке GPU "неграфических" задач в строку данных для записи в кэш L2 вносится некий временный маркер — "volatile" бит, как назвали его в Sony (по-англ. непостоянный). Благодаря этому маркеру упрощается запись и возврат данных по отдельным процессам, что не ведёт к торможению графики при одновременном выполнении неграфических расчётов. В общем — это те "12 одновременно работающих программ", о которых мечтает разработчик.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, samius, Вы писали:
S>Откуда видно что они отказались?
Они отказались после 4 Pentium'а, и вернулись в "Core i".
В Core2 afaik не было HT.
S>Интел ведь тоже начинал с 1-2% увеличения производительности на специфичных задачах
As it can be seen, the program shows very good scalability of 13.38 on 16 hardware threads (8 physical cores). Speedup obtained due to HT technology (difference between 8 threads and 16 threads) is 1.86. That's quite high speedup for HT technology (reference numbers are 1.2-1.4), and it may be explained by a high amount of cache misses (linked list traversal inherently produces high amount of cache misses), which are efficiently neutralized by HT technology (pipeline stalls of two HT sibling threads are interleaved, so that execution units are busy most of the time).
Здравствуйте, Doom100500, Вы писали:
D>Сдаётся, мне вопрос не филосовский. На высоком уровне программисту не надо знать ничего о внутреннем устройстве железа.
bullshit
Программисту не нужно знать о кэшах? О том что из памяти приходят большие блоки (64 байт на современном железе)?
Не хочется спускаться до уровня конкретных железок?
ОК — делай cache-oblivious algorithm — но это всё равно некоторое знание о внутреннем использовании железа, пусть не конкретного.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, samius, Вы писали:
EP>Они отказались после 4 Pentium'а, и вернулись в "Core i". EP>В Core2 afaik не было HT.
Действительно в Core2 не было. Но "отказались и вернулись" имеет немного другой смысл чем "отказались и не вернулись".
S>>Интел ведь тоже начинал с 1-2% увеличения производительности на специфичных задачах
EP>Маловато, тут говорят про 25%: EP>
EP>The total performance is never doubled by hyperthreading, but it may be increased by e.g. 25%
Дык я ведь написал что начинал. Это первые HT на пне4. Сейчас они действительно приближаются к 2x по сравнению с выключенным HT на некоторой синтетике. Да и winrar показывает стабильные 1.5x.
Здравствуйте, samius, Вы писали:
EP>>Они отказались после 4 Pentium'а, и вернулись в "Core i". EP>>В Core2 afaik не было HT. S>Действительно в Core2 не было. Но "отказались и вернулись" имеет немного другой смысл чем "отказались и не вернулись".
я не спорю, я просто пояснил причину возможной путаницы
