А почему просто не раздать потокам разные списки на вычисление,

без пересечений? Чтобы не надо было синхронизировать

А почему бы и нет, но задача ОСВОЕНИЕ МЕЖПОТОКОВЫХ ВЗАИМОДЕЙСТВИЙ

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

А то что если в списке 5 элементов, а ядер 32 то 32-5 = 27 - тупо будут стоять

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

Слишком сложные переживания даже сложнее чем написанный код 👍😁

Если думать об том что процессор нагреется и будет тротлить зачем его вообще включать? 👍

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

DELPHI SOLUTIONS
так так и делается всегда... задание разбивается н...

красиво

DELPHI SOLUTIONS
так так и делается всегда... задание разбивается н...

Ну и как в такой схеме на производительность влияет способ реализации списка паролей?

TDictionary и TList - есть разница?

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

Если тебе так важно остановить остальные потоки если один нашел коллизию - взводи событие.

так диапазоны ведь не пересекаются по исходным данным у потоков 🤷‍♂️ а коллизии для CRC16 искать - тоже просто создав массив 65536 boolean-ов

Конечно есть... у ТList доступ к элементу по индексу Tlist[index] а у TDictionary??? какой дуступ к элементу списка? через метод TDictionary.Items[key] function TList<T>.GetItem(Index: Integer): T; begin // CheckItemRange(Index) is expanded here manually to improve codegen if Cardinal(Index) >= Cardinal(FCount) then ErrorArgumentOutOfRange; Result := List[Index]; end;

Что-то не то у вас property Items[const Key: K]: V read GetItem write SetItem; default; function TDictionary<K,V>.GetItem(const Key: K): V; var index: Integer; begin index := GetBucketIndex(Key, Hash(Key)); if index < 0 then raise EListError.CreateRes(@SGenericItemNotFound); Result := FItems[index].Value; end; тут не просто вызов функции - а ещё и хэширование ключа TDictionary - это хэш-таблица, а не просто массив

CRC16 - Это совсем другое ... это был просто тест использования TParallel.for

аааа

А почему бы остальным потокам не отправить сообщение?

DELPHI SOLUTIONS
Да не там посмотрел ... перешел по правильным сс...

THashRec = record index: integer; hash: TBytes; end; TList<THashRec> Не понимаю только как вы эту структуру используете? У вас есть поиск по THashREc.index внутри TList? Если да, то каков размер TList?

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