SIMD.js – nowe API dla JavaScript

SIMD.js – nowe API dla JavaScript

    przez -
    20 419
    Mozilla Foundation
    SIMD.js to nowe API dla Java Script, które posiada wiele nowych funkcji i typów do obliczeń SIMD. Jest obecnie wspierane jedynie w Firefox Nightly i istnieje eksperymentalna wersja dla Chromium. SIMD.js jest rozwijane we współpracy z Mozilla, Google, Intel i kilkoma innymi partnerami. Nowe API ma przyspieszyć wiele aplikacji i gier dla przeglądarek internetowych, posiadając wysoką wydajność i niskie zużycie zasobów.

    • Jakub Konieczny

      JS to fajna zabawka, ale sam język do programowania się nie nadaje.
      Fajnie że się zabierają za jego usprawnianie i poprawianie wydajności, ale takie rzeczy powinny siedzieć w rdzeniu platformy i być standardem, SIMD powinien być wykrywany normalnie w kodzie jak to robią kompilatory C czy JITery, ale niestety JS jest dynamiczny i takich rzeczy nie da się wychwycić bezbłędnie w kodzie.

      Pozostaje tylko liczyć że to będzie standardem we wszystkich przeglądarkach.

      • mikolajs

        “JS to fajna zabawka, ale sam język do programowania się nie nadaje.”

        Powoli przyzwyczajaj się, że ta zabawka staje się głównym językiem programowania ;) A wydajność już teraz ma największą z wszystkich języków dynamicznie typowanych.

      • Jakub Konieczny

        Bzdura, nikt nie każe pisać w samym JS. Osobiście piszę ile się da w CoffeeScripcie który ma dużo czytelniejszą składnię i przede wszystkim da się obiektowo pisać z dziedziczeniem nie myśląc o samobójstwie.

        Po kompilacji niczym to się nie różni od tego, co bym napisał w JS poza tym że nie mam kodu spaghetti po stronie Coffee, a po stronie JS niby kod momentami jest dziwny (pętle po słownikach, albo jeszcze lepszy twór: funkcja której ostatnią instrukcją „główną” jest pętla xD), ale również czytelny. Jest jeszcze Kotlin, który można jeszcze alternatywnie do Javy skompilować.

        (hiperbola!) Bezpieczniej jest nawet napisać kod w C++ i skompilować do JS przez asm.js niż od razu pisać w JS. Statyczne typowanie zmniejsza ryzyko popełnienia wielu błędów które normalnie przechodzą przez parser JS jak miecz świetlny przez masło.

      • Roman

        Jeszcze powiedz, że piszesz obiektowo dla samej obiektowości, a większość twoich klas ma jedną instancję.
        Nie wiem czym się chwalisz. Że nie umiesz pisać programów w dynamicznym języku?
        Całe szczęście, że nie musisz pisać w jakimś funkcyjnym bo byś płakał. Ale jak ci się nudzi to polecam Go do zabawy.

      • Jakub Konieczny

        Próbowałem Go, ale jego stricte serwerowe przeznaczenie mi nie odpowiada, ale język całkiem ładny.

        W funkcyjnym bym sobie popisał, ale nie widzę sensu męczarni w czysto funkcyjnym klasy Haskell, ale pewne problemy jak dłubię w strukturalnym to aż się proszą o funkcyjną implementację. Scala niby obiektowo-funkcyjna, ale tej funkcyjności daleko do czystej funkcyjności.

        Nie lubię „obiektowości dla obiektowości”, podoba mi się w JS tożsamość obiektów ze słownikami (sporo ułatwia w bzdurnych sprawach, po serwerowej stronie w Pythonie często tworzę klasy lokalne do takich celów, słowniki są niezbyt wygodne), ale klasy wprowadzają pewien porządek. Nie lubię walić dziesiątek zmiennych, wolę popakować w obiekty, wygodniej się debuguje (Chromium:)).

        Skrypt który piszę mieli sporą ilość danych podobnych, a jednak różnego rodzaju danych i bez klas z metodami i bez dziedziczenia ciężko by to było ogarnąć w formalny sposób. Dodatkowo te cholerstwo musi być tak zaprojektowane żeby działało 24h bez żadnej zadyszki bez odświeżania strony, nie trudno o wyciek pamięci, gdy trzeba jeszcze zarządzać obiektami na mapie, same przypisanie nulla nie wystarczy.

      • mikolajs

        “Bzdura, nikt nie każe pisać w samym JS.”
        Nie każe, ale z lenistwa coraz częściej pisze się JS. Bo po co pisać w dwóch językach aplikacje webowe jak można w jednym?

        “Osobiście piszę ile się da w CoffeeScripcie”
        Na to samo wychodzi jakbyś pisał w JS ;)

        ” przede wszystkim da się obiektowo pisać z dziedziczeniem nie myśląc o samobójstwie.”

        Zobacz kiedyś na Dejavu. JS jest inny bo powstawał z myślą o skryptach w przeglądarce. Ale inny nie znaczy gorszy. Kwestia przyzwyczajenia. Na pewno jest inny niż to od czego zazwyczaj zaczyna początkujący programista.

        “Po kompilacji …”

        No właśnie, dla mnie to spory minus. Wolę pisać bezpośrednio w JS, nie muszę niczego kompilować. Poza tym to co wypluwają kompilatory przy bardziej złożonym kodzie jest dalekie do optymalności.

        “Bezpieczniej jest nawet napisać kod w C++ … ”

        Tak to się zgadza, tylko w zamian tracisz na szybkości rozwijania aplikacji. Użycie różnych frameworków JS bardzo przyspiesza pracę. Pisać w C++ i kompilować do JS wolą ludzie, którzy i tak na co dzień używają C++. Ci co tworzą tylko aplikacje webowe wolą JS, lub tak jak Ty CoffeeScript i inne podobne wynalazki.

        “Scala niby obiektowo-funkcyjna, ale tej funkcyjności daleko do czystej funkcyjności.”
        Scala pozwala gładko przejść z języka imperatywnego do funkcyjnego. Wejście w Heskell jest trudniejsze. Chyba nie jesteś jakimś językowym, Źydem, żeby tykać tylko to co jest koszerne ;) Język powinno się wybierać ze względów technicznych, a nie ideowych.

        Pisz w czym chcesz i lubisz, tylko nie kontestuj wyborów innych ludzi, bo ci mają swoje powody, być może inne niż Ty.

      • Jakub Konieczny

        Tak, JS powstał dla stron. Jakieś 20 lat temu, kiedy kogoś, kto pomyślał
        żeby napisać użyteczną dynamiczną aplikację w przeglądarce zamykano w wariatkowie.

        Składnia CS jest o wiele milsza dla oka niż JS, polecam się pobawić na http://js2coffee.org/. Stawiam FileWatchera i nie przejmuję się kompilacją. Przed migracją całego skryptu na CS (co poszło dość gładko przy użyciu tamtej stronki, tylko parę kosmetycznych poprawek miałem) zrobiłem wiele testów różnych składni i nie widzę żadnego wielkiego narzutu z tym związanych, CS jest tak zaprojektowany żeby był jedynie nakładką na używane w JS składnie, pozostałe drobnostki załatwia JIT (wspomniane pętle lubi rozbijać na postać SSA, co w sumie i tak JIT sam robi). W przeciwieństwie do Kotlina nie wymaga żadnych dodatkowych bibliotek.

        Wzmianka o C++ była hiperbolą o czym też uprzedzałem.

        Ja nie kontestuję wyborów innych, tylko wyrażam swoje zdanie na temat tego że JS nie jest wcale miłym językiem, mimo że same środowisko jest bardzo elastyczne i użycie języka kompilowanego do JS nie jest złym pomysłem.

      • mikolajs

        “że JS nie jest wcale miłym językiem, mimo że same środowisko jest bardzo
        elastyczne i użycie języka kompilowanego do JS nie jest złym pomysłem.”

        Dla Ciebie nie jest miły, ale dla innych jest. Dla mnie nie ma większej różnicy w użyciu JS w stosunku do innych języków dynamicznych. JS ma trochę inną składnię do której trzeba przywyknąć.
        Co do kompilacji innego języka do JS to widziałbym jeszcze sens gdybym miał używać języka statycznie typowanego. Sam proces kompilacji jednak utrudnia tworzenie aplikacji gdy używa się oprócz JS innego języka po stronie serwera, a całość pakuje do kontenera. Może również utrudniać użycie innych frameworków JS.

      • Jakub Konieczny

        Tysiące developerów JS pewnie nawet nie wie że biblioteki których używają są napisane w Coffee, sam się zdziwiłem gdy chciałem wprowadzić parę zmian w kilku skryptach i ściągnąłem źródła zamiast miniaturki, a tam zamiast plików .js: .coffee, wtedy też zauważyłem że warto się tym zainteresować. Jakbyś poczytał założenia CS to byś wiedział że z zewnątrz jest to całkowicie transparentne, to jest po prostu bardziej ogarnięta składnia dla JS.

        Sam JS nadal ma swoje dziwactwa pokroju (null<0 || null==0) != null<=0 (które ma wartość false i nie rzuca błędu, czego bym oczekiwał), które mógłbym uznać za problem wieku dziecięcego, ale on już ma 20 lat!. Cóż, tego Coffee naprawić nie może

      • mikolajs

        Może i składnia trochę ładniejsza i czytelniejsza niż JS (swego czasu się trochę tym interesowałem), ale jak dla mnie nie warta wysiłku. Różne problemy przy kodowaniu w JS da się dość łatwo rozpracować, znaleźć rozwiązanie w sieci, a w CS miałbym dodatkowy problem. Poza tym musiałbym rozwiązać problem pakowania do kontenera. Tylko po co jak JS mi pasuje? Nie każdy też lubi składnie Pythonową. Chociaż pisałem sporo w Pythonie to nigdy nie polubiłem kontroli zasięgu przy pomocy białych znaków. Zdecydowanie bardzie wolą składnię z nawiasami klamrowymi. Tam IDE samo poprawia mi wcięcia.

      • Jakub Konieczny

        Problem pakowania do kontenera rozwiązuje się parametrem -b przy kompilacji.
        Owszem, nie każdy lubi składnię pythonową. Ale ja tam wolę zarządzać wcięciami niż szukać klamer. Klamra może się zapodziać, wcięcia widać od razu.

      • mikolajs

        “Problem pakowania do kontenera rozwiązuje się parametrem -b przy kompilacji.”
        Chodziło o kontener WAR z JVM i strukturę mavena.

        “Klamra może się zapodziać, wcięcia widać od razu.”
        Dobre IDE od razu pokaże Ci błąd, a i samo zrobi wcięcia.

      • Roman

        Kompilatory C akurat kijowo wykorzystują wektoryzację i nie są żadnym wyznacznikiem. Do dziś nie mają wbudowanych typów wektorowych w standardzie. Co ma nawet język shaderów oparty na C99.
        JS jest dynamiczny, ale większość kodu jest funkcjonalnie statyczna i z tego korzystają optymalizatory w jego JIT.
        A co się nadaje twoim zdaniem do programowania? Bo mi się świetnie w tym programuje. Asynchroniczność sprawia, że to jeden z nowocześniejszych funkcjonalnie języków.

      • Jakub Konieczny

        Kwestia pisania kodu, kompilator z odpowiednią flagą znajdzie i zwektoryzuje, można też to ułatwić kompilatorowi pisząc odpowiednie parametry przy tablicach.

        Wspomniałem że CoffeeScript. jak zauważyłem spora część bibliotek do JS na GitHubie jest źródłowo w Coffee pisana.

    • asd

      Wolałbym się przebranżowić na operatora koparki niż pisać w JavaScript :)