> 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.