· kaynak dev.to (home feed)
Memory64, WebAssembly'ın 4GB heap sınırını kaldırıyor ama bir JavaScript ABI boşluğu bırakıyor
Bir dev.to raporu, Memory64 sayesinde 32-bit heap'in yapamadığı 473 milyon parametrelik bir WebAssembly tahsisinin mümkün olduğunu gösteriyor; ancak Number ile BigInt arasındaki pointer uyuşmazlığı hâlâ daha büyük tarayıcı içi ön ayarları eski yola itiyor.

4GB sınırının pratikteki görünümü
Klasik WebAssembly modülleri lineer belleği 32-bit pointer'larla adresler; bu da heap'i 4GB ile sınırlar. Çıkarım (inference) için bu sınır zaten dar, ama eğitim için daha da kötü: fp32 bir modelde yalnızca ağırlıklar için parametre başına dört bayt gerekir ve AdamW gibi optimizer'lar ek parametre başına durum tutarak bellek ayak izini ham ağırlık tensörlerinin çok ötesine büyütür. dev.to gönderisine göre bu hesap, ağırlıkları ve AdamW durumuyla birlikte fp32 bir model için pratik sınırı kabaca 250 milyon parametreye yerleştiriyor — tarayıcı tabanlı bir eğitim oyun alanı kurmaya çalışanlar için ciddi bir kısıt.
Memory64 neyi değiştirdi
Memory64, WebAssembly'ın pointer genişliğini 64 bite çıkarıyor ve JavaScript tarafında BigInt gerektiriyor; çünkü JavaScript Number — 64 bitlik bir kayan nokta değeri — her 64 bitlik tam sayıyı tam olarak temsil edemez. Gönderinin yazarı, aynı C++ kaynağını Memory64 ve BigInt desteği etkinleştirilmiş şekilde yeniden derleyip tahsis benchmark'ını tekrar çalıştırdı.
Ölçülen sonuçlar netti. 64 bitlik modül 3,7 saniyede 473.244.160 parametre tahsis etti, tek bir eğitim adımını 82,2 saniyede tamamladı ve ardından tahsisi sorunsuzca serbest bıraktı. Aynı kodun 32 bitlik derlemesi bu tahsisi hiç yapamadı. Başka bir deyişle teorik bellek sınırı gerçekten ve ciddi ölçüde hareket etti — başarılı çalışma, optimizer durumu dahil edildiğinde eski heap'in fiziksel olarak adresleyebileceğinin çok ötesinde.
Çalışmanın nerede tıkandığı
Sorun şu ki benchmark Node altında çalıştı ve bu, tarayıcının JavaScript'ten WebAssembly'a köprüsünü sınamıyor. Geliştirici çalışmayı gerçek tarayıcı içi akışa taşıdığında pointer değerleri bu sınırı tutarsız biçimde geçti: bir yerde Number, başka bir yerde BigInt olarak geldiler. Köprünün iki tarafı pointer tipinde anlaşamadığı için daha büyük tarayıcı içi ön ayarlar 32 bitlik kod yoluna — yani özgün 4GB kısıtının altına — geri düştü.
Gönderi, dürüst okumanın iki parçalı olduğunu açıkça belirtiyor. Memory64 kontrollü, ölçümlü bir çalışmada tahsis sınırını hareket ettirdi ve ürün yolu hâlâ bir ABI entegrasyon engeli içeriyor. Node altındaki tek seferlik başarılı tahsis, tam tarayıcı akışının yeni ölçekte çalıştığını kanıtlamadı. Ölçümler ve mevcut sınırlama projenin herkese açık devlog'unda kayıtlı.
Neden önemli
Bu hikâye, tarayıcı içi makine öğrenmesinin gerçek konumunun yararlı bir fotoğrafı. Motor düzeyindeki yetenek geldi: wasm64 heap'leri optimizer durumuyla birlikte yüz milyonlarca parametreli modelleri tutabiliyor; bu, 32 bitlik heap altında tamamen imkânsızdı. Ama motor düzeyindeki yetenek, çalışan bir ürün yoluyla aynı şey değil ve buradaki kalan engel gösterişsiz — tam olarak Node'daki benchmark'ların hiç dokunmadığı türden, JavaScript sınırında Number ile BigInt arasındaki bir ABI uyuşmazlığı.
Büyük yerel ML kod tabanlarını WebAssembly'a taşıyan geliştiriciler için ders, bu sınırı erken planlamaktır. JavaScript ile Memory64 modülü arasında pointer geçiren her kod BigInt'e tutarlı biçimde bağlılanmalı; aksi halde sessizce eski 32 bitlik yola ve eski 4GB tavanına düşer. Bu entegrasyon boşluğu kapanırsa, tarayıcılar daha önce mümkün olanın kabaca iki katı büyüklüğünde modelleri eğitmek ve ince ayar yapmak için makul bir ortam haline gelir — bu da tarayıcı içi yapay zekâ araçlarının gerçekçi olarak deneyebileceklerini değiştirir.
- #webassembly
- #memory64
- #javascript
- #bigint
- #in-browser-ai