Кабал, вы дурак и тратить время на обьсненя дураку - пустое.
Вы путаете многозадачность с многопоточностью. Можно запустить хоть 100 задачь в один поток и всё будет в шеколаде, но многопоточность от этого не появится.
Если вы непонимаете таких простых вещей, то что вы тогда вобще способны понять?

Иван, Вы только что жиденько обсерились
Задача - task. Поток - thread. Расскажите нам, дуракам да неучам, как несколько задач запихнуть в один поток
RTFM живет тут: http://en.wikipedia.org/wiki/Computer_multitasking
Во денек, емана...

Скорее все же быстрее. Типичное решение для улучшения загрузки процессора (и скорости выполнения задачи) - вынос операций ввода/вывода в отдельные потоки. Если процессор системы и так нагружен до 100% это, конечно, ничего не даст. А так, очень неплохо ускоряет программы, которым приходится что-то читать с диска - обрабатывать - писать на диск, например.

Если IO будет - то да, быстрее. А если написать многопоточное вычисление числа Зю с точностью до ХЗ какого знака - то нЭт
Но сдается мне, что все заинтересованные это и так осознают

Хорошо, а если вот какой пример на то, что от многопоточности производительность программы, приложения или некого интерфэйса не увеличивается. Предположим, в некоей фирме есть база данных, и если директору, бухгалтеру и паре торговых агентов вдруг одновременно приспичит к ней обратиться, причем к одинаковым ресурсам в ней, я думаю у базы данных может наступить клинч, если еще и разработчик не предусмотрел подобного варианта. Такой пример пойдет?
Я продолжаю просматривать ресурсы Интернета на поиск примеров, где многопоточность не увеличивает производительность программы - пока все вода водой, одна теория. Говориться о однопоточном WEB-сервере, для которого многопоточность вообще неприемлема (прошу прощения, если это не так -я только недавно изучаю этот предмет и могу говорить очаровательные глупости) - каков может быть пример подобного однопоточного сервера?

А, собственно, на вопрос автора кто отвечать будет? :)

Не могу себе представить веб-сервер для которого многопоточность неприемлима.
Многопоточность не дает никакого выигрыша только в случае невозможности распараллеливания задачи (а таких задач не так уж и много). Т.е. где в каждом последующем шаге поведение программы целиком зависит от ее предыдущего состояния, а состояние в n-ном шаге заранее предсказать нельзя (а то опять же можно было бы распараллелить).
Вот - копирование файла с оптического носителя :)
Сколькими потоками не читай, быстрее не получится :)

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

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

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

Ну, как бы при том, что она предоставляет эту возможность.
Не поддерживают, а используют. Поддерживает (или реализует) ее как раз ОС.
Не очень интересный вопрос, так как цифра запросто может меняться в зависимости от настроек программы или от алгоритма. Что даст тебе эта цифра?
Просто пустой документ - 11 потоков.

если не ошибаюсь, любая написанная с WPF программа уже автоматом изначально 2-поточна.

Об операционке и речи нет так как она итак всё поддерживает и не является узким местом. Тут важно само наличи в железе (процессор) и в программе (исполняющей код) а со средой и так всё в порядке.

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

Пожалуйсто, попробуйте настроить... щяс весь мир бьётся над тем как оптемизировать хотябы тежи игры под большее число потоков, а у вас уже всё просто... ворд на 11 потоков.
Насколько я знаю загрузить худо бедно 4 ядра смогла только GTA4... Да и разбиение на 2 потока ещё не полностью освоено в игровой сфере, а там за каждый мегагерц - борьба.
Ладно с играми. Топовые графические программы не всегда могут распаралелить потоки и в итоге подгатовка к обработки геометрии идёт в один поток на одном ядре из ... любого чесла ядер. А вы тут про 11 потоков в ворде... нафиг оно там надо.

Откуда вы это берёте? Вы вобще вкурсе о чём речь?

Тады ой. Тут уже тебе ссылку на многозадачность давали. Я тогда на многопоточность кину. ru.wikipedia.org/wiki/%D0%9C%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D0%BE%D1%82%D0... Да ты там уже побывал, я смотрю. Но не все прочитал, не все понял.
Если бы ты был в курсе, ты бы знал, откуда я это беру.

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

типо "сам такой"?...
...аргументы исчерпались так и неначавшись (

Хи-хи. Согласно твоей логике, три потока в программе следует делать, когда есть три ядра, а четыре, когда четыре и дальше по аналогии. -))))
Вабще-та, многопоточность имеет смысл всегда, когда нужны легковесные процессы. Хороший пример - высокопроизводительный сервер, где становятся критичными затраты на порождение процессов, обрабатывающие запросы клиентов. По грубым прикидкам, которые любят указывать в литературе, в среде UNIX затрачиваемое время на создание процесса примерно в 100 раз больше, чем на создание потока.

Потоки к ядрам отношения не имеют.

Нет, не пойдёт. Многопоточность и обеспечение целостности БД это как тёплое и мягкое. Первое - инструмент для программиста, второе - цель, которая обеспечивается рядом мер. Биты, байты, вольты и амперы - примерно также нужны для обеспечения целостности БД. Т.е. утверждать, что совсем без них оно всё обходится - не совсем верно, а сказать, что они используются - можно, но бессмысленно. -)

Придумайте сами абсолютно любое действие, выполнение которого не параллелится по потокам и вы приведёте абсолютно корректный пример, где многопоточность ОС не даст никакого выигрыша. Возьмите быструю сортировку массива - действие потенциально отлично распараллеливающееся. Напишите на С фунцкию сортировки, откомпилируйте gcc и вы получите код, которому до лампочки способность ОС создавать потоки.
Короче, абсолютно всё, что написано обычным образом без использования потоков и без использования специальных средств автоматически распараллеливающих однопоточный код по потокам (как пример: Data Parallel Haskell - расширение компилятора языка Haskell, "Glasgow Haskell Compiler", которое параллелит "обычный" код) не получит выигрыша от способности ОС создавать потоки.

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

калькулятора
-----
В Выни98 калькулятор был таки многопоточный - можно было убить
окно, а процесс CALC оставался висеть...

многопоточность имеет смысл только на многопроцессорных системах
в совсем примитивном случае процесс часто ждёт внешних сигналов
-----
Вообще-то, многопоточность вводится тогда, когда надо управлять
процессами обработки. Ожидание внешних сигналов и наличие многих
процессоров - частности. Ибо в больших майнфреймах по одному
процессору и как правило от 4-х до 16-ти задач/процессов/потоков
одновременно...
но сама система в этом случае будет ещё медленнее работать
-----
На том же майнфрейме переключение контекста задачи выполняется
одной командой... так что переключение практически не чувствуется.

Многопоточность присутствует? Присутствует
-----
Не обязательно... в том же наборе х86/87 хотя и два процессора, но только
один поток, с опережающей выборкой команд и свободный ФПП получает их
раньше... а поток - остается один...

Поток - thread.
------
Вообще-то, не только... Вспомни про наличие всеми почитаемого бач-файла...
Там тоже таки потоки...