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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сильно.

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

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

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

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

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

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

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

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

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

AVK>

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

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

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

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

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

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

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

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