Если писать программу "от потоков данных" а не "потоков исполнения",

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

...я недавно в легаси переписывал. Там сначала 30% времени все грузилось из БД в основном потоке.

Потом в статике создавалось 100500 потоков (буквально, каждому потоку назначался диапазон, тебе с 0 по 99 строку, тебе с 100 по 199, и т. д. до конца TList.)

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

Каждый из этих воркеров каждую отраьотанную строчку засовывал в VTV. По одной. Через Synchronize. Без BeginUpdate.

На последнее тратилось примерно 40%.

В промежутке работало примерно 1/2 потоков от аьстратного максимума, остальные ждали таймера.

Ах да, 10 потоков 4 ядра к сожалению оказались неспособны загрузить на 250%, только на 100.

Вопрос: это Дельфи была виновата, что это ТАК писали?

Ну, в какой-то мере да, что не было из коробки других библиотек типа OTL.

Но не только Дельфи. На СО до сих пор бывают вопросы, типа я сделал сто потоков, каждый из которых на 100% состоит из одного synchronize, где моё 100-кратное ускорение?...

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

А как правильно будет?

Потоков почислу ядров с небольшим запасом сверху. Поток освободился, взял фрейм данных на одной из стадий обработки (OTL Pipeline например) отработал, положил на вход следующей стадии. С какой именно стадии он берет фрейм решает либа, которая видит всю трансформации и видит на каких шагах пробки образуется и туда перекидывать воркеров с других звеньев.

Стикер

Ты на вопрос слишком просто смотришь. Возьми не десктопное приложение, а что-то серверное. Там потоков обычно больше чем количество ядер. Ибо потоки могут выполнять не только прямые задачи для распараллеливания, но и фоновые задачи. Опять же есть класс задач, где syscall примитивов синхронизации, вроде мьютексов, противопоказан. Там уже атомики рулят. Есть free-lock структуры... В общем тема это сложная

Стикер

Фоновые задачи не должны прямо влиять на основные, не? Если они фоновые... А вот в одном месте, куда я не пошёл ибо далеко ездить, переписывались сервер на 64 бита, потому что память скончалась, если слишком много запросов=потоков было. Рассказал им про $M и размер стека, может помогло, не знаю :) Ладно, я оффлайн, конец года сцуко, внезапно появились несколько ледлайнов как всегда.

Нет там ничего сложного. Достаточно для разработки и тестирования использовать не топовый комп, а какой-нибудь селерон с 2 ГБ памяти. Тогда в продакшене оно будет гарантированно летать с многократным запасом.

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

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

Т.е. мне свой AMD Ryzen 7 7700x выкинуть, да? 🤔

Я бы запустил эмулятор (виртуалку), но твой вариант мне тоже нравится. =)

Эта фиговина авторазгон до 5,4 ГГц включает)

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

Я тут себе на али прикупил железо для сервера на Intel Xeon E5 2670 v3 - в 10 тыс уложился (мать, проц, 16 ГБ ОЗУ DDR4 ECC, кулер, блок питания)

Извиняюсь. Я думал это ты написал так. А это был пример кривой реализации. Тогда согласен с написанным, за исключением того что потоков всегда должно быть столько сколько ядер. Не всегда, но количество потоков надо ограничивать, то есть для рабочих задач делать пул потоков, а не постоянное создание/уничтожение потоков. Фоновые потоки сами по себе без пула, обычно существуют всё время существования приложения

На слабом железе эта проблема будет больше и раньше заметна, чем на мощном. На мощном этот кеш с мутексом может вообще не понадобится, вся БД в памяти закешируется еще на уровне ОС и файловой системы. А также десятки других проблем, которые прощает мощное железо.

Наивный. В многопоточном программировании намного больше проблем чем ты думаешь. Это не только data race, но и взаимоблокировки (deadlock), leavelock, голодающие потоки, честное распределение и много другое. Многие вещи можно поймать только под нагрузкой. А какую нагрузку можно создать на хилом проце?

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

И вы этот хайлоад на дельфи пишете🧐?

Да. Часть на PHP, всякие веб-интерфейсы и веб-API. Есть скрипты на JavaScript. Есть немного на Си, там свой диалект, совместимый с дельфями - строки, массивы, Variant.

А если не секрет, что именно пишете?

Системы для МВД, МЧС, минздрав, минобр. От драйверов связи до распределенных баз, серверов, настольных, мобильных и веб рабочих мест

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

Я насчёт количества имел в виду потоки конкретной задачи (потока данных). Другие потоки или задачи , управляемые другим менеджером, они отдельно.

Прям так и всё... Ну... Например возьмём lock-free что-нибудь. В котором забыли атомарные инкременты (обычный ткнул) или барьеры памяти или ещё что-то. Запускаем "на хилом проце" . На одноядерном (остальное будет менее хилым). Упс, внезапно всё работает и баг скрылся. Чтобы баг выловить надо поймать физически одновременный инкремент из 2 потоков. При этом слабый проц вероятность этого не увеличит (одна команда ассемблера, её даже атомом не затормозишь). А вот количество потоков и частота инкрементов (обратно пропорционая длительности обработки данных) - т.е. крутость процессора - вполне. Наверное если порыться, можно даже академический статьи найти, какого рода баги скорее выявляются на слабых машинах, а какого рода на сильных. При том, что я в целом симпатизирую тезису "компы разработчика и тестера должен быть хуже среднего компа клиента" :-) Но с некоторыми багами лучше наоборот.

Что касается багов с многопоточностью я лично сделал для себя следующий вывод: 1. Ловить их лучше на многоядерной, но хилой конфигурации. Т.е. у меня был пример когда на виртуалке с одним ядром вероятность ошибки была маленькой, но при выделении 4-х ядер баг стал совершенно очевиден. 2. Тестировать задачу надо по возможности при максимальной загрузке потоков (т.е. например расчётную задачу пускать на расчёт с максимальной скоростью без искусственных задержек. Ну то есть к примеру если цель тестирования именно выявление багов связанных с распараллеливанием, то это в любом случае подразумевает многоядерную тестовую систему.

у разработчика комп должен быть быстрый, чтобы быстро компилить ) а вот тестеру(ам) надо зоопарк разных компов