Есть код на питоне как можно ускорить его мультипроцессность не работает?

Question

[Dayanc Kakamyradov]

код:

import multiprocessing
import itertools

lst = ['0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f']

def gen(args):
	count=0
	for x in itertools.product(lst,repeat = 16):
		key=''
		key+= "{}{}".format(3,''.join(x))
		count+=1
		print(key,count,end='\r')


if __name__ == '__main__':
	p = multiprocessing.Process(target=gen,args=(lst,))
	p.start()
	p.join()

но он медленно работает как его можно ускорить до миллион комбинации в секунду можете помочь как нибудь

Comments

[Сергей Соловьев]

Вопрос задан неверно. Ты имел ввиду мультиПРОЦЕССНОСТЬ

[mayton2019]

Вот могут быть сильные потери.
print(key,count,end='\r')
Такова специфика I/O.

[Вадим]

AshBlade, исправьте

Answer 1

[Сергей Соловьев]

Здесь только 1 процесс по факту работает , параллелизации нет.

Для оптимизации можешь распараллелить по первому индексу старта начала комбинации.
Например, один процесс обрабатывает комбинации начиная с 0 по 4, другой с 5 по 9 и т.д.

Comments

[Dayanc Kakamyradov]

не понял можете подробнее или кусок кода показать если не сложно??

[Василий Банников]

Dayanc Kakamyradov, тебе нужно разделить работу на несколько процессов, а не выполнять одну и ту же работу по несколько раз, как сейчас.

[pfg21]

погуглить "распаралеливание задачи" автор не знает тех.основы того чего хочет.

Answer 2

[Vindicar]

p = multiprocessing.Process(target=gen,args=(lst,))
p.start()

Ты запускаешь ровно один процесс, а потом стоишь и ждёшь (p.join()), когда он завершится. Это мало чем отличается от просто вызова gen() в твоём коде, безо всякого мультипроцессинга.
Кроме того, у тебя функция gen() делает всю работу, а должна обрабатывать только один элемент. Ты думаешь Питон волшебным образом поймёт, что вот именно этот цикл надо распараллелить?

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

Пример есть в документации, если ты туда заглядывал. В примере показано несколько вариантов использования пула процессов.
Я бы на твоём месте использовал или imap_unordered(), или imap(). Разница в том, что первый может не сохранять порядок - т.е. результаты тебе будут приходить не в том же порядке, в каком приходили данные во входной последовательности. Второй его сохраняет, но работает чуть медленнее (он ждёт, пока правильный порядок не получится).

Comments

[mayton2019]

Этот топик имеет предысторию https://qna.habr.com/user/Dayanch16/questions

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

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

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

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

[Vindicar]

mayton2019, ну чудь пройдёт - опыт останется. Хоть будет знать, как вообще пользоваться многопроцессингом в питоне. =)

[Dayanc Kakamyradov]

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

[Vindicar]

Dayanc Kakamyradov, сетевые операции вообще штука медленная. А блокчейн так и сам по себе тормозной.

[Dayanc Kakamyradov]

Vindicar, это не сетевая операция у питона есть свои библиотеки

[mayton2019]

Dayanc Kakamyradov, а что дальше будет с этими кошельками?

Answer 3

[mayton2019]

Вот в один поток на сях. Только сам скомпилируй. 32 млн строк в секунду. Если писать в /dev/null

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

// habr.com : mayton2019 - 3 Sep 2023

char *hex = "0123456789abcdef";
char *buf;

void streamer(int max_depth, int level, char *alphabet, int alphabet_size) {
   for(int i = 0 ; i < alphabet_size ; i++) {
      buf[level] = alphabet[i];   
      if ( level < max_depth ) {
        streamer(max_depth, level+1, alphabet, alphabet_size);
      } else {
        buf[level] = '\0';
        printf("%s\n", buf);
        break;
      }
   }
}

int main(int argc, char** argv) {
  buf = malloc(strlen(hex) + 1);
  streamer(16, 0, hex, strlen(hex));
  free(buf);
  return 0;
}

Вот как я мерял.

gcc hex-gen.c -o hex-gen.exe && ./hex-gen.exe | pv -l -r > /dev/null
[30.7M/s]
[30.1M/s]
[30.3M/s]

Вот если писать в текстовый файл то скорость чуть медленнее. 24 млн строк за секунду.

Вот. Проверяй данные. Что я нигде не ошибся.

UPD: Лишний ноль убрал.
UPD: +break добавил.