asm.js'e Veda Etmek

 (spidermonkey.dev)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Firefox 148 itibarıyla SpiderMonkey'nin asm.js optimizasyonu varsayılan olarak devre dışı bırakıldı ve ilgili kodun gelecekte kaldırılması planlanıyor
  • asm.js, JavaScript'in bir alt kümesi olduğu için mevcut siteler çalışmaya devam edecek; ancak genel JIT yolunda yürütüleceğinden optimizasyon avantajı ortadan kalkacak
  • asm.js içeriği WebAssembly ile yeniden derlenirse daha hızlı çalışma ve daha küçük ikili dosyalar elde edilebilir
  • asm.js, NaCl·PNaCl'a karşı ayrı bir sandbox veya alternatif API olmadan web içeriği içinde yerel koda yakın çalışmayı mümkün kıldı
  • 2013'te Firefox 22'ye giren OdinMonkey, Unity ve Unreal gibi C/C++ web dağıtımlarını mümkün kıldı ve WebAssembly'ye uzanan temeli oluşturdu

asm.js optimizasyonunun devre dışı bırakılması

  • Firefox 148 itibarıyla SpiderMonkey'nin asm.js optimizasyonu varsayılan olarak devre dışı bırakıldı ve ilgili kodun tamamı gelecekteki sürümlerde kaldırılacak
  • asm.js kullanan siteler çalışmaya devam edecek
    • asm.js, genel JavaScript'in bir alt kümesi olduğu için mevcut kod diğer script'ler gibi genel JIT yolunda çalışacak
    • Ancak asm.js'e özgü optimizasyon avantajları artık olmayacak
  • Hâlâ asm.js içeriği dağıtıyorsanız, WebAssembly ile yeniden derleme öneriliyor
    • WebAssembly ile yeniden derlerseniz daha hızlı çalışma ve daha küçük ikili dosyalar elde edebilirsiniz
    • SpiderMonkey'nin WebAssembly hattı, asm.js hattına kıyasla çok daha gelişmiş durumda
  • WebAssembly başarılı oldu ve asm.js kullanımının büyük kısmı zaten taşındığı için iki yolu birlikte sürdürmenin maliyeti büyüyor
    • Sürekli bakım süresi gerekiyor
    • VM içinde ek saldırı yüzeyi kalıyor

asm.js'in rolü ve OdinMonkey'nin kapanışı

  • asm.js, NaCl ve PNaCl'ın ortaya attığı “Web'de kod yerel hızda çalıştırılabilir mi?” sorusuna Mozilla'nın cevabıydı
    • Motorun anında tanıyabildiği, katı ve statik tiplenmiş bir JavaScript alt kümesini seçip bunu yerel koda derleme yaklaşımını kullandı
    • Ayrı bir sandbox, IPC veya alternatif API olmadan web içeriği içinde kalarak mevcut web API'lerini kullanabiliyordu
  • asm.js, 2013'te Firefox 22 ile sunuldu ve Unity ile Unreal gibi projelerin yalnızca standart web teknolojileriyle C/C++ kod tabanlarını web'e dağıtabilmesini sağladı
  • asm.js derleyicisinin adı OdinMonkey idi ve kaldırma çalışması Ragnarök hatasında “Twilight of OdinMonkey” olarak izleniyor
    • OdinMonkey'den doğan BaldrMonkey, WebAssembly optimizasyon derleyicisi
    • RabaldrMonkey, WebAssembly baseline derleyicisi
    • OdinMonkey, 13 yıllık görevini tamamladı ve kapanış sürecine girdi

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News yorumları

  • asm.js, NaCl ve PNaCl'ın ortaya attığı “web'de kodu yerel hızda nasıl çalıştırırız?” sorusuna Mozilla'nın verdiği yanıttı
    Bugün olsa Chrome muhtemelen NaCl ve PNaCl'ı doğrudan dayatırdı; sonra da herkes Safari ve Firefox'un neden “web” standardına ayak uyduramadığından şikayet ederdi

    • Bence hâlâ yanlış zaman çizgisindeyiz. PNaCl öldü ve zamanında gelen достойный bir halef yerine Electron uygulama çorbasında diri diri haşlanıyoruz
      Bir süre boyunca her şeyi tarayıcıda yapacağımızı ciddi ciddi düşünmüştüm. Bir bakıma gerçekten de giderek öyle oluyor ama genel deneyim her zamankinden daha kötü hissettiriyor. WASM'ı seviyorum ve sevmek istiyorum ama ekosistemin olgunlaşma hızı inanılmaz derecede kötü
      Daha da kötüsü, güvenilmez yapay zeka araçlarını ve onların çıktılarını tam da bu tür bir sandbox içinde çalıştırmamız gerekirken şirketler bunun tam tersine barındırılan sandbox'lar ve barındırılan JS tabanlı VM'ler satıyor
      Sonuçta mesele hep aynı galiba. İstemci tarafı sandbox'larda para yoktu
    • Hatırladığım kadarıyla öyle değildi. O zamanlar faydalı bir deneydi ama sonunda işe yaramadı
      Dahili olarak Flash oynatıcısını sandbox'a almakta işe yarıyordu ama LLVM tabanlı yaklaşımın sınırları kısa sürede ilgili herkes için netleşti
    • Aslında o dönemde de temelde bunu yapmaya çalıştılar. Web standart komiteleri üzerinden geçirmek istediler ve süreci de izlediler
      Doğru hatırlıyorsam başarısızlığın büyük nedeni, NaCl'ın fazla “büyük”, asm.js'in ise fazla “küçük” bir teknoloji olmasıydı; bu yüzden asm.js birkaç yıl sonra başlamasına rağmen önce üretime hazır hâle geldi
    • Sanırım kastedilen şey, Chrome'un bunu zorlayacağı, Apple'ın ise WebKit ekibine yatırım yapmadan sessizce oyalayacağı ve internette kolay yönlendirilen insanların da Apple'ın çizgisine uyacağı
      Ama Apple düzenleyici baskılar ciddileştikten sonra bu on yılda WebKit yatırımlarını artırmış gibi görünüyor; dolayısıyla bugün sonuç farklı olabilirdi
    • Web platformunda faydalı olacak bir özellik için yüksek uyumluluklu bir alternatif yoksa insanlar şikayet eder. asm.js ve ardından gelen Wasm tam olarak böyle alternatiflerdi
      Bu yüzden o zamanlar daha az şikayet vardı; bugünse Safari'nin App Store'a zarar verdiği düşünülen şeyleri yapmaması daha çok şikayet konusu oluyor. Neyse ki AB artık Apple'ı biraz hizaya getirmeye çalışıyor

  • Üzücü ama anlaşılır. İlginç bir not olarak, Figma başlangıçta tamamen C++ kod tabanıyla başlamıştı ve asm.js, bir tasarım aracının tarayıcıda çalışabileceğini kanıtlayan kilit unsurdu
    WebAssembly'e geçiş ise ücretli müşteriler geldikten sonra oldu ve yükleme süresi iyileşmesi de oldukça büyüktü. asm.js sonuçta hâlâ JS olduğu için paket boyutu daha büyük ve kodun AST olarak ayrıştırılması gerekiyor; WASM'de ise böyle bir gereklilik yok

    • Neyin bu kadar üzücü olduğunu bilmiyorum. Bu sadece bir zamanlar anlamlı olan bir derleme hedefi
      i386-unknown-freebsd1 desteğinin kaldırılmasına üzülmek gibi bir şey
    • Üzücü olan, elimizde düzgün bir yerel masaüstü Figma uygulaması olabileceği fikri

  • Demek asm.js'in ölümü artık geldi mi? Kehanet zaman çizgisinden uzaklaşıyoruz
    https://www.destroyallsoftware.com/talks/the-birth-and-death...
    Hâlâ izlemediyseniz şiddetle tavsiye ederim. “En iyi”yi nasıl tanımladığınıza bağlı olarak gelmiş geçmiş en iyi teknik sunum olabilir

    • Bu teknolojinin ölümüyle kehanetin ipliği koptu. Kayıtlı oyunu yükleyip kaderin dokusunu onarabilir ya da kendi yarattığınız mahvolmuş dünyada yaşamaya devam edebilirsiniz
    • O sunumu yılda iki ya da üç kez tekrar izliyorum. Sunumun nasıl yapılacağını ve slayt destesinin konuşmayla nasıl uyumlu hâle getirileceğini göstermesi açısından harika bir örnek; ayrıca işletim sistemlerindeki ayrıcalık halka yapısını da beklenmedik ölçüde öğretici biçimde özetliyor
      Bir gün savaş dönemlerini aşıp eski programlama paradigmalarına yönelik psikolojik saplantımızı bıraktığımızda daha ileri bir yönteme geçebiliriz. Tabii bu, bankanızın önümüzdeki en az 85 yıl boyunca YavaScript çalıştırmayacağı anlamına gelmiyor
    • asm.js'i WASM ile değiştirirseniz hâlâ doğru yoldasınız
    • Endişelenecek bir şey yok. YavaScript sonsuza kadar yaşayacak
    • Savaşı COVID ile değiştirirseniz ikisi de 2020'de olduğu için çok da sapmış olmuyor. Gerçek olup olmadığını görmek için yine de 2035'e kadar beklemek gerekecek

  • Gary Bernhardt'ın JavaScript sunumunu izlediğim anı asla unutamam.[0] asm.js ile ilk kez orada tanıştım ve kodu tarayıcıda çalışacak şekilde derleme tavşan deliğine de o zaman girdim
    12 yıl sonra onun kurgusundaki ne kadar çok şeyin gerçeğe dönüştüğünü görmek şaşırtıcı
    [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

    • “Kalın uygulamalar (thick apps)” kısmı hep aklımda kaldı. Hem adı komikti hem de bulunduğum duruma epey yakındı
      O sunumu ilk izlediğimde stajyerdim ve şirketim küçük endüstriyel IO kutuları için derleyici, IDE ve hata ayıklayıcıyı baştan sona kendi geliştiriyordu. Derleyici C ile yazılmıştı; Emscripten'la JS'ye çevriliyor, sonra IDE ve hata ayıklayıcı bölümleriyle birlikte devasa bir HTML dosyasına “derleniyordu” (aslında birleştiriliyordu). Kod yükleme ve hata ayıklama Ethernet üzerinden yapılıyor, her şey Ajax ile aktarılıyordu
      Lanetli bir mimari gibi geliyor ama müşteriler bayılıyordu. EXE olmadığı için müşterilerin aşırı katı kurumsal BT filtrelerine takılmıyordu. Bu yüzden Electron'a geçmedik. Bir bakıma kalın uygulamaların ilkel unsurlarına sahipti
    • Yapay zekanın yükselişi olmasaydı WASM tüm diller için makine seviyesinde bir derleme hedefi hâline gelebilirdi. Gary pek çok şeyi öngördü ama yapay zekayı göremedi

  • Yıllar önce bir WebGL kitabında asm.js hakkında küçük bir bölüm yazmıştım
    https://webglinsights.github.io/
    WebAssembly'nin öncülü olan asm.js'in yükselişini izlemek keyifliydi. İlk demolardan bazıları gerçekten çok etkileyiciydi; örneğin Unreal Engine'in tarayıcıda çalışması gibi. Şimdi burada güneşin batışını görmek buruk ama bunun yerini çok daha iyi şeyler aldı

  • asm.js'ten WASM'a giden bir transpiler gerekebilir
    Eski Emscripten sürümleriyle eski kodu derlemek epey sinir bozucu. Bazen birikmiş Emscripten ABI değişikliklerine uyarlamak için JS kodunu güncellemek kadar can sıkıcı olabiliyor

    • Binaryen'de eskiden asm2wasm aracı vardı ama bildiğim kadarıyla artık kullanım dışı. Onunla eşdeğer başka bir araç da bulamadım
      En azından asm.js optimizasyonları kapatılsa bile asm.js kodu çalışmaya devam eder ama bir dönüştürücü güzel olurdu
    • https://porffor.dev/

  • asm.js öldü! WebAssembly yaşasın!

    • Adil olmak gerekirse, wasm ortaya çıktığında asm.js'in zaten birkaç yıl önce kaldırılma yoluna girdiğini sanıyordum

  • Şahsen bunun hata olduğunu düşünüyorum. Gerçi pratik etkisinin ne kadar büyük olacağını bilmiyorum. Bildiğim kadarıyla asm.js kullanan çok fazla kişi kalmadı
    Ama wasm, JavaScript'ten fazla yalıtılmış durumda. Onu sınırlı ölçüde kullandıktan sonra acaba asm.js'e derlesem mi diye düşündüm
    Emscripten'ın bunu hâlâ tam olarak destekleyip desteklemediğinden de emin değildim
    wasm içinde çoğu web API'si çağrılamıyor
    Yapmaya çalıştığım işte daha da önemlisi, JS'den wasm'e sıfır kopya tampon geçemiyorsunuz
    Her şey bir ödünleşim. Yalıtım bir avantaj ama aynı zamanda dezavantaj da

    • asm.js, JS ile etkileşim açısından wasm'den kesinlikle daha sınırlı olurdu. Temelde yalnızca basit sayısal değerler ve dizi tamponlarıyla kısıtlı
      Oysa güncel wasm'de GC türleri var ve externref ile JS değerleri tutulabiliyor
      asm.js'te de sıfır kopya tampon muhtemelen mümkün değil. wasm tarafında sıfır kopya tampon önerisi var: https://github.com/WebAssembly/memory-control/blob/main/prop...
    • Doğru hatırlıyorsam Emscripten, 2020 civarında asm.js desteğini kaldırdı ve asm.js'i destekleyen en önemli araç zinciri muhtemelen oydu. Sonra Rust olabilir ama onun hâlâ destekleyip desteklemediğini bilmiyorum
      Katı asm.js'te de çoğu web API'si doğrudan çağrılamaz. Yalnızca sayılar desteklenir; JS string'leri veya nesneleri değil. Çünkü C heap'i, WASM'de olduğu gibi bir ArrayBuffer nesnesi içinde yönetilir
      Sıfır kopya tampon meselesi de aynı sorundan etkileniyor. asm.js'ten “gerçek” JavaScript'e çıkıp çağrı yapmak gerekiyor ve başka bir ArrayBuffer'ı asm.js heap'ine doğrudan eşleyemediğiniz için kopyalama lazım. “JavaScript FFI”, asm.js ile WASM arasında pratikte çok farklı değil
    • Yanlış anlamadıysam asm.js'te de aynı kısıtlar yok mu? Yani asm.js kodu içinden web API'lerini doğrudan çağıramıyor, “harici” işlevler için yine ayrı işlem yapmak gerekmiyor mu?

  • Mozilla'nın asm.js koduna aşırı derecede özel bir OdinMonkey yayımladığı zamanı hatırlıyorum. Chrome/V8 ekibi ise bunun yerine genel JavaScript'i daha hızlı çalıştıran ve asm.js'e de fayda sağlayan genel amaçlı JIT optimizasyonlarına odaklandı
    Hız farkı Firefox lehine 2 ila 4 kattı ve bunu epey güçlü biçimde pazarladılar :D
    Günümüzde çoğu tarayıcı JavaScript VM'i çok benzer tasarımlara ve optimizasyonlara yakınsadığı için, Odin olmasa da asm.js kodu yine de oldukça hızlı çalışacaktır

  • Çalışma anında JS kodu üretip algoritmaları hızlandırma planım suya düştü. Bunu wasm ile yapmak çok daha zor gibi görünüyor

    • Çalışma anında wasm kodu üretmek aslında epey kolay. Hatta geçerli asm.js kodu üretmekten bile daha kolay olabilir
      Test amaçlı olarak bunun önemli bir kısmını yapan küçük bir kütüphane var: https://searchfox.org/firefox-main/source/js/src/jit-test/li...
    • Bir kütüphane kullanırsanız daha zor değil. Rust'ta şunu kullanabilirsiniz: https://crates.io/crates/wasm-encoder
      JS tarafında ise muhtemelen https://www.npmjs.com/package/binaryen kullanılır
    • Hâlâ AssemblyScript var. Eğer yanlış anlamıyorsam ya da özelliği yanlış bilmiyorsam, gereksinimlerinize uyabilir
      https://www.assemblyscript.org/
    • Sadece asm.js alt kümesini kullanıp performansın nasıl olduğuna bakabilirsiniz. Tarayıcıların özel asm.js desteği olmasa bile, Emscripten çıktısının performansının şaşırtıcı derecede iyi olduğunu hatırlıyorum
    • Hâlâ çalışacaktır. Sonuçta asm.js normal JavaScript kodudur
      Sadece asm.js'e özel işlem hattı kadar hızlı ayrıştırılmaz veya çalıştırılmaz. Çok büyük bir uygulama değilse farkı fazla hissedeceğinizi sanmıyorum