Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные. Что мы обычно имеем при таком "улучшении"? Один и тот же тест показывает большое увеличение производительности при переходе со 128 мб на 256, чуть меньшее с 256 на 512, и так далее, и так далее, Пока прирост цены не перестанет оправдывать прирост производительности. Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

Здравствуйте, Guard, Вы писали:

G>Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

через -6 лет.

Здравствуйте, NikeByNike, Вы писали:

NBN>через -6 лет.
Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..

Здравствуйте, Guard, Вы писали:

G>Здравствуйте, NikeByNike, Вы писали:

NBN>>через -6 лет.
G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..

Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор.

ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

Здравствуйте, Guard, Вы писали:

G>Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

Ха, я думаю никогда — мы постараемся что бы программы отъедали максимум доступных ресурсов

Здравствуйте, dr.Chaos, Вы писали:

DC>ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

Вообще-то, речь шла о том, что через -6 лет (то есть, 6 лет назад ) произойдет "насыщение" . А тогда о параллелизме многие даже не думали.

Здравствуйте, Guard, Вы писали:

G>Здравствуйте, dr.Chaos, Вы писали:

DC>>ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

G>Вообще-то, речь шла о том, что через -6 лет (то есть, 6 лет назад ) произойдет "насыщение" . А тогда о параллелизме многие даже не думали.

Вообще, теории уже довольно много лет. Просто она не применялась на ПК поскольку реального параллелизма не было, только эмуляция.

Здравствуйте, dr.Chaos, Вы писали:

DC>Вообще, теории уже довольно много лет. Просто она не применялась на ПК поскольку реального параллелизма не было, только эмуляция.

Одно дело теория, другое — имплементация.

Здравствуйте, Guard, Вы писали:

G>Здравствуйте, dr.Chaos, Вы писали:

DC>>Вообще, теории уже довольно много лет. Просто она не применялась на ПК поскольку реального параллелизма не было, только эмуляция.

G>Одно дело теория, другое — имплементация.

Мне в институте на 4м курсе читали сети Петри и т.п. формальные методы распараллеливания. Имплементации наверняка есть надо только поискать, но не под PC, а под более серьезные машины. Мы по ходу курса изучали общую схему какой-то военной системы слежения(года эдак 70-80). Она позволяла вести до 170 целей одновременно. Так вот там эти методы и применялись.

ЗЫ Название не помню давно это было, если дома найду конспект приведу название.

Здравствуйте, jhfrek, Вы писали:

G>>Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

J>Ха, я думаю никогда — мы постараемся что бы программы отъедали максимум доступных ресурсов

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.
А Ворд он ещё под ДОС был, и ведь самое "удивительное", тексты в нём также набивали, хоть и в процах счёт мегагерц на единицы шёл.
Развитие это когда-нибудь да перейдёт в плоскость эволюции, как в автомобилестроении, например. Ну как можно рекламировать Core2Duo, если ещё четвёртый пент с гипертридингом подавался как лучшее решение для одновременного просмотра видео, прослушивания музыки, лазанья по интернету и играния в игры.

Здравствуйте, Xander Zerge, Вы писали:

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

Кстати, я свой Пентиум-I 100Мгц заменил сколько-то лет назад именно из-за интернета — сайты стали тормозить при отрисовке

Здравствуйте, Guard, Вы писали:

G>Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные. Что мы обычно имеем при таком "улучшении"? Кто что думает?

Я думаю, что со временем всё сведётся к паралелизму. Потому что строить очередной завод для создания процессора нового поколения окажется дороже, чем пихнуть два таких процессора на 1 motherboard. Кроме того, имеющиеся сейчас мощности компьютеров сами по себе огромны. Уже давно можно смотреть ip телеканалы. Потребности рынка будут, вероятно, уходить в сторону отказоустойчивого софта. Сумасшедший рост производительности процессоров (и связанный с ней бесконечный upgrade) замедлится по той простой причине, что эта производительность уже не требуется. Возрастать будут скорость интернета и объёмы накопителей.

Здравствуйте, strcpy, Вы писали:

S>Я думаю, что со временем всё сведётся к паралелизму. Потому что строить очередной завод для создания процессора нового поколения окажется дороже, чем пихнуть два таких процессора на 1 motherboard.

С другой стороны, сейчас имеются "4-ядерные" системы, где фактически два 2-ядерных процессора на одной плате. Такая система проигрывает по производительности прототипам quad core примерно на 20-30% за счет дополнительной задержки при передаче данных между процессорами. Настоящие же quad core реализованы по схемам с общим кэшем => выше скорость. Таким образом, технологически это тоже невыгодно.. Разрыв между качеством и ценой будет расти еще сильнее.

Здравствуйте, Xander Zerge, Вы писали:

XZ>А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

Да хоть семь тысяч. Если у тебя System Idle показывает 99%, то вся эта куча потоков попросту спит.

Здравствуйте, AndrewVK, Вы писали:

XZ>>А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.
AVK>Да хоть семь тысяч. Если у тебя System Idle показывает 99%, то вся эта куча потоков попросту спит.
Это я прекрасно знаю. Также как и то, что реально параллельных потоков слишком много ещё не скоро станет. Предположу, что на первый план выйдет, хм-м, приёмистость интерфейса, что-ли, характеризуемая производительностью на пиковых нагрузках. Пробовал Core 2 Duo, вроде мелочь, десятки миллисекунд, а всё же заметно приятнее, когда куда тыкаешь, а оно тут же и открывается.
Но, учитывая тенденции развития интерфейса ОС, на примере той же висты, тут ресурс жрать будет кому ещё долго.

S> Кроме того, имеющиеся сейчас мощности компьютеров сами по себе огромны. Уже давно можно смотреть ip телеканалы. Потребности рынка будут, вероятно, уходить в сторону отказоустойчивого софта. Сумасшедший рост производительности процессоров (и связанный с ней бесконечный upgrade) замедлится по той простой причине, что эта производительность уже не требуется. Возрастать будут скорость интернета и объёмы накопителей.
Вы забыли про существование некой фирмы под названием Microsoft, которая выдаст очередную гиперсупермегарулезно-потрясную технологию, для которой и терагерцевого проца будет мало.

Здравствуйте, Xander Zerge, Вы писали:

XZ>Пробовал Core 2 Duo, вроде мелочь, десятки миллисекунд, а всё же заметно приятнее, когда куда тыкаешь, а оно тут же и открывается.

Не знаю что ты там заметил. Современный GUI на 99% однопоточный принципиально, так что все работает на одном ядре. В новом сервере rsdn 4 ядра, но никакой разницы для пользователя в скорости реакции интерфейса по сравнению с равночастотным одноядерником не наблюдается.

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

А в висте, гы-гы, интерфейс тоже однопоточный. Даже WPF.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Xander Zerge, Вы писали:

XZ>>Пробовал Core 2 Duo, вроде мелочь, десятки миллисекунд, а всё же заметно приятнее, когда куда тыкаешь, а оно тут же и открывается.

AVK>Не знаю что ты там заметил.

Эффект плацебо

Здравствуйте, AndrewVK, Вы писали:

AVK>Не знаю что ты там заметил. Современный GUI на 99% однопоточный принципиально, так что все работает на одном ядре. В новом сервере rsdn 4 ядра, но никакой разницы для пользователя в скорости реакции интерфейса по сравнению с равночастотным одноядерником не наблюдается.
Врать не буду — что видел, сказал. Буду покупать себе новый комп — куплю именно такой. Подчеркну только, если было непонятно, что я не на скорость отрисовки нажатия кнопочки смотрел. И принципиальность тут не причём. Сам процесс организации и управления виртуальной многопоточностью откусывает ресурс у процессора, увеличение же количества реальных потоков позволит, например, избавиться от всего хлама в сотнях потоков ОС, повесив их на одно ядро, отдав второе на откуп тому боевому потоку, которому чем быстрее, тем лучше, и выкушает вычислительный ресурс ядра на 100%. Другой вопрос, что над этим ещё с софтом работать надо.

XZ>>Но, учитывая тенденции развития интерфейса ОС, на примере той же висты, тут ресурс жрать будет кому ещё долго.
AVK>А в висте, гы-гы, интерфейс тоже однопоточный. Даже WPF.
Вот хватит уже совсем из меня дурака делать, ладно? Графические драйвера под многопоточность оптимизируют, это даст выигрыш в отрисовке сложных графических интерфейсов, коими обещает накормить нас МС, в сравнении с одноядерниками.

Я уж не говорю о том, что распараллеливание началось ещё с появлений мат.сопроцесорров, музыкальных сопроцессоров, графических процессоров — никто же не отрицает то, что их использование позволяет достичь заметного прироста производительности системы?
Так и сейчас происходит, единственное отличие — распараллеливание теперь дошло и до универсальных микропроцессоров.

Здравствуйте, neiroman, Вы писали:

S>> Кроме того, имеющиеся сейчас мощности компьютеров сами по себе огромны. Уже давно можно смотреть ip телеканалы. Потребности рынка будут, вероятно, уходить в сторону отказоустойчивого софта. Сумасшедший рост производительности процессоров (и связанный с ней бесконечный upgrade) замедлится по той простой причине, что эта производительность уже не требуется. Возрастать будут скорость интернета и объёмы накопителей.
N> Вы забыли про существование некой фирмы под названием Microsoft, которая выдаст очередную гиперсупермегарулезно-потрясную технологию, для которой и терагерцевого проца будет мало.

какая феерическая чушь

N> Вы забыли про существование некой фирмы под названием Microsoft, которая выдаст очередную гиперсупермегарулезно-потрясную технологию, для которой и терагерцевого проца будет мало.

Я думал про это, но писать не стал.
Очевидно, что и Microsoft испытывает проблемы сбыта, связанные с тем, что с некоторого момента секретаршам уже "нечего больше хотеть".

G>С другой стороны, сейчас имеются "4-ядерные" системы, где фактически два 2-ядерных процессора на одной плате. Такая система проигрывает по производительности прототипам quad core примерно на 20-30% за счет дополнительной задержки при передаче данных между процессорами. Настоящие же quad core реализованы по схемам с общим кэшем => выше скорость. Таким образом, технологически это тоже невыгодно.. Разрыв между качеством и ценой будет расти еще сильнее.

К сожалению, я не понял вашего последнего предложения.

Когда говорят о каких-то процентах, возникает законный вопрос о том, на каких задачах проводилось тестирование. Одни задачи не паралелятся принципиально (решение некоторых диффуров). Другие же (например, раскодирование и сжатие информации, в частности быстрое преобразование Фурье; работа экземпляров IP сервисов) отлично паралелятся. Если при разработке ПО ориентироваться на то, что среда будет многоядерной, можно добиться существенных результатов.

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

Здравствуйте, Xander Zerge, Вы писали:

XZ>Врать не буду — что видел, сказал.

А что ты видел? С чем сравнивал? Насколько я знаю, одноядерных вариантов Core 2 пока нет.

XZ>Сам процесс организации и управления виртуальной многопоточностью откусывает ресурс у процессора,

Наличие нескольких ядер необходимость смены контекста никоим случаем не исключает.

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

Спящие потоки ни на каком ядре не выполняются, они спят.

XZ> отдав второе на откуп тому боевому потоку, которому чем быстрее, тем лучше, и выкушает вычислительный ресурс ядра на 100%.

Вобщем нет такого. А даже если бы и было, все это легко компенсируется лишними 100МГц частоты.
Я знаю, откуда ты взял про скорость реакции. Она увеличится, если есть постоянный поток, пожирающий только процессор. Например, если у тебя на компе один поток постоянно жмет видео, то поток GUI будет несколько ленивее работать. Вот в этом случае второе ядро спасет. В остальных же ситуациях разницу между одним ядром и двумя ты не увидишь и в микроскоп.

AVK>>А в висте, гы-гы, интерфейс тоже однопоточный. Даже WPF.
XZ>Вот хватит уже совсем из меня дурака делать, ладно?

Я дурака не делаю, я тебе излагаю факты. WPF однопоточен. Единственное, что там может быть асинхронно, это рендеринг графики, потому что иначе толку от аппаратного акселератора не будет.

XZ> Графические драйвера под многопоточность оптимизируют, это даст выигрыш в отрисовке сложных графических интерфейсов, коими обещает накормить нас МС, в сравнении с одноядерниками.

Ты менбше слухи слушай, а лучше сам почитай как composition engine устроен.

Здравствуйте, strcpy, Вы писали:

S>...Потребности рынка будут, вероятно, уходить в сторону отказоустойчивого софта. Сумасшедший рост производительности процессоров (и связанный с ней бесконечный upgrade) замедлится по той простой причине, что эта производительность уже не требуется. Возрастать будут скорость интернета и объёмы накопителей.


ИМХО, и сейчас софт довольно таки отказоустойчивый

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

1) Редактирование домашнего видео (со всё возрастающим качеством)
2) Игрушки
3) Мега-мупер-пупер навороченные GUI с элементами AI

Здравствуйте, strcpy, Вы писали:

S>Когда говорят о каких-то процентах, возникает законный вопрос о том, на каких задачах проводилось тестирование. Одни задачи не паралелятся принципиально (решение некоторых диффуров).

Дифуры часто сводятся в матричной алгебре, где всё ОТЛИЧНО параллелится.

Здравствуйте, Erop, Вы писали:

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

E>1) Редактирование домашнего видео (со всё возрастающим качеством)
E>2) Игрушки
E>3) Мега-мупер-пупер навороченные GUI с элементами AI

4) Постепенный переход к БД на десктопе заместо файлов (ака полуубитый winfs).

Здравствуйте, RandomGuid, Вы писали:

RG>4) Постепенный переход к БД на десктопе заместо файлов (ака полуубитый winfs).

Ну если вообще перепроэктировать OS в направлении очень многопроцессорности, то там много чего навертеть можно.
И в области файловой системы и в области гуёв и много чего ещё

Здравствуйте, AndrewVK, Вы писали:

AVK>А что ты видел? С чем сравнивал? Насколько я знаю, одноядерных вариантов Core 2 пока нет.
Я не тестировщик, но заметил. Доказывать ещё и свои наблюдения не собираюсь совершенно. Второе ядро, кстати, через BIOS можно отрубить.

XZ>>Сам процесс организации и управления виртуальной многопоточностью откусывает ресурс у процессора,
AVK>Наличие нескольких ядер необходимость смены контекста никоим случаем не исключает.
Контекст в рамках одного ядра — да. Между двумя ядрами потоки скакать не будут.

XZ>> увеличение же количества реальных потоков позволит, например, избавиться от всего хлама в сотнях потоков ОС, повесив их на одно ядро,
AVK>Спящие потоки ни на каком ядре не выполняются, они спят.
Даже если они не выполняются, контексты их висят.

XZ>> отдав второе на откуп тому боевому потоку, которому чем быстрее, тем лучше, и выкушает вычислительный ресурс ядра на 100%.
AVK>Вобщем нет такого. А даже если бы и было, все это легко компенсируется лишними 100МГц частоты.
Вот в том и дело, что они лишние — больше наращивать проблематично, придётся возвращаться к водяному охлаждению и прочим изыскам по отводу тепла, не говоря о других проблемах таких высоких частот. И сейчас рост производительности становится выгоднее обеспечивать за счёт многоядерности.

AVK>Я знаю, откуда ты взял про скорость реакции. Она увеличится, если есть постоянный поток, пожирающий только процессор. Например, если у тебя на компе один поток постоянно жмет видео, то поток GUI будет несколько ленивее работать. Вот в этом случае второе ядро спасет. В остальных же ситуациях разницу между одним ядром и двумя ты не увидишь и в микроскоп.
Я говорю именно о пиковых нагрузках, когда на один клик мышки поднимается и перепахивается тонна информации. В этот короткий момент нагрузка достигает 100%, и по ощущениям реакция 100мс против 200мс всё равно заметна, как существенное ускорение.

AVK>Я дурака не делаю, я тебе излагаю факты. WPF однопоточен. Единственное, что там может быть асинхронно, это рендеринг графики, потому что иначе толку от аппаратного акселератора не будет.
А уже это и замечательно, и даже достаточно — ведь Интел те же деньги просит за двухъядерник?
Да и если софт заточен под старые архитектуры, уж это-то железячников никогда не останавливало.

AVK>Ты менбше слухи слушай, а лучше сам почитай как composition engine устроен.
А причём тут слухи? Почитайте хоть те же тесты видеоадаптеров на игрушках, оптимизация кода игр и драйверов под многоядерники даёт заметное улучшение, даже большее, чем тот же SLI, именно потому, что рендеринг идет далеко не на 100% в видеопроцессоре.

Здравствуйте, dr.Chaos, Вы писали:

DC>Здравствуйте, Guard, Вы писали:

G>>Здравствуйте, dr.Chaos, Вы писали:

DC>>>Вообще, теории уже довольно много лет. Просто она не применялась на ПК поскольку реального параллелизма не было, только эмуляция.

G>>Одно дело теория, другое — имплементация.

DC>Мне в институте на 4м курсе читали сети Петри и т.п. формальные методы распараллеливания. Имплементации наверняка есть надо только поискать, но не под PC, а под более серьезные машины. Мы по ходу курса изучали общую схему какой-то военной системы слежения(года эдак 70-80). Она позволяла вести до 170 целей одновременно. Так вот там эти методы и применялись.

DC>ЗЫ Название не помню давно это было, если дома найду конспект приведу название.

Так тут задача, вроде, удачно ложится на распараллеливание — 170 независимых целей, на каждую назначена задача слежения на своем процессоре. Оч.хорошо. А как распараллелить алгоритм, который никаким боком не хочет распараллеливаться. Т.е. такой, например, где очередной результат зависит от предыдущих расчетов. Ему наличие кучи ядер никак не поможет.

Здравствуйте, AndrewVK, Вы писали:

XZ>>Врать не буду — что видел, сказал.

AVK>А что ты видел? С чем сравнивал? Насколько я знаю, одноядерных вариантов Core 2 пока нет.

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

Здравствуйте, Xander Zerge, Вы писали:

XZ>>>Сам процесс организации и управления виртуальной многопоточностью откусывает ресурс у процессора,
AVK>>Наличие нескольких ядер необходимость смены контекста никоим случаем не исключает.
XZ>Контекст в рамках одного ядра — да. Между двумя ядрами потоки скакать не будут.

Если активен только один поток, то никто никуда скакать не будет.

AVK>>Спящие потоки ни на каком ядре не выполняются, они спят.
XZ>Даже если они не выполняются, контексты их висят.

Что такое "висят контексты"?

XZ>Я говорю именно о пиковых нагрузках, когда на один клик мышки поднимается и перепахивается тонна информации.

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

XZ>А уже это и замечательно, и даже достаточно — ведь Интел те же деньги просит за двухъядерник?

Это может и замечательно, но на скорости реакции практически не сказывается.

AVK>>Ты менбше слухи слушай, а лучше сам почитай как composition engine устроен.
XZ>А причём тут слухи?

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

XZ> Почитайте хоть те же тесты видеоадаптеров на игрушках,

При чем тут игрушки?

Здравствуйте, IT, Вы писали:

IT>Отклик системы на двух ядрах значительно шустрее. Особенно это хорошо на янусе заметно, когда он начинает синхронизироваться

Янус как раз по честному многопоточен.

Здравствуйте, AndrewVK, Вы писали:

XZ>>Контекст в рамках одного ядра — да. Между двумя ядрами потоки скакать не будут.
AVK>Если активен только один поток, то никто никуда скакать не будет.
Так не бывает, чтобы был активен только один.

AVK>>>Спящие потоки ни на каком ядре не выполняются, они спят.
XZ>>Даже если они не выполняются, контексты их висят.
AVK>Что такое "висят контексты"?
А что такое контексты? Я имею в виду дескрипторы состояния задачи (TSS) процессора, которые должны быть, даже если поток спит. И даже если они создаются на лету — это ещё одно место, где тратится вычислительный ресурс.

XZ>>Я говорю именно о пиковых нагрузках, когда на один клик мышки поднимается и перепахивается тонна информации.
AVK>Если алгоритм однопоточный, то никакой разницы между одним и несколькими ядрами не будет.
А причём тут однопоточность алгоритма? Проблема "расшить"?

XZ>>А уже это и замечательно, и даже достаточно — ведь Интел те же деньги просит за двухъядерник?
AVK>Это может и замечательно, но на скорости реакции практически не сказывается.
Почему же не скажется-то, если картинка пользовательского интерфейса будет отрисовываться быстрее? Да и не только в картинке дело, а в обработке запросов — как только возникает тяжёлая задача, ей можно отдать ядро, а всеми остальными жизненными задачами операционке заниматься на другом, не отвлекая первое. Тяжёлая задача — это даже не какое-нибудь архивирование, сжатие и т.п., а элементарная подготовка выдачи данных на запрос пользователя, которая может гнаться одним потоком.

XZ>>А причём тут слухи?
AVK>При том, что ты явно демонстрируешь крайне слабое знание предмета.
Традиционный наезд при остутствии аргументации? Уж от вас не ожидал никак.

XZ>> Почитайте хоть те же тесты видеоадаптеров на игрушках,
AVK>При чем тут игрушки?
А мы вообще о чём разговариваем? О том, что даст наращивание многоядерности в повседневной работе, в частности, в отрисовке графического интерфейса.
Игрушки как раз при том, что на них и на тестах, на их базе построенных, тестятся графические возможности железа и софта. Раз речь зашла о графическом движке нового микрософтовского гуя, я и привёл аргументы в пользу того, что многопроцессорная система будет рисовать его быстрее, при соответствующей подготовке, конечно.

Здравствуйте, trophim, Вы писали:

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

Есть такая наука -- вычматы. Там учёные всю голову сломали как так сделать
Так что берём, курим, делаем...

Здравствуйте, AndrewVK, Вы писали:

AVK>Янус как раз по честному многопоточен.
Ну в Винде сейчас много кто многопоточен. И IE, и офис, и всё, что через RPC (в том числе и OLE) работает...

Здравствуйте, Xander Zerge, Вы писали:

XZ>>>Контекст в рамках одного ядра — да. Между двумя ядрами потоки скакать не будут.
AVK>>Если активен только один поток, то никто никуда скакать не будет.
XZ>Так не бывает, чтобы был активен только один.

Бывает 99% времени на типовом десктопе.

AVK>>Что такое "висят контексты"?
XZ>А что такое контексты?

Что такое "висят контексты"?

XZ> Я имею в виду дескрипторы состояния задачи (TSS) процессора, которые должны быть, даже если поток спит. И даже если они создаются на лету — это ещё одно место, где тратится вычислительный ресурс.

При чем тут многоядерность? Что, несколько ядер уменьшат размер таблицы хендлов?

AVK>>Если алгоритм однопоточный, то никакой разницы между одним и несколькими ядрами не будет.
XZ>А причём тут однопоточность алгоритма? Проблема "расшить"?

При том, что при однопоточном алгоритме и одном активном приложенее в один момент времени будет рабюотать один поток, а остальные будут проставивать. Даже на rsdn, при не очень большой нагрузке далеко не всегда оба ядра загружены на 100%. А на десктопе ситуация, когда на втором ядре что то выполняется, крайне редка.

AVK>>Это может и замечательно, но на скорости реакции практически не сказывается.
XZ>Почему же не скажется-то, если картинка пользовательского интерфейса будет отрисовываться быстрее?

Она зачастую медленнее отрисовывается. Но асинхронно. Ускорение от многоядерности мы получим разве что при рендеринге шрифтов. Все остальные операции упрутся в видеокарту, а не в ядра процессора.

XZ> Да и не только в картинке дело, а в обработке запросов — как только возникает тяжёлая задача, ей можно отдать ядро,

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

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

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

AVK>>При том, что ты явно демонстрируешь крайне слабое знание предмета.
XZ>Традиционный наезд при остутствии аргументации? Уж от вас не ожидал никак.

Аргументация прежде всего должна быть у тебя.

XZ>>> Почитайте хоть те же тесты видеоадаптеров на игрушках,
AVK>>При чем тут игрушки?
XZ>А мы вообще о чём разговариваем?

Сильно.

Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc).

XZ>Раз речь зашла о графическом движке нового микрософтовского гуя,

А ты его видел? Архитектуру представляешь?

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

Не было аргументов. Ни одного.

Здравствуйте, Erop, Вы писали:

AVK>>Янус как раз по честному многопоточен.
E>Ну в Винде сейчас много кто многопоточен. И IE, и офис, и всё, что через RPC (в том числе и OLE) работает...

Дело не в нолминальной многопоточности, а в наличии потоков, выполняющих в параллель тяжелые вычисления. В янусе такой есть. В том же IE нет, поскольку в отдельных потоках выполняется только закачка, рендеринг происходит в основном потоке, это по тому же янусу хорошо заметно. В офисе на роль такого потока может подойти разве что проверка орфографии. "Все что через RPC" это слишком расплывчато.

Здравствуйте, AndrewVK, Вы писали:

AVK>

Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc).

Ну вот конкрентно MS Word всякие спеллеры/граммеры запускает на другой нити, чем редактор.
Да и всякие OLE-объекты вставленные в документ тоже в отдельной нити обычно живут (и даже в отдельном приложении)

опять же, АФАИК, в NT-based системах гуй и пользовательский код живут в разных потоках, хотя теперь это может и не совсем так, но при распространении многоядерности к тауой технологии MS наверняка вернётся ну и т. д.

Правда есть на этой розовой картине большая чёрная клякса. В винде долгое время была ошибка. Когда процессор был не нужен, он не останавливался, а просто крутил пустой цикл, ожидая чего бы повыполнять. Если вы запускаете HT-режим, то "второй" процессор начинал загружать всякую левую нагрузку давать наразделяемые устройства вычислительной системы. Так что почле включения HT всё могло заметно тормознуться. Но теперь это вроде поправили

Здравствуйте, AndrewVK, Вы писали:

AVK>Дело не в нолминальной многопоточности, а в наличии потоков, выполняющих в параллель тяжелые вычисления. В янусе такой есть. В том же IE нет, поскольку в отдельных потоках выполняется только закачка, рендеринг происходит в основном потоке, это по тому же янусу хорошо заметно. В офисе на роль такого потока может подойти разве что проверка орфографии. "Все что через RPC" это слишком расплывчато.

Например любой outprocess OLE-server. Скажем ёксельная таблица, вставленная в вордовый документ.

RG>Дифуры часто сводятся в матричной алгебре, где всё ОТЛИЧНО параллелится.
Я ж не сказал все!

Здравствуйте, AndrewVK, Вы писали:

XZ>>Так не бывает, чтобы был активен только один.
AVK>Бывает 99% времени на типовом десктопе.
Кто такой этот поток?

XZ>> Я имею в виду дескрипторы состояния задачи (TSS) процессора, которые должны быть, даже если поток спит. И даже если они создаются на лету — это ещё одно место, где тратится вычислительный ресурс.
AVK>При чем тут многоядерность? Что, несколько ядер уменьшат размер таблицы хендлов?
Хэндлы — это из Windows, дескрипторы задач — в процессорах/ядрах. Система распределяет эти задачи между ядрами.

XZ>>А причём тут однопоточность алгоритма? Проблема "расшить"?
AVK>При том, что при однопоточном алгоритме и одном активном приложенее в один момент времени будет рабюотать один поток, а остальные будут проставивать. Даже на rsdn, при не очень большой нагрузке далеко не всегда оба ядра загружены на 100%. А на десктопе ситуация, когда на втором ядре что то выполняется, крайне редка.
Неужели нечего делать в фоне?

AVK>>>Это может и замечательно, но на скорости реакции практически не сказывается.
XZ>>Почему же не скажется-то, если картинка пользовательского интерфейса будет отрисовываться быстрее?
AVK>Она зачастую медленнее отрисовывается. Но асинхронно. Ускорение от многоядерности мы получим разве что при рендеринге шрифтов. Все остальные операции упрутся в видеокарту, а не в ядра процессора.
В драйвер видеокарты, а не в графический процессор. Если драйвер переписан под многоядерность, то работу по подготовке данных в видеоадаптер можно осуществлять быстрее.

XZ>> Да и не только в картинке дело, а в обработке запросов — как только возникает тяжёлая задача, ей можно отдать ядро,
AVK>Не можно. Потому что вся обработка будет в том же потоке, что и отработка действий пользователя. Нужно специальным образом затачивать софт под несколько ядер, и не факт что весь бенефит утонет в накладных расходах на синхронизацию.
Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?
AVK>По факту же таких тяжелых обработок в современных приложениях крайне мало. В основном асинхронная обработка в современных приложениях связана с ожиданием отклика из сети или какого нибудь медленного внешнего устройства.
Откройте папочку windows\system32 в explorere — тот будет мучиться и пыжиться, перелистывая многочисленные экзешники и выдирая из них пиктограммы для отображения.

XZ>>Тяжёлая задача — это даже не какое-нибудь архивирование, сжатие и т.п., а элементарная подготовка выдачи данных на запрос пользователя, которая может гнаться одним потоком.
AVK>Нет таких задач для современного процессора. Поскольку это очень хитрая обработка, которая требует миллиарды команд процессора. И уж точно такая подготовка не элементарна.
Потому и нет, что современный процессор только появился. Задачи будут — было бы на чём считать.

AVK>Аргументация прежде всего должна быть у тебя.
Интересный подход.

XZ>>А мы вообще о чём разговариваем?
AVK>Сильно.
AVK>

Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc).

Речь зашла про гуй с наворотами на DirectX, потому игрушки из той же плоскости.
Компилятор — тут можно распараллелить, ах как замечательно.
Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
Internet — есть тут браузеры, отличающиеся выводом странички по ходу загрузки. А если на страничке сложности, типа большой таблицы, он её пересчитывает всю после каждой новой скачанной ячейки, что нагружает проц ох как хорошо.

XZ>>Раз речь зашла о графическом движке нового микрософтовского гуя,
AVK>А ты его видел? Архитектуру представляешь?
Зачем такие детали-то? Если гуй что-то рисует, мне, как пользователю важно, чтобы делал он это как можно быстрее.

XZ>> я и привёл аргументы в пользу того, что многопроцессорная система будет рисовать его быстрее, при соответствующей подготовке, конечно.
AVK>Не было аргументов. Ни одного.
С таким подходом и разговаривать не о чем. Подождём годик и "паглядим."

Здравствуйте, trophim, Вы писали:

G>>>Одно дело теория, другое — имплементация.

DC>>Мне в институте на 4м курсе читали сети Петри и т.п. формальные методы распараллеливания. Имплементации наверняка есть надо только поискать, но не под PC, а под более серьезные машины. Мы по ходу курса изучали общую схему какой-то военной системы слежения(года эдак 70-80). Она позволяла вести до 170 целей одновременно. Так вот там эти методы и применялись.

DC>>ЗЫ Название не помню давно это было, если дома найду конспект приведу название.

T>Так тут задача, вроде, удачно ложится на распараллеливание — 170 независимых целей, на каждую назначена задача слежения на своем процессоре.

Так и есть. Но это к имплементации методов, только имплементация зашита в железо, т.к. решается конкретная задача, универсальность тут не нужна.

T> Оч.хорошо. А как распараллелить алгоритм, который никаким боком не хочет распараллеливаться. Т.е. такой, например, где очередной результат зависит от предыдущих расчетов. Ему наличие кучи ядер никак не поможет.

Для распараллеливания алгоритмов существуют формальные методы, в частности Сети Петри. Некоторые из них по-моему даже автоматизированны были. Если он не расспараллеливается надо перестраивать алгоритм.

Вообще ИМХО когда ядер станет больше 10 вручную затачивать программы разделением на нити станет нереально. Там и должны появиться компиляторы которые по-меньшей часть работы, будут делать автоматически.

Здравствуйте, Erop, Вы писали:

E>Ну вот конкрентно MS Word всякие спеллеры/граммеры запускает на другой нити, чем редактор.

Но запускает он это в потоке с минимальным приоритетом. Поэтому на скорости отклика это практически не сказывается. Появление второго ядра лишь сделает проверку лишь слегка быстрее при активной работе пользователя.

E>Да и всякие OLE-объекты вставленные в документ тоже в отдельной нити обычно живут

Это вряд ли. Я сейчас не скажу про OLE-контейнеры, но, к примеру, ActiveX по стандарту работают только в STA.

E>опять же, АФАИК, в NT-based системах гуй и пользовательский код живут в разных потоках

Чего?

Здравствуйте, Xander Zerge, Вы писали:

XZ>>>Так не бывает, чтобы был активен только один.
AVK>>Бывает 99% времени на типовом десктопе.
XZ>Кто такой этот поток?

Обычно GUI-поток активного приложения в момент какого либо действия пользователя.

XZ>>> Я имею в виду дескрипторы состояния задачи (TSS) процессора, которые должны быть, даже если поток спит. И даже если они создаются на лету — это ещё одно место, где тратится вычислительный ресурс.
AVK>>При чем тут многоядерность? Что, несколько ядер уменьшат размер таблицы хендлов?
XZ>Хэндлы — это из Windows

А ты про что?

XZ>, дескрипторы задач — в процессорах/ядрах. Система распределяет эти задачи между ядрами.

Кхм. Ты точно уверен, что знаешь, о чем говоришь?

XZ>Неужели нечего делать в фоне?

Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.

AVK>>Она зачастую медленнее отрисовывается. Но асинхронно. Ускорение от многоядерности мы получим разве что при рендеринге шрифтов. Все остальные операции упрутся в видеокарту, а не в ядра процессора.
XZ>В драйвер видеокарты, а не в графический процессор.

В железо видеокарты.

XZ> Если драйвер переписан под многоядерность, то работу по подготовке данных в видеоадаптер можно осуществлять быстрее.

Не может. Потому что отрисовкой примитивов занимается GPU на карте, а не СPU.

AVK>>Не можно. Потому что вся обработка будет в том же потоке, что и отработка действий пользователя. Нужно специальным образом затачивать софт под несколько ядер, и не факт что весь бенефит утонет в накладных расходах на синхронизацию.
XZ>Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?

А софт написан с учетом этого?

AVK>>По факту же таких тяжелых обработок в современных приложениях крайне мало. В основном асинхронная обработка в современных приложениях связана с ожиданием отклика из сети или какого нибудь медленного внешнего устройства.
XZ>Откройте папочку windows\system32 в explorere — тот будет мучиться и пыжиться, перелистывая многочисленные экзешники и выдирая из них пиктограммы для отображения.

Ага. Тот самый случай, когда все упирается в медленный винчестер. Второе ядро тут ничем не поможет.

AVK>>Аргументация прежде всего должна быть у тебя.
XZ>Интересный подход.

Подход очень простой. Тот кто выдвигает предположения, тот и должен их аргументировать. У тебя подход другой?

AVK>>

Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc).

XZ>Речь зашла про гуй с наворотами на DirectX, потому игрушки из той же плоскости.

Нет, не из той же. Техника там совсем иная, сильно отличающаяся от использования видеоадаптера игрушками. DirectX там исключительно в качестве средства доступа к железу.

XZ>Компилятор — тут можно распараллелить, ах как замечательно.

Языком.

XZ>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.

У меня не тормозит совсем. Что я делаю не так?

XZ>Internet — есть тут браузеры, отличающиеся выводом странички по ходу загрузки.

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

AVK>>А ты его видел? Архитектуру представляешь?
XZ>Зачем такие детали-то?

Понятно. Архитектура и общие принципы построения у нас уже "какие то детали". Разговор дальше в том же духе лишен смысла.

XZ> Если гуй что-то рисует, мне, как пользователю важно, чтобы делал он это как можно быстрее.

Ты же рассуждаешь о том, как этот гуй ускорится от второго ядра. Так при чем тут пользователь?

AVK>>Не было аргументов. Ни одного.
XZ>С таким подходом и разговаривать не о чем. Подождём годик и "паглядим."

Слив засчитан.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Erop, Вы писали:

E>>Ну вот конкрентно MS Word всякие спеллеры/граммеры запускает на другой нити, чем редактор.

AVK>Но запускает он это в потоке с минимальным приоритетом. Поэтому на скорости отклика это практически не сказывается. Появление второго ядра лишь сделает проверку лишь слегка быстрее при активной работе пользователя.

E>>Да и всякие OLE-объекты вставленные в документ тоже в отдельной нити обычно живут

AVK>Это вряд ли. Я сейчас не скажу про OLE-контейнеры, но, к примеру, ActiveX по стандарту работают только в STA.

E>>опять же, АФАИК, в NT-based системах гуй и пользовательский код живут в разных потоках

AVK> Чего?

VC 2003 .Net + Framework 1.1 для Hello World с кнопкой OK создавал 5 потоков. Для чего я так и не понял. Возможно на DualCore рассчитывали .

> NBN>>через -6 лет.
> G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..
>
> Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор.
>
> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

Здравствуйте, dr.Chaos, Вы писали:

DC>VC 2003 .Net + Framework 1.1 для Hello World с кнопкой OK создавал 5 потоков. Для чего я так и не понял.

Ну раз не понял, то какой смысл это приводить в качестве аргумента? Тем более что все эти 5 потоков спят. Фреймворк еще иногда и UDP-порт зачем то слушает.

Здравствуйте, Sergey, Вы писали:

>> NBN>>через -6 лет.
>> G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..
>>
>> Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор.
>>
>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

S>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

Угу а весь до этого написанный код вручную распараллеливать?? Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции. Распараллеливать самомому задачу на 80 ядер, это сродни написания на асме современных приложений.

Здравствуйте, Guard, Вы писали:

G>Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные. Что мы обычно имеем при таком "улучшении"? ... Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

Глядя на то, как Visual Studio 2005 + Visual Assist умудряются забирать 98% ресурсов 1.7ГГц-процессора "просто так", в фоне, даже без компиляции, я думаю что современные разработчики успешно справятся с поставленной задачей и смогут забить ресурсы даже 80-ядерного процессора

Хотя на самом деле грустно это, не прогресс а сплошной маркетинг.

Здравствуйте, dr.Chaos, Вы писали:

DC>VC 2003 .Net + Framework 1.1 для Hello World с кнопкой OK создавал 5 потоков. Для чего я так и не понял. Возможно на DualCore рассчитывали .
Они знали о секретной разработке Intel(R) Penta Core

>>> NBN>>через -6 лет.
>>> G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..
>>>
>>> Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор.
>>>
>>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??
>
> S>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

> Угу а весь до этого написанный код вручную распараллеливать??

Весь код, сильно нуждающийся в распараллеливании, уже много лет пишут так, чтоб он работал на произвольном количестве процессоров. Ну а если не написали сразу многопоточно — да, придется либо ручками править, либо забить на возможный выигрыш от возросшего числа ядер. Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.

> Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции.

Ну инструмент такой не помешал бы конечно, но и без него жить можно, хотя и не просто. К сожалению, особого прогресса в этой области не заметно.

> Распараллеливать самомому задачу на 80 ядер,

Какая разница — на 2 процессора или на 80? Большинству числомолотилок пофиг, на сколько ядер их разнести (если, конечно, они вообще распараллеливаются). А не-числомолотилкам оно обычно не надо (у них в другом тормоза, как правило).

> это сродни написания на асме современных приложений.

Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер

Здравствуйте, Sergey, Вы писали:

>>>> NBN>>через -6 лет.
>>>> G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода..
>>>>
>>>> Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор.
>>>>
>>>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??
>>
>> S>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

>> Угу а весь до этого написанный код вручную распараллеливать??

S>Весь код, сильно нуждающийся в распараллеливании, уже много лет пишут так, чтоб он работал на произвольном количестве процессоров. Ну а если не написали сразу многопоточно — да, придется либо ручками править, либо забить на возможный выигрыш от возросшего числа ядер. Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.

>> Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции.

S>Ну инструмент такой не помешал бы конечно, но и без него жить можно, хотя и не просто. К сожалению, особого прогресса в этой области не заметно.

>> Распараллеливать самомому задачу на 80 ядер,

S>Какая разница — на 2 процессора или на 80? Большинству числомолотилок пофиг, на сколько ядер их разнести (если, конечно, они вообще распараллеливаются). А не-числомолотилкам оно обычно не надо (у них в другом тормоза, как правило).

Большая, потому как человек может держать держать в голове максимум 9 образов, а в среднем 5-7. И разнести задачу на 80 ядер самому архисложно учитывая при этом конкурентность, разделяемые ресурсы и т.п. Числомолотилки, довольно неплохо распараллеливаются вручную я не спорю. Но как поступать в общем случае? Получается что от большего кол-ва ядер выиграет только ограниченное число приложений, а остальные так и будут использовать 1 ядро? Очень сомневаюсь что параллельность останется на откуп разработчика.

>> это сродни написания на асме современных приложений.

S>Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер

Да ну, а я думал там тоже на дотНете пишут. Может я некорректно выразился, но GUI утилитку для работы с БД писать на асме просто глупо.

> S>Какая разница — на 2 процессора или на 80? Большинству числомолотилок пофиг, на сколько ядер их разнести (если, конечно, они вообще распараллеливаются). А не-числомолотилкам оно обычно не надо (у них в другом тормоза, как правило).
>
> Большая, потому как человек может держать держать в голове максимум 9 образов, а в среднем 5-7. И разнести задачу на 80 ядер самому архисложно учитывая при этом конкурентность, разделяемые ресурсы и т.п.

На 2 ядра — не менее сложно На самом деле, когда я создаю отдельную нить исполнения, мне все равно, сколько физических процессоров присутствует в системе — 2 или 80.

> Числомолотилки, довольно неплохо распараллеливаются вручную я не спорю. Но как поступать в общем случае?

А нет никакого общего случая — лично мне все время попадаются какие-то частные

> Получается что от большего кол-ва ядер выиграет только ограниченное число приложений, а остальные так и будут использовать 1 ядро?

Числомолотилки — не такое уж и ограниченное количество приложений Это, помимо всякого рокет сайнс, и архиваторы, и сжатие видео, и даже игрушки (да и не только игрушки — вообще, любое 3D). В архиваторах многопоточность приделывается на раз, было бы желание. Сжатие видео — тоже. В игрушках она вообще без проблем загоняется в драйвер и вообще прикладного разработчика не беспокоит. Кто не выиграет? Понятное дело, не выиграют те приложения, которым и одного процессора за глаза хватает.

> Очень сомневаюсь что параллельность останется на откуп разработчика.

Пока чего-нибудь радикального не придумают — ни куда не денешся, кроме как на откуп разработчика ее оставлять. Но радикальных придумок что-то не видать.

>>> это сродни написания на асме современных приложений.
>
> S>Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер
>
> Да ну, а я думал там тоже на дотНете пишут. Может я некорректно выразился, но GUI утилитку для работы с БД писать на асме просто глупо.

Гуевым утилкам для работы с БД и многоядерность нафиг не упала Зачем там, где хватает одного процессора, использовать еще 79?

Здравствуйте, Sergey, Вы писали:

S>Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.
7Zip умеет например

Здравствуйте, Sergey, Вы писали:

>> S>Какая разница — на 2 процессора или на 80? Большинству числомолотилок пофиг, на сколько ядер их разнести (если, конечно, они вообще распараллеливаются). А не-числомолотилкам оно обычно не надо (у них в другом тормоза, как правило).
>>
>> Большая, потому как человек может держать держать в голове максимум 9 образов, а в среднем 5-7. И разнести задачу на 80 ядер самому архисложно учитывая при этом конкурентность, разделяемые ресурсы и т.п.

S>На 2 ядра — не менее сложно На самом деле, когда я создаю отдельную нить исполнения, мне все равно, сколько физических процессоров присутствует в системе — 2 или 80.

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

>> Числомолотилки, довольно неплохо распараллеливаются вручную я не спорю. Но как поступать в общем случае?

S>А нет никакого общего случая — лично мне все время попадаются какие-то частные

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

хъ

>> Очень сомневаюсь что параллельность останется на откуп разработчика.

S>Пока чего-нибудь радикального не придумают — ни куда не денешся, кроме как на откуп разработчика ее оставлять. Но радикальных придумок что-то не видать.

Будет иначе пользы от более чем 8-ми ядерным процессоров почти никакой.

>>>> это сродни написания на асме современных приложений.
>>
>> S>Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер
>>
>> Да ну, а я думал там тоже на дотНете пишут. Может я некорректно выразился, но GUI утилитку для работы с БД писать на асме просто глупо.

S>Гуевым утилкам для работы с БД и многоядерность нафиг не упала Зачем там, где хватает одного процессора, использовать еще 79?

Я и не говорил что им многоядерность нужна, я сравнил сложность разбиения программы на 80(не архиватора ) потоков и написание на асме такой утилитки.

> S>На 2 ядра — не менее сложно На самом деле, когда я создаю отдельную нить исполнения, мне все равно, сколько физических процессоров присутствует в системе — 2 или 80.
>
> Все правильно, но вот на самом деле по иному детализировав процесс можно его разложить на 4 или 5 ветвей исполнения, а если еще некоторые операции независимыми сделать, так и того больше.

Можете привести практический пример случая, когда 3 потока уместны, а 4 — нет?

> Такие места бывает очень трудно найти без знания теории, но теоретические выкладки можно автоматизировать.

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

>>> Числомолотилки, довольно неплохо распараллеливаются вручную я не спорю. Но как поступать в общем случае?
>
> S>А нет никакого общего случая — лично мне все время попадаются какие-то частные
>
> Ну что для тебя лучше думать как потоки конкурируют или как они в архитектуру вписываются для конкретного проца или бизнес логику накручивать.

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


>>> Очень сомневаюсь что параллельность останется на откуп разработчика.
>
> S>Пока чего-нибудь радикального не придумают — ни куда не денешся, кроме как на откуп разработчика ее оставлять. Но радикальных придумок что-то не видать.
>
> Будет иначе пользы от более чем 8-ми ядерным процессоров почти никакой.

Я пока даже на 8-ми ядерных железках свои программы не гонял Но, думаю, толк и от 64 ядер будет, если железячники не подкачают.

>
>>>>> это сродни написания на асме современных приложений.
>>>
>>> S>Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер
>>>
>>> Да ну, а я думал там тоже на дотНете пишут. Может я некорректно выразился, но GUI утилитку для работы с БД писать на асме просто глупо.
>
> S>Гуевым утилкам для работы с БД и многоядерность нафиг не упала Зачем там, где хватает одного процессора, использовать еще 79?
>
> Я и не говорил что им многоядерность нужна, я сравнил сложность разбиения программы на 80(не архиватора ) потоков и написание на асме такой утилитки.

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

Здравствуйте, Erop, Вы писали:

AVK>>

Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc).

E>Ну вот конкрентно MS Word всякие спеллеры/граммеры запускает на другой нити, чем редактор.

Не поленился и проверил. Открыл в ворде (11.6359.6360 sp1 — достаточно актуальная версия, нес па?) 70-и страничный документ и посмотрел в Process Explorer его треды. У Word.exe 1 (один) тред. У mso.dll тоже. Все процессорное время жрет первый, за исключением жалких крох, которые иногда требуются gdi+. При работающем спеллчекере скроллинг тормозит так, что мама не горюй. В среднем примерно 20-25%
С отключенным спеллчекером количество тредов то же, тормозов при скроллинге нет, в среднем примерно 3% времени процессоров.
Ни форматирование текста ни поиск и замена ситуацию не изменили.

2X Intel Xeon-A (Prestonia). Т.е. два физических процессора и два виртуальных HT.

Какой же из всего этого следует вывод?
В чем я мог ошибиться?

Здравствуйте, AndrewVK, Вы писали:

E>>опять же, АФАИК, в NT-based системах гуй и пользовательский код живут в разных потоках
AVK> Чего?

Первоначально в арихитектуре NT была система, собственно ядро. А была Win32 subsistem, Этап одсистема жила в отдельном процессе, и на каждую нить, которая может рисовать окна (то есть позвала какой-нибудь вызов из соответсвующего API), создавала свою нить, которая собственно всё и рисовала. А запросы к рисованию ГУЯ просто сериализовались и передавались через LPC в эту нить.

С тех пор часть рисования ГУЯ вынесли в ядро, часть, вроде как, осталась в Win32Subsystem, Какая --

Здравствуйте, CreatorCray, Вы писали:

S>>Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.
CC>7Zip умеет например

Но не очень хорошо. Зависимость от числа ядер далеко не линейная. Уже на 4 ядрах одно ядро практически не работает.

Здравствуйте, Erop, Вы писали:

E>Первоначально в арихитектуре NT была система, собственно ядро. А была Win32 subsistem, Этап одсистема жила в отдельном процессе, и на каждую нить, которая может рисовать окна (то есть позвала какой-нибудь вызов из соответсвующего API), создавала свою нить, которая собственно всё и рисовала. А запросы к рисованию ГУЯ просто сериализовались и передавались через LPC в эту нить.

Уверен?

E>С тех пор часть рисования ГУЯ вынесли в ядро, часть, вроде как, осталась в Win32Subsystem, Какая --

Понятно. Слышал звон, не знаю где он. В NT до версии 4.0 драйвера видеоадаптера работали вне нулевого кольца. Тормозило. В 4.0 их внесли внутрь. Никакого отношения к потокам это не имело, User32/Gdi32 во всех версиях винды однопоточные.

> E>Первоначально в арихитектуре NT была система, собственно ядро. А была Win32 subsistem, Этап одсистема жила в отдельном процессе, и на каждую нить, которая может рисовать окна (то есть позвала какой-нибудь вызов из соответсвующего API), создавала свою нить, которая собственно всё и рисовала. А запросы к рисованию ГУЯ просто сериализовались и передавались через LPC в эту нить.
>
> Уверен?
>
> E>С тех пор часть рисования ГУЯ вынесли в ядро, часть, вроде как, осталась в Win32Subsystem, Какая --
>
> Понятно. Слышал звон, не знаю где он. В NT до версии 4.0 драйвера видеоадаптера работали вне нулевого кольца. Тормозило. В 4.0 их внесли внутрь. Никакого отношения к потокам это не имело, User32/Gdi32 во всех версиях винды однопоточные.

А вот что про это пишет Руссинович:
"Prior to Windows NT 4, the window manager and graphics services were part of the user-mode Win32 subsystem process. In Windows NT 4, the bulk of the windowing and graphics code was moved from running in the context of the Win32 subsystem process to a set of callable services running in kernel mode (in the file Win32k.sys). The primary reason for this shift was to improve overall system performance. Having a separate server process that contains the Win32 graphics subsystem required multiple thread and process context switches, which consumed considerable CPU cycles and memory resources even though the original design was highly optimized.

For example, for each thread on the client side there was a dedicated, paired server thread in the Win32 subsystem process waiting on the client thread for requests. A special interprocess communication facility called fast LPC was used to send messages between these threads. Unlike normal thread context switches, transitions between paired threads via fast LPC don't cause a rescheduling event in the kernel, thereby enabling the server thread to run for the remaining time slice of the client thread before having to take its turn in the kernel's preemptive thread scheduler. Moreover, shared memory buffers were used to allow fast passing of large data structures, such as bitmaps, and clients had direct but read-only access to key server data structures to minimize the need for thread/process transitions between clients and the Win32 server."

Здравствуйте, AndrewVK, Вы писали:

CC>>7Zip умеет например
AVK>Но не очень хорошо. Зависимость от числа ядер далеко не линейная. Уже на 4 ядрах одно ядро практически не работает.
Ну там ИМХО многопоточность была добавлена как фенька, т.е. как приятное дополнение. Но сам 7Zip изначально на работу на многоядерных системах не проектировался. Его ниша — домашние компы, на которых на то время HT был максимумом мечтаний

DE>Глядя на то, как Visual Studio 2005 + Visual Assist умудряются забирать 98% ресурсов 1.7ГГц-процессора "просто так", в фоне, даже без компиляции, я думаю что современные разработчики успешно справятся с поставленной задачей и смогут забить ресурсы даже 80-ядерного процессора

А вы уверены в том, что VisualAssist тратит процессорное время попусту?
Я — нет. Вероятно в фоне происходит какое-нибудь построение дерева вызовов или ещё что-то в этом духе, чтобы при вводе исходного кода всё уже было готово к работе.
С другой стороны, я вынужден согласиться с тем, что в современной индустрии порой побеждает не лучший продукт, а хороший продукт + крикливая реклама. Однако, насколько мне известно, google вовсе не тратится на маркетинг, вложив всю прибыль в обеспечение хороших условий своим разрабочикам.

Здравствуйте, AndrewVK, Вы писали:

XZ>>Кто такой этот поток?
AVK>Обычно GUI-поток активного приложения в момент какого либо действия пользователя.
Ага, драйвера спят, служебные задачи не выполняются... У меня, вон, полчаса после ребута винты-зеркала сверяются.

AVK>>>При чем тут многоядерность? Что, несколько ядер уменьшат размер таблицы хендлов?
XZ>>Хэндлы — это из Windows
AVK>А ты про что?
Про процессоры и их дескрипторы задач.

XZ>>, дескрипторы задач — в процессорах/ядрах. Система распределяет эти задачи между ядрами.
AVK>Кхм. Ты точно уверен, что знаешь, о чем говоришь?
Да.

XZ>>Неужели нечего делать в фоне?
AVK>Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.
Из чего это видно?

AVK>>>Она зачастую медленнее отрисовывается. Но асинхронно. Ускорение от многоядерности мы получим разве что при рендеринге шрифтов. Все остальные операции упрутся в видеокарту, а не в ядра процессора.
XZ>>В драйвер видеокарты, а не в графический процессор.
AVK>В железо видеокарты.
Железо гоняется драйвером, драйвер — софт, работающий на процессоре. Если задача для графического адаптера не типовая, т.е. требуется подготовка данных, работает формула "быстрее процессор -> быстрее драйвер".

XZ>> Если драйвер переписан под многоядерность, то работу по подготовке данных в видеоадаптер можно осуществлять быстрее.
AVK>Не может. Потому что отрисовкой примитивов занимается GPU на карте, а не СPU.
Примитивы надо подготовить, прежде чем отрисовывать.

XZ>>Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?
AVK>А софт написан с учетом этого?
Будет написан.

AVK>>>По факту же таких тяжелых обработок в современных приложениях крайне мало. В основном асинхронная обработка в современных приложениях связана с ожиданием отклика из сети или какого нибудь медленного внешнего устройства.
XZ>>Откройте папочку windows\system32 в explorere — тот будет мучиться и пыжиться, перелистывая многочисленные экзешники и выдирая из них пиктограммы для отображения.
AVK>Ага. Тот самый случай, когда все упирается в медленный винчестер. Второе ядро тут ничем не поможет.
Прежде, чем выковырять пиктограмму, надо, загрузив модуль, перепахать его ресурсы, загрузив нужный, и приведя к битмапу. У меня, бывает, на секунды три задумывается, пролистывая страницу эксплорера на три десятка экзешников, общим объёмом в пяток мегабайт — винт всырую считывает их за пятую часть секунды.

XZ>>Интересный подход.
AVK>Подход очень простой. Тот кто выдвигает предположения, тот и должен их аргументировать. У тебя подход другой?
А тот, кто предположения опровергает, свои опровержения аргументировать не должен, ага?

XZ>>Речь зашла про гуй с наворотами на DirectX, потому игрушки из той же плоскости.
AVK>Нет, не из той же. Техника там совсем иная, сильно отличающаяся от использования видеоадаптера игрушками. DirectX там исключительно в качестве средства доступа к железу.
А в игрушках не оном ли качестве?

XZ>>Компилятор — тут можно распараллелить, ах как замечательно.
AVK>Языком.
? Компилим модули не подряд, а параллельно.

XZ>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
AVK>У меня не тормозит совсем. Что я делаю не так?
Не знаю. Я, если вставлю английский текст в ворд, он каждое словцо сначала подчеркнёт, как неверное, сделав это со скоростью слов 30 в секунду, и только после этого определит, наконец, что язык английский, и даст работать с текстом без тормозов.

XZ>>Internet — есть тут браузеры, отличающиеся выводом странички по ходу загрузки.
AVK>Вот только проблема в том, что браузеры упираются в канал, а не в скорость процессора.
Я приводил пример странички с табличкой (1М), которую FF на модеме грузил минут двадцать, ужрав весь проц.

AVK>>>А ты его видел? Архитектуру представляешь?
XZ>>Зачем такие детали-то?
AVK>Понятно. Архитектура и общие принципы построения у нас уже "какие то детали". Разговор дальше в том же духе лишен смысла.
Архитектура конкретной реализации софта? Зачем её знать, я верю на слово, что она однопоточна. Зачем спорить, что её принципиально нельзя изменить?

XZ>> Если гуй что-то рисует, мне, как пользователю важно, чтобы делал он это как можно быстрее.
AVK>Ты же рассуждаешь о том, как этот гуй ускорится от второго ядра. Так при чем тут пользователь?
Потому, что ускорение отрисовки наиболее интересно пользователю — "хочу, чтобы не дыр-дыр, а всё плавненько и быстренько."

AVK>>>Не было аргументов. Ни одного.
XZ>>С таким подходом и разговаривать не о чем. Подождём годик и "паглядим."
AVK>Слив засчитан.

У-у.

Компьютерра, №35, 26.09.06

"После завтра II, В. Гуриев"
...
Компьютеры, 199 экспертов
...
Параллельное ПО станет стандартом:
вряд ли ............ 5%
трудно сказать ..... 9%
скорее всего ....... 83,4%
Это произойдёт в ближайшие
10 лет ............. 58,6%
20 лет ............. 31,6%

Здравствуйте, AndrewVK, Вы писали:


E>>Да и всякие OLE-объекты вставленные в документ тоже в отдельной нити обычно живут

AVK>Это вряд ли. Я сейчас не скажу про OLE-контейнеры, но, к примеру, ActiveX по стандарту работают только в STA.

ActiveX да, но почти все встраиваемые объекты-документы выполнены как out-of-proccess. Для всех, например, загруженных в разных приложениях встроенных документов MS Word, OLE запускает один экземпляр скрытого MS Word, ну и там потом проводит load balancing и управление потоками, при вызове удаленных методов этого OLE-сервера.

> E>>Да и всякие OLE-объекты вставленные в документ тоже в отдельной нити обычно живут
>
> AVK>Это вряд ли. Я сейчас не скажу про OLE-контейнеры, но, к примеру, ActiveX по стандарту работают только в STA.
>
> ActiveX да, но почти все встраиваемые объекты-документы выполнены как out-of-proccess. Для всех, например, загруженных в разных приложениях встроенных документов MS Word, OLE запускает один экземпляр скрытого MS Word, ну и там потом проводит load balancing и управление потоками, при вызове удаленных методов этого OLE-сервера.

С чего бы это ActiveX работать только в STA? ActiveX декларирует в реестре, в какой потоковой модели он может жить — STA, MTA или Both. Контейнер пытается его создавать в той модели, в какой это ему, контейнеру, надо (потому что CoInitialize/CoInitializeEx вызывает именно конетйнер). Если ActiveX ее не умеет — его создание просто обломится с соответствующим кодом ошибки.

Здравствуйте, Xander Zerge, Вы писали:

AVK>>Обычно GUI-поток активного приложения в момент какого либо действия пользователя.
XZ>Ага, драйвера спят, служебные задачи не выполняются... У меня, вон, полчаса после ребута винты-зеркала сверяются.

Это не создает заметной нагрузки на процессоры.

XZ>>>, дескрипторы задач — в процессорах/ядрах. Система распределяет эти задачи между ядрами.
AVK>>Кхм. Ты точно уверен, что знаешь, о чем говоришь?
XZ>Да.



AVK>>Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.
XZ>Из чего это видно?

Из того, что загрузка процессора = 0.

XZ>>>Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?
AVK>>А софт написан с учетом этого?
XZ>Будет написан.

Надежды юношей питают.

AVK>>Ага. Тот самый случай, когда все упирается в медленный винчестер. Второе ядро тут ничем не поможет.
XZ>Прежде, чем выковырять пиктограмму, надо, загрузив модуль, перепахать его ресурсы, загрузив нужный, и приведя к битмапу. У меня, бывает, на секунды три задумывается, пролистывая страницу эксплорера на три десятка экзешников, общим объёмом в пяток мегабайт — винт всырую считывает их за пятую часть секунды.

У тебя процессор в этот момент на 100% загружен? У меня нет.

AVK>>Подход очень простой. Тот кто выдвигает предположения, тот и должен их аргументировать. У тебя подход другой?
XZ>А тот, кто предположения опровергает, свои опровержения аргументировать не должен, ага?

Аргументировать можно только в ответ на аргументы.

AVK>>Нет, не из той же. Техника там совсем иная, сильно отличающаяся от использования видеоадаптера игрушками. DirectX там исключительно в качестве средства доступа к железу.
XZ>А в игрушках не оном ли качестве?

В онном. И что? ПРоблема не в DirectX, проблема в том, как видеокарта используется.

XZ>>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
AVK>>У меня не тормозит совсем. Что я делаю не так?
XZ>Не знаю.



AVK>>Вот только проблема в том, что браузеры упираются в канал, а не в скорость процессора.
XZ>Я приводил пример странички с табличкой (1М), которую FF на модеме грузил минут двадцать, ужрав весь проц.

Это явные проблемы софта.

AVK>>Понятно. Архитектура и общие принципы построения у нас уже "какие то детали". Разговор дальше в том же духе лишен смысла.
XZ>Архитектура конкретной реализации софта? Зачем её знать

Затем что иначе оценить выигрышь от второго ядра невозможно в принципе.

XZ>, я верю на слово, что она однопоточна. Зачем спорить, что её принципиально нельзя изменить?

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

Твои слова? Чего ты все время увильнуть с темы хочешь?

AVK>>Ты же рассуждаешь о том, как этот гуй ускорится от второго ядра. Так при чем тут пользователь?
XZ>Потому, что ускорение отрисовки наиболее интересно пользователю — "хочу, чтобы не дыр-дыр, а всё плавненько и быстренько."

Замечательно. Какое это имеет отношение к реальной возможности ускорения? Опять тему сменить хочешь?

AVK>>>>Не было аргументов. Ни одного.
XZ>>>С таким подходом и разговаривать не о чем. Подождём годик и "паглядим."
AVK>>Слив засчитан.

XZ>У-у.

XZ>Компьютерра

Серьезный технический источник

XZ>, №35, 26.09.06
XZ>

XZ>"После завтра II, В. Гуриев"
XZ>...
XZ>Компьютеры, 199 экспертов
XZ>...
XZ>Параллельное ПО станет стандартом:
XZ>вряд ли ............ 5%
XZ>трудно сказать ..... 9%
XZ>скорее всего ....... 83,4%
XZ>Это произойдёт в ближайшие
XZ>10 лет ............. 58,6%
XZ>20 лет ............. 31,6%

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

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Обычно GUI-поток активного приложения в момент какого либо действия пользователя.
XZ>>Ага, драйвера спят, служебные задачи не выполняются... У меня, вон, полчаса после ребута винты-зеркала сверяются.
AVK>Это не создает заметной нагрузки на процессоры.
Однако ж. Вот, кстати, сейчас читаю доки в PDF. Тормозит-с.

AVK>>>Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.
XZ>>Из чего это видно?
AVK>Из того, что загрузка процессора = 0.
А кто её показывает, что она 0?

XZ>>>>Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?
AVK>>>А софт написан с учетом этого?
XZ>>Будет написан.
AVK>Надежды юношей питают.
Луддит?

XZ>>Прежде, чем выковырять пиктограмму, надо, загрузив модуль, перепахать его ресурсы, загрузив нужный, и приведя к битмапу. У меня, бывает, на секунды три задумывается, пролистывая страницу эксплорера на три десятка экзешников, общим объёмом в пяток мегабайт — винт всырую считывает их за пятую часть секунды.
AVK>У тебя процессор в этот момент на 100% загружен? У меня нет.
Мне это неинтересно. Мне важно то, что я жду несколько секунд, чтобы листать следующую страничку. Утомляет поиск файла с любимым скринсэйвером.

AVK>>>Нет, не из той же. Техника там совсем иная, сильно отличающаяся от использования видеоадаптера игрушками. DirectX там исключительно в качестве средства доступа к железу.
XZ>>А в игрушках не оном ли качестве?
AVK>В онном. И что? ПРоблема не в DirectX, проблема в том, как видеокарта используется.
А что есть DirectX, не софт ли?

XZ>>>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
AVK>>>У меня не тормозит совсем. Что я делаю не так?
XZ>>Не знаю.
AVK>
Безжалостно выдернуто из контекста и осмеяно.

XZ>>Я приводил пример странички с табличкой (1М), которую FF на модеме грузил минут двадцать, ужрав весь проц.
AVK>Это явные проблемы софта.
Если проц позволит обходить проблемы софта — ура процу.

AVK>>>Понятно. Архитектура и общие принципы построения у нас уже "какие то детали". Разговор дальше в том же духе лишен смысла.
XZ>>Архитектура конкретной реализации софта? Зачем её знать
AVK>Затем что иначе оценить выигрышь от второго ядра невозможно в принципе.

XZ>>, я верю на слово, что она однопоточна. Зачем спорить, что её принципиально нельзя изменить?
AVK>

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

AVK>Твои слова? Чего ты все время увильнуть с темы хочешь?
Я не увиливаю. Про принципиальную однопоточность не я утверждал, но даже это готов принять. Однако когда количество потоков исчисляется сотнями, при количестве процессов на десяток меньшем, можно спросить, зачем это делается и не даст ли это выигрыша при распараллеливании?

AVK>>>Ты же рассуждаешь о том, как этот гуй ускорится от второго ядра. Так при чем тут пользователь?
XZ>>Потому, что ускорение отрисовки наиболее интересно пользователю — "хочу, чтобы не дыр-дыр, а всё плавненько и быстренько."
AVK>Замечательно. Какое это имеет отношение к реальной возможности ускорения? Опять тему сменить хочешь?
С чего вы взяли про смену темы? Если часть системы удастся ускорить, то вся система тоже получит увеличение в производительности.

XZ>>Компьютерра
AVK>Серьезный технический источник
Жду цитату по теме из технического источника, который является серьёзным на ваш компетентный взгляд.

XZ>>, №35, 26.09.06
XZ>>

XZ>>"После завтра II, В. Гуриев"
XZ>>...
XZ>>Компьютеры, 199 экспертов
XZ>>...
XZ>>Параллельное ПО станет стандартом:
XZ>>вряд ли ............ 5%
XZ>>трудно сказать ..... 9%
XZ>>скорее всего ....... 83,4%
XZ>>Это произойдёт в ближайшие
XZ>>10 лет ............. 58,6%
XZ>>20 лет ............. 31,6%

AVK>Да да. Мне это новое веяние, решать технические и научные вопросы путем голосования всегда нравилось. Вобщем, слив засчитан.
Это не решение, это форма предположений и прогнозов, которые мы тут строим, изложенная бОльшим количеством людей.
Пацанский метод ведения спора. Ни слова по теме, общие фразы, дергание заумных слов с претензией на сложные термины ("composition engine", ах, я в шоке), безапелляционная вера в собственный авторитет и неприятие самой возможности существования других мнений.
А за всем стоит элементарный снобизм. "Ах, я, суперспец, 10 лет обучения, 20 лет в отрасли, колоссальный опыт разработки, а эти долбаные железячники выкатывают процессоры, на которых скоро троечник-школьник-недоучка на корявом бэйсике сможет решить задачу, которую двадцать лет назад приходилось писать на ассемблере, оптимизируя каждую командочку, перелопачивать тонны справочников и спец-литературы, будучи крайне редким и ценным специалистом. А ведь ещё появятся новые архитектуры, новые задачи, это ж опять всё изучать-переучивать, ах как лень уже."
Фу.

Я же предположу, что в ближайшие коды ещё появятся лейбочки на софте типа "64-bit architecture compatible" и "Optimized for Quad-Core Processors".
Может, чисто маркетинговые, но вот ещё пример — какая-нибудь система мониторинга и визуализации, четыре модели — четыре экрана, всяк дешевле (в железе, софте и управлении) будет повесить на один комп с многоядерником, чем сеть из компов ваять.
Или становящаяся модной тема "умный дом" — один компьютер должен уметь управлять кучей устройств, экранов там всяких, да рабочие терминалы не забывать. Опять же, мозг лучше держать один, но мощный, чем распихивать компьютеры по этажам.
Будет железо — будут новые задачи, будут тенденции развития этих задач под которые потребуется новое железо. Это не автомобиль, развитие которого давно вышло на эволюционный этап...
Вот! Автомобиль! ("Остап был голоден, и его несло.") А ну как управлять одним ядром всеми системами? А когда одна создаст нештатную операцию, придётся решать задачу выхода из неё, затрачивая 100% вычислительного ресурса, даже если в штатном режиме проц нагружен на 1%? А как быть с усложнением систем реального времени? Должен быть запас, упор будет делаться не на производительность, а на пиковую производительность системы — когда считать быстро не надо 99,9% времени, но в те три миллисекунды считать надо очень, супер-, сверхбыстро! Вспомните времена, когда при записи CD страшно было мышкой тронуть, чтобы сессию записи не сорвать. У меня быстрые круговые движения мыши по экрану откушивают 10% проца. А вдруг в это время надо будет что-то высчитать? Кому-то ресурса не достанется.

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.
XZ>>Из чего это видно?
AVK>Из того, что загрузка процессора = 0.

Кстати, безотносительно к предмету вашего спора, почему бывает что Таск Менеджер показывает что 99% времени работает System Idle (то есть система вроде бездействует), но при этом на внешние воздействия Винда не реагирует?

Здравствуйте, Xander Zerge, Вы писали:

AVK>>Это не создает заметной нагрузки на процессоры.
XZ>Однако ж. Вот, кстати, сейчас читаю доки в PDF. Тормозит-с.

Значит упирается в винт. Тут тебе второе ядро не поможет.

AVK>>Из того, что загрузка процессора = 0.
XZ>А кто её показывает, что она 0?

Что, мало утилит?

XZ>>>>>Почему в одном, если софт написан с учётом возможности исполнения в многопроцессорной среде?
AVK>>>>А софт написан с учетом этого?
XZ>>>Будет написан.
AVK>>Надежды юношей питают.
XZ>Луддит?



AVK>>У тебя процессор в этот момент на 100% загружен? У меня нет.
XZ>Мне это неинтересно.

Тогда не надо высасывать из пальца выводы.

XZ> Мне важно то, что я жду несколько секунд, чтобы листать следующую страничку. Утомляет поиск файла с любимым скринсэйвером.

А с чего ты взял, что второе ядро улучшит ситуацию?

AVK>>В онном. И что? ПРоблема не в DirectX, проблема в том, как видеокарта используется.
XZ>А что есть DirectX, не софт ли?

Софт. А что?

XZ>>>>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
AVK>>>>У меня не тормозит совсем. Что я делаю не так?
XZ>>>Не знаю.
AVK>>
XZ>Безжалостно выдернуто из контекста и осмеяно.

Нормально выдернуто. Отражает уровень аргументов.

XZ>>>Я приводил пример странички с табличкой (1М), которую FF на модеме грузил минут двадцать, ужрав весь проц.
AVK>>Это явные проблемы софта.
XZ>Если проц позволит обходить проблемы софта — ура процу.

А позволяет ли?

XZ>>>, я верю на слово, что она однопоточна. Зачем спорить, что её принципиально нельзя изменить?
AVK>>

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

AVK>>Твои слова? Чего ты все время увильнуть с темы хочешь?
XZ>Я не увиливаю. Про принципиальную однопоточность не я утверждал, но даже это готов принять. Однако когда количество потоков исчисляется сотнями, при количестве процессов на десяток меньшем, можно спросить, зачем это делается

Я кажется уже говорил — практически всегда потоки в современном софте используют для ожидания отклика от медленных устройств — сети, жесткого диска и т.п.

XZ> и не даст ли это выигрыша при распараллеливании?

Не даст. Выигрыш при распараллеливании это даст, если несколько потоков жрут процессор одновременно и сильно. У меня на машине такое бывает нечасто — в янусе при синхронизации, при сборке больших проектов в студии. Поэтому выигрышь от второго ядра на текущем софте будет весьма невеликим. А вот, скажем, на сервере rsdn одновременно крутяться 5-6 активных процессов и оба ядра загружены практически полностью. Вот там выигрышь от 2-4 ядер огромный.

AVK>>>>Ты же рассуждаешь о том, как этот гуй ускорится от второго ядра. Так при чем тут пользователь?
XZ>>>Потому, что ускорение отрисовки наиболее интересно пользователю — "хочу, чтобы не дыр-дыр, а всё плавненько и быстренько."
AVK>>Замечательно. Какое это имеет отношение к реальной возможности ускорения? Опять тему сменить хочешь?
XZ>С чего вы взяли про смену темы?

С того, что весь этот тред я пытаюсь сказать одну единственную вещь — на современном софте проку от кучи ядер 0. Требуется весьма основательная переделка софта, чтобы получить от этого значительный выигрышь.

XZ> Если часть системы удастся ускорить, то вся система тоже получит увеличение в производительности.

Увы, ускорение это на десктопе практически незаметно. Опыт имеется.

AVK>>Да да. Мне это новое веяние, решать технические и научные вопросы путем голосования всегда нравилось. Вобщем, слив засчитан.
XZ>Это не решение, это форма предположений и прогнозов, которые мы тут строим, изложенная бОльшим количеством людей.

Какое это имеет отношение к исходной теме? Я не спорю с тем, что когда нибудь мы получим существенный прирост от многопроцессорности. Но на данный момент такого прироста на десктопе нет, сколько б там потоков task manager не показывал.

XZ>Пацанский метод ведения спора. Ни слова по теме, общие фразы, дергание заумных слов с претензией на сложные термины

Это ты про себя?

XZ> ("composition engine", ах, я в шоке)

Батенька, composition engine это базовое понятие архитектуры WPF. Если ты не знаешь, что это такое, то не стоит делать столь глубокомысленных выводов по поводу этой технологии, бо ты совершенно не представляешь себе что это такое.
http://windowssdk.msdn.microsoft.com/en-us/library/ms750441.aspx

...
WPF displays data by traversing the unmanaged data structures managed by the milcore. These structures, called composition nodes, represent a hierarchical display tree with rendering instructions at each node.
...

http://www.winsupersite.com/showcase/longhorn_preview_2003.asp

Longhorn's low-level graphics engine--the bits that replace GDI and GDI+--is called the Desktop Composition Engine, or DCE (code-named Avalon).

http://www.ondotnet.com/pub/a/dotnet/2004/03/08/winfs_detail_3.html

XZ>, безапелляционная вера в собственный авторитет и неприятие самой возможности существования других мнений.

О, переход на личности. Правильной дорогой идете, товарищь.

XZ>А за всем стоит элементарный снобизм. "Ах, я, суперспец, 10 лет обучения, 20 лет в отрасли, колоссальный опыт разработки, а эти долбаные железячники выкатывают процессоры, на которых скоро троечник-школьник-недоучка на корявом бэйсике сможет решить задачу, которую двадцать лет назад приходилось писать на ассемблере, оптимизируя каждую командочку, перелопачивать тонны справочников и спец-литературы, будучи крайне редким и ценным специалистом. А ведь ещё появятся новые архитектуры, новые задачи, это ж опять всё изучать-переучивать, ах как лень уже."

Эк тебя задело. Заметь, я ничего этого не говорил .

XZ>Я же предположу, что в ближайшие коды ещё появятся лейбочки на софте типа "64-bit architecture compatible" и "Optimized for Quad-Core Processors".

Опять тему меняешь? Напоминаю тебе твое же высказывание, на которое я отвечал, еще раз:

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

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

>>>
>>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

S>>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

DC>Угу а весь до этого написанный код вручную распараллеливать?? Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции. Распараллеливать самомому задачу на 80 ядер, это сродни написания на асме современных приложений.

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

Здравствуйте, mik1, Вы писали:

>>>>
>>>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40??

S>>>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.

DC>>Угу а весь до этого написанный код вручную распараллеливать?? Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции. Распараллеливать самомому задачу на 80 ядер, это сродни написания на асме современных приложений.

M>Малюсенькая ремарочка. Паралелить надо не на заранее известное число потоков. Паралелить надо на кол-во потоков на каждой конкретной машине пользователя. У кого-то дома может быть одноядерник, а у кого-то два оптерона двухядерных в одном корпусе живут. У одного один проц, у другого — 4. Поэтому механизм разбиения должен быть либо в компиленном коде, либо это должен быть интерпртатор, сразу пляшущий от числа доступных процессоров (доступных свободных процессоров в идеальном случае).

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

M>>Малюсенькая ремарочка. Паралелить надо не на заранее известное число потоков. Паралелить надо на кол-во потоков на каждой конкретной машине пользователя. У кого-то дома может быть одноядерник, а у кого-то два оптерона двухядерных в одном корпусе живут. У одного один проц, у другого — 4. Поэтому механизм разбиения должен быть либо в компиленном коде, либо это должен быть интерпртатор, сразу пляшущий от числа доступных процессоров (доступных свободных процессоров в идеальном случае).

DC>Собственно да. Тут и вылазят плюсы управляемого кода. Я думаю разумно было бы компилить исходники в промежуточный код, а инсталятор будет оптизировать их под конкретную платформу.

Инсталятор — хорошо, но не совсем верно. Во-первых, инсталятор, оптимизирующий под конкретную платформу — это, как я понимаю, компилятор? С чего в чего? Кто его автор? Каковы условия распространения?
Во-вторых, если я меняю проц. Скажем, на 775 сокете с одноядерника на core 2 duo. Пусть и с перепрошивкой биоса. Ну реальная же ситуация? Софт у меня останется в его старом виде. Оно нам надо? Ну даже если я машину буду полностью апгрейдить, то не исключено, что старый хард я оставлю. И если мастодонтов типа офиса переставлять придется (реестр, мать его), то, скажем, winrar я из года в год копирую каталогом и всё (ну и обновляю изредка).
Так что не совсем у Вас хорошее решение.
Но если искать оптимальное — то упершься либо в фреймворки, либо в языки, заточенные под эту ситуацию (где всё вынесено в рантайм).

Здравствуйте, mik1, Вы писали:

M>>>Малюсенькая ремарочка. Паралелить надо не на заранее известное число потоков. Паралелить надо на кол-во потоков на каждой конкретной машине пользователя. У кого-то дома может быть одноядерник, а у кого-то два оптерона двухядерных в одном корпусе живут. У одного один проц, у другого — 4. Поэтому механизм разбиения должен быть либо в компиленном коде, либо это должен быть интерпртатор, сразу пляшущий от числа доступных процессоров (доступных свободных процессоров в идеальном случае).

DC>>Собственно да. Тут и вылазят плюсы управляемого кода. Я думаю разумно было бы компилить исходники в промежуточный код, а инсталятор будет оптизировать их под конкретную платформу.

M>Инсталятор — хорошо, но не совсем верно. Во-первых, инсталятор, оптимизирующий под конкретную платформу — это, как я понимаю, компилятор? С чего в чего? Кто его автор? Каковы условия распространения?
Я думаю что все таки оптимизатор промежуточного кода. Возможен вариант разработки и встойки такого API в ОС. Возможно это будет отдельная программа (или билиотека) от производителя компилятора, которая встраивается в инсталятор.
M>Во-вторых, если я меняю проц. Скажем, на 775 сокете с одноядерника на core 2 duo. Пусть и с перепрошивкой биоса. Ну реальная же ситуация? Софт у меня останется в его старом виде. Оно нам надо? Ну даже если я машину буду полностью апгрейдить, то не исключено, что старый хард я оставлю. И если мастодонтов типа офиса переставлять придется (реестр, мать его), то, скажем, winrar я из года в год копирую каталогом и всё (ну и обновляю изредка).

Ну дык с натив кодом по другому и не получиться.

M>Так что не совсем у Вас хорошее решение.
M>Но если искать оптимальное — то упершься либо в фреймворки, либо в языки, заточенные под эту ситуацию (где всё вынесено в рантайм).

Вообще тут нверно будет такая ситуация, что ОС все потоки что найдет будет распределять м-ду потоками управления тут врядли возникнет проблема с разным количеством ядер. Есть ресурс, значит запихнем, нет ну и хрен с ним. Тут, скорее всего сами средства изменятся, как уже говорил Влад. И если кмитет по стандартизации С++ это не учтет, то следующие 10 лет опять будем на велосипедах ездить. Хотя и сейчас полно библиотек для работы с нитями.

Здравствуйте, AndrewVK, Вы писали:

XZ>>Однако ж. Вот, кстати, сейчас читаю доки в PDF. Тормозит-с.
AVK>Значит упирается в винт. Тут тебе второе ядро не поможет.

950К? Кривой софт "адназначна". 7 потоков, три секунды машинного времени (P4-2.4) на загрузку документа (практически сполшной текст), беглое пролистывание колесом до конца — ещё 5 секунд 100% загрузки. Пара ядер его бы исправила, может быть. Кому интересно — акробат седьмой, док по fltk, экран большой, адобовский фонт-смуфинг включён (вот это бы замечательно можно отпараллелить). Да и ещё Core2Duo хорош приятно большим кэшем.

AVK>>>Из того, что загрузка процессора = 0.
XZ>>А кто её показывает, что она 0?
AVK>Что, мало утилит?
Если утилита работает — уже не ноль.

XZ>>>>Будет написан.
AVK>>>Надежды юношей питают.
XZ>>Луддит?
AVK>
Понял.

AVK>>>У тебя процессор в этот момент на 100% загружен? У меня нет.
XZ>>Мне это неинтересно.
AVK>Тогда не надо высасывать из пальца выводы.
Ответ чуть ниже.
XZ>> Мне важно то, что я жду несколько секунд, чтобы листать следующую страничку. Утомляет поиск файла с любимым скринсэйвером.
AVK>А с чего ты взял, что второе ядро улучшит ситуацию?
Видел сам своими глазами. Специально полез в эту папочку — открывается и листается. Может, конечно, ещё почему, но винт — вряд ли, это точно, а иной разницы, кроме как в процессорах между компами нет — у меня и памяти поболе будет.

AVK>>>В онном. И что? ПРоблема не в DirectX, проблема в том, как видеокарта используется.
XZ>>А что есть DirectX, не софт ли?
AVK>Софт. А что?
Ускоряем софт низкого уровня в гуе — ускоряем сам гуй.

XZ>>Безжалостно выдернуто из контекста и осмеяно.
AVK>Нормально выдернуто. Отражает уровень аргументов.
Это было лишь вступительное начало фразы, уточняющей, где именно тормозит.

XZ>>>>Я приводил пример странички с табличкой (1М), которую FF на модеме грузил минут двадцать, ужрав весь проц.
AVK>>>Это явные проблемы софта.
XZ>>Если проц позволит обходить проблемы софта — ура процу.
AVK>А позволяет ли?
Если быстрее работает то, что работало медленнее — да. Если я нажму F5 и не буду знать чем заняться 5 секунд — плохо. Если время на сборку проекта уменьшится вдвое — уровень комфорта возрастёт на порядок.

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

XZ>> и не даст ли это выигрыша при распараллеливании?
AVK>Не даст. Выигрыш при распараллеливании это даст, если несколько потоков жрут процессор одновременно и сильно. У меня на машине такое бывает нечасто — в янусе при синхронизации, при сборке больших проектов в студии. Поэтому выигрышь от второго ядра на текущем софте будет весьма невеликим. А вот, скажем, на сервере rsdn одновременно крутяться 5-6 активных процессов и оба ядра загружены практически полностью. Вот там выигрышь от 2-4 ядер огромный.
Т.е. есть софт, в данном случае, серверный, умеющий выгодно использовать многопроцессорные системы? Есть. А почему? Потому что в серверных решениях такие системы используются уже давно и софт был соответствующим образом написан. Теперь многопроцессорность идёт на десктопы и софт для них тоже будет использовать эти возможности, а раз на десктопах работает софт для той самой "повседневной деятельности," то и выишрыш в использовании на многоядерных процессорах ПО и из этой области не заставит себя долго ждать.

XZ>>С чего вы взяли про смену темы?
AVK>С того, что весь этот тред я пытаюсь сказать одну единственную вещь — на современном софте проку от кучи ядер 0. Требуется весьма основательная переделка софта, чтобы получить от этого значительный выигрышь.
Я говорю то же самое.

XZ>> Если часть системы удастся ускорить, то вся система тоже получит увеличение в производительности.
AVK>Увы, ускорение это на десктопе практически незаметно. Опыт имеется.
Какой же такой опыт, если "требуется весьма основательная переделка софта?"

AVK>>>Да да. Мне это новое веяние, решать технические и научные вопросы путем голосования всегда нравилось. Вобщем, слив засчитан.
XZ>>Это не решение, это форма предположений и прогнозов, которые мы тут строим, изложенная бОльшим количеством людей.
AVK>Какое это имеет отношение к исходной теме? Я не спорю с тем, что когда нибудь мы получим существенный прирост от многопроцессорности. Но на данный момент такого прироста на десктопе нет, сколько б там потоков task manager не показывал.
Да что вы к этому ТМ-у уцепились?! Понятно, что когда общая нагрузка на ядра 0,1%, пофиг, сколько этих ядер там есть. Вот только если сразу двум из этих многих сотен потоков захочется что-то сделать срочно и сразу, двуядерник сделает это дело в два раза быстрее, не заставляя пользователя ждать.

XZ>>Пацанский метод ведения спора. Ни слова по теме, общие фразы, дергание заумных слов с претензией на сложные термины
AVK>Это ты про себя?
Да, забыл упомянуть и такой метод ведения разговора, как "сам дурак."

XZ>> ("composition engine", ах, я в шоке)
AVK>Батенька, composition engine это базовое понятие архитектуры WPF. Если ты не знаешь, что это такое, то не стоит делать столь глубокомысленных выводов по поводу этой технологии, бо ты совершенно не представляешь себе что это такое.
Я про эту "технологию" (вот, блин, мания величия в отрасли — кажный метод, алгоритм или структуру, технологией обзывать) и не заикался, вы её зачем-то подняли.
Ладно, ознакомился. Контролы рендерятся каждый в свой буфер, потом эти растры собираются в экранный буфер, который и отображается на экране. Офигенно сложная вещь, действительно достойная звания "технология".
Здесь распараллелить можно всё и вся. Граф.адаптеры давно количеством конвейеров меряются, потому дело чуть ли не только за драйверами, чтобы использовать эти конвейеры для параллельного рендеринга.

XZ>>, безапелляционная вера в собственный авторитет и неприятие самой возможности существования других мнений.
AVK>О, переход на личности. Правильной дорогой идете, товарищь.
Хде? Вы что-то себе навоображали...

XZ>>А за всем стоит элементарный снобизм. "Ах, я, суперспец, 10 лет обучения, 20 лет в отрасли, колоссальный опыт разработки, а эти долбаные железячники выкатывают процессоры, на которых скоро троечник-школьник-недоучка на корявом бэйсике сможет решить задачу, которую двадцать лет назад приходилось писать на ассемблере, оптимизируя каждую командочку, перелопачивать тонны справочников и спец-литературы, будучи крайне редким и ценным специалистом. А ведь ещё появятся новые архитектуры, новые задачи, это ж опять всё изучать-переучивать, ах как лень уже."
AVK>Эк тебя задело. Заметь, я ничего этого не говорил .
Это просто такой вот черновой психоанализ всего "диалога". Задело-то не меня, мне учиться в кайф.

XZ>>Я же предположу, что в ближайшие коды ещё появятся лейбочки на софте типа "64-bit architecture compatible" и "Optimized for Quad-Core Processors".
AVK>Опять тему меняешь? Напоминаю тебе твое же высказывание, на которое я отвечал, еще раз:
AVK>

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

Так что вы настаиваете на этой моей фразе и именно по ней спорите, прямо уцепившись в неё зубами?... Ума не приложу...
А-а, нашёл, прочитал. Я просто улыбаюся. Во-первых, там стоял смайлик — цитируйте и его тогда уж. Во-вторых, в целом я там как раз и выразил здоровый скепсис относительно этих революций, технологий и поколений, аргументированный, кстати, упоминаниями о решении тех же повседневных задач на заведомо более медленном оборудовании, затронув проблему усложнения рекламирования и продавания очередного чуда техники рядовому пользователю взамен недавно купленного и прекрасно работающего, упоминанием 793 потоков, безвозмездно подсказав маркетологам путь продвижения технологии в массы. Пускай двигают, мне это даже интереснее — будет ширше рынок для сбыта продукции с моей деляночки. Вы же, я вижу, восприняли всё всерьёз и бросились опровергать, тут-то тема и сползла.

AVK>Постоянные попытки перевести спор на обсуждение самой возможности распараллеливания я иначе как слив расценить не могу.
"Слив" — пацанское слово.

Здравствуйте, jhfrek, Вы писали:

J>Здравствуйте, AndrewVK, Вы писали:

AVK>>>>Ну вот в данный момент, к примеру, у меня ничего в фоне процессор не жрет.
XZ>>>Из чего это видно?
AVK>>Из того, что загрузка процессора = 0.

J>Кстати, безотносительно к предмету вашего спора, почему бывает что Таск Менеджер показывает что 99% времени работает System Idle (то есть система вроде бездействует), но при этом на внешние воздействия Винда не реагирует?

какой нить lock в ядре — часто такое бывает когда вынь сбрасывает или читает что нить большое из свопа.

Здравствуйте, Xander Zerge, Вы писали:

XZ>Пара ядер его бы исправила, может быть.

А может и нет.

AVK>>Что, мало утилит?
XZ>Если утилита работает — уже не ноль.

Ну 0.001. Это ничего не меняет.


XZ>Видел сам своими глазами. Специально полез в эту папочку — открывается и листается. Может, конечно, ещё почему, но винт — вряд ли, это точно

На основании чего такой вывод сделал?

AVK>>Софт. А что?
XZ>Ускоряем софт низкого уровня в гуе — ускоряем сам гуй.

DirectX сам по себе процессор почти не жрет, если не занимается эмуляцией недостающих фич на видеокарте. Жрет прикладной код.

XZ>>>Если проц позволит обходить проблемы софта — ура процу.
AVK>>А позволяет ли?
XZ>Если быстрее работает то, что работало медленнее — да.

А работает ли быстрее?

XZ> Если я нажму F5 и не буду знать чем заняться 5 секунд — плохо. Если время на сборку проекта уменьшится вдвое — уровень комфорта возрастёт на порядок.

Не уменьшается. Я опыты проводил (C#). А вот от страйпа компиляция в студии скоряется на десятки процентов. Делай выводы.

AVK>>Я кажется уже говорил — практически всегда потоки в современном софте используют для ожидания отклика от медленных устройств — сети, жесткого диска и т.п.
XZ>Современный софт писался под однопоточный процессор, поэтому дополнительные потоки решали такие задачи.

А речь про современный софт и идет. Ты ведь утверждал, что ничего специально параллелить не надо, не так ли?

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

Вот когда войдут, тогда и поговорим. А в настоящее время все намного печальнее.

XZ>Т.е. есть софт, в данном случае, серверный, умеющий выгодно использовать многопроцессорные системы?

Да.

XZ> Есть. А почему? Потому что в серверных решениях такие системы используются уже давно и софт был соответствующим образом написан.

Так и есть.

XZ> Теперь многопроцессорность идёт на десктопы и софт для них тоже будет использовать эти возможности, а раз на десктопах работает софт для той самой "повседневной деятельности," то и выишрыш в использовании на многоядерных процессорах ПО и из этой области не заставит себя долго ждать.

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

AVK>>С того, что весь этот тред я пытаюсь сказать одну единственную вещь — на современном софте проку от кучи ядер 0. Требуется весьма основательная переделка софта, чтобы получить от этого значительный выигрышь.
XZ>Я говорю то же самое.

Нет, ты как раз заявил, что у тебя 700 потоков уже есть и ничего специально параллелить не нужно.

AVK>>Увы, ускорение это на десктопе практически незаметно. Опыт имеется.
XZ>Какой же такой опыт, если "требуется весьма основательная переделка софта?"

Опыт использования существующего софта. Что ты постоянно норовишь от темы уйти?

AVK>>Какое это имеет отношение к исходной теме? Я не спорю с тем, что когда нибудь мы получим существенный прирост от многопроцессорности. Но на данный момент такого прироста на десктопе нет, сколько б там потоков task manager не показывал.
XZ>Да что вы к этому ТМ-у уцепились?!

Я уцепился? Мне кажется, это ты о нем упоминал.

XZ> Понятно, что когда общая нагрузка на ядра 0,1%, пофиг, сколько этих ядер там есть.

Ну слава богу.

XZ>Я про эту "технологию" (вот, блин, мания величия в отрасли — кажный метод, алгоритм или структуру, технологией обзывать)

Метод, алгоритм? Все таки почитай про WPF, оно полезно, особенно если планируешь для Windows программы разрабатывать.

XZ>Ладно, ознакомился. Контролы рендерятся каждый в свой буфер, потом эти растры собираются в экранный буфер, который и отображается на экране. Офигенно сложная вещь, действительно достойная звания "технология".

И ничего то вы не поняли

XZ>Здесь распараллелить можно всё и вся.

Там уже вся и все распараллелено. Но не на уровне CPU, а на уровне GPU. В процессор там упирается только рендеринг шрифтов. Но тут скорее новые видеожелезки это делать научаться, чем все дружно перейдут на многоядерники. В видеокарте параллельность естественнее и дается значительно меньшей ценой.
Главное другое — milcore рабоатет асинхронно, соотв. реакция на действия пользователя будет быстрой, вне зависимости от загрузки и скорости видеокарты. А вот сам пользовательский код, из-за требований совместимости с STA ActiveX, будет однопоточным и параллелить опять придется руками, через DispatcherObject.

XZ>>>, безапелляционная вера в собственный авторитет и неприятие самой возможности существования других мнений.
AVK>>О, переход на личности. Правильной дорогой идете, товарищь.
XZ>Хде? Вы что-то себе навоображали...



AVK>>Эк тебя задело. Заметь, я ничего этого не говорил .
XZ>Это просто такой вот черновой психоанализ всего "диалога".

Сэр психоаналитик? Боюсь разочаровать, но со стороны это похоже не на психоанализ, а на истерику.

AVK>>Опять тему меняешь? Напоминаю тебе твое же высказывание, на которое я отвечал, еще раз:
AVK>>

А чего там стараться? У меня ТМ показывает 793 потока. Ещё есть куда распараллеливаться.

XZ>Так что вы настаиваете на этой моей фразе и именно по ней спорите, прямо уцепившись в неё зубами?

Естественно я регулярно пресекаю твои попытки уйти от темы. То, похоже, давно понял, что не прав, вот и юлишь постоянно.

XZ>А-а, нашёл, прочитал. Я просто улыбаюся. Во-первых, там стоял смайлик — цитируйте и его тогда уж.

Через буфер не копируется.

XZ> Во-вторых, в целом я там как раз и выразил здоровый скепсис относительно этих революций, технологий и поколений,

Ух ты. А в приведенной фразе звучит прямо обратное.

AVK>>Постоянные попытки перевести спор на обсуждение самой возможности распараллеливания я иначе как слив расценить не могу.
XZ>"Слив" — пацанское слово.

Зато точно отражает суть.

> Там уже вся и все распараллелено. Но не на уровне CPU, а на уровне GPU. В процессор там упирается только рендеринг шрифтов. Но тут скорее новые видеожелезки это делать научаться, чем все дружно перейдут на многоядерники. В видеокарте параллельность естественнее и дается значительно меньшей ценой.
> Главное другое — milcore рабоатет асинхронно, соотв. реакция на действия пользователя будет быстрой, вне зависимости от загрузки и скорости видеокарты. А вот сам пользовательский код, из-за требований совместимости с STA ActiveX, будет однопоточным и параллелить опять придется руками, через DispatcherObject.

На счет "требований совместимости с STA ActiveX" можно поподробнее?

M>>Инсталятор — хорошо, но не совсем верно. Во-первых, инсталятор, оптимизирующий под конкретную платформу — это, как я понимаю, компилятор? С чего в чего? Кто его автор? Каковы условия распространения?

DC>Я думаю что все таки оптимизатор промежуточного кода. Возможен вариант разработки и встойки такого API в ОС. Возможно это будет отдельная программа (или билиотека) от производителя компилятора, которая встраивается в инсталятор.

То есть компиляторы под форточки только из Редмонда будут?

M>>Так что не совсем у Вас хорошее решение.
M>>Но если искать оптимальное — то упершься либо в фреймворки, либо в языки, заточенные под эту ситуацию (где всё вынесено в рантайм).

DC>Вообще тут нверно будет такая ситуация, что ОС все потоки что найдет будет распределять м-ду потоками управления тут врядли возникнет проблема с разным количеством ядер. Есть ресурс, значит запихнем, нет ну и хрен с ним. Тут, скорее всего сами средства изменятся, как уже говорил Влад. И если кмитет по стандартизации С++ это не учтет, то следующие 10 лет опять будем на велосипедах ездить. Хотя и сейчас полно библиотек для работы с нитями.

Ось и сейчас распределяет потоки по процессорам. Только вот есть у нас N-процессорник. И есть задача, которую можно разбить на M > N примерно равных частей (и достаточно больших, чтобы весь этот огород городить). Насколько частей бить то будем ее? На M? Плохо — у нас будет M-N ЛИШНИХ активных потоков, активно конкурирующих за ресурсы процессора. За что мы будем платить context switching-ом со всеми вытекающими. Все же оптимальнее сразу задачу бить на N потоков, которые будут сидеть каждый на своем проце и не мешать друг другу.
Хоть задачка это, млин, еще та. У нас выравнивание нагрузки на ноды (как процессоры, так и машины в кластере) очень неприятной задачей является в нашем функциональном проекте...

Здравствуйте, Sergey, Вы писали:

S>На счет "требований совместимости с STA ActiveX" можно поподробнее?

Информация не из первых рук, поэтому вкратце: требование соместимости с ActiveX, особенно с WebBrowser Control, по утверждениям МС, явилось причиной того, что весь WPF работает в STA.

Здравствуйте, mik1, Вы писали:

M>>>Инсталятор — хорошо, но не совсем верно. Во-первых, инсталятор, оптимизирующий под конкретную платформу — это, как я понимаю, компилятор? С чего в чего? Кто его автор? Каковы условия распространения?

DC>>Я думаю что все таки оптимизатор промежуточного кода. Возможен вариант разработки и встойки такого API в ОС. Возможно это будет отдельная программа (или билиотека) от производителя компилятора, которая встраивается в инсталятор.

M>То есть компиляторы под форточки только из Редмонда будут?
Ммм.. А что их только микрософт делает?

M>>>Так что не совсем у Вас хорошее решение.
M>>>Но если искать оптимальное — то упершься либо в фреймворки, либо в языки, заточенные под эту ситуацию (где всё вынесено в рантайм).

DC>>Вообще тут нверно будет такая ситуация, что ОС все потоки что найдет будет распределять м-ду потоками управления тут врядли возникнет проблема с разным количеством ядер. Есть ресурс, значит запихнем, нет ну и хрен с ним. Тут, скорее всего сами средства изменятся, как уже говорил Влад. И если кмитет по стандартизации С++ это не учтет, то следующие 10 лет опять будем на велосипедах ездить. Хотя и сейчас полно библиотек для работы с нитями.

M>Ось и сейчас распределяет потоки по процессорам. Только вот есть у нас N-процессорник. И есть задача, которую можно разбить на M > N примерно равных частей (и достаточно больших, чтобы весь этот огород городить). Насколько частей бить то будем ее? На M? Плохо — у нас будет M-N ЛИШНИХ активных потоков, активно конкурирующих за ресурсы процессора. За что мы будем платить context switching-ом со всеми вытекающими. Все же оптимальнее сразу задачу бить на N потоков, которые будут сидеть каждый на своем проце и не мешать друг другу.

Ну дык мы и сейчас так платим только на одно ядро . А вообще говоря, тут либо сам на нити бьешь и задаешь все жестко, либо даешь компилятору(оптимизатору?) рекомендации в виде пометки блоков кода безопасных для параллельного выполнения, и он уже сам распараллеливает под конкретную платформу. Те если кусок кода(функция) не зависит от выполняющейся пихает в свободное ядро, в противном случае выполняет дальше. Такой подход лучше применим к ФЯ, но и для ООЯ тоже может быть применен. Я других путей не вижу. Хотя в итоге может быть и комбинация.

M>Хоть задачка это, млин, еще та. У нас выравнивание нагрузки на ноды (как процессоры, так и машины в кластере) очень неприятной задачей является в нашем функциональном проекте...

Здравствуйте, Sergey, Вы писали:

S>На счет "требований совместимости с STA ActiveX" можно поподробнее?

Информация не из первых рук, поэтому вкратце: требование соместимости с ActiveX, особенно с WebBrowser Control, по утверждениям МС, явилось причиной того, что весь WPF работает в STA.

Здравствуйте, AndrewVK, Вы писали:

XZ>>Видел сам своими глазами. Специально полез в эту папочку — открывается и листается. Может, конечно, ещё почему, но винт — вряд ли, это точно
AVK>На основании чего такой вывод сделал?
У меня — RAID, на том компе — одиночный. Потом такой объём файлов должен читаться за полсекунды от силы — их немного, и они небольшие... Полез замерять — только открыл папочку — замерзает всё секунд на 3-4. Каждый пролист — полсекунды раздумий. Он отрисовывает сразу, задумывается, потом только напротив файлов прописывает пиктограммы. И ничего в это время ни нажать, ни тронуть. Было бы второе ядро — другие окошки жили бы себе поживали.

AVK>>>Софт. А что?
XZ>>Ускоряем софт низкого уровня в гуе — ускоряем сам гуй.
AVK>DirectX сам по себе процессор почти не жрет, если не занимается эмуляцией недостающих фич на видеокарте. Жрет прикладной код.
Если. Насколько я помню, сначала выходил DirectX с новыми фичами в софтовой эмуляции, а только после этого видеоадаптеры осваивали их постепенно.
Потом, гуёвая графика — растровая, вектора там немного, тем более 3Д, потому, прежде, чем что-то загонять в железный буфер, это надо нарисовать или загрузить — подготовить, в-общем. Кнопочки, фенечки, рюшечки всякие разные. Это же можно делать в четыре руки.

XZ>>Если быстрее работает то, что работало медленнее — да.
AVK>А работает ли быстрее?
Я упоминал тесты железа на драйверах с оптимизацией под двуядерники. Если интересно, можно поискать.

XZ>> Если я нажму F5 и не буду знать чем заняться 5 секунд — плохо. Если время на сборку проекта уменьшится вдвое — уровень комфорта возрастёт на порядок.
AVK>Не уменьшается. Я опыты проводил (C#). А вот от страйпа компиляция в студии скоряется на десятки процентов. Делай выводы.
Не заточена студия под это дело — процесс компилятора запускается только один. А если зарядить батничек, который сначала pch соберёт, а потом пучками будет модули компилить?

XZ>>Современный софт писался под однопоточный процессор, поэтому дополнительные потоки решали такие задачи.
AVK>А речь про современный софт и идет. Ты ведь утверждал, что ничего специально параллелить не надо, не так ли?
Нет, абсолютно. Я утверждаю обратное, что можно переписать (и перепишут).

XZ>> Когда многоядерные процессоры войдут в обычную практику, софт должен быть готов к этому, поэтому будут решения, позволяющие использовать возможность параллельной вычислительной обработки данных.
AVK>Вот когда войдут, тогда и поговорим. А в настоящее время все намного печальнее.
Тенденции последних лет говорят о том, что софтописатели получают железо в виде сэмплов много раньше потребителей, потому задержки получаются минимальными.

XZ>> Теперь многопроцессорность идёт на десктопы и софт для них тоже будет использовать эти возможности, а раз на десктопах работает софт для той самой "повседневной деятельности," то и выишрыш в использовании на многоядерных процессорах ПО и из этой области не заставит себя долго ждать.
AVK>Опыт показывает, что софт меняется очень медленно, значительно медленнее железа. Поддержка многопроцессорности это не такая уж простая задача, как тебе кажется, и требует неслабых инвестиций.
Это мы слышали, Y2K, миллиарды баксов, а то не выживем. Набиваем цену. В принципе, правильно.

AVK>>>С того, что весь этот тред я пытаюсь сказать одну единственную вещь — на современном софте проку от кучи ядер 0. Требуется весьма основательная переделка софта, чтобы получить от этого значительный выигрышь.
XZ>>Я говорю то же самое.
AVK>Нет, ты как раз заявил, что у тебя 700 потоков уже есть и ничего специально параллелить не нужно.
Я говорил не так и по другой теме и вообще эта фраза оторвана от контекста и неправильно истолкована.

AVK>>>Увы, ускорение это на десктопе практически незаметно. Опыт имеется.
XZ>>Какой же такой опыт, если "требуется весьма основательная переделка софта?"
AVK>Опыт использования существующего софта. Что ты постоянно норовишь от темы уйти?
Нет, стоп. Какая тема? Есть опыт, но требуется основательная переделка. Или софт переделан или опыта нет.

AVK>>>Какое это имеет отношение к исходной теме? Я не спорю с тем, что когда нибудь мы получим существенный прирост от многопроцессорности. Но на данный момент такого прироста на десктопе нет, сколько б там потоков task manager не показывал.
XZ>>Да что вы к этому ТМ-у уцепились?!
AVK>Я уцепился? Мне кажется, это ты о нем упоминал.

XZ>> Понятно, что когда общая нагрузка на ядра 0,1%, пофиг, сколько этих ядер там есть.
AVK>Ну слава богу.

XZ>>Я про эту "технологию" (вот, блин, мания величия в отрасли — кажный метод, алгоритм или структуру, технологией обзывать)
AVK>Метод, алгоритм? Все таки почитай про WPF, оно полезно, особенно если планируешь для Windows программы разрабатывать.
О да, я эту "технологию" помню ещё по спектрумам. Тогда это называлось "спрайтовой анимацией."

XZ>>Ладно, ознакомился. Контролы рендерятся каждый в свой буфер, потом эти растры собираются в экранный буфер, который и отображается на экране. Офигенно сложная вещь, действительно достойная звания "технология".
AVK>И ничего то вы не поняли
Я-то всё понял правильно, а уж чего вы там туману над этим нагоняете, мне уже неинтересно... "Технология", надо же!..

XZ>>Здесь распараллелить можно всё и вся.
AVK>Там уже вся и все распараллелено. Но не на уровне CPU, а на уровне GPU. В процессор там упирается только рендеринг шрифтов. Но тут скорее новые видеожелезки это делать научаться, чем все дружно перейдут на многоядерники. В видеокарте параллельность естественнее и дается значительно меньшей ценой.
Это чем это она естественнее ЦП? Не тем ли, что под неё заложились достаточно быстро, сделав ставку не на гонку частот, а на распараллеливание операций?
AVK>Главное другое — milcore рабоатет асинхронно, соотв. реакция на действия пользователя будет быстрой, вне зависимости от загрузки и скорости видеокарты. А вот сам пользовательский код, из-за требований совместимости с STA ActiveX, будет однопоточным и параллелить опять придется руками, через DispatcherObject.

AVK>>>Эк тебя задело. Заметь, я ничего этого не говорил .
XZ>>Это просто такой вот черновой психоанализ всего "диалога".
AVK>Сэр психоаналитик? Боюсь разочаровать, но со стороны это похоже не на психоанализ, а на истерику.
Не бойтесь, вы это уже сделали давно. Спор ради спора — неинтересно. А что до анализа — вы бы не вступили, если бы не "зацепило".

AVK>Естественно я регулярно пресекаю твои попытки уйти от темы. То, похоже, давно понял, что не прав, вот и юлишь постоянно.
Опять-двадцать пять! Читать моё исходное сообщение внимательно, с увеличительным стеклом и между строк!
Я вступил в дискуссию в ответ на ваш серьёзный ответ, наткнулся на кучу характерных наездов, попытался отвечать серьёзно, совершенно позабыв о первом своём сообщении и его характере, в чём каюсь.
А юлить, действительно приходится вам, потому как попали вы, многоуважаемый сэр, впросак (между строк: использую вашу риторику и манеру ведения диалога), начав спорить с моим шуточным пассажем про потоки, только сейчас, после пояснений, это поняв.

Я же чётко и прямо заявляю, что (а) многоядерник позволяет выполняться части современного софта быстрее, (б) обеспечивает ту же производительность на меньших частотах, (в) при использовании оптимизированного софта выигрыш в производительности возрастёт, (г) дальнейшее развитие вычислительных систем как в железе, так и в софте — за многоядерностью и параллельностью.

XZ>> Во-вторых, в целом я там как раз и выразил здоровый скепсис относительно этих революций, технологий и поколений,
AVK>Ух ты. А в приведенной фразе звучит прямо обратное.
Между строк! Лупу возьмите. Ну блин, тонко не пошутишь, толсто — ступишь.
Разжёвываю. Прочтите моё упоминание рекламной кампании P4+HT. Дальше — больше, "Пользователь! Твой процессор задыхается от сотен потоков команд! Выкинь его на свалку и купи наш, с 2-мя, с 4-мя, 31-м ядрами, чтоб нагрузка распределилась."

AVK>>>Постоянные попытки перевести спор на обсуждение самой возможности распараллеливания я иначе как слив расценить не могу.
XZ>>"Слив" — пацанское слово.
AVK>Зато точно отражает суть.
Ссуть — не ссуть, а "слив" — пацанва использует. Или та бабка на рынке — и сказать нечего, а последнее слово за собой оставить хочется.
Оставляйте.
(между строк в этом слове написано желание поскорее закончить диалог, причём исключительно в силу отсутствия интереса в дальнейшем его продолжении, но никак не по причине признания ошибочности моих суждений)

> S>На счет "требований совместимости с STA ActiveX" можно поподробнее?
>
> Информация не из первых рук, поэтому вкратце: требование соместимости с ActiveX, особенно с WebBrowser Control, по утверждениям МС, явилось причиной того, что весь WPF работает в STA.

А при чем здесь WebBrowser Control и WPF, если речь идет о DirectX? У всех объектов которого, насколько мне известно, threading model декларируется как both.

> AVK>Не уменьшается. Я опыты проводил (C#). А вот от страйпа компиляция в студии скоряется на десятки процентов. Делай выводы.
> Не заточена студия под это дело — процесс компилятора запускается только один. А если зарядить батничек, который сначала pch соберёт, а потом пучками будет модули компилить?

Занятно А у меня компиляторов при сборке солюшена запускается два. Можно конечно и 4 поставить, но оно и так оба проца зажирает, только при линковке в диск упирается.

DC>>>Я думаю что все таки оптимизатор промежуточного кода. Возможен вариант разработки и встойки такого API в ОС. Возможно это будет отдельная программа (или билиотека) от производителя компилятора, которая встраивается в инсталятор.

M>>То есть компиляторы под форточки только из Редмонда будут?
DC>Ммм.. А что их только микрософт делает?

А что, форточки у нас не только Редмонд делает? Или он в ось ВСТРАИВАТЬ дает?


M>>Ось и сейчас распределяет потоки по процессорам. Только вот есть у нас N-процессорник. И есть задача, которую можно разбить на M > N примерно равных частей (и достаточно больших, чтобы весь этот огород городить). Насколько частей бить то будем ее? На M? Плохо — у нас будет M-N ЛИШНИХ активных потоков, активно конкурирующих за ресурсы процессора. За что мы будем платить context switching-ом со всеми вытекающими. Все же оптимальнее сразу задачу бить на N потоков, которые будут сидеть каждый на своем проце и не мешать друг другу.

DC>Ну дык мы и сейчас так платим только на одно ядро . А вообще говоря, тут либо сам на нити бьешь и задаешь все жестко, либо даешь компилятору(оптимизатору?) рекомендации в виде пометки блоков кода безопасных для параллельного выполнения, и он уже сам распараллеливает под конкретную платформу. Те если кусок кода(функция) не зависит от выполняющейся пихает в свободное ядро, в противном случае выполняет дальше. Такой подход лучше применим к ФЯ, но и для ООЯ тоже может быть применен. Я других путей не вижу. Хотя в итоге может быть и комбинация.

Ну дык и бить ее сейчас нет смысла (на одном ядре). Для N-процессорника наиболее эффективно использование N+1 вычислительного потока (+1 потому что один из потоков да на подкачку страницы и попадет и уснет на это время). И то, этот +1 зависит от машины и размерности данных в задаче. Бывает, он и не нужен.
А Вы уверены, что Вы ЛУЧШИМ образом укажете, что можно параллелить, а что нет? Я бы даже от эксперта не ожидал таких слов слышать для задач сложнее Hello world. В ФЯ эту задачу имеет смысл перепоручать машине. Уровень будет неплохой. А вот в обычном императивном коде тут черт ногу сломит, к сожалению...

Здравствуйте, mik1, Вы писали:

DC>>>>Я думаю что все таки оптимизатор промежуточного кода. Возможен вариант разработки и встойки такого API в ОС. Возможно это будет отдельная программа (или билиотека) от производителя компилятора, которая встраивается в инсталятор.

M>>>То есть компиляторы под форточки только из Редмонда будут?
DC>>Ммм.. А что их только микрософт делает?

M>А что, форточки у нас не только Редмонд делает? Или он в ось ВСТРАИВАТЬ дает?

Погодите, но оптимизируем мы не под форточки, а под железку. Кроме того я имел ввиду либо API, либо утилиту от производителя компилятора. Кроме того кто мешает стороннему производителю использовать API?

M>>>Ось и сейчас распределяет потоки по процессорам. Только вот есть у нас N-процессорник. И есть задача, которую можно разбить на M > N примерно равных частей (и достаточно больших, чтобы весь этот огород городить). Насколько частей бить то будем ее? На M? Плохо — у нас будет M-N ЛИШНИХ активных потоков, активно конкурирующих за ресурсы процессора. За что мы будем платить context switching-ом со всеми вытекающими. Все же оптимальнее сразу задачу бить на N потоков, которые будут сидеть каждый на своем проце и не мешать друг другу.

DC>>Ну дык мы и сейчас так платим только на одно ядро . А вообще говоря, тут либо сам на нити бьешь и задаешь все жестко, либо даешь компилятору(оптимизатору?) рекомендации в виде пометки блоков кода безопасных для параллельного выполнения, и он уже сам распараллеливает под конкретную платформу. Те если кусок кода(функция) не зависит от выполняющейся пихает в свободное ядро, в противном случае выполняет дальше. Такой подход лучше применим к ФЯ, но и для ООЯ тоже может быть применен. Я других путей не вижу. Хотя в итоге может быть и комбинация.

M>Ну дык и бить ее сейчас нет смысла (на одном ядре). Для N-процессорника наиболее эффективно использование N+1 вычислительного потока (+1 потому что один из потоков да на подкачку страницы и попадет и уснет на это время). И то, этот +1 зависит от машины и размерности данных в задаче. Бывает, он и не нужен.
M>А Вы уверены, что Вы ЛУЧШИМ образом укажете, что можно параллелить, а что нет? Я бы даже от эксперта не ожидал таких слов слышать для задач сложнее Hello world. В ФЯ эту задачу имеет смысл перепоручать машине. Уровень будет неплохой. А вот в обычном императивном коде тут черт ногу сломит, к сожалению...

Я могу выделить участки кода которые могут выполняться независимо, кроме того для этого не так трудно сделать анализатор с возможностью указания не только независимых участков, но и слабо зависимых.
Что-то вроде того:

may_be_parallel
{
res1 = fun1();
res2 = fun2();
...
}
mega_fun(res1,res2,...);

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

Здравствуйте, Xander Zerge, Вы писали:

AVK>>DirectX сам по себе процессор почти не жрет, если не занимается эмуляцией недостающих фич на видеокарте. Жрет прикладной код.
XZ>Если. Насколько я помню, сначала выходил DirectX с новыми фичами в софтовой эмуляции, а только после этого видеоадаптеры осваивали их постепенно.

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

XZ>Потом, гуёвая графика — растровая, вектора там немного, тем более 3Д, потому, прежде, чем что-то загонять в железный буфер, это надо нарисовать или загрузить — подготовить, в-общем. Кнопочки, фенечки, рюшечки всякие разные. Это же можно делать в четыре руки.

"Кнопочки, фенечки, рюшечки всякие разные" существуют на уровне PresentationCore, который однопоточный. А на уровне milcore есть только composition nodes.

AVK>>Не уменьшается. Я опыты проводил (C#). А вот от страйпа компиляция в студии скоряется на десятки процентов. Делай выводы.
XZ>Не заточена студия под это дело

О!

XZ> — процесс компилятора запускается только один. А если зарядить батничек, который сначала pch соберёт, а потом пучками будет модули компилить?

С++ не пользуюсь.

AVK>>А речь про современный софт и идет. Ты ведь утверждал, что ничего специально параллелить не надо, не так ли?
XZ>Нет, абсолютно. Я утверждаю обратное, что можно переписать (и перепишут).

Понятно, тема ушла окончательно. На сем предлагаю завязать. Дисскуссию на несколько более приличном уровне можешь продолжить в топике Многопоточность, параллелизм

Автор: Mamut
Дата: 29.09.06

.

AVK>>Вот когда войдут, тогда и поговорим. А в настоящее время все намного печальнее.
XZ>Тенденции последних лет говорят о том, что софтописатели получают железо в виде сэмплов много раньше потребителей, потому задержки получаются минимальными.

Да ну? То то я гляжу что рендеринг десктопной графики на базе ресурсов 3D акселератора, который аппаратно был возможеш на карточках уровня TNT2, в виндах в релизе появится хорошо если к концу года. При том что идее 100 лет в обед.

AVK>>Нет, ты как раз заявил, что у тебя 700 потоков уже есть и ничего специально параллелить не нужно.
XZ>Я говорил не так и по другой теме

А я про эту другую тему только и говорю, в отличие от. Я именно на эту фразу и отвечал.

XZ> и вообще эта фраза оторвана от контекста и неправильно истолкована.

Нет там никакого контекста. На этой фразе ты начал и закончил абзац.

AVK>>Опыт использования существующего софта. Что ты постоянно норовишь от темы уйти?
XZ>Нет, стоп. Какая тема?

Твое сообщение, на которое я изначально ответил.

AVK>>Метод, алгоритм? Все таки почитай про WPF, оно полезно, особенно если планируешь для Windows программы разрабатывать.
XZ>О да, я эту "технологию" помню ещё по спектрумам. Тогда это называлось "спрайтовой анимацией."

Почитай сначала, потом выводы будешь делать.

AVK>>И ничего то вы не поняли
XZ>Я-то всё понял правильно

Силен. Мне, так не один час понадобилось разобраться хотя бы с основами.

XZ>, а уж чего вы там туману над этим нагоняете, мне уже неинтересно... "Технология", надо же!..

Ты даже не представляешь объем работ, который был проделан МС при создании WPF.

AVK>>Там уже вся и все распараллелено. Но не на уровне CPU, а на уровне GPU. В процессор там упирается только рендеринг шрифтов. Но тут скорее новые видеожелезки это делать научаться, чем все дружно перейдут на многоядерники. В видеокарте параллельность естественнее и дается значительно меньшей ценой.
XZ>Это чем это она естественнее ЦП?

Тем что там под нее все заточено изначально.

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

Нет, тем что графические задачи специфичнее универсальных, соотв. и железо можно сделать более узкозаточенным, а, следовательно, более простым при той же производительности. Это сейчас шейдеры появились. А до этого каждый параллельный блок практически ничего, кроме примитивнейшей задачи, не умел. Синхронизация, в частности, обеспечиваесть серьезными ограничениями на способ межблочного взаимодействия и рассчетом на то, что это самое межблочное взаимодействие в решаемых задачах практически отсутствует.
Даже сейчас применение всего лишь условного ветвления в шейдерах резко снижает их скорость. А ты говоришь ЦП.

AVK>>Сэр психоаналитик? Боюсь разочаровать, но со стороны это похоже не на психоанализ, а на истерику.
XZ>Не бойтесь, вы это уже сделали давно. Спор ради спора — неинтересно. А что до анализа — вы бы не вступили, если бы не "зацепило".

Опять же разочарую — не зацепило. Всего лишь намекнул, что истерика и переход на личности здесь неуместны.

XZ>Опять-двадцать пять! Читать моё исходное сообщение внимательно, с увеличительным стеклом и между строк!

Между строк при желании можно поэму Пушкина прочесть. Так что в лес. Мысль была высказана вполне внятно.

XZ>Я же чётко и прямо заявляю, что (а) многоядерник позволяет выполняться части современного софта быстрее, (б) обеспечивает ту же производительность на меньших частотах, (в) при использовании оптимизированного софта выигрыш в производительности возрастёт, (г) дальнейшее развитие вычислительных систем как в железе, так и в софте — за многоядерностью и параллельностью.

Круто. Главное — ни малейшего отношения к теме.

XZ>>> Во-вторых, в целом я там как раз и выразил здоровый скепсис относительно этих революций, технологий и поколений,
AVK>>Ух ты. А в приведенной фразе звучит прямо обратное.
XZ>Между строк! Лупу возьмите.

Взял. Между строк обнаружены только белые пиксели. Так что отмазка не катит.

XZ>(между строк в этом слове написано желание поскорее закончить диалог, причём исключительно в силу отсутствия интереса в дальнейшем его продолжении, но никак не по причине признания ошибочности моих суждений)

Здравствуйте, Sergey, Вы писали:

S>А при чем здесь WebBrowser Control и WPF, если речь идет о DirectX?

С чего ты взял? Речь шла именно про новый супер-пупер интерфейс Висты, который собственно WPF и есть. А DirectX это уже частности.

S> У всех объектов которого, насколько мне известно, threading model декларируется как both.

WPF напрямую с DirectX не работает, только через milcore.

Здравствуйте, mik1, Вы писали:

M>Малюсенькая ремарочка. Паралелить надо не на заранее известное число потоков. Паралелить надо на кол-во потоков на каждой конкретной машине пользователя. У кого-то дома может быть одноядерник, а у кого-то два оптерона двухядерных в одном корпусе живут. У одного один проц, у другого — 4. Поэтому механизм разбиения должен быть либо в компиленном коде, либо это должен быть интерпртатор, сразу пляшущий от числа доступных процессоров (доступных свободных процессоров в идеальном случае).


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

Здравствуйте, AndrewVK, Вы писали:

AVK>Понятно. Слышал звон, не знаю где он.

Самокритично

Здравствуйте, Klapaucius, Вы писали:

K>Какой же из всего этого следует вывод?
K>В чем я мог ошибиться?

А какой был язык?

С таким новым вордом я не работал, но вот к версиям постарее я как-то писал profftools И они таки звались на другой нити

> S>А при чем здесь WebBrowser Control и WPF, если речь идет о DirectX?
>
> С чего ты взял? Речь шла именно про новый супер-пупер интерфейс Висты, который собственно WPF и есть.

А, ну тогда ладно. Мне то просто глаз резануло утверждение, что де ActiveX'ы да и DirectX кроме как в STA работать не умеют по определению.

> А DirectX это уже частности.
>
> S> У всех объектов которого, насколько мне известно, threading model декларируется как both.
>
> WPF напрямую с DirectX не работает, только через milcore.

Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF

Здравствуйте, AndrewVK, Вы писали:

AVK>Не знаю что ты там заметил. Современный GUI на 99% однопоточный принципиально, так что все работает на одном ядре. В новом сервере rsdn 4 ядра, но никакой разницы для пользователя в скорости реакции интерфейса по сравнению с равночастотным одноядерником не наблюдается.

AVK>А в висте, гы-гы, интерфейс тоже однопоточный. Даже WPF.


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

Здравствуйте, Sergey, Вы писали:

S>Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF

Кто тебе сказал, что user многопоточный? Где ты окно создал, там его и используй, иначе будут глюки. А аналог GDI в WPF многопоточный.

> S>Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF
>
> Кто тебе сказал, что user многопоточный?

А кто тебе сказал, что он однопоточный.

> Где ты окно создал, там его и используй, иначе будут глюки.

Ни разу не было. Что я делал не так?

> А аналог GDI в WPF многопоточный.

Я таки надеюсь, они со временем и всю WPF на многопоточную переделают.

Здравствуйте, Sergey, Вы писали:

>> S>Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF
>>
>> Кто тебе сказал, что user многопоточный?

S>А кто тебе сказал, что он однопоточный.

А ты попробуй. Я как то давно по неопытности пробовал . Хотя некоторые моменты прокатывают. Например смена значения у прогресс-бара. Но вобще то любое обращение нужно перекидывать не напрямую, а через message loop.

>> А аналог GDI в WPF многопоточный.

S>Я таки надеюсь, они со временем и всю WPF на многопоточную переделают.

Ранние беты были многопоточными. А сейчас он на попытку работы из другого потока без диспатчера делает кислую рожу. Так что пока не будет управляемой версии браузера, надеятся не стоит. Хотя конечно бог его знает, что там послужило настоящей причиной этих финтов ушами. Swing вон, к примеру, значительно более толерантен к потокам и ничего.
С другой стороны, не так уж и сильно это нужно. Рендеринг с анимацией сделали асинхронным и слава богу. А для фоновых процессов и существующей механики работы через message loop хватает.

Здравствуйте, Guard, Вы писали:

G>Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные.
G>...[skip]...
G>Таким образом, интересно, когда это наступит для повседневных задач (Gnu CC, Word, Netsurfing, etc). Кто что думает?

Я думаю, сначала придется решать проблему с медленной RAM. В подавляющем большинстве случаев выходит так, что нужно прожевать большой объем данных, а не гонять по кругу несколько чисел. В этом случае шина данных забивается моментально, например на двухпроцессорной Xeon тачке, где два процессора лезут в память по одной шине, распараллеливание задач обработки изображеий обычно давало выигрыш в 1.5 — 1.6 раз, не больше. Отсюда следует, что пока есть узкое место в виде доступа к RAM, могоядерность не имеет особого смысла. Вот когда осовная RAM приблизится по своим параметрам к кэш памяти, вот тогда будет круто.
В случае с AMD64 процами — подход со встроенным контроллером памяти и NUMA архитектурой мне нравится. Но я так и непонял как из виндов положить данные для задачи в память процессора, на котором исполняется эта задача.

DC>Я могу выделить участки кода которые могут выполняться независимо, кроме того для этого не так трудно сделать анализатор с возможностью указания не только независимых участков, но и слабо зависимых.
DC>Что-то вроде того:
DC>

DC>may_be_parallel
DC>{
DC>res1 = fun1();
DC>res2 = fun2();
DC>...
DC>}
DC>mega_fun(res1,res2,...);
DC>

DC>Упрощенно, но что-то в этом духе, по-моему в Аде такие языковые конструкции есть. А компилятор уже сам решает как это разбить.

Ну, если не сичтать того, что fun1 может изменять значения каких-нить глобальных переменных (ну или полей нашего класса), а fun2 их читать — то да, такое можно параллелить. Правда остается вопрос в вычислительной сложности этих функций. А то мы за создание нового потока заплатить дороже можем...

E>Собственно в реальных задачах всёвыходит ровно наоборот.
E>Типа еужно параллелить не самый вложенный цикл, а самый внешний.
E>Скажем в архиваторе хорошо бы раздать потокам файлы или куски файла, а потом они будут жать, каждый свой кадр совершенно независимо.
E>Соответсвенно как это делать на уровне компилятора/интерпретатора --

Интерпретатора — легко. Глянул, сколько процов есть, разбил цикл на M/N (М-сколько итераций, N — сколько процов) частей и работай себе. Многие так ручками и пишут. С архиваторами пример, правда, не показательный. Там за счет ускорения степень сжатия уменьшится. Словарь каждому потоку придется набирать самостоятельно.

Здравствуйте, Guard, Вы писали:

G>Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные. Что мы обычно имеем при таком

Четко прослеживается тенденция к переходу на параллельные приложения и на Intel software network.
Например http://or1cedar.cps.intel.com/ISN/Community/en-US/blogs/for_developers/archive/2006/09/15/30223958.aspx

>>> S>Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF
>>>
>>> Кто тебе сказал, что user многопоточный?
>
> S>А кто тебе сказал, что он однопоточный.
>
> А ты попробуй.

сто раз пробовал

> Я как то давно по неопытности пробовал .

И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток?

> Хотя некоторые моменты прокатывают. Например смена значения у прогресс-бара.

Замечательно. Таким образом, мы выяснили, что SendMessage и PostMessage вполне себе многопоточны Осталось выяснить, что же конкретно в user, на твой взгляд, не многопоточно... Попробуй назвать хотя бы одну функция для работы с окнами, которую бы требовалось вызывать только из нитки, создавшей окно.

> Но вобще то любое обращение нужно перекидывать не напрямую, а через message loop.

Все что надо винда сама зашлет через message loop. А прикладному программисту при этом дозволяется самому решать, из какой нитки вызывать функции для работы с окнами. А иногда даже — обращаться не только из другой нитки, но и из другого процесса.

>>> А аналог GDI в WPF многопоточный.
>
> S>Я таки надеюсь, они со временем и всю WPF на многопоточную переделают.
>
> Ранние беты были многопоточными. А сейчас он на попытку работы из другого потока без диспатчера делает кислую рожу. Так что пока не будет управляемой версии браузера, надеятся не стоит. Хотя конечно бог его знает, что там послужило настоящей причиной этих финтов ушами.

Я так думаю, настоящей причиной послужила банальная нехватка времени.

Здравствуйте, trophim, Вы писали:

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

Лет 10 назад, мне мой научный руководитель в универе мимоходом рассказал про то, что есть такая область математики, что америкосы вовсю ею занимаются и ухитрились даже процесс сложения двух двоичных чисел распараллелить. ХЗ правда или нет.

Здравствуйте, Sergey, Вы писали:

S>Числомолотилки — не такое уж и ограниченное количество приложений Это, помимо всякого рокет сайнс, и архиваторы, и сжатие видео, и даже игрушки (да и не только игрушки — вообще, любое 3D).

Шифрование забыл. Всякие SSL/TLS/GPG/etc. Куда ж сейчас без этого?

Здравствуйте, Sergey, Вы писали:

S>Почему то мне кажется, что такая теория сродни теории автоматического доказательства корректности программ — вроде бы она и есть, но в практически важных случаях не работает, а потому нафиг ни кому не упала.

Она скорее сродни оптимизации кода, которая вполне даже работает, во вполне даже общих случаях.

> S>Числомолотилки — не такое уж и ограниченное количество приложений Это, помимо всякого рокет сайнс, и архиваторы, и сжатие видео, и даже игрушки (да и не только игрушки — вообще, любое 3D).
>
> Шифрование забыл. Всякие SSL/TLS/GPG/etc. Куда ж сейчас без этого?

Какое-то параллелится, а какое-то не очень. Я, например, не очень себе представляю, как тот же blowfish распараллелить. Там же блок зашифровался — ключик сменился. Потому и не написал.

Здравствуйте, Sergey, Вы писали:

S>И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток?

Я прошу прощения, что встреваю. Доков под рукой нет, возился с этими вещами давно, но разве сама винда не заботится о синхронизации потоков при обращении к окну? Мне что-то смутно помнится, что поток А, обращающийся к окну, созданному в потоке Б, блокируется (то бишь фактически вызов пропускается через message loop).

Здравствуйте, AndrewVK, Вы писали:

skipped

XZ>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.

AVK>У меня не тормозит совсем. Что я делаю не так?

Согласен со всеми утверждениями, кроме этого. Вы неправильно делаете только одно: документы маленькие открываете (на быстрой машине). Когда документ на несколько сот страниц, то при его листании торможение из-за спеллчекера становится очень ощутимым. Я так и не смог отключить спеллчекер — пришлось снесни (все галочки по 10 раз убирал и снова ставил — нифига). Почему-то он у меня всегда(!) активен и тормозит, пёс.

> S>И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток?
>
> Я прошу прощения, что встреваю. Доков под рукой нет, возился с этими вещами давно, но разве сама винда не заботится о синхронизации потоков при обращении к окну?

Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя

> Мне что-то смутно помнится, что поток А, обращающийся к окну, созданному в потоке Б, блокируется (то бишь фактически вызов пропускается через message loop).

Здравствуйте, Sergey, Вы писали:

S>Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя

Я так не считаю и не считал никогда. Вспоминаем о чем собственно топик был — об ускорении на нескольких ядрах. Синхронизация через message loop это не многопоточное выполнение, это именно синхронизация разных потоков. Естественно, что обратиться к существующему окну можно из другого потока. Естественно, в одном приложении можно запустить несколько потоков со своими message loops (в янусе, кстати, вовсю используется). А вот чего нельзя, так это собрать иерархию окон из разных потоков. А без этого говорить об многопоточном UI, имхо, не имеет смысла.

> S>Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя
>
> Я так не считаю и не считал никогда.

Извольте цитату: "Кто тебе сказал, что user многопоточный? Где ты окно создал, там его и используй, иначе будут глюки."

> Вспоминаем о чем собственно топик был — об ускорении на нескольких ядрах. Синхронизация через message loop это не многопоточное выполнение, это именно синхронизация разных потоков. Естественно, что обратиться к существующему окну можно из другого потока.

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

> Естественно, в одном приложении можно запустить несколько потоков со своими message loops (в янусе, кстати, вовсю используется). А вот чего нельзя, так это собрать иерархию окон из разных потоков.

Тоже можно. Могу пример выложить, если кто не верит.

> А без этого говорить об многопоточном UI, имхо, не имеет смысла.

Еще как имеет.