Вопрос Дипсику

О чём спрашивает человек:

обычный Python multi процесс на CUDA?

есть какой серый ящик для сборки мультипроцессного(чисто для ускорения на обычных ядрах cpu(8-16-32?) cpu-bound - но не ai И не чистая числомолотилка)python-апликаха на gpu (c их мириадами ядер)

ожидания на порядки порядков нет - но если хотябы в 2-3 раза уже хлеб

на входе обычный python разбиваемый на os.cpu_count - подпроцессы досточно автомномны независимого

вот как бы меньшими усилиями очучествить на cuda?

Ответ Дипсика

Человек спрашивает о возможности ускорения CPU-bound Python-приложения (не связанного с AI или чистыми вычислениями) с помощью многопроцессорной обработки на GPU (CUDA), используя существующую структуру, где задача уже разбита на независимые подпроцессы через os.cpu_count().

Суть вопроса:

1. Текущий подход:

   • Обычный Python-код, распараллеленный на несколько процессов (например, через multiprocessing).
   • Каждый процесс автономен и работает на CPU.
   • Задача не связана с AI или тяжелыми численными расчетами (типа матричных операций).

2. Цель:

   • Перенести вычисления на GPU (CUDA) с минимальными усилиями.
   • Ожидает ускорение в 2–3 раза (не на порядки).

3. Проблема:

   • GPU (CUDA) эффективен для массово параллельных задач (SIMD-архитектура), где одна операция применяется к множеству данных.
   • Если задача состоит из независимых, но разнородных процессов, GPU может быть неэффективен из-за накладных расходов на передачу данных и организацию ядер.

Возможные решения (с минимальными изменениями кода):

1. Numba + CUDA:

   • Если в коде есть циклы или операции, которые можно переписать под GPU, Numba позволяет добавить декоратор @cuda.jit для автоматического распараллеливания на GPU.
   • Пример:

     from numba import cuda
     @cuda.jit
     def kernel(data):
         i = cuda.grid(1)
         if i < data.size:
             data[i] *= 2  # Пример простой операции
     

   • Минус: Требует переписывания частей кода под CUDA-ядро.

2. CuPy:

   • Замена NumPy для GPU. Если в коде есть операции с массивами, CuPy ускорит их без изменений синтаксиса.
   • Пример:

     import cupy as cp
     x = cp.array([1, 2, 3])  # Массив на GPU
     y = x * 2  # Операция на GPU
     

   • Минус: Работает только для задач, сведенных к операциям с массивами.

3. Ray:

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

     import ray
     @ray.remote(num_gpus=1)
     def gpu_task(data):
         # Код, использующий GPU (например, через CuPy)
         return result
     

   • Плюс: Подходит для гетерогенных задач.

4. Dask + CUDA:

   • Если задача хорошо разбивается на блоки, Dask может распределить их между CPU/GPU.

Если задача не «GPU-дружественная»:

• Вывод: Если код состоит из разнородных, условных операций (например, парсинг, работа с сетью, сложная логика), GPU не даст ускорения, а возможно, даже замедлит выполнение из-за накладных расходов.
• Альтернатива: Оптимизировать многопроцессорный CPU-код (Cython, PyPy, вынос тяжелых частей в C/Rust).

Итоговый ответ:

Для переноса на CUDA с минимальными усилиями:

1. Проверить, можно ли выразить задачу через операции с массивами → CuPy.
2. Если есть параллельные однотипные вычисления → Numba + CUDA.
3. Если задачи независимые, но требуют GPU → Ray.

Если код не подходит под эти случаи, GPU, скорее всего, не поможет. Лучше оптимизировать CPU-версию.

Тыц. Но там довольно ограниченное подмножество.

Что за «серый ящик»? Ты хочешь код на pycuda запускать на CPU? Обычно всё-таки используют более высокоуровневые фреймворки. Например, если код написан на JAX, то его можно легко запустить на CPU, в т.ч. и в многопроцессном (и даже многохостовом) режиме.

Если код на numpy написан, то его можно портировать на JAX, но объём работы сильно зависит от стиля, в котором этот код написан — если там всё по красоте через broadcasting и векторные операции делается, то должно быть несложно, а если цикл на цикле и циклом погоняет, то проще будет с нуля переписать

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

Если хочется действительно высокой производительности не надо писать числодробилки на нампай:-)

Тем паче никакого питона

Нормальную формулировку вопроса в этот раз не завезли

Зато линейная алгебра удобная!

Питон в числодробилках отлично заходит для фронтенда, кодогенерации, постобработки результатов и пр.

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

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

Но у питона конечно синтаксис в этом плане поприятнее.

https://keldysh.ru/e-biblio/krasnov/

например вот.

на форте пиши, и там корутины какие-то используй

а то фсё пистон, да пистон

eforth от того же автора:

Multi-threading and message passing are available From v5.0 and on, multi-core platform can utilize Forth VMs running in parallel. see the multi-threading section below for details

A thread pool is built-in. Size is defaults to number of cores.

Message Passing send/recv with pthread mutex waiting.

IO and memory update can be synchronized with lock/unlock.

китайский deepseek 理解 товарища кулиньцао!

всегда хотелось спросить qulinxao: у тебя ник в честь вот этого?

или просто звучит прикольно?

chochain/guru – GPU/CUDA in Ruby от того же автора и
ещё ряд ссылок по форту: ряд wasm реализаций, LLVM форт Reschivon/movForth и TclForth, игра «жизнь» в APL (где-то к ней прикладывалась реализация на форте и лиспе реализованном на хаскеле с массивами а не списками вместо conscell),

https://github.com/chochain/weForth https://github.com/hcchengithub/jeforth.3we https://github.com/chochain/guru https://github.com/chochain/weForth https://github.com/stefano/wasm-forth https://github.com/remko/waforth

https://github.com/gmpalter/cl-forth https://github.com/Josefg/Scientific_FORTH https://github.com/Reschivon/movForth https://github.com/davazp/eulex https://davazp.net/2012/12/08/eulex-forth-implementation.html

Пару лет спустя я снова нашёл этот код. Мне больше нечем было заняться, поэтому я решил попробовать. Я портировал свою первоначальную реализацию на 32-битную систему и интегрировал реализацию Forth с ядром C. Как только я смог писать на нём программы, я заменил C и расширил язык, добавив в него множество слов. Я написал процедуры вывода, последовательный драйвер, драйвер клавиатуры и видео, систему управления памятью, обработчики исключений, таймер… Это было так весело, что я не смог остановиться и написал драйвер для динамика, ассемблер и дизассемблер, утилиты trace/untrace, игру Sokoban, взятую из GForth, сочетания клавиш для Emacs и автодополнение в терминале, как в readline, а также простой интерпретатор Lisp! Я уже говорил, как здорово было создавать систему с нуля?

TclForth, емакс на форте и игра жизнь на APL

https://github.com/marcpaq/b1fipl

https://github.com/wejgaard/TclForth https://github.com/larsbrinkhoff/fmacs https://aplwiki.com/wiki/John_Scholes%27_Conway%27s_Game_of_Life

про многозадачность в форте

https://nweb42.com/books/forth/mnogozadachnost-v-forth/ https://nweb42.com/books/forth/mnogopotochnoe-programmirovanie-forth/ https://theforth.net/package/multi-tasking https://bradrodriguez.com/papers/mtasking.html

https://sourceforge.net/projects/concurrentforth/

https://forth-standard.org/proposals/multi-tasking-proposal

https://stackoverflow.com/questions/32736552/does-forth-support-multithreading

форт на баш и баш в форт

https://github.com/Bushmills/Bashforth https://github.com/Bushmills/yoda

игрушки – C++ движок с общей настраиваемой VM, синтаксическим сахаром, и прочими штуками типа форта;

https://github.com/i42output/neos https://neos.dev/ https://neogfx.org/

игра под Atari на форт и история её ковыряния

https://github.com/s-macke/starflight-reverse

в общем, найти форт с поддержкой многозадачности – тот ещё квест.

проще сделать самому типа корутин (кооперативной многозадачности) как описано выше.

или интегрировать в сам движок форта, если он написан на С++, например (см. про tensorForth и eforth переписанный на С++ на лямбдах и корутинах)

есть proposal в Forth 2012, есть переносимая concurentforth, но в целом – надо смотреть саму конкретную реализацию и её документацию (поэтому например реализации на С++/Java/Rust/Go с многозадачностью на самих этих языках реализации имеют смысл)

ещё есть язык SL скриптовый встраиваемый интерпретируемый с синтаксисом типа С только форт, на самом деле (см. jed/joe/most/ slgtk и guilets) – там тоже стало модно из него тензоры дёргать, хоть из С LAPACK,BLAS-подобные, хоть на нём самом (там примитивных нормальных чисел поболее чем в питоне, например комплексные из коробки в самом движке а не boxed как в питоне)

ещё есть nim который nimrod который как питон только конпелируемый в сишку. bazel skylark или как-то так который python на java;cl-python; всякие там разновидности подмножества компилируемого питона

в общем, активно ищут нечто похожее только гибче и без GIL.

в целом, тоже любопытный подход.

вообще, надо нормально сформулировать вопрос: что за код, и как его распараллелить на многопроцессное/многозадачное и как его потом перенести на GPU.

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

хотя вот да, вообще идея интересная: то же самое ML только на форте, а не питоне; и интерактивность, гибкость, расширяемость, DSL-ность и т.п.

не говоря уж о всяких theory of mind штуках типа Mentifex Mind.AI (MindREXX => MindForth), J.Picrat книжках на ту же тему про «теорию сознания».

опять же, всякие там MUD и MUCK, TinyMUCK на форте; LambdaMOO; https://github.com/teamSpoon …. LogicMOO, PrologMUD и тоже «теорию сознания» – на прологе, OpenCYC (на Java/ABCL/Common Lisp/Prolog), CycL, KLIF, Attempto controlled language для естественно-язычных онтологий – на лиспе; ну и всякие там PopLog, Shen для похожих целей.

в общем, там и без питона но с CUDA и LLM (или даже не с компутационным ЕЯ типа LLM и БЯЗ, а с символическим типа пролога и лиспа) много с чем интересно будет поиграться :)))

игра «жизнь» в APL (где-то к ней прикладывалась реализация на форте и лиспе реализованном на хаскеле с массивами а не списками вместо conscell)

в вики: версия на Ruby – github.com/zverok/ruby_as_apl

в вики: 6.20-Conway-Game-of-Life-in-LispE – версия на LispE

само LispE – это реализация лиспа на хаскеле с массивами вместо conscell : 1.-Introduction

ещё у того же автора есть TAMGU – тоже любопытный недоязычок: функциональный, императивный и логический (в этом смысле напоминает PopLog или Shen)

там есть и треды из коробки, и функциональщина, и лисп, и пролог – см. например парсер на глагне через правила наподобие предикатов пролога и DCG-грамматик.

вообще, вот в тему github.com/teamSPoon и в его репозиториях см. LogicMOO (больше инфо в вики), PrologMUD, CYC изначальный и отдельно парсеры CycL, Attempto Controlled Language.

вот такую вот штуку типа LogicMOO, PrologMUD, аналогичную LambdaMOO только на языках типа пролога – на самом деле, имело бы бОльший смысл для наглядности писать на тех же PopLog, Shen.

или TAMGU. он вполне в духе PopLog, но вместе с тем какой-то питонистый.

и треды там из коробки, и сокеты – и всё остальное.

minizork_en.lisp на LispE

6.5-Bridging-with-Python на LispE

gameoflife.tmg на Tamgu

tableur.tmg , tamgucalc.tmg , tamgucalc_mc.tmg – ёксель на Tamgu

curltest.tmg – curl парсер на Tamgu

Korean.tmg – парсер хангыль на Tamgu

fibres.tmg – fibers и unlockthread.tmg – треды на tamgu

minizork_en.lisp

dcg.lisp , dcgfr.lisp + compile_rules.lisp , apply_rules.lisp – парсер естественного языка (английского или французского) посредством правил DСG (Directive Clause Grammars) грамматик.

examples/python_interpreter/interpreter.lisp, examples/python_interpreter/code.py – сабж.

вот интересно, а GIL не завезли в этот недоинтерпретатор?

хотя он там с питоном тоже интегрируется: pythonlispe/examples