რა დროს აირჩევთ threading, multiprocessing ან asyncio?

Question

Accepted Answer

Python სთავაზობს სამ concurrency მოდელს, და სწორი არჩევანი უპირველეს ყოვლისა დამოკიდებულია იმაზე, თუ თქვენი სამუშაო **I/O-bound** თუ **CPU-bound** — გადაწყვეტილება, რომელიც მნიშვნელოვნად გაზეწულია GIL-ით (რომელიც თავს უხსნის ძაფებს Python კოდის პარალელურად გაშვებისა).

## სამი მოდელი

```text
threading        → multiple threads, ONE process. GIL-limited for CPU.
multiprocessing  → multiple PROCESSES, each its own interpreter/GIL → true parallelism.
asyncio          → single thread, cooperative coroutines yielding at await points.
```

## threading — I/O-bound concurrency-სთვის

```python
from concurrent.futures import ThreadPoolExecutor

# ✅ good for I/O — the GIL is RELEASED during I/O waits, so waits overlap
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(download_url, urls))   # many downloads concurrently
```

ძაფები კარგად მუშაობენ I/O-bound ამოცანებისთვის (ქსელი, ფაილები, ბაზა), რადგან GIL თავი თავს ხსნის მოლოდინის დროს — მრავალი მოლოდინი ხდება ერთდროულად. მათ **არ შეუძლიათ** CPU-bound სამუშაოს დაჩქარება.

## multiprocessing — CPU-bound პარალელიზმისთვის

```python
from concurrent.futures import ProcessPoolExecutor

# ✅ good for CPU — separate processes each have their own GIL → use all cores
with ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(heavy_computation, data))   # genuine parallelism
```

CPU-ის მძიმე სამუშაოსთვის (სურათის დამუშავება, მათემატიკა, მონაცემთა დამუშავება), ცალკეული პროცესები აკვეყებს ერთ GIL-ს და ნამდვილად პარალელურად გაშვებული მრავალი ბირთვზე. খরচი: უფრო მაღალი ზეწოლა (პროცესის დაწყება) და მონაცემები უნდა იყოს **serialized** პროცესებს შორის (გაზიარებული მეხსიერება, თუ არა).

## asyncio — მაღალი-concurrency I/O-სთვის

```python
import asyncio
# ✅ best for MANY concurrent I/O operations (thousands) — lightest weight
await asyncio.gather(*(fetch(url) for url in urls))
```

asyncio ამუშავებს ერთ ძაფზე უზარმაზარი რაოდენობის concurrent I/O ოპერაციას, უფრო ეფექტიანი, ვიდრე ძაფები (არ არის per-thread ზეწოლა) — იდეალური სერვერებისა და მაღალი-concurrency ქსელის კოდისთვის.

## გადაწყვეტილების სახელმძღვანელო

```text
CPU-bound (computation)              → multiprocessing
I/O-bound, moderate concurrency      → threading (simple, works with sync libraries)
I/O-bound, HIGH concurrency          → asyncio (thousands of connections, but needs
                                       async-compatible libraries)
Mixed CPU + I/O                       → combine (e.g. asyncio + a process pool for CPU)
```

## რატომ აქვს მნიშვნელობა

სწორი concurrency მოდელის არჩევანი Python-ის წარმადობის ერთ-ერთი ყველაზე მნიშვნელოვანი გადაწყვეტილება და არასწორი არჩევანი (კლასიკური ცდომილება: ძაფები CPU-bound სამუშაოსთვის, რომელიც GIL-ი უარყოფს) იწვევს კოდს, რომელიც სკალირებადი არ არის.

მიმართული ლოგიკა მოდის GIL-დან: **ძაფი/asyncio I/O-bound-ისთვის** (GIL თავი თავს ხსნის მოლოდინის დროს — concurrency მუშაობს) და **multiprocessing CPU-bound-ისთვის** (ცალკეული GIL-ები რეალური პარალელიზმისთვის), asyncio სასურველი, როდესაც concurrency ძალიან მაღალია.

კითხვის ღრმა გაგება თითოეული მოდელის ძლიერი მხარე, ხარჯები (პროცესის ზეწოლა/serialization, asyncio-ის ბიბლიოთეკის მოთხოვნები), და I/O-vs-CPU გადაწყვეტილება აუცილებელია concurrent Python-ის დაწერისთვის, რომელიც ნამდვილად აჩენს წარმადობას.