Şu yazıyı okuyorsunuz: Python ve Multi-CPU-Arch: AI’ya doğru
İlk olarak dünyanın önde gelen yapay zeka ve teknoloji haber ve medya şirketi Towards AI’da yayınlandı. Yapay zeka ile ilgili bir ürün veya hizmet yaratıyorsanız sizi yapay zeka destekçisi olmayı düşünmeye davet ediyoruz. Towards AI’da yapay zeka ve teknoloji girişimlerinin ölçeklenmesine yardımcı oluyoruz. Teknolojinizi kitlelere ulaştırmanıza yardımcı olalım.
Mac M1/M2’deki Python araç zinciri kopmalarını güvenilir bir şekilde düzeltin
giriiş
Python’un tasarım hedeflerinden biri platformdan bağımsız olmak ve komut dosyalarını tüm ortamlarda değişiklik yapmadan çalıştırmaktır. Uygulamalar ve kütüphaneler Python betikleriyle yazıldığı sürece Python bu uyumluluğu sağlama konusunda iyi bir iş çıkarır. Python’un popülaritesi ve adaptasyonu arttıkça, giderek daha fazla kütüphane performansı ve verimliliği artırmak için yerel olarak derlenmiş kodu içeren python uzantılarını kullanmaya başladı. Pandas ve NumPy gibi popüler Python kütüphaneleri, yerel uzantıları sayesinde büyük miktarda veriyi verimli bir şekilde işleyebilir. Giderek daha fazla python kütüphanesi yerel olarak derlenmiş kodu kullanmaya başladıkça, python ortamlarında platform uyumluluk sorunları ortaya çıkmaya başladı. Mx(M1/M2) tabanlı MacBook’lar kullanılıyorsa, python ortamında platform uyumluluğu sorunlarına tanık olma ihtimali yüksektir. Bu makalede, pip ve conda gibi python kitaplık yöneticilerinin platforma bağlı ikili dosyaları nasıl yönettiği, neden bozuldukları ve M1/M2 Mac kurulumlarında bunların daha basit, daha güvenilir ve tekrarlanabilir bir şekilde nasıl aşılacağı anlatılmaktadır.
Python ikili dosyaları, diğer ikili dosyalar gibi, farklı CPU mimarileri ve platformları (Windows/Mac/Linux) için ayrı ayrı derlenir. Python bir sisteme Python kütüphanesi kurduğunda, yerel CPU ve platforma özel meta verileri toplar ve işler. Python kitaplığı yerel uzantılar içeriyorsa, yerel olarak çalıştırılabilmesi için CPU’da ve platforma özgü ikili dosyada derlenmesi gerekir. ‘PIP’ ve ‘conda’ gibi Python paket yöneticilerinin CPU ve platform bağımlılıklarını nasıl yönettiğine dair kısa bir anlayış, onların eksikliklerini ve bunların nasıl üstesinden gelineceğini anlamanıza yardımcı olacaktır.
Çoklu PIP ark desteği
PIP, python paketlerini dağıtmak için ‘tekerlek’ paketleme standardını kullanır. ‘Wheel’, saf Python komut dosyalarını ve yerel uzantıları hem kaynak kodunda hem de derlenmiş ikili formatta paketlemeye yönelik bir paketleme sistemidir. PIP’in farklı dağıtım formatlarını nasıl koruduğuna daha iyi bakmak için, seçtiğiniz kitaplığın ‘pip’ web sayfasını ziyaret edin ve “Dosyaları İndir”i tıklayın. Bu sayfada, “Kaynak Dağıtımı” bölümü kaynak biçiminde mevcut paketleri listeler ve “Entegre Dağıtımlar” bölümü önceden oluşturulmuş ikili biçimlerde mevcut tüm paketleri listeler. Örneğin, bu sayfa bağlantı ‘pandalar’ kütüphanesi için kaynak ve önceden oluşturulmuş dağıtımları gösterir. Bu dağıtım paketleri aşağıda belirtilen bir adlandırma kuralını takip eder.
{dist}-{version}(-{build})?-{python}-{abi}-{platform}.whl
{Parantez} içindeki her bölüm, tekerleğin ne içerdiği ve tekerleğin nerede çalışıp çalışmayacağı hakkında bir anlam taşıyan, tekerlek adının bir etiketi veya bileşenidir. Örnek:
pandas-1.5.0-cp311-cp311-macosx_11_0_arm64.whl
pandas — kütüphane1.5.0’ın adıdır — kütüphanecp11’in sürümüdür — Pythoncp11’in minimum sürümü gereklidir — Minimum uygulama ikili arayüzü (ABI) gereklidirmacosx_11_0_arm64 — Yine aşağıdakilere bölünmüş platform etiketi: – macosx — İşletim sistem – 11_0: Gerekli minimum MacOS SDK sürümü – arm64 — CPU mimarisi
PIP adlandırma kuralı aynı zamanda paket paketlerini optimize etmek için ‘joker karakterleri’ de destekler. Örneğin, ‘chardet-3.0.4-py2.py3-none-any.whl’ python2 ve python3’ü destekler ve ABI’ye bağlı değildir ve herhangi bir platforma ve CPU mimarisine kurulabilir. Birçok Python kütüphanesi, paket paketlerinin sayısını optimize etmek için bu joker karakter seçeneklerini kullanır. Python ‘tekerleği’ ve PIP hakkında daha fazla bilgi için bkz. Python Wheels nedir ve bunu neden önemsemelisiniz?
PIP kurulumu neden başarısız oluyor?
Çoğu zaman PIP kurulumu iki ana nedenden dolayı başarısız olur. İlk olarak, eğer depoda önceden oluşturulmuş bir kitaplık mevcut değilse, PIP yerel uzantının kaynak kodunu ana sistem üzerinde derleyecektir. Bunu yapmak için derleme araçlarının ve diğer bağımlı kitaplıkların ana makinede bulunmasını beklersiniz. Bazen bu, özellikle bağımlılık ağacı derinleştiğinde, yapı bağımlılıklarını yerel olarak kurmak zor bir hal alır.
İkincisi, tekerlek paket adlarındaki ‘joker karakter’ nedeniyle. MacBook yakın zamanda kol tabanlı ‘M1/M2’ CPU mimarisini tanıttı. MacOS için eski tekerlek paketlerinden bazıları CPU mimarisi için “herhangi biri” olarak listeleniyordu çünkü o zamanlar desteklenen tek mimari x86 idi. PIP, paketin bu eski sürümlerden birine olan bağımlılığını çözerse, PIP bu paketi çalıştığını varsayarak daha yeni bir CPU mimarisine yükleyecektir. Bu soruna bir örnek ‘azure-eventhub’ paketidir. Bu kütüphane ‘uamqp’ adı verilen başka bir kütüphaneye bağlıdır. Bu kitaplık, M1/M2 arm64 işlemciyle uyumlu olmayan macOS için evrensel/joker karakter paketini listeler. M1/M2’ye ‘azure-eventhhub’ yüklerseniz paketin başarıyla kurulacağını göreceksiniz ancak bu paketi içe aktarırken bir çalışma zamanı istisnası oluşturacaktır.
Conda çoklu kemer desteği
Conda, platformun taşınabilirliğini sağlamak için bir adım daha ileri gidiyor. Conda yalnızca Python kitaplıklarını değil aynı zamanda farklı işletim sistemleri ve CPU mimarileri için bağımlı kitaplıkları, ikili dosyaları, derleyicileri ve Python yorumlayıcılarını da paketler. Bu, tüm takım zincirinin tüm ortamlarda taşınabilir olmasını sağlar. Tüm bağımlı ikili dosyalar aynı zamanda Python kitaplıklarıyla paketlendiğinden, standart C kitaplıkları dışında yerel sisteme herhangi bir bağımlılık beklemezsiniz. Peki eğer conda daha iyi taşınabilirlik sağlıyorsa ve PIP’in eksikliklerini gideriyorsa ne ters gidebilir? Sorun tüm Python paketlerinin Conda’da mevcut olmamasıdır. Conda’da bulunmayan python paketlerini kurmak için conda ortamında pip kullanmak yaygındır; bu nedenle kişi PIP eksikliklerine maruz kalır. Yine (seçici olmamak gerekirse) ‘azure-eventhub’ paketi de bunun bir örneğidir.
Böyle bir platform uyumluluk sorunuyla karşılaşılırsa ve forumlarda çözüm aranırsa, belirli bir python veya kitaplık sürümü yüklemek, kitaplığı ‘brew’ gibi diğer paketleme sistemleri aracılığıyla yüklemek veya alternatif paketler yüklemek vb. gibi farklı seçeneklerle karşılaşılacaktır. . Bu düzeltmelerin çoğu üretim açısından güvenilir değildir ve diğer sistemlerde kopyalanamayabilir. Aşağıda python platformu uyumluluk sorunlarının üstesinden gelmenin daha basit, daha güvenilir ve yinelenebilir yolları olan üç seçenek bulunmaktadır. Bunlar:
- Pip’i kaynaktan yükleme
- Conda ve Rosetta
- Docker çoklu kemer yapıları
Pip’i kaynaktan yükleme
Bir paketin yerel koduna ilişkin derleme bağımlılıkları minimum düzeydeyse, ana sistem üzerinde yeniden derlenebilir. Bir python araç zinciri (kütüphaneler) yüklenemediğinde, büyük olasılıkla bozulan üst düzey paket değil, bağımlılık ağacında yuvalanmış bağımlı bir pakettir. Aşağıdaki komut pip’e paketin ikili sürümünü kurmamasını söylemek için kullanılabilir. Örneğin, aşağıdaki komut ‘uamqp’nin ikili pip versiyonunu atlayacak ve onu kaynaktan derleyecektir.
pip kurulumu – ikili olmayan uamqp azure-eventhub
Conda ve Rosetta
Bu sorunun üstesinden gelmenin bir diğer yolu ise ‘Rosetta’dan yararlanmaktır. Python’un x86 sürümünü Rosetta’nın üzerinde çalıştırmanın en kolay seçeneği conda platform geçersiz kılma seçeneğini kullanmaktır. Örnek
CONDA_SUBDIR=osx-64 conda create -n myenv_x86 python=3.10conda active myenv_x86conda config –env –set subdir osx-64 #Config, pythonpython -c “içe aktarma platformunun x86_64 platform sürümünü kullanıyor; yazdır(platform.machine())”
“CONDA_SUBDIR” ortam değişkeni, conda ortamı oluşturma komutunu yürütürken conda CPU mimarisini geçersiz kılar. Conda config komutu her zaman yeni ortamdaki CPU mimarisini geçersiz kılar, dolayısıyla o ortamdaki diğer tüm komutlar için “CONDA_SUBDIR” ayarlamaya gerek yoktur. Conda platformunun x86’ya geçersiz kılındığı yeni bir ortam oluşturduktan sonra, diğer herhangi bir conda ortamı gibi davranır. Bu ortamda bir PIP kurulumu yapılabilir ve bu, python kitaplıklarının x86 sürümünü yükler. Aynı terminalde birden fazla conda ortamı arasında geçiş yapmak sorunsuzdur ve VS Code gibi diğer araçlar bile sorunsuz bir şekilde sorunsuz çalışır.
Docker Çoklu Arch
Üçüncü seçenek ise yine Rosetta’dan yararlanmak ancak ‘docker’ aracılığıyla. Bu, en taşınabilir seçenektir ve birden fazla ortamda ve kullanıcıda çalışmak için mükemmeldir. Docker’ın çapraz platform özelliği, M1/M2 MacBook’larda x86 docker görüntülerinin oluşturulmasını zorlamak için kullanılabilir. Bir x86 docker görüntüsüyle bir docker çalıştırması gerçekleştiğinde, görüntüyü çalıştırmak için dahili olarak Rosetta’yı kullanır. Aşağıda x86 platformlar arası liman işçisi görüntüsü oluşturma adımları verilmiştir.
ubuntuRUN apt-get updateRUN apt-get install -y python3CMD’DEN [“/usr/bin/python3”, “-c”, “import platform; print(\”Platform:\”, platform.machine())”]
$docker yapısı –linux/amd64 platformu . -t img_x86
$docker koşusu –linux/amd64 platformu -es img_x86Platform: x86_64
Birden fazla kullanıcı ve ortamda daha iyi taşınabilirlik için Dockerfile’ın FROM komutunda “platform” seçeneği kullanılabilir. Bu, kullanıcı build komutunun “—platform” seçeneğini belirtmese bile x86 görüntüsünün kullanılmasını sağlar.
İLE İLGİLİ –platform=linux/amd64 ubuntu ÇALIŞTIR apt-get updateRUN apt-get kurulum -y python3CMD [“/usr/bin/python3”, “-c”, “import platform; print(\”Platform:\”, platform.machine())”]
Bu liman işçisi dosyası, “—platform” liman işçisi oluşturma seçeneği olmadan bir x86 liman işçisi görüntüsü oluşturacaktır.
$docker yapısı. -t img_x86$ liman işçisi çalıştır -it img_x86Platform: x86_64
Çözüm
Yukarıda belirtilen seçenekler Python platformu uyumluluk sorunlarını güvenilir bir şekilde çözmenin tek yolu olmayabilir, ancak bunların çoğumuz için bu sorunları hızlı bir şekilde aşmak, hayal kırıklığını önlemek ve zamandan tasarruf etmek için genel ve açık bir yaklaşım olarak hizmet edeceğini düşünüyorum. çözüm. çözüm. Umarız yakın gelecekte Python ekosistemi daha da gelişecek ve kullanıcıdan herhangi bir ek girdi olmadan birden fazla CPU ve platformu sorunsuz bir şekilde yönetebilecek şekilde olgunlaşacaktır.
Python ve Multi-CPU-Arch ilk olarak Medium’da Towards AI’da yayınlandı; burada insanlar bu hikayeyi vurgulayarak ve yanıtlayarak sohbeti sürdürüyorlar.
Towards AI aracılığıyla yayınlandı
