Здравствуйте, 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. А некоторые алгоритмы не распараллеливаются в принципе.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 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
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
>>> NBN>>через -6 лет. >>> G>Это если бы все поголовно оптимизировали программы. Ну а мы имеем ситуацию, когда большинство программеров не заботятся о качестве кода.. >>> >>> Вообще распараллеливание на уровне операции формализовано и сведено к алгоритму, давно. Т.е. оптимизировать код под N-дцать потоков управления способны только автоматизированные инструменты. Т.е. эти оптимизации напрашиваются в компилятор. >>> >>> ЗЫ Как вы себе представляете распараллеливание вручную на 80 потоков управления, ну или хотя бы 40?? > > S>Вообще-то некоторые алгоритмы легко распараллеливаются вручную хоть на 100, хоть на 1000 потоков. Так же легко, как делается обход массива — не важно, 2 в нем элемента или 2000. А некоторые алгоритмы не распараллеливаются в принципе.
> Угу а весь до этого написанный код вручную распараллеливать??
Весь код, сильно нуждающийся в распараллеливании, уже много лет пишут так, чтоб он работал на произвольном количестве процессоров. Ну а если не написали сразу многопоточно — да, придется либо ручками править, либо забить на возможный выигрыш от возросшего числа ядер. Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.
> Я говорю о том что при большом количестве ядер необходим новый инструмент для автоматического распараллеливания существуюегох кода. И автоматического распараллеливания нового кода при компиляции.
Ну инструмент такой не помешал бы конечно, но и без него жить можно, хотя и не просто. К сожалению, особого прогресса в этой области не заметно.
> Распараллеливать самомому задачу на 80 ядер,
Какая разница — на 2 процессора или на 80? Большинству числомолотилок пофиг, на сколько ядер их разнести (если, конечно, они вообще распараллеливаются). А не-числомолотилкам оно обычно не надо (у них в другом тормоза, как правило).
> это сродни написания на асме современных приложений.
Вы будете смеяться, но до сих пор самым эффективным способом программирования FPU остается ассемблер
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, 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?
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Любой архиватор только выиграл бы, если бы умел распаковывать разные блоки на разных процессорах — но увы, тот же rar больше одного процессора не умеет.
7Zip умеет например
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, 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(не архиватора ) потоков и написание на асме такой утилитки.
Без оговорки о том, о какого рода программе идет речь, ваше сравнение бессмысленно.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Таким образом, интересно, когда это наступит для повседневных задач (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.
Какой же из всего этого следует вывод?
В чем я мог ошибиться?
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, 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 во всех версиях винды однопоточные.
Чего?
.
