Загоняемся на многоядерные процы
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Загоняемся на многоядерные процы - 2007-08-14 16:11:16.020000
|
|
|
Jasmin
Сообщений: 2320
Оценки: 0
Присоединился: 2007-05-03 23:08:53.390000
|
Вот чего нарыла
http://www.osp.ru/pcworld/2007/04/4230114/
Радуйтесь, Тирминатор и rgo, так называемый OpenMP есть только в вашем любимом C++. А вообще конечно неоптимизированные приложения это лень программистов. Главный аргумент - куда девать распарралеленный код если проц не многоядерный и операционка не поддерживает многопоточность.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-14 17:51:37.606666
|
|
|
tt_andrey
Сообщений: 213
Оценки: 0
Присоединился: 2007-07-03 13:54:36.440000
|
Статья ни о чем
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-14 22:22:04.180000
|
|
|
Yashin
Сообщений: 964
Оценки: 0
Присоединился: 2007-05-09 20:18:01.153333
|
Если проц и операционка не многоядерные то распаралеленный код будет выполнятся в главном потоке. А для Делфи остается вариант использывать потоки.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-14 22:28:54.893333
|
|
|
tt_andrey
Сообщений: 213
Оценки: 0
Присоединился: 2007-07-03 13:54:36.440000
|
quote:
rgo, так называемый OpenMP есть только в вашем любимом C++
кстати не думаю, что rgo так радеет за Си++, скорее за Си ;)
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 15:55:06.476666
|
|
|
Jasmin
Сообщений: 2320
Оценки: 0
Присоединился: 2007-05-03 23:08:53.390000
|
У нас жарко, искать лень, лучше спрошу здесь
Сегодня один умник рассказывал что прирост производительности при 2 ядрах такой маленький потому что типа одно ядро выполняет одну команду, второе следующую, если для следующей нет данных то второе ядро простаивает. ИМХО бред. Так могут работать множества АЛУ в одном ядре при всяких конвеерах/VLIW коммандах но никак не независимые ядра.
Так как всетаки работает Коре Дуо? Мое мнение - после ресета ядра устанавливают счетчики команд на разные значения. Первое ядро работает как обычно, второе крутится в цикле NOPов. Также есть какие то команды для изменения счетчика комманд на любом ядре. Кто точно знает, поправьте меня, глупую… [sm=ah.gif]
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 16:59:14.910000
|
|
|
tt_andrey
Сообщений: 213
Оценки: 0
Присоединился: 2007-07-03 13:54:36.440000
|
Два ядра полностью независимы. И они не имеют право да и не могут просто брать себе разные следующие друг за другом команды одного потока. Один поток в течение всего кванта времени выполняется полностью одним ядром, в это время на другом ядре выполняется другой поток или вообще ничего не выполняется.
Два ядра не дают никакого прироста или убытка для однопоточного приложения, но дают прирост для многопоточного. А многопоточность приложения обеспечивает уже программист
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 21:41:05.500000
|
|
|
rbzombie
Сообщений: 88
Оценки: 0
Присоединился: 2005-01-07 04:14:13
|
Я думаю что надо узучать спецификации Intel в которых все описано,а гадать что там и да как там можно до старости.Каждый думает по разному и рвет на себе волосы,что типа должно быть вот так.Личное мое мнение нужны очень мощные задачи(моделирование,расчет крутых уравнений,графика) такие задачи как известно используются учеными и прочим научным народом,а реклама раскажет что ты хочешь услышать.Пока это просто реклама и не более того.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 22:54:35.766666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: rbzombie
Личное мое мнение нужны очень мощные задачи(моделирование,расчет крутых уравнений,графика) такие задачи как известно используются учеными и прочим научным народом,а реклама раскажет что ты хочешь услышать.Пока это просто реклама и не более того.
когда у тебя несколько процессов конкурируют за последние кванты времени процессора, то второе ядро не помешает.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 23:23:51.933333
|
|
|
Yashin
Сообщений: 964
Оценки: 0
Присоединился: 2007-05-09 20:18:01.153333
|
quote:
ORIGINAL: tt_andrey
Два ядра полностью независимы. И они не имеют право да и не могут просто брать себе разные следующие друг за другом команды одного потока. Один поток в течение всего кванта времени выполняется полностью одним ядром, в это время на другом ядре выполняется другой поток или вообще ничего не выполняется.
Два ядра не дают никакого прироста или убытка для однопоточного приложения, но дают прирост для многопоточного. А многопоточность приложения обеспечивает уже программист
Так что же получается, Винда никак не разделяет потоки по процессорам? Я считал что если приложение не многопоточное, то должно выполнятся одновременно два несвязанных процесса, разве это нитак? А ведь как мало сейчас многопоточных приложений и потоки используются лишь в редких случаях, зато одновременно на компьютере запущенно множество процессов, которые как мне кажется и должны выполнятся на разных процессорах.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-16 23:36:51.800000
|
|
|
rbzombie
Сообщений: 88
Оценки: 0
Присоединился: 2005-01-07 04:14:13
|
To rgo это с чем же таким надо работать что бы камня не хватило(это происходит очень редко),нужна ось которая будет управлять многоядерностью это раз(то что сейчас есть,это сырое изделие) второе это софт который будет поддерживать многоядерные технологии
А нельзя ли поставить Windows server 2003 и проверить использование ядер?
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-17 00:53:44.740000
|
|
|
Yashin
Сообщений: 964
Оценки: 0
Присоединился: 2007-05-09 20:18:01.153333
|
Windows Vista поставь, может и не хватить
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-17 01:06:25.046666
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: rbzombie
To rgo это с чем же таким надо работать что бы камня не хватило(это происходит очень редко),
это зависит от пользователя. у тебя может и редко. у меня регулярно.
quote:
ORIGINAL: rbzombie
нужна ось которая будет управлять многоядерностью это раз(то что сейчас есть,это сырое изделие)
ты про венду? ну вообще бытует мнение что венда сырая поделка. но, на самом деле, всё не так плохо как ты разрисовываешь, поддержка многопроцессорности в венде есть уже очень давно, она появилась задолго до первого многоядерного проца. ну а добавить две сотни ассемблерных команд в ядро, научив его использовать ядра как процессоры – это не так уж и сложно. и это сделано.
quote:
ORIGINAL: rbzombie
второе это софт который будет поддерживать многоядерные технологии
если речь идёт о нескольких конкурирующих процессах, то от них не требуется никакой специальной подготовки, для того чтобы венда могла их по разным ядрам разнести.
ну а если речь о каком-нибудь софте для брутфорса/ray-tracing'а и пр, то я уверен что _этот_ софт уже давно умеет работать на многих ядрах одновременно. ведь от такого софта требуется лишь использовать, хоть иногда win32api функцию CreateThread, которая присутствует в венде _всегда_. по-крайней мере с '95-ой венды.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-17 16:54:13.026666
|
|
|
Jasmin
Сообщений: 2320
Оценки: 0
Присоединился: 2007-05-03 23:08:53.390000
|
Короче, железная оптимизация мне представляется такой:
Выделить в программе части которые могут работать как сервера. Запихнуть их в отдельные процессы
Допустим пишем игру. Будут процессы
PHYSIC.EXE
AI.EXE
Вручную какой нить API функцией расставить им Affinity, т е на каком ядре исполняются
Запустить оба процесса, будут выполнятся уж точно одновременно
Подождать пока оба закончат и выводить кадр
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-17 19:18:28.980000
|
|
|
Yashin
Сообщений: 964
Оценки: 0
Присоединился: 2007-05-09 20:18:01.153333
|
Зачем отдельные процессы то? Лучше использывать потоки, да и все, только в играх не все так легко - там же все связано и тот же АЙ зависит от физики. Но фоновую мелодию запустить будет можно.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-17 23:30:41.480000
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: Jasmin
Короче, железная оптимизация мне представляется такой:
Выделить в программе части которые могут работать как сервера. Запихнуть их в отдельные процессы
Допустим пишем игру. Будут процессы
PHYSIC.EXE
AI.EXE
Вручную какой нить API функцией расставить им Affinity, т е на каком ядре исполняются
Запустить оба процесса, будут выполнятся уж точно одновременно
Подождать пока оба закончат и выводить кадр
в принципе – запросто. только ты слегка усложняешь. процесс physic.exe реализовывает некий сетевой протокол, по которому сторонний процесс может управлять объектом в игре. если сторонний процесс не успевает – это его проблемы. кстати, это способ уменьшить количество лагов в игре – ведь с определённой вероятностью лаг будет выражаться не в том, что картинка замрёт на долю секунды, а в том, что бот вдруг протупит.
этот подход, конечно, не всегда рулит. но довольно часто деление задачи на отдельные процессы позволяет разделить задачу на несколько практически _независимых_ частей. причём частей, которые могут использовать не только много процессоров отдного кластера, но и много кластеров. узким местом такого подхода будет сетевое соединение, и запросто может случиться так, что все бонусы использования многих ядер/процессов будут с избытком потрачены на накладные расходы по сериализации/десериализации данных, и передачу их через ядро в адресное пространство соседнего процесса.
если продолжать с предложенным примером игры, то я думаю, что скажем стратегии, типа варкрафта и ему подобных, очень даже здорово лягут в предложенную клиент-серверную архитектуру.
quote:
ORIGINAL: Jasmin
Зачем отдельные процессы то? Лучше использывать потоки, да и все, только в играх не все так легко - там же все связано и тот же АЙ зависит от физики. Но фоновую мелодию запустить будет можно.
может быть, в данной ситуации всё-таки потоки лучше – я не возьмусь утверждать, не пробовал. но чисто по ощущениям могу сказать, что потоки хуже тем, что:
1. их сложнее отлаживать,
2. у них общее адресное пространство, и, например, ошибка в ai может привести к повреждению структур физического движка.
3. придётся писать одну программу размер которой, грубо говоря равен сумме размеров физического движка, и движка интеллектуального. а это сложнее чем написать эти движки поотдельности.
на самом деле ai не так уж и сильно зависит от физики. когда бот управляет скажем самолётом, ему достаточно знать лишь показания приборов, положение и скорость объектов в пределах видимости. а это не так уж и много. в обратную же сторону, бот будет передавать лишь команды, причём команд будет не так уж и много, чтобы об этом стоило говорить.
но на самом деле я заговорил про процессы немного в другом контексте. когда я смотрю киношку, а на заднем фоне у мну висит броузер, в котором крутиться n-ное количество флешек рекламы, то у меня уже есть два процесса активно кушающих процессорное время. а если где-нибудь в бекграунде у меня музыка перекодируется из .flac в mp3, чтобы я смог её послушать завтра по пути на работу через mp3 плеер, то вообще хорошо становится. и вот тут, лишнее ядро будет не лишним. или ещё одна ситуация, уже не вендовая – пересборка системы, для неё большим бонусом является возможность запускать одновременно компиляцию двух файлов. другое дело, что всё-таки ядро – это не процессор. и запросто может случиться, что прирост скорости от того, что ось имеет возможность использовать второе ядро будет всего 10%. но в каких-то ситуациях прирост может составить и 50%.
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-18 00:41:39.020000
|
|
|
Jasmin
Сообщений: 2320
Оценки: 0
Присоединился: 2007-05-03 23:08:53.390000
|
quote:
ORIGINAL: rgo
другое дело, что всё-таки ядро – это не процессор.
А какая разница? Чего такого нет у ядра что есть у процессора? УУ, АЛУ, регистры, дешифратор, конвееры, даже кеш свой. Единственное что шина общая но я думаю в двухядерниках она ширее, чтоб не быть бутылочным горлышком
|
|
|
|
|
RE: Загоняемся на многоядерные процы - 2007-08-19 21:25:46.393333
|
|
|
rgo
Сообщений: 7170
Оценки: 281
Присоединился: 2004-09-25 05:14:25
|
quote:
ORIGINAL: Jasmin
quote:
ORIGINAL: rgo
другое дело, что всё-таки ядро – это не процессор.
А какая разница? Чего такого нет у ядра что есть у процессора? УУ, АЛУ, регистры, дешифратор, конвееры, даже кеш свой. Единственное что шина общая но я думаю в двухядерниках она ширее, чтоб не быть бутылочным горлышком
ну фих его знает. просто из общих соображений мне так кажется. может быть я не прав.
к процессору ведь прилагается ещё внешняя логика расположенная на материнке… ну фиг знает… я, честно говоря, с многопроцессорными/двухядерными системами опыта ковыряния немного имел, чтоб судить по результатам что лучше, а даташиты на процы читать мне лень за ненадобностью ;)
хотя, с другой стороны, sun делает 64-х ядерные процы и, надо думать, оно того стоит.
но как бы там ни было, когда (если) я соберусь-таки апгрейдить свой pIII, основным критерием при выборе проца будет количество ядер :)
игрался я у знакомца с компиляцией (флаг -j у gmake который регулирует количество параллельных компилирующих процессов) – точных замеров не проводил, просто запустил с -j 1 и -j 3, просто по ощущениям быстрее. далеко не в два раза, конечно, но там оперативки было 3x128Mb, а с учётом всяких запущенных гномов/мозилл и прочих монстров надо бы побольше.
|
|
|
|
|
|
