Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
gutasiho
Я с данной ОС не сталкивался, потому что там и как устроено, и кто у кого подсмотрел идею не знаю.
WildGoblin
Скрипты (в терминологии IBM OS/360 это называлось "пакетное задание") как и любой иной инструмент автоматизации управления это всего лишь способ автоматической отдачи команд управления системе чтобы человек не торчал всё время у пульта управления, а мог заняться своими делами.
И не более того, но они в принципе не могут изменить природу решаемой задачи. Если её не возможно разбить на равное числу считалок число параллельно считаемых подзадач ("потоков"), то она будет использовать столько считалок, сколько сможет, а все остальные будут простаивать.
Как пример Avidemux старых версий - веток 2.5 - 2.7. Она прекоасно работала на четырёхядерных ЦП загружая их почти полностью, например на Core I7 2600 (4c/8p), но уже на шестиядерном Xeon E5 2667 (6c/12p) при счёте видео, а эта задача отлично распараллеливается на большое число процессоров, Avidemux v2.5/v2.6 использовали только три, редко четыре ядра из шести ядер, ветка 2.7 постепенно научилась использовать пять, реже шесть ядер, а на двенадцатиядерном Xeon E5 2697 v2 (12c/24p) только ADM v2.8.2, и то не всегда использует все двенадцать ядер и двадцать четыре потока ЦП. А к примеру компилятор GCC нучился использовать все ядра Xeon E5 2697 v2 только в v10.20, аналогично и MS VC++ - для MSVC2010 хватит E5 2667, на более мощном десятиядернике Е5 2690 он использует до 7 - 8 ядер из десяти, и только MSVC2015 - MSVC2017 начинают использовать 9, реже все 10 ядер, MSVC2019 уже умеет использовать все двенадцать ядер Е5 2697, но на двух процессорной DELL Precesion Workstation T7610 с парой Xeon E5 2697 v2 в моих задачах и он часто "игнорирует" второй ЦП или использует на нём три, реже четыре ядра, а к примеру новые версии созданного в нашей конторе ChipCAD и двух E5 2697 v2 маловато будет - он хотя и будет достаточно быстро считать на двенадцати ядерных камнях, но своего оптимума достигает на процессорах имеющих от 44 и более ядер.
А задаче которая постоянно взаимодействует с человеком ЦП с большим числом ядер и вовсе не нужен ибо там просто нечего распараллеливать на большое число счётных узлов. Да, можно извернуться и выделить часть вспомогательных задач в отдельные и крутить их на своих ядрах, но сколько они будут простаивать? И многие игры относяться к этому классу задач - что-то, например обсчёт графики, некоторые элементы логики, но не все! можно раскидать на несколько считалок что даст сокращение времени их счёта, а взаимодействие с человеком раскидывать не имеет смысла так в любом случае машина думает намного быстрее его.
Программисты это прекрасно знают, но т.к. они часть производственной цепочки "Изготовитель железа - Разработчик ОС - Разработчики приложений для неё" то материально заинтересованы в увеличении продаж её новых продуктов, а потому часто искуственно завышают требования приложений для стимуляции продаж новинок.
Ничего личного, банальная экономика...
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Всего записей: 33206 | Зарегистр. 31-07-2002 | Отправлено: 22:49 26-10-2022 | Исправлено: Victor_VG, 22:52 26-10-2022 |
|
А про вышесказанное - ну это отдельная большая тема, сейчас тут её "начинать" смыла нет 
