Здравствуйте, 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 — сколько процов) частей и работай себе. Многие так ручками и пишут. С архиваторами пример, правда, не показательный. Там за счет ускорения степень сжатия уменьшится. Словарь каждому потоку придется набирать самостоятельно.