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

← →
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]
> Нет никакой уверенности, что потоки будут выполняться
> на разных процессорах.

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

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

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

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

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

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

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

← →
DVM © (2008-06-19 15:45) [31]

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

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

← →
DrPass © (2008-06-19 15:51) [32]

> ВОобще типа да, но если вы имели счастье сравнить выполнение
> 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)
> Сам же вопрос распаралеливания программы оставляю за рамками
> рассуждения.

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

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

← →
DVM © (2008-06-19 16:00) [34]

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

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

← →
DVM © (2008-06-19 16:01) [35]

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

SetThreadAffinityMask

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

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

Да.
Thread Affinity Mask + google

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

> DVM © (19.06.08 16:01) [35]

Таки опередил :)

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

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

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

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

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

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

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

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

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

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

← →
stas © (2008-06-19 16:25) [41]

Fin (19.06.08 13:01)
Смотря какое приложение, если сложных расчетов не делает не стоит заморачиваться, винда отдаст остальные ядра другим приложениям либо распределит между вашим и остальными приложениями.
А если ведутся какие-то расчеты типа перебор паролей в цикле, сжатие архива, обработка видео, тогда нужно определить сколько ядер в системе, и запустить столько циклов расчета (каждый со своими параметрами) в разных потоках.

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

> DrPass © (19.06.08 16:15) [40]
> Ну так и я в общем-то работал в свое время на 386 без сопра.
> Ничего, винда 3.1 вполне шустренько жужжала (на 8 мб ОЗУ).

Я не говорю о том шустро или нет.
Я говорю о том, что без сопра одна и та же машина винду гоняла заметно медленнее. Вот и все.
А уж нафик ей FPU - я не знаю. Видимо координаты окон даблами описаны унутрях, либо синусы активно юзаются при перемещении окон :)

← →
Anatoly Podgoretsky © (2008-06-19 17:04) [43]

> KSergey (19.06.2008 15:38:28) [28]

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

← →
Anatoly Podgoretsky © (2008-06-19 17:06) [44]

> KSergey (19.06.2008 15:39:29) [29]

Я имел удовольствие работать и с SX и DX разница небольшая есть, но далеко не в пользу SX или DX, а в пользу той платы где был установлен соопроцессор.

← →
stas © (2008-06-19 21:08) [45]

Fin (19.06.08 15:53) [33]
Можно принудительно отправить поток на одно ядро, но єто может замедлить работу.
Делал такой опыт: Запускал программу кодирования видео (однопоточную), при этом нагрузка была на 2 ядра по 50% +1-5% других приложений, система работала без тормозов
стоило перекинуть процесс пережатия на одно ядро,
как все жутко начало тормозить, при этом 1 ядро загружено на 100%, 2-е 1-5%

← →
VirEx © (2008-06-20 07:54) [46]

> [45] stas © (19.06.08 21:08)

это да, к томуже читал статью о том как правильно настроить windows для работы на двуядернике: если в таск манагере графиг (кривые) загрузки первого и второго ядра разный, то это не есть гуд

← →
Anatoly Podgoretsky © (2008-06-20 09:00) [47]

> VirEx (20.06.2008 7:54:46) [46]

Какая разница, если это не 100% то процессор простаивает, и без разницы простаивает одинаково или по разному.
Неправильно когда один нагружен на 100% а второй еле еле.

← →
VirEx © (2008-06-20 09:19) [48]

> Неправильно когда один нагружен на 100% а второй еле еле.

вот про это и говорю

← →
Anatoly Podgoretsky © (2008-06-20 10:22) [49]

> VirEx (20.06.2008 9:19:48) [48]

Надо, что бы оба на 100%

← →
Fin (2008-06-20 11:07) [50]

> Anatoly Podgoretsky © (20.06.08 10:22) [49]
> > VirEx (20.06.2008 9:19:48) [48]Надо, что бы оба на 100%

как этого добиться или хотя бы приблизиться к таким показателям?

← →
DVM © (2008-06-20 11:09) [51]

> как этого добиться или хотя бы приблизиться к таким показателям?

много потоков создавай в каждом интенсивная работа - будет тебе 2 по 100

← →
KSergey © (2008-06-20 11:36) [52]

> DVM © (20.06.08 11:09) [51]
> много потоков создавай в каждом интенсивная работа

while true do begin i := i + 1; end;

← →
Skyle © (2008-06-20 11:44) [53]

> KSergey © (20.06.08 11:36) [52]

while true do ;

← →
Anatoly Podgoretsky © (2008-06-20 11:56) [54]

> Fin (20.06.2008 11:07:50) [50]

Заменить программу.

← →
Fin (2008-06-20 12:16) [55]

> Anatoly Podgoretsky © (20.06.08 11:56) [54]
> > Fin (20.06.2008 11:07:50) [50]Заменить программу.

Ну это то конечно понятно.

Перефразирую вопрос. Собственно я уже упоминал, что сам процесс распоралеливания алгоритма выполняющего основную задачу оставляю за рамками обсуждения, добавлю только то, что исхожу из того, что он более или менее сбалансирован.
И вот тут интересно, то как (не именно код, а стратегия) управлять или распределять нагрузку по ядрам.
Как вариант вообще об этом не думать и то как поступит ОС так пусть и будет или имеет смысл вмешиваться.

← →
DVM © (2008-06-20 12:17) [56]

> или имеет смысл вмешиваться.

Лучше не вмешиваться.

← →
Котик Б (2008-06-20 12:27) [57]

Уважаемый автор вопроса. Моё мнение таково:
- если вы не знаете зачем вам нужно распаралелить работу программы, то лучше пока этого не делать :)
- если ваша программа работает стабильно в один поток на 2х (3х-4х) процессоре - радуйтесь - она не мешает работать другим программам !

← →
KSergey © (2008-06-20 12:32) [58]

> Skyle © (20.06.08 11:44) [53]
> while true do ;

Хотелось сделать работу поинтенсивнее :)

← →
Fin (2008-06-20 12:39) [59]

> Котик Б (20.06.08 12:27) [57]

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

← →
Котик Б (2008-06-20 12:52) [60]

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

Дабы не быть голословным - вот вам для затравки :)
http://www.dtf.ru/articles/read.php?id=39888

> [49] Anatoly Podgoretsky © (20.06.08 10:22)
> > VirEx (20.06.2008 9:19:48) [48]
>
> Надо, что бы оба на 100%

вот именно про это и говорю :)

Наткнулся сегодня.
По-моему - очень интересная статья на заданную тему.

http://www.dtf.ru/articles/read.php?id=39888

← →
полуиспользователь (2008-06-20 22:48) [64]

Кстати, коль уж идёт речь о более одного процессорных системах, объясните пож., как это работает и чем управляется. Нагрузку на процессоры распределяет сама ОС, независимо от многопоточности приложения или оно должно быть многопоточным?

Я заметил при видеообработке на системе AMD Athlon 64 x2 XP5000+:
с Ulead VideoStudio 9, при кодировании уже непосредственно в DVD формат,
загружен только один процессор на все сто, другой же абсолютно бездействует. А вот при использовании Pinnacle Video Studio 10+, работают оба процессора на все сто. И интересно, что результат по скорости не в два раза а где-то в три, а то и поболее (субъективное измерение :-)) в пользу Pinnacle. Вот только Ulead Studio работает намного надёжнее: Pinnacle частенько виснет :-(

> очень интересная статья на заданную тему.

интересная, хоть я к игрушкам никоим боком.

> Нагрузку на процессоры распределяет сама ОС, независимо
> от многопоточности приложения или оно должно быть многопоточным?
>

Нагрузку распределяет сама ОС. Приложение должно быть многопоточным, чтобы выполняться одновременно на двух процессорах.

← →
полуиспользователь (2008-06-20 23:12) [67]

> Игорь Шевченко © (20.06.08 22:59) [66]
>
> Нагрузку распределяет сама ОС. Приложение должно быть многопоточным,
> чтобы выполняться одновременно на двух процессорах.

Спасибо. Я так и думал. Жаль, что Ulead Studio 9 кодирует в одном потоке. Есть конечно новые версии, но при каждом обновлении за всё нужно платить.
Вывод: если приложение, работающее в одном потоке и соответственно, неспособное распределиться по процессорам, переделать на многопоточность - можно сорвать дополнительные "бабки", разумеется, если оно интенсивно пожирает процессорное время.

> Вывод: если приложение, работающее в одном потоке и соответственно,
> неспособное распределиться по процессорам, переделать на
> многопоточность - можно сорвать дополнительные "бабки",
> разумеется, если оно интенсивно пожирает процессорное время.
>

В случае, если его возможно распараллелить - безусловно.

> http://www.dtf.ru/articles/read.php?id=39888&page=5

Немного поэкспериментировав, я наконец выяснил, что наткнулся на распространенную проблему архитектур с распределенной памятью (shared memory architectures): одновременный доступ двух процессоров к близким участкам памяти заставляет внутренний контроллер сбрасывать кэш памяти.

После того, как я разнес структуры данных потоков на 256 байт путем добавления небольшого массива:

TMyThreadData data;
BYTE guard[256];
TMyThreadData data2;
Все стало на свои места:

...

Странно, но эта проблема не проявилась на HT-процессоре.

кто-нибудь может прокомментировать последнее?
// тесты автора, честно говоря, не разбирал - поверил на слово

> Странно, но эта проблема не проявилась на HT-процессоре.
>
>
> кто-нибудь может прокомментировать последнее?

Могу только сказать, что HT - это не совсем полноценная многоядерность. В частности, кэш, насколько мне известно у них общий.

> axis_of_evil © (20.06.08 23:27) [69]

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

http://rsdn.ru/?article/baseserv/RUThreadingMethodology.xml

--
Regards, LVT.

Игорь Шевченко © (20.06.08 23:36) [70]
> В частности, кэш, насколько мне известно у них общий.

это объясняет :>
спасибо - мне как раз было интересно, чем реализация НТ отличается от реализации двух процессоров

> Fin © (20.06.08 22:16) [63]
> > KSergey © (20.06.08 17:32) [62]
> уже было [60]

И правда, извиняюсь за невнимательность. Хотя по тому посту у меня не хватило соображения ее почитать, наткнулся потом случайно :)

> Игорь Шевченко © (20.06.08 22:58) [65]
> интересная
http://www.dtf.ru/articles/read.php?id=39888

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

← →
ol'ka (2008-06-22 21:49) [76]

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

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

полуиспользователь (20.06.08 22:48) [64]
Ulead кодирует медленно и неочень качественно, лучше maincondept, проблем никогда небыло использует многопоточность а также SSE и т.д.

А какже конвееры? они и на одном ядре "паралелят"

← →
Fin (2008-06-23 14:39) [80]

> Slym © (23.06.08 10:43) [79]
> А какже конвееры? они и на одном ядре "паралелят"

ну этот вопрос имхо вообще не из той оперы и что бы каким то образом ещё пытаться оптимальнее подстроиться под конвер, то скоре и писать программу надо как минимум на асемблере.

← →
ol'ka (2008-06-23 22:54) [81]

мне кажется от проца зависит эффективность распераллеливания однопоточной задачи. Есть ведь у конвеера прогнозирование ветвлений, развертка циклов, так чтобы проц команду типа jmp никогда и не видел у себя в кэше, наверное и независимые вычисления могут на разные ядра направляться.

>ol"ka (23.06.08 22:54) [81]
Я и не думал что девушки такими умными бывают... )))

← →
ol'ka (2008-06-25 02:39) [83]

> stas © (24.06.08 16:24) [82]
> >ol"ka (23.06.08 22:54) [81]
> Я и не думал что девушки такими умными бывают... )))

здесь кто-нибудь разве писал что я девушка?

> ol"ka (25.06.2008 2:39:23) [83]

Стесняюсь спросить, а имя какое? И отчество тоже.

>ol"ka
ну, я по нику сделал вывод.

> Anatoly Podgoretsky © (25.06.08 08:45) [84]
> > ol"ka (25.06.2008 2:39:23) [83]Стесняюсь спросить, а
> имя какое? И отчество тоже.

Кирбальмандын Турбинкасыбаршидович?

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