Новые камни Intel, 4/8 - всё

я не знаю, каким образом можно дожить до маразма, когда программист не знает, сколько потоков у него в программе

Вы видимо не работали с современными библиотеками.

Представим простое гуевое приложение с логином и десятком элементов и потребляет пару десятков микросервисов.

Вы хотите сделать его неблокирующимся и не тормозным.

Сколько тредов понадобится?

программист должен ещё уметь оценить объём памяти и ограничить его сверху

Всё прямо как в прошлом веке ;)

Смысл - выяснить, сколько кадров он сможет подготовить для рендеринга

Сколько каких кадров? 320x240? Какой в этом смысл?

Сколько каких кадров? 320x240? Какой в этом смысл?

Неотрендеренных, т.е. у них нет «разрешения». Рендером занимается видеокарта.

Неотрендеренных, т.е. у них нет «разрешения». Рендером занимается видеокарта.

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

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

Это просто голые «скелеты», трансформацией, текстурированием, освещением, фильтрацией, сглаживаем, тесселяцией и прочим и прочим занимается видеокарта.

«плодить треды по мере необходимости» можно только в софте, которому пофигу, упадёт система или нет, будет дико тормозить или нет.

Вы бы из прошлого века вылезли.

Тред пул написанный Оракл или МС будет работать быстрее и надежнее с высокой нагрузкой написанного вами на коленке при высокой нагрузке.

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

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

Это просто голые «скелеты»

Однаковые по объему рассчета «скелеты».
Я в этом сомневаюсь.

Однаковые по объему рассчета «скелеты».

Да. На их количество влияют параметры «дальность отрисовки», «плотность населения» и т.д. В некоторых играх они могут быть занесены в раздел «Графика»

Увы по ходу ты не понимаешь.

Большая часть настроек графики _никак_ не меняет условия для процессора. Вообще.

Я в этом сомневаюсь.

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

Гумно, где core i9?

https://ark.intel.com/ru/products/126699/Intel-Core-i9-7980XE-X-series-Proces...

Сексапильно. Где бы денег на него взять... )

Имхо, если на такое железо нет денег, то и задач, скорее всего, тоже :)

А как главному инвестору идея открыть на ЛОРе аукцион на первый прототип?

https://ark.intel.com/products/91317/Intel-Xeon-Processor-E5-2699-v4-55M-Cach... а этот хуже? 317 тыс.руб. и он твой хоть сегодня

Верните светоча!

Вместо заката солца вручную - плодите треды по мере необходимости в расчете на ОС/рантайм.

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

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

Имхо, если на такое железо нет денег, то и задач, скорее всего, тоже :)

Как так нет? А гамать в мега-нига-игры?

Какой игре актуально более 4 ядер?

Тред пул написанный Оракл или МС будет работать быстрее и надежнее с высокой нагрузкой написанного вами на коленке при высокой нагрузке.

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

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

Ваш философский опус не имеет ничего общего с реальностью.

Никто не делит данные на треды.

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

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

потребует от программиста знать, что он делает

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

Хм.
Т.е. вы предлагаете в каждом проекте каждый программист должен писать и сопровождать свой тредпул?

Мне кажется это будет неудобно даже для небольшого проекта с десятком программистов и будет работать только если проект делает один программист.

кто такой MC?

Microsoft

«Простейшим примером будет обработка данных полученных из разных источников, например БД или Вэб Сервисов.»

Мы говорим не про Xeonы и даже не про i9, а про i7 - соответственно, не сервера с кучей более-менее независимых задач, а десктопы с одним пользователем и ~одной задачей(игра, GIMP, etc)(да, в фоне куча других- но это 5% одного ядра в сумме). Разделение на большие, логически несвязанные, куски типа «логика», «графика», «гуй» - не даст примерно ничего, чтоб получать преимущества от многоядерности нужно делить на части сравнительно мелкие объёмы данных - а значит растёт влияние оверхеда и нужно учитывать количество ядер и всё остальное.

Повторюсь

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

Ну и конечно же программирование

потребует от программиста знать, что он делает

Соответственно никакого «оверхеда»

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

невежество - считать сомнения невежеством.
Или свои слова - доказательством.

Столько времени уверенно доказывать то, чего сам не знаешь - невежество.

невежество - считать сомнения невежеством.

Клевый статус вк!

Дичь как она есть.
У вас ОС состоит из 70 костылей^W процессов. И тут все такие задаются невежеством многоядерности.

Ели бы еще всем ядрам по 4ГГц.
Хотя... открою-ка я другую тему...

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

Если ты не в состоянии понять, о чем именно я говорил и говорю, то тебе к доктору.

Есть задачи, которые легко рспараллелить(Какой-нибудь веб-сервер проще написать многопоточным, чем однопоточным), а есть - которые сложно, и для десктопа типичны именно такие задачи.

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

Кортана/Сири уже -1 ведро (с НТ)
Скайп/вэбкамера -1 ведро

и далее по мелочам.

Всё идет к таким играм, «шлЁмам» и фоновой слежке за базаром пользователя. ИМХА до ядрышек это все будет очень голодным.

А кому нужен один поток, могут купить ИБМ z14, как раз процики пот такие задачи.

а есть - которые сложно, и для десктопа типичны именно такие задачи

Десктопные задачи очень хорошо паралелятся.

Приведенный выше пример с гуевой формой.

Вы нажимаете кнопку и один тред рисует букву второй делает спелчек.

И т.д.

Вы похоже во времена МС-ДОС живёте ;)

Да все в твоих коментах понятно: "Я нихрена не знаю чем в играх занимается процессор, а чем - видеокарта, но вы все неправы, в тестах CPU нужен ботлнек в GPU!!!11"

ваш ответ «потому что знающие программисты знают, что это сложно и не связываются

Вы пожалуйста не привирайте мои слова.

Или я подпишу вас как мудака и буду общаться соответственно ;)

Вы нажимаете кнопку и один тред рисует букву второй делает спелчек.

... и один из тредов требует в 20 раз больше CPU, поэтому их разнесение на два ядра увеличивает скорость не в 2, а в 1.05 раз, но всем на эти наносекунды плевать, поэтому возьмём другой пример:

я беру инструмент Палец в GIMPе, большую кисть, вожу по холсту - и получаю 6 «FPS», и изменения продолжают применяются 10 секунд после того, как я отпустил мышь, и при этом только одно ядро из 4/8 моего i7 950 загружено на 100%, остальные - 5..15%.

и куда здесь «Вместо заката солца вручную - плодите треды по мере необходимости в расчете на ОС/рантайм.»?

Вы похоже во времена МС-ДОС живёте ;)

Нет, вы.
Ибо во времена DOS, внезапно, обработку нажатий клавиш/мышь или проигрывание музыки тоже выносили в отдельные «треды», и в многозадачных ОС(которые, напомню, стали стандартом для десктопа за 10 лет до появления первых бытовых процессоров с HT) с тредами было всё ещё лучше - вот только «треды для избежания блокировок и более логичного дизайна программы» и «треды для получения максимальной производительности на многоядерных системах» - это две большие разницы, связанные почти никак.

Будем пользоваться 4/8 на i7U процессорах в Intel NUC на Coffee Lake.

я беру инструмент Палец в GIMPе, большую кисть, вожу по холсту - и получаю 6 «FPS», и изменения продолжают применяются 10 секунд после того, как я отпустил мышь, и при этом только одно ядро из 4/8 моего i7 950 загружено на 100%, остальные - 5..15%.
и куда здесь «Вместо заката солца вручную - плодите треды по мере необходимости в расчете на ОС/рантайм.»?

Я думаю кроме вас во премена МСДОСа живет ещё много програмистов не умеющих threads ;)

Нет, вы.

Усипуси.
В детсаде каникулы?

Ибо во времена DOS, внезапно, обработку нажатий клавиш/мышь или проигрывание музыки тоже выносили в отдельные «треды»

Мдм
Называть прерывани ДОСа тредами даже в кавычках может только человек понятия не имеющий что это такое.

Завязывайте вы с этим.