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-17 22:15

Rejestracja: 16 lat temu

Ostatnio: 50 minut temu

0

Kolejne 10 razy? To już jest 100-krotne przyspieszenie w porównaniu w .NET!

Z pewnością nie 10 razy, chyba że w jakimś specyficznym, zoptymalizowanym algorytmie. Średnio to będzie raczej 0,1 „raza szybciej”. Albo i wolniej.

zarówno dawniej Word jak i teraz otwiera mi się nie natychmiast

Tu większe znaczenie ma prędkość dysku, i akurat pod tym względem SSD jest sporym krokiem naprzód.

Pozostało 580 znaków

2019-06-17 22:18

Rejestracja: 14 lat temu

Ostatnio: 2 minuty temu

6

@kmph:
Nie musisz gdybać. Jest już zestaw benchmarków: https://www.techempower.com/benchmarks/ Jest C, C++, Java, Go, PHP, Python, C#, JavaScript i wiele innych. Wiarygodność średnia (jak to przy mikrobenchmarkach) ale lepsze to niż nic.

Najbardziej spowalnia baza danych. Jeśli jesteś w stanie trzymać wszystkie dane w RAMie to apka w Javie będzie super szybka. Jeśli musisz trzymać dane w jakimś np MSSQLu to nawet gdybyś resztę okodował w czystym asemblerze to i tak aplikacja jako całość będzie działać wolno. By uzyskać super szybkość musisz w zasadzie pisać cały stos technologiczny od podstaw specjalnie pod własne zastosowania.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-06-17 22:22

Pozostało 580 znaków

2019-06-17 22:31

Rejestracja: 1 rok temu

Ostatnio: 6 minut temu

2

W C# da się zoptymalizować tak kod żeby latał z prędkością natywnych apek, przy czym w natywnych jezykach bez GC i VM łatwiej sobie w stopę strzelić. Może 15-20 lat temu było inaczej tak obecnie nie widzę powodów by celem optymalizacji pisać duży system w czymś natywnym. Co innego kod niskopoziomowy jak osdev, sterówniki, uC etc. I tak 99,9999% z wydajnością to wina programisty czy architektury a nie języka. Już optymalizowałem kod w C# który realizował to samo zadanie ale schodziłem z czasem wykonania z kilku dni do kilku minut a czasem kilkudziesięciu sekund i już mam pare takich optymalizacji na koncie. Najmniej wydajny kod piszą programiści a nie współczesne języki.

edytowany 1x, ostatnio: somedev, 2019-06-18 05:46
*na kONcie - Wibowit 2019-06-17 22:45
z kilku dni do kilkudziesięciu sekund? :O opowiedz - Pinek 2019-06-18 01:15
@Wibowit: dzięki. @Pinek No tak - jak w firmach masz wesoła twórczość i opierasz kod na tablicach niesortowanych a szukasz tam wśród setek tysięcy elementów kilka tysięcy razy. Jak tworzysz nowe tablice i przepisujesz stare bo usuwasz jeden element ... czasami starczyło zmienić strukturę danych na Listę czy Słownik. Czasami okazuje się ze polowe czasu robi się rzecz n a druga polowe kolejnych 10 rzeczy - starczyło jedna puścić w jednym tasku a reszte synchronicznie w drugim o kończyły równo. Czasami starczy deduplikować eventy bo jest wiele takich samych pod rząd. - somedev 2019-06-18 05:50
Generalnie jak jest problem z wydajnością to 1 - trzeba zobaczyć jaki syfiaty jest kod. 2 - zastanowić się nad architektura - może się wymagania zmieniły, 3 - zewnętrzne słabe punkty jak sieć, I/O dysków (dobry ssd jest tańszy nic programista), jakiś wolny WS, na końcu kwestie technologii wykonania czy np nie przepisać na asm (tak wtf i przesadzone bo kod będzie gorszy niż instrukcje generowane przez clr) - somedev 2019-06-18 05:53

Pozostało 580 znaków

2019-06-17 22:36
Moderator

Rejestracja: 16 lat temu

Ostatnio: 13 godzin temu

7

@kmph: większość "zwykłych" aplikacji jest I/O bound a nie CPU bound. Nie ogranicza cię moc obliczeniowa tylko odczyty danych (z dysku ale też z pamięci) albo requesty sieciowe. Bo z jednej strony możesz się ładnie wyskalować z mikroserwisami, postawić po 100 nodów każdego, ale potem każda taka hopka do mikroserwisu to stracone milisekundy i nie ma tu znaczenia czy masz te serwisy w kodzie maszynowym naklepane czy w pythonie.

Jak piszesz soft do crackowania hashy to faktycznie lepiej to zrobić w C, bo tam jedyne co robisz to mielisz coś na CPU.

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ś.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-06-17 22:42

Rejestracja: 3 lata temu

Ostatnio: 19 minut temu

1

Nawet jeśli, zakładając czysto hipotetycznie, masz 2 języki programowania, wolniejszy i szybszy, przy czym zakładamy, że wolniejszy obsłuży 1000 req/sec (pomijamy inne czynniki spowalniające, zakładamy same "surowe" cpu bound), a "szybszy" 10x tyle, czyli 10000 req/sec, a Twoja aplikacja dostaje, powiedzmy 100 000 req/sec, to i tak w przypadku nawet użycia tego "szybszego" masz problem wydajnościowy i nie obejdzie bez rozwiązań w architekturze. Za to często, języki nazwijmy to "szybkie" typu C/C++, zwłaszcza jakiś asm, nie są językami w których masz łatwość utrzymywania/rozwijania projektu, do tego aby pisać np. wydajny kod w asm, to chyba musiałbyś być inżynierem od CPU, który zna go na wylot (marny promil takich programistów jest), w każdym razie musiałbyś być bardziej ogarnięty od programistów kompilatorów do C.

Obecnie znaczenie ma szybkość implementacji logiki biznesowej, do tego obecne języki typu Java (i koledzy z JVMa), Go, Python, Ruby, Rust, Erlang czy nawet JS nadają się podobnie, zakładając dostępność odpowiednich bibliotek (czytaj: nie trzeba w danym projekcie biznesowym wynajdować jakiegoś trywialnego koła od nowa). Więc np. możesz użyć Pythona i mieć 1000 req/sec, zamiast C i 100 000 req/sec (hipotetycznie), ale za to w Pythonie np. apkę napiszesz 10x szybciej i łatwiej będzie Ci zdebugować w razie czego, a w razie problemów wydajnościowych założysz na etapie architektury, że możesz dokładać dodatkowe nody a odpowiedni load balancer nie dopuści, by apka dostała zbyt duży ruch.

Tutaj artykuł, który porusza (m.in) też ten problem: http://thume.ca/2019/04/29/co[...]-in-rust-haskell-c-and-python

Poza tym liczy się też przecież przepustowość i inne cechy sieci. Autor wątku zakłada idealną prędkość przesyłu danych. W realnym świecie tak to nie działa. Nawet jak ktoś ma superwydajny serwer to opóźnienia rzędu 500ms na długich dystansach są traktowane jako norma. - siloam 2019-06-18 07:06

Pozostało 580 znaków

2019-06-17 23:07

Rejestracja: 2 lata temu

Ostatnio: 7 godzin temu

5
kmph napisał(a):

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.

To może twój. Mój się otwiera poniżej sekundy a za kolejnym razem to już w ogóle w pomijalnym czasie. Po prostu używam 20-letniej wersji. Ale nie musisz być hardkorem, zainstaluj sobie kilkunastoletnią :p

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?

Jest nawet gorzej, Prawo Wirtha powiada, że:

Oprogramowanie zwalnia szybciej, niż sprzęt przyspiesza.

Nieoptymalność współczesnego softu jest po prostu koszmarna. Wszyscy wychodzą z założenia, że uzerzy mają gigachercowe wielordzenie to sobie zmielą co trzeba, a to przecież nie nasze kilowaty :p


Pozostało 580 znaków

2019-06-18 00:15

Rejestracja: 14 lat temu

Ostatnio: 2 minuty temu

3

U mnie ostatnio comiesięczny skan McAfee na firmowym laptopie trwał ok 162 godziny. Co prawda wydaje mi się, że w to wliczał się czas w uśpieniu, ale i tak przez jakiś tydzień antywirus zarzynał mi 2 rdzenie w 2 rdzeniowym laptopie. Dla mnie zostały głównie HyperThready. Ciekawe ile % wydajności traci się na korpo krapie instalowanym w standardzie na korpo lapkach?


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit, 2019-06-18 00:16
Pokaż pozostałe 8 komentarzy
No ja też nie mogę wyłączać antywirusa. Ale mogę zrobić to: while($true) { ps -Name "*antyvir*" | kill -Force; Start-Sleep -m 500; } ;) - somekind 2019-06-18 14:47
McAfee to nie antywirus tylko KUPA (Korporacyjnie Uzasadniony Pakiet Antywydajnościowy). Co radzi założyciel firmy tego oprogramowania: https://www.youtube.com/watch?v=bKgf5PaBzyg - vpiotr 2020-03-08 04:15
@vpiotr: Klasyk. Niestety nie mam pistoletu :) Ale od czasu napisania tego posta dostałem nowego lapka firmowego i teraz mam 4 rdzenie, a sam antywir jakoś tak rzadziej zamula. Może pod Windowsem 10 coś tam zoptymalizowali i crap szybciej działa. - Wibowit 2020-03-08 07:27
4 rdzenie? To co wczesniej miales? 😁 - vpiotr 2020-03-08 10:21
2. Jest w poście napisane przecież. ZTCP to było chyba Core i7-4600M. W naszym korpo używa się głównie Thinkpadów, a taki Thinkpad T470 oferował tylko Core i7 7. generacji gdzie seria U miała tylko 2 rdzenie. Dopiero w nowszym T480 (którego teraz mam) jest Core i7 serii U z 4 rdzeniami. - Wibowit 2020-03-08 10:22

Pozostało 580 znaków

2019-06-18 07:48

Rejestracja: 1 rok temu

Ostatnio: 1 godzina temu

1
kmph napisał(a):

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).

Prawda, tylko że koszty utrzymania to nie tylko infra, to też ludzie którzy muszą ją utrzymywać :) Po prostu w dzisiejszych czasach cena krzemu << cena ludzi. Warto przeliczyć to sobie w głowie, to potem okazuje się, że koszty chmury to jakaś znikoma część :)

Pozostało 580 znaków

2019-06-18 09:08

Rejestracja: 7 lat temu

Ostatnio: 4 dni temu

0

Jak już tutaj napisano - aplikacje webowe rzadko mają problem z mocą obliczeniową - cięższe procesy są przetwarzane jako batch'e, a aplikacja webowa ma po prostu działać w akceptowalnej dla użytkownika prędkości.
Dodatkowo nawet w samych językach wysokiego poziomu używa się nieefektywnych rozwiązań - choćby i powszechnie stosowane kolekcje obiektów (zamiast np. tablic prymitywów). Ot takie czasy, siła procków rośnie.

Ciekawie może też na to wpłynąć serverless, np. na Lambdzie płaci się za bloki czasowe po 100ms, więc może się okazać, że o ile request nie musi się wykonać super szybko, optymalizacja ze 199ms do 100ms nie ma sensu biznesowego. - kelog 2019-06-18 09:20
Właśnie stosowanie tablic prymitywnych zamiast sensownych kolekcji to w wielu przypadkach problem. - somedev 2019-06-18 09:58
@somedev - czasem tak, czasem nie. Raczej jednak nie spotyka się tablic prymitywów w aplikacjach webowych. @kelog - właśnie o to chodzi, że nawet zejście z średniego czasu 200ms do powiedzmy 40ms na obsługę nie zostanie pewnie odnotowane przez użytkownika - wartek01 2019-06-18 10:20

Pozostało 580 znaków

2019-06-18 12:16

Rejestracja: 14 lat temu

Ostatnio: 2 minuty temu

6

Języki wysokiego poziomu skracają https://en.wikipedia.org/wiki/Time_to_market a to jest często kluczowe.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

Odpowiedz

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