Wątek przeniesiony 2019-06-20 21:57 z przez cerrato.

Jak duże spowolnienie wynika używania języków wysokiego poziomu?

Odpowiedz Nowy wątek
2019-06-17 21:59

Rejestracja: 5 lat temu

Ostatnio: 16 godzin temu

3

Hipotetyczna sytuacja: Buduję sobie webappkę, dajmy na to w C# albo Javie. Nagle zaczyna mi przybywać użytkowników, apka mi siada, szukam zatem możliwości umieszczenia jej na farmie serwerów i jeszcze co prędzej modyfikuję kod, by dało się go w ten sposób zrównoleglić, bo pisząc apkę nie myślałem o skalowalności i głupio napisałem ją tak, że działa wyłącznie na jednym serwerze.

Ile z tego problemu wynika z faktu, że używam C# a nie C++? Istnieje nastawiony na wydajność framework C++-owy do serwisów webowych. Jak bardzo może być on szybszy od takiego np. ASP .Net? Ile razy więcej użytkowników na raz może obsłużyć na tym samym serwerze? Bo jeśli np. 10, to od razu spadają nam koszta utrzymania apki (mniej musimy płacić za chmurę albo nawet i wcale, bo stronę obsługuje "serwer" w postaci laptopa w szafie w naszym domu).

Aj tam, C++. Pójdźmy dalej, C? Gdzie tam. For the sake of argument zastanówmy się nad webappką napisaną w asemblerze. Są szaleńcy w to się bawiący. Ile mogłoby wynosić przyspieszenie w porównaniu z C++? Kolejne 10 razy? To już jest 100-krotne przyspieszenie w porównaniu w .NET! Laptop w szafie dałby radę nawet dla całkiem dużych serwisów, dla których w przypadku .Neta trzeba by już porządnej farmy serwerów (i architektury appki pod taką farmę pisanej)?

Dlaczego pytam. Naszła mnie bowiem myśl, że chociaż przez ostatnie 15-20 lat komputery przyspieszyły o rzędy wielkości (4 rdzenie po 3GHz każdy to norma nawet dla sprzętów ze średnio-dolnej półki vs jeden rdzeń z taktowaniem liczonym w megahercach), to jednak zarówno dawniej Word jak i teraz otwiera mi się nie natychmiast - trzeba przeczekać splash screen. A przecież podstawowe możliwości nie zmieniły się. Czy nie jest zatem tak, że im bardziej komputery przyspieszają, tym bardziej spowalnia software, bo devom nie chce się go optymalizować oraz korzystają z wolnych języków / frameworków / itp (bo są wygodniejsze), i w konsekwencji przyspieszanie komputerów nic nie daje, bo się to wyrównuje ze spowalniającym oprogramowaniem?

Stąd też wytrzasnąłem to oczekiwane 100-krotne przyspieszenie asemblera w porównaniu w C#; stukrotne przyspieszenie komputerów nie przyspiesza ładowania się Worda.

Dobry przykład z Wordem. - Silv 2019-06-17 23:56
A na Rust, Swift, Crystal można przepisać te apkę webową? Wymieniłbym jeszcze Go, ale raczej nie jest już dużo szybszy od Javy. - light 2019-06-18 16:10
co do tego worda, to dość długo miałem równocześnie office 2013 i jakiś tam najnowszy nawet nie wiem. Każdy program offica w najnowszej wersji odpla się szybciej niż tez z 2013 wiec to nie prawda że nie optymalizuja - _flamingAccount 2020-03-07 21:32

Pozostało 580 znaków

2020-03-23 19:55
Moderator

Rejestracja: 12 lat temu

Ostatnio: 4 minuty temu

0

HiPE ma teraz problemy, bo nie został zaktualizowany do najnowszych ERTS. Ogólnie tak, Erlang jest wolniejszy od Javy w CPU bound, ale IO ma zdecydowanie łatwiej rozwiązane, przez co ewentualne braki wydajności są nadrabiane przez zręczniejszą obsługę IO, która jest IMHO jedną z największych zalet tej platformy.


Dlatego właśnie aplikacja napisana na Erlang VM może zredukować liczbę maszyn (czyli koszty) przy dużym ruchu. - donPietro 2020-03-25 12:44
I tak i nie, to zależy od ruchu oraz od tego jakiego typu to aplikacja. - hauleth 2020-03-25 16:27
Zreczniejsza obsługa I/O nie oznacza, że Erlang na jakiś patent na zmniejszenie obciążenia systemu operacjami I/O. Możliwe, że pewne rodzaje oprogramowania pisze się łatwiej, ale zasadniczo nie będzie to wydajniejsze niż analogiczny program napisany sensownie w C++/Javie. Poza tym współczesne I/O jest bardzo szybkie. Coraz częściej widzę że wąskim gardłem jest CPU i pamięć. - Krolik 2020-03-25 19:37
Tu nie chodzi mi o to, że IO w Erlangu jest jakoś magiczniej wydajniejsze, bo specjalnie nie jest. Jednak ideą jest to, że jest wygodniej pisać wydajnie oraz konstrukcje języka wspomagają niektóre aspekty wydajnej pracy. Przykładowo GC w Erlangu jest IMHO bardziej przejrzyste niż w Javie (w 90% przypadków jest to zwykły heap, który jest niszczony jak tylko umrze proces, a większość z nich podlega pod generational hypothesis). Wbudowane wsparcie dla IO vectors też jest genialnym rozwiązaniem - hauleth 2020-03-26 11:48

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0