Aktywne Wpisy
Na ile ją oceniacie?
- 1/10 4.3% (35)
- 2/10 5.9% (48)
- 3/10 12.4% (101)
- 4/10 18.4% (150)
- 5/10 23.8% (194)
- 6/10 20.0% (163)
- 7/10 9.3% (76)
- 8/10 2.5% (20)
- 9/10 3.3% (27)
controll +18
#nieruchomosci skad wy niby #!$%@? bierzecie 25% wkladu pod hipo za 700k? Czy w polsce mamy wysyp bogaczy ? Kazdy 25latek ma na koncie 175k?
Aktywne Znaleziska
1. #javascript nie jest najlepszy do wykonywania złożonych obliczeń.
2. jeśli powyższe jest prawdą to w czym tkwi słabość js w tym obszarze?
3. czy ma wpływ na wydajność kodu js środowisko w którym ten kod odpalimy? Tzn. ten sam kod odpalony w przeglądarce i w node.js?
wołam; @Sh1eldeR, @Marmite, @Ginden oraz innych znających się na JS.
To zależy :P a tak serio, przeglądarka ma jeszcze wiele innych rzeczy do ogarnięcia, interfejs użytkownika,
1. Tak.
2. Brak wsparcia dla SIMD, brak specjalizowanych typów liczb (jest tylko Float64, który przez V8 jest czasem optymalizowany do UInt31), brak możliwości wykonywania obliczeń na GPU, wątki mają duży overhead, dane zwykle są nielokalne.
3. Nie ma znaczącej różnicy między przeglądarką a Node.js uruchomionymi na tym samym komputerze.
i takiego https://github.com/mikeseven/node-opencl chociaż troszkę rozwiązuje problemy, czy to tylko proteza a wydajność leży i kwiczy? Lepszym rozwiązaniem będzie napisanie modułu dla nodejs w c?
Drugie pewnie jest dobrym rozwiązaniem, ale Twój serwer produkcyjny raczej nie ma karty graficznej.
Ogólnie to co Ty masz zamiar w ogóle robić?
- takie, których nie musisz rozwiązywać, bo można je sprytnie rozwiązać znacznie łatwiej
- takie, których nie rozwiążesz sam, bo ludzie pracują nad tym od wielu lat bez dużych sukcesów (większość problemów optymalizacyjnych)
- takie, które rozwiązuje dedykowane rozwiązanie (full text search)
- takie, które powinien rozwiązać Twój admin bazy danych lub analityk (wszelkiego rodzaju grafy, wyliczanie podobieństwa, rekomendacje), bo i tak
Niemal na pewno prawda, bo praktycznie na pewno są języki lepsze od niego do złożonych obliczeń.
(@Ginden, chyba warto, żebyś też to przeczytał)
a) niemożność klasycznego programowania współbieżnego, czy raczej: bardzo restrykcyjne podejście do współbieżności. Blok (sekwencja) kodu w JS nigdy nie zostanie przerwana w połowie. Jeśli
a) brak konkretów i konsensusu w sprawie wątków. Do ES2016 niemal pewno nie wejdą.
b) to tylko int31 obecnie.
c) Może będzie, może nie. Prace chwilowo są martwe, aczkolwiek dobrze wróży istnienie jakiegokolwiek standardu.
d) analiza leksykalna jest trywialna pod warunkiem operacji na pewnej grupie typów - prymitywy, tablice mrożone. Większość operacji graficznych można łatwo zrównoleglić.
Co więcej, bailout nie jest niczym trudnym w przypadku czystych funkcji - jeśli któraś
a) Ale WebWorkery już masz w przeglądarkach. Jest też biblioteka w Nodzie (choć chyba jej nigdy nie użyłem). Prace nad bardziej zaawansowanymi rzeczami trwają i pochłonęły już trochę czasu, ale trochę tutaj końca nie widać.
b) Zauważ też, że obecne implementacje SIMD wspierają wektory większej liczby typów: Float32, Float64, Int32... Ale zostawmy SIMD: to samo można powiedzieć o Typed Arrays [1]!
c) Jest duży nacisk na SIMD w ramach grupy
@Sh1eldeR: mógłbyś mi to troszkę bardziej wytłumaczyć? O co chodzi z wszędobylskim operatorem przypisania, o efektach ubocznych coś słyszałem, dlaczego nie jest to język czysto funkcyjny, dlaczego clojure jest lepszy i dlaczego "kod w nim napisany nie pójdzie ot tak na
B) gdzie masz implementacje SIMD w przeglądarce? Co do TypedArrays - w domu przejrzę kod źródłowy V8 i SpiderMonkey, ale AFAIR TypedArrays tylko przechowują dane jako typ, w momencie pobierania są one zmieniane w int32, int31 lub float64.
c) Nacisk jest, implementacji brak. A