Привет
Что то не до конца понимаю разницу.
Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности.
Есть еще разница?
Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница?
S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
S>>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
D>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
D>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
D>>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
D>Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
люди разрабатывавшие IPP library все-таки скорее программисты, чем железячники
Здравствуйте, dilmah, Вы писали:
D>>>ну почему? для разработчика какой-нибудь высокопроизводительной математической библиотеки это может означать разницу на каком уровне нет смысла паралеллить операции.
D>>Походу эти разработчики пишут только под конкретное железо. Тогда опять — же проблема больше железячная, из мира Embedded, а не програмисткая, где важнее гибкость и минимум зависимостей, в том числе и от железа. Не?
D>люди разрабатывавшие IPP library все-таки скорее программисты, чем железячники
И что, есть разные сборки под разные материнские платы? Кстати, IPP — интеловская либа вроде.
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности.
Есть реализации с раздельным кэшом (более того, L1 предпочитают делать персональным для каждого ядра).
Но многопроцессорность требует поддержки в чипсете, а сейчас это сильно дороже, чем в процессоре. Поэтому её очень мало. Предпочитают держать один процессор, но расширять его общение с системой.
S>Есть еще разница? S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Плюсы — что можно в случае нескольких задач, каждая из которых критична к использованию кэшей, разделить их по ядрам (процессорам). Минусы — это всё параллельность, которую сложнее реализовывать, чем последовательное исполнение.
Но, учитывая, что даже для дешёвых домашних систем процы в основном по 2 ядра, первый ряд граблей уже пройден.
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, Вы писали:
N>>Для системного — иное управление, отличия политики шедулинга.
S>а для чайников можно объянсить
Я думаю, что имелось в виду следующее:
Для прикладных программистов уже существуют разработанные примитивы для распаралеривания задач в самом языке ( например asyn/await в C# ) или библиотеках ( упомянутая выше ipp ). Прикладной программист просто будет оперировать тасками, создавать их, ожидать, раздавать приоритеты ( может быть ). И не задумываться ни о кеше, ни о шине ни, даже о количестве процессоров, и уж , тем более, ни о том разные это процессоры или разные ядра.
Ну а если ты хочешь предоставить эти примитивы, то тогда уже интересуйся железными технологиями и предусмотри все возможные варианты.
Сдаётся, мне вопрос не филосовский. На высоком уровне программисту не надо знать ничего о внутреннем устройстве железа. Низкий уровень тоже к философии программирования не имеет отношения.
Здравствуйте, snaphold, Вы писали:
S>Привет S>Что то не до конца понимаю разницу. S>Насколько я понимаю сейчас разница только в том, что в случае многопроцессорности, кэш процессора не будет делиться и это плюс многопроцессорности. S>Есть еще разница?
Современный многопроцессорный компьютер вероятно построен по NUMA архитектуре. Это и даёт главную особенность таких компьютеров — доступ к большей части памяти нелокальный, то есть осуществляется заметно медленнее чем к собственной памяти процессора (пример как это выглядит).
S>Вопрос 2. Какие плюсы/минусы имеет Многоядероность и многопроцессорность с точки зрения разработки?
Для прикладного программирования поддерживать многопроцессорность сложнее. Сложность не в правильности работы программы — любая параллельная программа без проблем запустится и на NUMA-компьютере. Сложность заключается в сохранении скорости работы — если некоторые потоки будут запущенны на удалённых NUMA-узлах, то они будут работать медленнее при попытке доступа к уже нелокальной для них памяти. То есть для многопроцессорного компьютера мало распараллелить работу над задачей, нужно ещё организовать потоки таким образом, чтобы они как можно реже обращались к другим NUMA-узлам.
В случае одного многоядерного процессора всё проще — память однородна. Главное в чужой кэш не писать, а читать быстро можно откуда угодно.
Собственно, дальше проблему "многоядероность vs. многопроцессорность" можешь рассматривать как "SMP vs. NUMA". Конечно, раньше SMP были многопроцессорными, и этот термин придуман не для многоядерности, но если смотреть на современные процессоры, то будет примерно так.
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, watch-maker, Вы писали:
WM>>Здравствуйте, snaphold, Вы писали:
WM>>В случае одного многоядерного процессора всё проще — память однородна. Главное в чужой кэш не писать, а читать быстро можно откуда угодно.
S>а если рассматривать 2 процессора по 2 ядра каждый на одной материнке? S>в чем будет разница по сравнению с одним 4-х ядерным процессором?
И опять хочу высказать по этому поводу своё скромное мнение.
Это зависит полностью от производителя данной конкретной материнки. Сегодня мы знаем о NUMA, завтра может появиться что-то ещё. Разруливать это должны драйвера.
Здравствуйте, snaphold, Вы писали: S>Хорошо. Поставлю вопрос так: какая разница между многопроцессорностью и многоядерностью с точки зрения программирования?
В первом приближении никакой разницы. Каждое ядро считается отдельным процессором. Так, в java вызов Runtime.availableProcessors() дает число ядер.
В следующем приближении можно заметить, что у ядер общий кэш и это снижает производительность. С этим можно бороться с помощью Processor_affinity.
Здравствуйте, Doom100500, Вы писали:
D>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
Здравствуйте, ML380, Вы писали:
ML>Здравствуйте, Doom100500, Вы писали:
D>>По-моему, эти понятия к программированию не имеют вообще никакого отношения. Как там делится кеш между процессорами или ядрами — вопрос только производителя железа.
ML>тынц
А кто с этим спорит? Если топик в философии, то я озвучиваю свои хотелки. А мне, решающему, в большинстве случаев, прикладные задачи хотелось бы, чтобы мой new , вызванный в контексте определённого потока пришёл в VirtualAlloc, в случае с NUMA. Я, как прикладной программист не хочу устанавливать AffinityMask. Создать группу различных тасков, вызвать их параллельно и получить уведомление об их завершении. Я хочу писать parallel_foreach и не заниматься разбором сколько у меня сейчас процессоров и на какой шине лежит его память. И даже не хочу задумываться о том, как мне придётся менять свой код, когда появится многопроцессорная материнка без NUMA, а с чем-нибудь другим, новым и передовым. Интуитивный интерфейс для моей прикладной задачи должен предоставить разработчик этого нового и передового. А мне только останется вызвать new.
