Программы для модогядерных процессоров

← →
Fin (2008-06-19 13:01) [0]

Добрый день!
Всё больше и больше машин с многоядрными процесорами, и вот задумываюсь рад своих программ подработать, так сказать оптимизировать под многоядерные процессоры.
Скажу честно раньше об этом при написании программ не задумывался и почти все приложения писались однопоточными.
И в виду отсутствия опыта написания подобных программ возникают вопросы - скорее фундаментального плана. А именно каким образом распределят нагрузку между ядрами, в голову приходит только один вариант - многопоточные приложения, а операционка сама всё сделает или и тут не всё так просто. Сам же вопрос распаралеливания программы оставляю за рамками рассуждения.

Хочется услышать мнения форумчан.

← →
Сергей_77 (2008-06-19 13:03) [1]

имхо стоит сделать количество потоков, равное количеству процессоров

← →
DVM © (2008-06-19 13:03) [2]

> в голову приходит только один вариант - многопоточные приложения,
> а операционка сама всё сделает или и тут не всё так просто

Так и есть. Главное правильно спроектировать разделение работы между потоками и синхронизацию оных (если необходимо)

← →
palva © (2008-06-19 13:14) [3]

А что будет, если ваша "приспособленная" программа будет запущена на 386 процессоре? По-моему, нужно делать ставку на современные идеологии разработки. Может быть, DOT NET ?

← →
DVM © (2008-06-19 13:18) [4]

> palva © (19.06.08 13:14) [3]

а что будет с DOT NET запущенном на 386 процессоре?

← →
Правильный-Вася (2008-06-19 13:19) [5]

> а что будет с DOT NET запущенном на 386 процессоре?

не, не так
что будет с 386, если на нем запустить дот нет?

← →
Правильный-Вася (2008-06-19 13:34) [6]

> для модогядерных процессоров

тока сейчас заметил
это процессоры с моддингом ядер? с пропилами и раскоряченными ножками?

← →
Fin (2008-06-19 13:44) [7]

> Правильный-Вася (19.06.08 13:34) [6]
> > для модогядерных процессоровтока сейчас заметилэто процессоры
> с моддингом ядер? с пропилами и раскоряченными ножками?

К сожалению должен вас разочеровать - очепятка.

P.S. Моддинговые процессоры - а это идея.... :)

← →
Dmitry S © (2008-06-19 14:08) [8]

> P.S. Моддинговые процессоры - а это идея.... :)

Я както давно мечтал, чтобы на видеопроцессоре в качестве верхней поверхности микросхемы был маленький экран, который показывает тоже самое, что на мониторе:)

← →
VirEx © (2008-06-19 14:10) [9]

> [8] Dmitry S © (19.06.08 14:08)
>
> > P.S. Моддинговые процессоры - а это идея.... :)
>
> Я както давно мечтал, чтобы на видеопроцессоре в качестве
> верхней поверхности микросхемы был маленький экран, который
> показывает тоже самое, что на мониторе:)

я тоже вглядывался в стеклышко проца zx spectrum, но не курил

← →
DVM © (2008-06-19 14:12) [10]

> я тоже вглядывался в стеклышко проца zx spectrum

какое там стеклышко? стеклышко на микросхеме памяти с УФ стиранием

← →
axis_of_evil © (2008-06-19 14:13) [11]

> Сергей_77 (19.06.08 13:03) [1]
> имхо стоит сделать количество потоков, равное количеству
> процессоров

и в мин. системных требованиях указывать число процессоров, после чег оввести максимальные системные требования - и вписать это число туда %>

← →
AndreyV © (2008-06-19 14:13) [12]

> [9] VirEx © (19.06.08 14:10)
> я тоже вглядывался в стеклышко проца zx spectrum, но не
> курил

Интересно как же ты тогда увидел на процессоре стёклышко.

← →
palva © (2008-06-19 14:23) [13]

> что будет с 386, если на нем запустить дот нет?

Неужели перегреется? К сожалению, у меня нет такого процессора - попробовать.

← →
DVM © (2008-06-19 14:26) [14]

> palva © (19.06.08 14:23) [13]

есть два кардинально различающихся 386: SX и DX. На DX теоретически можно даже XP запустить, но загружаться она будет сутки где то. SX - урезанный без сопроцессора.

← →
palva © (2008-06-19 14:35) [15]

> но загружаться она будет сутки где то

Ну тогда хорошо, что у меня его нет.

← →
DrPass © (2008-06-19 15:07) [16]

> Сергей_77 (19.06.08 13:03) [1]
> имхо стоит сделать количество потоков, равное количеству
> процессоров

А смысл? Нет никакой уверенности, что потоки будут выполняться на разных процессорах. Вполне вероятно, что по очереди и на одном - это как уж винда решит.

> есть два кардинально различающихся 386: SX и DX. На DX теоретически
> можно даже XP запустить, но загружаться она будет сутки
> где то. SX - урезанный без сопроцессора.

Они оба без сопроцессора. Только у 386SX шина данных 16 бит, а у DX - 32 бита

← →
KSergey © (2008-06-19 15:13) [17]

> DrPass © (19.06.08 15:07) [16]
> > имхо стоит сделать количество потоков, равное количеству процессоров
>
> А смысл? Нет никакой уверенности, что потоки будут выполняться
> на разных процессорах. Вполне вероятно, что по очереди и
> на одном - это как уж винда решит.

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

← →
DVM © (2008-06-19 15:14) [18]

> DrPass © (19.06.08 15:07) [16]

> Они оба без сопроцессора.

Да точно. Я с 486 спутал. Давно это было.

← →
KSergey © (2008-06-19 15:16) [19]

> Fin (19.06.08 13:01)

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

← →
DiamondShark © (2008-06-19 15:19) [20]

> По-моему, нужно делать ставку на современные идеологии разработки.
> Может быть, DOT NET ?

DOT NET тут не поможет. Встроенных средств распараллеливания у неё нет, а вручную -- что DOT NET, что не DOT NET -- всё равно. DOT NET даже тормознее.

Вообще, на винде имеет смысл распараллеливать только достаточно тяжёлые задачи из-за большой затратности виндовых средств параллелизма. Виндовый поток -- слишком тяжёлый объект.

ОС нужна новая, с поддержкой легковесной многозадачности, чтобы можно было в операторе a := B + C (где B и C -- некие подвыражения) распараллелить вычисление B и C и получить выгоду, которую не съёдят накладные расходы на порождение потоков.

← →
VirEx © (2008-06-19 15:19) [21]

> [10] DVM © (19.06.08 14:12)
>
> > я тоже вглядывался в стеклышко проца zx spectrum
>
> какое там стеклышко? стеклышко на микросхеме памяти с УФ
> стиранием

нет, там под стеклышком мелкий чип был и проводки от него шли, а весь остальной "корпус" был из пластмассы

← →
Правильный-Вася (2008-06-19 15:21) [22]

> я тоже вглядывался в стеклышко проца zx spectrum, но не курил

похоже, что наоборот - курил ;)
на Z80 нет никаких стеклышек, это на ПЗУ были

← →
DVM © (2008-06-19 15:24) [23]

> нет, там под стеклышком мелкий чип был и проводки от него
> шли

Вот разные, все без стелышек.

http://www.cpu-world.com/CPUs/Z80/MANUF-Zilog.html

Со стеклышком микросхема ПЗУ была, которую часто использовали в паре с этим процессором в ZX80

← →
Anatoly Podgoretsky © (2008-06-19 15:25) [24]

> DVM (19.06.2008 14:26:14) [14]

Что бы узнать разницу надо писать особые тестовые программы, ты можешь такую написать?

← →
Anatoly Podgoretsky © (2008-06-19 15:27) [25]

> KSergey (19.06.2008 15:13:17) [17]

Это обман зрения, слишком грубым инструментом наблюдаешь, да на разных ядрах, но в разное время.

← →
VirEx © (2008-06-19 15:28) [26]

> [23] DVM © (19.06.08 15:24)

ладно, уговорил)

← →
DVM © (2008-06-19 15:34) [27]

> Anatoly Podgoretsky © (19.06.08 15:25) [24]

> Что бы узнать разницу надо писать особые тестовые программы,
> ты можешь такую написать?

Чтобы увидеть разницу между машиной с сопроцессором и без можно и ничего не писать. Это и так видно. Повторю, я перепутал с 486DX и SX.

← →
KSergey © (2008-06-19 15:38) [28]

> Anatoly Podgoretsky © (19.06.08 15:27) [25]
> > KSergey (19.06.2008 15:13:17) [17]
>
> Это обман зрения, слишком грубым инструментом наблюдаешь,
> да на разных ядрах, но в разное время.

Не, разумеется, что в разное время :) Не может же она самостоятельно решить как их буквально распараллелить.
Я это писал к тому, что фраза

> DrPass © (19.06.08 15:07) [16]
> Нет никакой уверенности, что потоки будут выполняться
> на разных процессорах.

не совсем полна. Т.е. да, не факт, что в конкретной ситуации при конкретных запущеных программах и нагрузке потоки будут в итоге выполняться на разных процессорах параллельно, однако видно, что по возможности винда все ж раскидает их на разные процессоры, раз даже один поток - и тот раскидывает, в чем уж точно нет никакой надобности.

> Anatoly Podgoretsky © (19.06.08 15:25) [24]
> Что бы узнать разницу надо писать особые тестовые программы,
> ты можешь такую написать?

ВОобще типа да, но если вы имели счастье сравнить выполнение Win3.11 на 386 с сопроцесором и без - то разница заметна даже без секундомера. Так что винда - как обычно самый лучший тест :)

> KSergey © (19.06.08 15:39) [29]

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

> KSergey © (19.06.08 15:40) [30]

у меня вот сейчас на столе лежит девайс с неким x86 совместимым процессором, но сопроцессора у него нет, хотя частот чипа аж 300 Мгц. Он еле ползает особенно с графическим интерфейсом если что на нем запустить.

> ВОобще типа да, но если вы имели счастье сравнить выполнение
> Win3.11 на 386 с сопроцесором и без - то разница заметна
> даже без секундомера. Так что винда - как обычно самый лучший
> тест :)

А нафига ей сопроцессор-то? Чтобы форточки по экрану таскать, FPU как-бы и не нужен...

> однако видно, что по возможности винда все ж раскидает их
> на разные процессоры, раз даже один поток - и тот раскидывает,
> в чем уж точно нет никакой надобности

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

← →
Fin (2008-06-19 15:53) [33]

> KSergey © (19.06.08 15:16) [19]
> > Fin (19.06.08 13:01) Вопрос встречный: а что делает
> программа? Вообще ее можно распараллелить?А так - думанье
> тут простое и известное: винда по процессорам раскидывает
> потоки. Сумеете конкретную программу разумно раскидать не
> насколько потоков - получите выигрыш на многопроцесорной
> системе, не сумеете - так и думать тут не о чем.

Ну собственно в том то и вопрос как загрузить многоядерные процессоры, собственно мои домыслы и оправдались - многопоточностью, а то что нужно саму задачу ещё распаралелить это тоже ясно , да я в первом посту собственно и пояснил

>Fin (19.06.08 13:01)
> Сам же вопрос распаралеливания программы оставляю за рамками
> рассуждения.

А так смею заверить ряд моих задач собственно очень хорошо распаралеливаються.

Смущает меня только один момент, что если ОС всё же вздумает эти эти потоки поставить на одно ядро, сотюда вопрос можно принудительно отправит поток на конкретное ядро?

> А нафига ей сопроцессор-то? Чтобы форточки по экрану таскать,
> FPU как-бы и не нужен...

Win95/98 без сопроцессора вообще не ставится даже вроде.

> можно принудительно отправит поток на конкретное ядро?

SetThreadAffinityMask

> Fin (19.06.08 15:53) [33]
> сотюда вопрос можно принудительно отправит поток на конкретное ядро?

Да.
Thread Affinity Mask + google

> DrPass © (19.06.08 15:51) [32]
> А нафига ей сопроцессор-то? Чтобы форточки по экрану таскать,
> FPU как-бы и не нужен...

Я говорю о практических наблюдениях. Теория меня не интересует.

> DiamondShark © (19.06.08 15:19) [20]
> ОС нужна новая, с поддержкой легковесной
> многозадачности, чтобы можно было в операторе a := B + C
> (где B и C -- некие подвыражения) распараллелить вычисление
> B и C и получить выгоду, которую не съёдят накладные расходы
> на порождение потоков.

Bluebottle OS (она же Active Object System (Aos)) :>

> KSergey © (19.06.08 16:05) [38]

> Я говорю о практических наблюдениях. Теория меня не интересует

Ну так и я в общем-то работал в свое время на 386 без сопра. Ничего, винда 3.1 вполне шустренько жужжала (на 8 мб ОЗУ). Это относительно современный софт сопр пользует по-полной где надо и не надо. А в начале 90-х без него вполне успешно обходились в большинстве случаев.

Программы для модогядерных процессоров Найти похожие ветки