Железо для графики

[Андрей Викторов]

использует ли приложение все ядра

Важно что оно использует.

 

[_MBK_]

Важно что оно использует.

А смысл? Если на производительности это никак не отражается?
Вам шашечки или ехать, не пойму?
Попробую прованговать пример
Допустим вы запустили некий ресурсоемкий иллюстраторовский процесс из под винды.
Процесс, как уже сказали выше, линейный и расспараллеливанию не подлежит. Соответственно, иллюстратор запросил для него кучу ресурсов у винды, которая, в свою очередь, бросилась перераспределять эти ресурсы, отбирая их у других приложений - занимая данным малополезным действием остальные ядра.

 

[Андрей Викторов]

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

 

[_MBK_]

Вряд ли разработчики сами точно знают
как работает компьютер в целом и его части, как программные, так и аппаратные,
в частности)))

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

Умофон как бы состоял из невообразимого числа свитков с законами, исполнявшимися электрической силой много раз в секунду, вот только записаны эти повеления были иначе, чем принято у нас. Вместо латунных цилиндров и полосок рисовой бумаги ветхие люди применяли изощренную и чрезвычайно мелкую резьбу по камню, во много слоев вытравливая в нем тончайшие иероглифы с непостижимо сложным смыслом. Электричество, проходя по ним так и сяк, каждый раз как бы принудительно прочитывало их.
Нечто похожее происходит, когда ветер вращает барабан молитвенной мельницы с вырезанными на нем мантрами. Но здесь было наоборот: мельница оставалась неподвижной, а вокруг нее замысловато кружил ветер – и не простой ветер, а как бы дуновение множества голосов, читающих заклинания.
Молитвенный барабан назывался у ветхих людей словом «Хад», а произносящий заклинания голос – словом «Цоф» (так я расслышал). Мантры на барабане «Хад» были все время одни и те же, а заклинания «Цоф» постоянно менялись.
И каждый раз, когда эти «Хад» и «Цоф» встречались, электрическая сила как бы околдовывала себя сама – подчиняясь заклинаниям, она разбегалась по металлическому лабиринту таким хитрым способом, что функции умофона проявлялись совершенно безблагодатно – то есть вообще без вмешательства Ангелов!

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

 

[ch_alex]

Вот вы всё обсуждаете, а я подумал, что дождусь выхода AMD RYZEN и посмотрю, что получилось...

 

[TRANTOR]

в случае растрирования, раскидать объекты по ядрам

Можно (рисовать в параллельные пиксельные буфера и склеивать результат в пикселях же). Вот только затык не в отрисовке, а в работе с самими объектами. В моем примере просто копирование, до отрисовки дело даже не доходит.

 

[Dmitrij M]

AMD RYZEN

вряд ли это будет milestone в графике 2Д

 

[ch_alex]

Я сделаю вид, что понял весь текст. Но на самом деле понял только графики.

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

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

 

[Дональд]

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

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

 

[_MBK_]

В связи с этим было бы интересно провести те же тесты, перенастроив параметры производительности Windows так, чтобы 6 из 8 ядер по умолчанию были приостановлены. Тогда будут нагружаться только два ядра, и только если их не хватит - начнёт нагружать третье ядро.

Кому интересно, а главное, ЗАЧЕМ?
Иллюстратор. судя по вышесказанному, вы использовать дополнительные ядра никаким образом не заставите (разве что код перепишете заново), а производительность системы подобными ухищрениями разве что понизить можно, но никак не увеличить.

 

[Дональд]

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

Эта картинка выглядит так, будто 100%-я нагрузка с двух ядер распределяется на все восемь.

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

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

Не понял, про какие именно ухищрения Вы пишете, процитирую статью, ссылку на которую дал в предыдущем сообщении:

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

 

[_MBK_]

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

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

 

[Дональд]

Не следует идеализировать (а в данном случае, фактически, обожествлять систему)

А где я это делал-то?

 

[_MBK_]

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

 

[TRANTOR]

независимые команды в разные

Не может он этого. Он не знает, какие зависимые, а какие нет, пока бородатый программист явно ему это не скажет. Например, с помощью такого: Intel Threading Building Blocks — Википедия Или такого: OpenMP — Википедия

В компиляторах от Интела есть опция для автоматического распараллеливания, но от нее, как правило, только хуже становится.

 

[_MBK_]

Ну в общем таки да

 

[IPTIV]

По-моему, всё вот это когда-то уже обсуждали, причём те же самые сограждане Если резюмировать опыт моих изысканий, то получается, что:
1. Иллюстратор использует 1 (одно) ядро и чем оно быстрее - тем лучше. Двухъядерник с быстрыми ядрами уделывает четырёхъядерник с медленными ядрами примерно той же архитектуры (в смысле, сравнивать Core2Duo E8600 и i5-2300 не корректно, нужно сравнивать C2D с C2Q, а i5-2xxx с i3-2xxx).
2. Видеокарта, даже соответствующая системным требованиям для активации аппаратного ускорения, нифига Иллюстратору не даёт - на ЦП он может даже ещё быстрее "крутиться", чем с включенной "ракетой". А вот ФШ многие операции при наличии подхлдящей видеокарты выполняет быстрее, иногда - на порядки.
3. ФШ и ИД используют все ядра процессора и всю оперативку. Кстати, правдивая история про то, достаточно ли 8ГБ оперативки. Сегодня клиент один уважаемый слёзно попросил сделать ему баннер. Все болеют, делать пришлось самому. По привычке сел за свой компьютер с 8 ГБ и начал колупать баннер 3000х2500мм@100dpi. Короче, уже с третьего слоя я всё проклял! Оперативка забита вся, винт жужжит, ФШ еле ворочается. Но т.к. пересаживаться лень, то так и промучился, пока не сделал, при этом вспоминал РУДТПшников, которым "16 ГБ совсем ненужно". НУЖНО 16 ГБ, ещё как нужно! И 32 лишними не будут!