Скорее все же быстрее.
-----
Все же помимо выполнения самой работы будет присутствовать управление
потоками и переключение между ними. Пусть в одну команду, но будет медленнее...
То, что у себя ты описал ниже, легко реализуется не потоками, а аппаратными
прерываниями - тогда действительно все быстро и без потерь... но это не софт,
а железо...

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

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

Про какой процессор идет речь? в x86 кеш не трогается http://en.wikipedia.org/wiki/Task_State_Segment

первое же предложение
The TSS may reside anywhere in memory.
кеш невозможно оставить. другому потоку нужны свои данные в кеше.

А если они уже в кеше? т.е., примитивно, два потока и их данные полностью умещаются в кеше.

два уместятся, правда и займёт неактивный поток полкеша , чем наполовину снизит его эффективность
а если потоков более 1000 как сейчас на моём компьютере?

Зачем отгружать кеш, если там могут сидеть данные, которые уже не понадобятся никогда и никому? I like to move it, move it?.. Если поток захочет данные и словит промах в кеше, данные подгрузятся. Дешевле обойдется.

Т.е. следуя логике, процессор не должен, а может сменить содержимое кеша.
Для случая с двумя потоками, почему отдельный поток должен занять именно половину кеша? Например один поток требует 100 кб, а второй поток 300 кб.

К чему я веду. Что кеш не связан с переключениекм задач в процессоре напрямую, т.е. при переключении задачи, процессор не меняет принудительно кеш для новой задачи. Читая вашу фразу У читателя складывается впечатление, что кеш обязательно сменится. Кстати кеш в рам никогда не оптравляется, так и до deadlock'а докатититься можно. :-)

А куда же он отправляется, если в элементе данных кэша были сделаны изменения (dirty)?

Согласен. Этот аспект я упустил из виду.

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

Формально он прав. Но в данном примере цель второго потока не в увеличении производительности, а ИМХО в обеспечении "незамерзаемости" интерфейса пользователя и 3-й, 4-й и т.д. потоки с расчетами вполне себе могут поднять производительность. А Вы и все участники дисскуссии ломают голову какую бы труднораспараллеливаемую задачу придумать. :-)
Тогда в дополнение еще пример.
1ый поток - GUI
2ой поток - менеджер рабочих потоков
3..N - рабочие потоки (может зависить от кол-ва ЦПУ)
2-ой поток не повышает производительность, он всего лишь управляет рабочими потоками, так чаще всего удобнее.
Вопрос препа из разряда задачки для дошкольников
1 - 0
2 - 0
6 - 1
8 - 2
9 - 1
11 - ?

0
Я был в детском садике.

Я был в другом... :-)

Я чуствовал, я чесслово чуствовал что препод окажется редкостным ммм... балбесом :)
Единственный неадекватный проф у нас тоже операционные системы читал...
Как уже выше написали прав он только формально. Пример просто ммм.. глупый. Таких примеров можно придумать хоть пиццот мильярдов. Рецепт простой: один поток делает что-то нужное а еще стопиццот потоков рисуют колокольчики, звенять ими и показывают вам картинки котят. От такой многопоточности производительность нашей задачи не повысится, да.

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

А если они уже в кеше?
-----
Врядли. Зависит, разумеется, от проца, но придумать, как управляться с двумя и более потоками в кэше - проблемно. Особенно, если нет аппаратной части для этого...

Явно от такой многопоточности производительность не повысится.
-----
Просто у вас препод, который не имеет достаточного понимания предмета.
Дело в том, что он сравнивает разные по фукциональности задачи:
- расчет _и вывод на экран_
- расчет _только_
такое сравнение просто не корректно. Корректным было бы сравнивать производительность двух програм - решающих одну и ту же задачу (имеющих одну и ту же, в том числе и бесполезную, функциональность), но реализованных в форме одного и нескольких потоков.
Хохмы.
Эээ... Я тут подумал - в принципе и первый поток не нужен - нужен только результат расчета... так что его можно исключить для повышения производительности...
Или... хммм... в Выни есть процесс/поток, который гарантировно не делает _ничего_ полезного - можно предложить преподу выключить ненужный поцесс для увеличения производительности системы... Будет интересен сам процесс и достигнутый результат...

Формально он прав.
-----
Он принципиально не прав. См. выше.