Люди, тону, помогите!
Помогите ответить на вопросы по операционной системе: нужно два примера, когда многопоточность в ОС увеличивает производительность программы, по сравнению с однопоточностью, и два примера, когда многопоточность не увеличивает производительность программы по сравнению с однопоточностью.
Я конечно могу налить теоритической "воды", мол, какая разница между этими двумя понятиями, но преподавателя интересуют конкретные примеры.

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

Sorry, операционка здесь действительно не причем, меня просто ввело в заблуждение общее название предмета.
Ладно, каким образом тот же 3DMax может поддерживать многопоточность - например, обработку какого-нибудь объекта (например, обработка сложной текстуры) можно вывести в фоновый процесс, и, например , параллельно создавать другой объект?

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

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

каким это образом?

Понятия не имею каким образом. На двух ядрах быстрее кодируется, чем на одном.

так это уже многопроцессорность

Что удивляет?

Ну и что? Многопоточность присутствует? Присутствует. Ограничения по колчеству ядер в вопросе нет.

на четырёхядерном проце программа (пусть будет 3Дмакс) загружает всё 4 ядра на 100%. Можно поставить приоритет загрузки проца (в диспечере задач) ниже и открыть паролельно ещё одну программу и спокойно в ней работать.
Также можно (в диспеччере задач) указать какие именно ядра будут трудится над поставленной задачей, например:
У вас происходит кодирование видео, процес не быстрый и может занять всё 4 ядра (не во всех приложениях, но может) в тоже время вам не охото сидеть молча а есть желание поиграть в Крайзис. открываем диспеччер задач, находим процесс отвечающий за кодирование видео (он будет сильно нагружать проц) и настраеваем его на использование ядер 0 и1. ядра 2 и3 остаются свободными. для чего? прально, для отстрелва корейских (американских) захвачиков.
..это пример ы работы с многопоточностью.
Естественно, многопоточность может работать толко на многоядерных (многопроцесорных) системах или системах имитирующих её (напримар технология Hyper-Threading).

Многопоточность может работать везде, где есть само понятие потока С количеством ядер/процессоров не связано.

Я имею в виду полноценную многопоточность а не когда два потока выполняются по очереди. Многопоточность подрозумевает паралельное исполнение.
Многопото́чность - свойство платформы (например, операционной системы, JVM и т. д.) или приложения, состоящее в том, что процесс, порождённый в операционной системе, может состоять из нескольких потоков, выполняющихся ╚параллельно╩, то есть без предписанного порядка во времени.
Так что на одноядерном проце многопоточность не катит. и даже Hyper-Threading помогает работе многопоточных систем но никак не заменят.

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

Иван, ты смотришь в книгу и видишь известную фигуру.

Мнэ. Многопоточность подразумевает исполнение в несколько потоков. :)
Могу рассказать про программку, в которой оказалось удобно сделать много потоков, но не пускать их параллельно. А управлять ими. В любой момент времени активен был только один поток. Из н-цати.

Ну и?..
4 потока:
1-й ждет, когда юзверь ушастый нажмет кнопочку "А".
2-й ждет, когда юзверь ушастый нажмет кнопочку "Б".
3-й ждет, когда юзверь ушастый нажмет кнопочку "В".
4-й - рисует на экране обнаженную женщину.
Прошу указать, где имеет место быть "непараллельность", т.е. предписанный порядок по времени.
Иван, ты кто по образованию и профессии будешь? Просто любопытно...

Ололошеньки-лоло
Иван, сколь давно появились многоядерные процессоры / многопроцессорные системы, доступные обывателю?

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

Кабал, вы дурак и тратить время на обьсненя дураку - пустое.
Вы путаете многозадачность с многопоточностью. Можно запустить хоть 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.
------
Вообще-то, не только... Вспомни про наличие всеми почитаемого бач-файла...
Там тоже таки потоки...

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

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

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

Про какой процессор идет речь? в 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
Я был в детском садике.

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

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

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

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

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

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

И процесс, и результаты бенчерами пережёваны и проглочены мульён раз.
Для получения максимально возможного результата в СуперПи нужно:
- оставить в вине ХР только 4 процесса, остальные, в т.ч. проводник, выключаются. Выкл. (вроде бы... забыл точно, какой именно) userinit.exe вызывает shutdown, против чего помогает команда "shutdown a";
- очистить память от мусора, для чего обычно копируется файл большого размера. Я запускал для этого прогу memTest, занимающую 90% памяти;
- дать приоритет реального времени superpi.exe.
Данные мероприятия дают в SuperPi 1M выигрыш в десятые доли секунды (при результатах порядка 10с). На рабочей винде с кучей запущенных прог резалт будет хуже на 1-2 с.
Кстати, SuperPi - автору хороший пример однопоточной проги, количество ядер CPU никак не сказывается на скорости вычисления.
Хороший пример четырёхпоточной проги - SMP-Slient F@H, одна work unit обрабатывается 4-мя параллельно работающими процессами, наибольшая скорость вычислений получается при привязывании каждого процесса к отдельному ядру 4-хъядерного процессора - так оптимальнее всего используется кэш.

Ой, как сложно!!!
Я то всего лишь предлагал убить System Idle Process, пожирающий до 99% процессорного ресурса компа...

А чёрт, а я и не допёр

Задание в интерпретации топикстартера звучит

Ваш ответ

В задании я не вижу слов "сравнение", "сравнить" и пр. синонимы. Надо предоставить 4-е примера. Все. Что делают потоки и какая у них должна быть функциональность ни слова, поэтому ответ-намек проподавателя формально (см. ru.wikipedia.org/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0...) корректен.
Слова "формально" и "принципиально" - не антонимы, так же как "кисло" и "мягко".

два примера, когда многопоточность не увеличивает производительность программы по сравнению с однопоточностью.
-----
так же как "кисло" и "мягко".
-----
Смотри первую из хохм.
Утверждение же преподавателя можно, формально, перефразировать так: Программа с урезанной функциональностью имеет более высокую производительность в части не исключенной из программы. Что вполне корректно.
Однако в контексте же перефразированного ответа преподавателя вполне уместно задать вопрос об том, как правильно рассчитать суммарную производительность, включая производительность исключенной части, системы? Данный вопрос так же корректен, но меняет оценку певоначального утверждения на противоположную, т.к. исключенная часть имеет оценку времни выполнения как бесконечность.
Так что оценка (или сравнение) производительности имеет смысл только при полностью эквивалентной функциональности. В свете примера, данного преподавателем, основной и единственный поток должен осуществлять поминутный вывод на экран и рассчет - тогда можно корректно оценить насколько дополнительный поток "НЕ УВЕЛИЧИВАЕТ" производительность программы.
Думаю, что он умрет (в смысле производительности) на поолинге таймера. По крайней мере у меня, при необходимости обеспечить точность не хуже -5/+10 тиков, поолинг таймера в однопоточной системе легко "съедал" до 20% выч.ресурса... а выполняся по нему именно вывод на экран.

Люди, в общем, я запуталась окончательно(( Я себя таким глухим тетеревом чувствую((

Ну мы, вообще-то, специально говорили простым языком и не пользовались
никакими математическими сложностями...

Ваш текст выше мне непонятет. Выглядит как вырывание выражения из контекста.
Некорректно.
Обозначим производительнось однопоточной программы ака "Программа с урезанной функциональностью" как П1, а многопоточной программы как П2. Тогда вторую часть вопроса записывается как П2 <= П1. Т.е. выражение "не увеличивается" означает, что производительсть обеих программ может быть равна (П2 == П1) и неравенство останеться истинным.
Фраза записывается как П1 > П2. Вы осознанно или неосознанно выбрасываете знак равенства из вопроса. Формально-корректное перефразирование звучит как "Программа с урезанной функциональностью имеет равную или большую производительность в части не исключенной из программы."
Поэтому формально пример преподавателя корректен.

Ваша цитата

Моя цитата

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

ну примеры простые
1. если потоки произошедшие от одного процесса не имеют точек пересечения, т.е. к примеру имеют каждый свою область вычсления, то такой процесс будет работать быстрее чем процесс состояший из одного потока.
пример из жизни. по двухполосной трассе запускают 1000 грузовиков. трасса разделяется на 3 двухполосных ответвления не пересекающиеся между собой и приводящие к одной цели. логично что в таком случае грузовики приедут быстрее чем если бы они все ехали по сплошной однополосной трассе.
2. если потоки произошедшие от одного процесса используют к примеру один и тот же источник информации, т.е. должны ждать друг друга (я не имею ввиду deadlock. я имею ввиду пример когда они ждут сравнительно дольше), то такой процесс будет работать медленее чем процесс состоящий из одного потока.
тот же пример но с 100 перекрестками. я думаю вы поняли о чем я говорю.
программки сами подберите или придумайте что нить.
меня передергивает от перевода поток. поток для меня это stream. thread как то не вписывается в это понятие потока

Некорректно.
-----
Корректно. В любом случае при доступной константной вычислительной мощности Р и распределении ее на Р1.1 + Р1.2 или направлении полностью на Р2.1, Р2.1 будет больше Р1.1, при условии что Р1.2 не ноль... Если же Р не постулируется константной, то говоритьб об корректности бессмысленно...
как П2 <= П1.
-----
На деле все несколько по-другому:
имеется задача З1, состоящая из выполнения работ P1.1 (расчет) + P1.2(отрисовка)
имеется задача З2, состоящая из выполнения работ Р2.1 (расчет и P'2.2 - не имплементировано)
Утверждается, что:
Р2.1 == Р1.1 (тождественно равны) и
Р2.1 будет выполнена не медленнее (быстрее) P1.1 или (к3 * Р2.1) <= (k1 * P1.1), что верно.
Но не верно, что З2 выполнит работы не медленнее (быстрее) З1.
Т.е. хотя утверждение (к1 * P2.1) <= (k3 * P1.1) - верно,
но(!) оценка должна делаться не для пары P1.1\P2.1, для пары З1\З2
где З1 = k1 * P1.1 + k2 * P1.2
и З2 = к3 * Р2.1 + к4 * P'2.2
и к1-к3 - конечны, а к4 - бесконечен т.к. З2 не может выполнить P'2.2,
и утверждение З2 <= З1 - не верно.
Субъекивная же оценка же преподавателем Р1.2 как "ненужное" и последующая подмена пары З1\З2 на Р1.1\Р2.1 - всего лишь ложная посылка, приводящая к неправильной оценке.
Для правильного сравнения нужно обеспечить в З2 имплементацию Р'2.2 (и обеспечить == Р1.2), что сделает к4 конечным и позволит корректно сравнивать производительность З2 в отношении З1.

Вы осознанно или неосознанно выбрасываете знак равенства из вопроса.
-----
В данном случае он не принципиален, ибо проблема совешенно в другом.
Но Я согласен с поправкой - больше или равно (=>) будет точнее.
Еще раз - оно не столь приципиально как замена З1\З2 на Р1.1\Р2.1
Поэтому формально пример преподавателя корректен.
-----
Нет. Замени отрисовку на экране записью в файл (функциональность Р*.2 не принципиальна) и затребуй оный по окончании работы программы. И не важно, что в нем содержится, важно что временем выполнения задачи будет время создания файла второй задачей... А ненужность этого файла - вопрос чисто субъективный.

меня передергивает от перевода поток. поток для меня это stream.
thread как то не вписывается в это понятие потока
-----
Это терминология. Типа по морю - ходят.
Стриам обычно в контексте ввод/вывод, а треад - паралельная задача.
Тут еще стоит пожаловаться на мультитрединг как на рапределенные системы...
Но и это пустяки, если конечно не переводить дословно на интервью...

логично что в таком случае грузовики приедут быстрее чем если бы они все ехали по сплошной однополосной трассе.
-----
Не логично.
Логично, что без надлежащего управления все грузовики будут продолжать ехать по той же трассе и приедут в тоже время.
Так же логично, что кто-то, скорее всего - первый, должен остановиться на развилке и направить каждый грузовик на его трассу.
Ну и совсем логично, что тот, кто будет разруливать ситуацию приедет последним - т.е. позднее, чем если бы он просто ехал.
Т.е. при описанной схеме грузовики, при зачете по последнему, приедут медленнее...
Задачу Я правда извратил. Для правильного понимания нужно ввести много груза, много грузовиков, некоторое количество полос, сколько-то водителей и оценку в тонно-километрах. Тогда модель будет более правильной. Но даже в этом случае не гарантируется, что не будет существовать более эффективного (однотредного) решения, чем то, которое предложит диспетчер.

Все. Понял. Согласен. Был неправ.
Поясненая для автора топика. Если она еще читает его. Пример препа
Рассматривается компьютер имеющий два или более ЦПУ.
Допустим что:
- задание выполняется 10 минут (т1).
- вывод одного промежуточного значения на экран 0.01 сек. За минут на вывод будет затрачено 0.01 * 10 = 0.1 сек (т2)
При одном потоке время затраченное на выполнение задания и вывод на экран составит т1 + т2.
При двух потоках время затраченное на выполнения задания и вывод на экран составит время самого медленного потока плюс время на синронизацию данных (т3) - т1 + т3. Что есть "время на синронизацию данных"? Есть область в памяти, которая хранит промежуточные результаты. Когда рабочий поток записывает данные в эту область, а параллельно поток вывода на экран пытается считать эти данные, то один из потоков должен ожидать окончание операции чтения/записи конкурирующим потокм. т3 < т2, т.к. вывод на экран заведомо медленее синхронихации, потому что вовлекает в себя исполнение промежуточного кода (драйвер видеокарты) и осуществляется используя более медленные шины данных. Блокировка памяти осуществляется процессором аппаратно.
Получается
т1 + т2 (один поток) > т1 + т3 (два потока)
и пример преподавателя не является примером, когда ворой поток не увеличивает производительность.
Преподаватель может возражать тем, что
- время на затраченно на вывод пренебрежительно мало в сравнеии с временем выполнения задание. Возражение препу - не важно насколько оно мало, но оно существует и отлично от нуля.
- в условии второго задания нет утверждения, что компьютер во втором случает имеет один ЦПУ. Преп - редкостная редиска.
to Murr: Спасибо за интересную и конструктивную дискусию.

Спасибо за интересную и конструктивную дискусию.
------
Гы? Дискуссии то собственно не было. Просто изложил в доступной форме азы
одного из моих образований - Инженер-системотехник...
Правда стоило перевести в матричную форму - там оно по-проще в пояснениях...
при владении соответствующим мат.аппаратом...

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