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

2019-06-18 15:28

Rejestracja: 6 lat temu

Ostatnio: 21 godzin temu

3

Obecnie oprogramowanie jest przesadnie rozrośnięte (bloated). Komputery były szybsze, kiedy były wolniejsze. Rozwój hardware'u częściowo spowodował to, że programiści w większości przestali się przejmować pisaniem wydajnego oprogramowania, bo praktycznie niemalże nie mają ograniczeń sprzętowych, jak kiedyś. Większość współczesnego softu to niestety przeciwieństwo zasad YAGNI, KISS i Unix Philosophy. Wspomniane zostały mikroserwisy. Owszem tam może być jakiś dodatkowy narzut w postaci opóźnień sieciowych itp., ale spowolnienie aplikacji nie wynika tylko z wolniejszych połączeń sieciowych. Na pewno nieraz korzystaliście z powolnej aplikacji desktopowej, która w zasadzie internetu do działania nie potrzebuje, albo przymulił Wam system operacyjny. Dodatkowym problemem jest fakt, że sporo firm typu korpo dorzuca do swojego softu wszelkiej maści spyware, który wysyła na ich serwery informacje o użytkownikach. Tego typu praktyki też spowalniają działanie programów.

edytowany 1x, ostatnio: wiciu, 2019-06-18 15:29

Pozostało 580 znaków

2019-06-18 15:59

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

0

Polecam:
https://www.dobreprogramy.pl/[...]ijac-programu,News,87400.html


Pozostało 580 znaków

2019-06-18 16:40

Rejestracja: 3 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: U krasnoludów - pod górą

11

Czyli kolejne standardowe biadolenie o mitycznej szybkości ASM czy C.

Wychowałem się na ośmiobitowcach (C64 głównie), potem Amiga i w sumie nadal daje rade pisać w ASM (dla sportu - polecam http://www.int80h.org/).

Ale te wszystkie koncepcje, że w ASM lub C będzie szybciej - to bzdury.

Dasz radę dopieścić w ASM jakąś procedurkę typu mnożenie macierzy itp... ale przy większym kodzie zaczniesz się gubić co jest w którym rejestrze i w efekcie wyjdzie kod potencjalnie słabszy nić w C.
A do tego rok później wyjdzie nowe CPU z nowymi rejestrami i okaże się, że kod gościa kóry to napisał w Javie jest szybszy, bo po update JVM sam sobie użyje nowych instrukcji i rejestrów, a ty będziesz musiał na nowo wszystko wyrzeźbić.

Przy nietrywialnym kodzie (projekty kilkumiesięczne) nie masz szans konkurować z językami wyższego poziomu, po prostu nie dasz rady zoptymalizować kodu przed końcem cywilizacji. Jest gorzej: maszyny wirtualne (typu JVM) w teorii mogą osiągnąc dużo wyższą wydajność niż statyczne kompilatory, wiedzą o kodzie dużo więcej, (np. które branche są częściej odpalane itp. ).
Pieknie to jest oczywiście tylko w teorii, bo na razie to raczej w bardzo szczegolnych to dobrze działa. (ale jest coraz ciekawiej - see Graal compiler in java). Chwilowo jakbym miał coś docyklowąć na konkretny sprzęt to pewnie bym brał C++ zamiast javy. Z drugiej strony taką potrzebę (komercyjnie) przez ostatnie 20 lat to miałem: prawie raz.

Trochę programów w C/ASM poznałem - wiele z nich ma koszmarne bugi wydajnościowe, których można by uniknąć, gdyby pisano w czymś wyższego poziomu.
(np. w programach C trudniej się robi bezpieczne cache (m.in przez brak GC), więc bywa, że czytamy i parsujemy ten sam plik po 100 razy na sekundę- taki kod u jednego klienta chodzi... ale wystarcza, a zrobienie tego z cachem okazało się bardzo niebezpieczne/trudne (moduł apache)).

Albo - dla odmiany - mamy ostro mutujący kod w Javie/C++ i nie możemy go zrównoleglić, mimo, że na kompie marnuje się 20 rdzeni.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 2x, ostatnio: jarekr000000, 2020-03-08 11:49
Mutujący kod też można teoretycznie zrównoleglic, np. ConcurrentHashMap może przy efektywnym kluczu być używana przez 16 wątków :P - scibi92 2019-06-18 18:26
@scibi92 co innego jest pisać kod explicite na wątki ( java), a co innego pisać normalny kod jednowątkowo, gdzie komplikator, albo runtime sam stwierdzi, że w sumie może sobie coś zrównoleglić. Na JVM mimimalne zrównoloeglenie występuje- Jit i GC chodzą na osobnych wątkach. - jarekr000000 2019-06-19 10:50
Niedoceniana zaleta Javy: alokacja pamięci pod obiekt to jakieś 10 cykli procesora: około dwa ify + przesunięcie pointera w Edenie. malloc() z c to przeglądanie nietrywialnej struktury danych. - Pijany Krawiec 2019-06-29 22:01

Pozostało 580 znaków

W2K
2019-06-19 08:09
W2K

Rejestracja: 14 lat temu

Ostatnio: 2 dni temu

0

Moim zdaniem w przypadku apek webowych noie ma to sensu. Po prostu w takim przypadku zwykle sprawdza się stwierdzenie że czas programisy kosztuje duzo więcej niz czas maszyny. Jeśli widzisz potrzebę zrobienia rzreczy tego typu tzn ze prawopodobnie coś jest nie tak z samą architekturą aplikacji.

Pozostało 580 znaków

2019-06-19 10:55

Rejestracja: 16 lat temu

Ostatnio: 53 minuty temu

0
jarekr000000 napisał(a):

Dasz radę dopieścić w ASM jakąś procedurkę typu mnożenie macierzy itp... ale przy większym kodzie zaczniesz się gubić co jest w którym rejestrze i w efekcie wyjdzie kod potencjalnie słabszy nić w C.

Bardziej złożony kod w asm wygląda trochę jak C, tylko gorzej – tworzy się procedury (które kompilator mógłby zinline'ować), używa zmiennych w RAMie (bo można je ponazywać, a kompilator spokojnie użyłby rejestru) i w efekcie robi się wolniej, zarówno pod względem czasu pisania jak i wydajności.

No ale w celach edukacyjno-rozrywkowych czasami można tak porzeźbić.

Pozostało 580 znaków

2019-06-19 11:20

Rejestracja: 5 lat temu

Ostatnio: 16 godzin temu

0

@jarekr000000:

Kontrprzykład?

But someone did anyways, a fully graphical, multitasking OS that can run from a floppy: menuetos.net. While it's not exactly the same thing as Windows/Linux/MacOS (more primitive/flickers, etc), it's a cool proof of concept of how much space can be saved when you use only assembler.

= oszczędzamy chociażby na błędach stron

@Shalom

Shalom napisał(a):

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?

Nie, po prostu soft dzisiaj jest wielokrotnie bardziej złożony niż kiedyś.

bardziej złożony = wolniejszy. A jeśli, przykład: Word, bardziej złożony nie oznacza posiadający istotnie większą funkcjonalność, to jakby point is proven

przy okazji, dzięki za link do tego menuet.os - dużo fajnych materiałów tam mają - do zabawy super. - jarekr000000 2019-06-19 11:59

Pozostało 580 znaków

2019-06-19 11:33

Rejestracja: 3 lata temu

Ostatnio: 23 minuty temu

0
kmph napisał(a):

@jarekr000000:

Kontrprzykład?

But someone did anyways, a fully graphical, multitasking OS that can run from a floppy: menuetos.net. While it's not exactly the same thing as Windows/Linux/MacOS (more primitive/flickers, etc), it's a cool proof of concept of how much space can be saved when you use only assembler.

Ty serio z tym kontrprzykładem?

Co w nim nie tak? - kmph 2019-06-19 11:34
A co on miał pokazać, że można coś pisać w asm, że kiedyś się pisało, czy, że warto pisać? - TurkucPodjadek 2019-06-19 11:41

Pozostało 580 znaków

2019-06-19 11:40

Rejestracja: 3 lata temu

Ostatnio: 1 godzina temu

Lokalizacja: U krasnoludów - pod górą

2
kmph napisał(a):

@jarekr000000:

Kontrprzykład?

But someone did anyways, a fully graphical, multitasking OS that can run from a floppy: menuetos.net. While it's not exactly the same thing as Windows/Linux/MacOS (more primitive/flickers, etc), it's a cool proof of concept of how much space can be saved when you use only assembler.

= oszczędzamy chociażby na błędach stron

No i pytanie czy używasz tego menuetos ? Da się używać ? Ile rodzajów sprzętu obsługuje, grafika, audio, itp. Pójdzie na moim kompie?
Bo taki linux (który wcale nie jest optymalny) to na starcie musi poobsługiwać całkiem dużo sprawdzeń dotyczących różnego rodzaju sprzętu i jeszcze pokompensować wiele błędów hardwarowych. Ten kod gdzieś musi się znaleźc.

Jak masz jedną platformę sprzętwą to sprawa jest dużo prostsza:
Mój pierwszy okienkowy system to Final III na C64 -zarąbisty i mieścił się w 64 KB ROMU

Final 3
https://rr.pokefinder.org/wiki/Final_Cartridge

Zresza IMO linux jest średnio niewydajny, bo jest napisany w C :-) i ma swoje lata. Cholera wie ile z kodu, który jest w kernelu faktycznie potrzebna na nowych sprzętach.
O wiele ciekawiej wygląda teraz Redox w Ruście, kóry ładuje się do GUI w nic sekund i wygląda, że może być uzywalny - kiedyś.
Gorzej, że jak (jeśli) dopiszą obsługą setek driverów sieciowych, chipsetów itp .. to pewnie też spuchnie, przestanie się mieścić w 50MB i szybko startować.
(A nie wiadomo czy kiedykolwiek dopiszą, bo chyba nadal nie stoi za tym żadna firma z dużą ilością kasy).


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 1x, ostatnio: jarekr000000, 2019-06-19 11:43

Pozostało 580 znaków

2019-06-19 11:51

Rejestracja: 5 lat temu

Ostatnio: 16 godzin temu

0
jarekr000000 napisał(a):

No i pytanie czy używasz tego menuetos ? Da się używać ? Ile rodzajów sprzętu obsługuje, grafika, audio, itp. Pójdzie na moim kompie?

Zdaję sobie sprawę, że pisanie w ASM jest p-dobnie DUŻO mniej wygodne niż w C, które z kolei jest DUŻO mniej wygodne niż w językach wysokopoziomowych.

Dlatego, i owszem, najczęściej użyteczne aplikacje z szeroką funkcjonalnością pisane są w językach wysokopoziomowych.

Ja się na przykład nie piszę na przepisywanie tego w ASM.

Jednak: Ja postawiłem hipotezę, że ten (zrozumiały) trend odbywa się kosztem wydajności; i że przyspieszanie sprzętu pozwala w zasadzie na wejście na wyższy poziom abstrakcji a nie na przyspieszenie działania programów, bo wejcie na wyższy poziom abstrakcji znosi korzyści z przyspieszenia sprzętu. Ktoś zapodał prawo Wrighta, które zdawałoby się to potwierdzać.

Ty postawiłeś tezę, że jest wręcz odwrotnie: że dla nietrywialnych aplikacji to przejście na wyższe poziomy abstrakcji umożliwia wysoką wydajność, podczas gdy pozostawanie na niskim poziomie abstrakcji tę wydajność zabija - niemal zawsze na odcinku ASM - C, niekiedy także na odcinku C - Java.

menuetos nie miał być (w mojej intencji) przykładem na to, że w ASM da się (w praktyce, nie tylko w teorii) napisać bardzo rozbudowany, w praktyce użyteczny system. Miał być przykładem na to, że w ASM można napisać wysokowydajny, nietrywialny system, podczas gdy wg Twojej wypowiedzi - o ile dobrze ją rozumiem - wbrew pozorom system w C byłby wydajniejszy niż system w ASM.

Pozostało 580 znaków

2019-06-19 12:48

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

0

Tak jeszcze a propos tematu: komputery sprzed 30 lat są szybsze od obecnych (przynajmniej w pewnych kwestiach).


edytowany 1x, ostatnio: Freja Draco, 2019-06-19 12:49
To jest jedynie taka ciekawostka, całkowicie bez związku z rzeczywistością :P - cerrato 2019-06-19 12:54
Naprawdę? Nawet w dobie gamingowego wszystkiego? No chyba, że do tego wystarczą kolorowe diody ;) - Freja Draco 2019-06-19 14:47

Pozostało 580 znaków

Odpowiedz

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