Czy Kotlin naprawdę jest lepszy od C#?

Zakręcony Samiec napisał(a):

Może i oferuje, ale za kilka lat i tak to trafi do Javy

Nawet nie wiem jak skomentować kilka lat... Po pierwsze wątpliwe, że wszystkie udogodnienia trafią do Javy. Cześć pewnie tak, ale już teraz Java staje się składniową pokraką z obecnym wsparciem dla var. Po drugie Kotlin też się cały czas rozwija i będzie dodawał nowe rzeczy do składni.

Zakręcony Samiec napisał(a):

a Kotlin już zawsze będzie powolną nakładką Javy.

Zdefinjuj, co znaczy powolną.

Zakręcony Samiec napisał(a):

Wkurza fakt, że przez Kotlina rozrosło się bardziej Intellij, ponieważ zrobili z Kotlina nierozłączanego pasożyta w tym IDE.

A to problem odinstalować plugin?

Raczej można tylko kompilator Kotlina odinstalować, Kotlin file/class i Kotlin script nadal będzie widoczne, to jest na stałe zintegrowane z IDE od JetBrains.

Ponieważ trochę się czasem zajmuje ratowaniem różnych produkcji (mniej niż bym chciał, ale jednak) to wkleję tylko rysunek poglądowy:

Różnice w typowych aplikacjach miedzy np. Kotlinem, a Javą są, na komfort użytkowania aplikacji nie wpływają znacznie. Kod funkcyjny w JVM wygląda słabo w mikrobenchmarkach, ale przeważnie nie stanowi o wydajności aplikacji.

Dla takiego twittera, który działa na setkach serwerów urwanie procenta z CPU to jest oszczędność kasy... i co ciekawe - tam używają Scali. (Był w tym roku ciekawy wykład Chrisa Thallingera jak to poprawki w JVM (Graal) dały im ten jeden procent)

Po prostu bezpieczeństwo, stabilność i czytelność kodu są ważnejsze. Lata temu (rok 2000) byłem na wykładzie ludzi zaangażowanych w kodowanie Apache HTTP, nadal jednego z kluczowych serwerów na uniksach - dla nich też takie były priorytety. Szybkość daleko za czytelnością kodu (wtedy to był dla mnie szok). Dzięki temu udało im się utrzymać jakoś ten projekt (w C!) i (przy okazji) osiągnąć całkiem niezłą szybkość działania. Łatwiej poprawiać czysty sensowny kod niż mętlik.

W tej chwili faktycznie jeden z celów teamu Oracle/ JVM - poprawa działania i diagnostyki(!) kodu funkcyjnego. Z tym, że to nie znaczy, że jest źle, po prostu da się jeszcze poprawić.

Kod funkcyjny ma jedną wielką przewagę w wydajności, jest lepiej skalowalny - nie mutujemy to łatwo rozrzucać.- im więcej rdzeni będzie dochodzić tym ta przewaga bedzie rosnąć. Już teraz to widać przy bigdata (Spark/scala), blockchainach (Haskell!!).

Co do tematu -za słaby jestem z C#, żeby się wypowiadać. Kotlin ma jasne przewagi nad javą - polegające na tym, że powstął później i czerpie z doświadczeń Scali i Javy. Dzięki temu ma dużo prostszą i elegantszą składnię od nowej javy, a wielokrotnie większe mozliwości.

Dla wszystkich nadal biadolacych jak im ta lambda zużyła dwanaście bajtów i 6 cykli CPU - ryjcie proszę w płytkach FPGA, będziecie mieli jeszcze wydajniej, mniej zajmiecie pamięci, mniej zużyjecie prądu i w ogóle będzie wypas. Dlaczego jeszcze nie ryjecie?

Ile jest prawdy w tematach

Rynek zweryfikuje czy Kotlin się przyjmie, czy pozostanie w swojej niszy jak Scala. Jak na razie Swift cały czas pnie się w górę, odkąd Apple go udostępniło jako Open Source jest wykorzystywany jak język backendu :)

@jarekr000000: @Wibowit

Co do Escape Analysis, czy w związku z tym można założyć, że możemy tworzyć funkcje za każdym razem kiedy są ona używane, np: new AddTwo().apply(3) i nie wpłynie to tragicznie na wydajność, rozmiar sterty i czasy trwania GC, bo zostanie ona zaalokowana na stosie? I nie potrzebujemy optymalizować tego (pytanie czy rzeczywiście to byłaby optymalizacja) implementując funkcje jako singletony? Mam na myśli np coś takiego: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/Comparators.java#l47 (chociaż gdyby to miałoby nie pomóc to dlaczego jest to tak zaimplementowane w jdk).

Escape Analysis jest jedną z wielu optymalizacji i wchodzi do gry po sprofilowaniu kodu przez JITa - innymi słowy, działa dopiero po rozgrzaniu JVMki. Druga sprawa to to, że escape analysis jest optymalizacją dość lokalną (ze względów praktycznych, by ograniczyć czas analizy kodu), więc jeśli obiekt przechodzi przez wiele metod, które nie są wklejone (inline'ing) to escape analysis nie zadziała. Jednak w częstym przypadku typu new Klasa(a, b, c).metoda(x, y ,z) escape analysis sobie świetnie radzi zakładając, że zarówno konstruktor jak i metoda są w miarę krótkie.

Trzeba też wziąć pod uwagę zyski i koszty. Jeśli zysk (wydajnościowy) jest minimalny, a koszt (czytelności kodu) jest dość duży to nie opłaca się kombinować. Optymalizacje w JDK wpływają na wydajność bardzo dużej ilości kodu, natomiast optymalizacje w jednej metodzie w JanuszAppie mają zwykle wpływ tylko na ten mały kawałek kodu. Polecam po prostu odpalić profiler na swojej aplikacji i sprawdzić gdzie CPU spędza najwięcej czasu.

Niestety żadne te nowe języki nie nadają się do pisania wydajnych gier komputerowych, a to właśnie takie gry na PS4 czy PC napędzają technologię. Są tworzone benchmarki, które już wyglądają jak rzeczywistość. Obecnie C++ i nawet D i Rust nie jest dla niego zagrożeniem, a co dopiero języki typu C# czy z maszyny wirtualnej JVM. Większośc ludzi jak i z branży IT nie zachwyca się sklepem komputerowym, stroną banku tylko wydajnymi grami, sorry Winnetou!

Szalony Program napisał(a):

Niestety żadne te nowe języki nie nadają się do pisania wydajnych gier komputerowych, a to właśnie takie gry na PS4 czy PC napędzają technologię. Są tworzone benchmarki, które już wyglądają jak rzeczywistość. Obecnie C++ i nawet D i Rust nie jest dla niego zagrożeniem, a co dopiero języki typu C# czy z maszyny wirtualnej JVM. Większośc ludzi jak i z branży IT nie zachwyca się sklepem komputerowym, stroną banku tylko wydajnymi grami, sorry Winnetou!

Rynek ier typowo konsolowych czy pc dużej produkcji dziś nie jest taki jak 15 lat temu. Dziś masz mnóstwo gier w przeglądarce / mobilnych. Popatrz na taka firmę jak https://supercell.com/en/
Kilka lat temu zainwestowano w nich o ile dobrze pamiętam 80mln $. Żyją do dziś i chyba osiągają całkiem niezłe wyniki. A jak widać po produkcjach nie są to wypasione produkcje wyglądające jak pełnometrażowe superprodukcje filmowe.
Jest dużo małych firemek produkujących gry niekiedy bardziej grywalne niż te produkcje na które wydano miliony dolarów. Optymalizacja ma coraz mniejsze znaczenie bo sprzęt jest wydajniejszy. Oczywiście czasami ta oszczędność optymalizacji powoduje ledwo 60fps na 2080GTX ale to już inne sprawa.

Co do JVM - kilka lat temu grałem w Drakensang Online napisane podobno w całości w Java. Nie wiem ile w tym prawdy ale grafika robiła na mnie wrażenie i na moim laptopie również bo gotował się jak czajnik z wrzątkiem. Plus, że nie musiałem pobierać jakichś mega paczek i instalować, a graczy też było tam dość sporo.

Co do powyższego zdania o grach.
Redengine wiedźminowski jest zrobiony w C++ . Oczywiiście podstawa to zrzucenaie co się da na kartę ( HLSL itd).

Co do javy : Dawno temu, żeby pokazać, że to bzdura chłopaki przerobili źródła quake 2 na javę i odpalili - wyszło całkiem nieźle.
https://bytonic.de/html/jake2.html

Java nie jest idaelna do robienia gier AAA, bo ma nadal nieprzewidywalny GC i wywołania GPU są kosztowniejsze niż z C/C++. Ale obie rzeczy się poprawiają. Moja ulubiona gra jest w Javie i to na VR (vivecraft).

Co do wydajności new AddTwo().apply(3) to zastanawianie się nad tym to oznaka tzw. mikrooptymalizacji - czyli źródła zła wszelkiego.
Rada praktyczna: patrzysz na linijkę, szacujesz czy jest wywoływana ponad 1000 razy na sekundę?

• Jeśli nie - olewasz i idziesz dalej (99% procent przypadków)
• jeśli tak to dopisz benchmark (JMH) i sprawdź czy szybkość zadowala (i dodatkowo możesz podejrzeć jak się zachowuje - choć jest to trudne - nawet z -
  XX:+PrintAssembly trudno coś wywnioskować). Profilery łgają - trzeba sie dużo naoglądać i naeksperymentować, żeby jakieś rozsądne wnioski wyciągnąć. Jedyne, co się w miarę tanio robi to porównanie z alternatywną wersją -
  jeśli dobrze zrobiony benchmark (z użyciem JMH) pokaże, że czas new AddTwo().apply(3) jest praktycznie taki sam jak alternatywy bez tworzenia obiektu to znaczy, że escape analysis zadziałało.
  Co gorsza Dobrze zrobiony benchmark to niestety zwierz rzadki.

Ten benchmark jest zły?
youtube.com/watch?v=qlyzo9ll9Vw

Szalony Program napisał(a):

Niestety żadne te nowe języki nie nadają się do pisania wydajnych gier komputerowych, a to właśnie takie gry na PS4 czy PC napędzają technologię. Są tworzone benchmarki, które już wyglądają jak rzeczywistość. Obecnie C++ i nawet D i Rust nie jest dla niego zagrożeniem, a co dopiero języki typu C# czy z maszyny wirtualnej JVM. Większośc ludzi jak i z branży IT nie zachwyca się sklepem komputerowym, stroną banku tylko wydajnymi grami, sorry Winnetou!

Gierki napędzają rynek gier i tyle. Serwerowe maszyny są o rzędy wielkości mocniejsze od konsoli PS4 czy typowego blaszaka. Kilkudziesięciordzeniowe procesory nie są tworzone do gier. Podobnie płyty główne obsługujące setki gigabajtów albo i terabajty RAMu. Nowa technika renderowania trawy nie ma absolutnie żadnego wpływu na życie przeciętnego Kowalskiego. Od bajerów graficznych sklep komputerowy nie będzie działał lepiej, strona banku też. Przeciętny użytkownik komputera spędza najwięcej czasu przeglądając neta, a na stronach internetowych rządzi JavaScript.

To prawda JVM jest przystosowany do olbrzymiej mocy obliczeniowej, tylko czy dobrze wykorzystuje te tysiące rdzeni połączone na kilku płytach głównych z terabajtami RAMu w porównaniu do języków kompilowanych? Chodzi tu o wielowątkowość procesorów.

Java w porównaniu do C++ przede wszystkim dobrze wykorzystuje czas programisty. Programista zamiast pałować się z memory corruption czy przekombinowanym metaprogramowaniem może skupić się na dowożeniu funkcjonalności biznesowych i wysokopoziomowych optymalizacjach.

Sama (stosunkowo niewielka) przewaga wydajnościowa C++ nie jest gwarantem satysfakcjonującej wydajności. Programista C++ może np dwa tygodnie optymalizować parsowanie jednego raportu, a programista Javy w tym czasie zrobi jeszcze pamięć podręczną na raporty, zrównoleglenie na wiele maszyn i np wstępne filtrowanie raportów dzięki czemu danych do parsowania jest znacznie mniej. Efekt będzie taki, że w C++ parsowanie pojedynczego raportu będzie 2x szybsze niż w Javie, ale cały system w Javie będzie 10x szybszy niż w C++, bo wersja Javowa będzie znacznie sprytniejsza i uniknie dużej ilości niepotrzebnej pracy.

W aplikacjach biznesowych okazji do unikania niepotrzebnej pracy, zrównoleglania jej bądź sprytnego rozkładania obciążenia albo do tworzenia różnego rodzaju pamięci podręczych jest mnóstwo. Stąd czas najlepiej przeznaczyć na takie wysokopoziomowe optymalizacje zamiast żyłowania mielenia danych w kółko. Co więcej - typowe kolekcje czy idiomy w Javie nie są wyżyłowane pod względem wydajnościowym. Implementując własne hashmapy, używając niskopoziomowych pętli, etc można zyskać sporo wydajności, ale ogarnięty programista tego nie robi dopóki nie będzie chociażby podejrzeń, że dany kawałek kodu odczuwalnie spowalnia system.

A odpowiadając na pytanie wprost: Tak, Javowy ekosystem ma wiele metod/ bibliotek/ etc do obsługi wielowątkowości, wieloprocesowości, rozproszenia na wiele maszyn, itd Polecam poczytać o tzw Big Data - tam JVM ma bardzo silną pozycję, np jest: https://en.wikipedia.org/wiki/Apache_Spark

Wibowit idąc Twoim tokiem myślenia, języki nowsze takie jak Kotlin, Swift może i Go powinny jeszcze bardziej ułatwiać rozwiązywanie problemów programisty. Więc po co się zatrzymywać na samej Javie? Gnać do przodu za językami wyższego poziomu, celowo nie wymieniłem tu ani jednego języka skryptowego, chociaż mogłem taki Elixir.

Wibowit napisał(a):

Szalony Program napisał(a):

Niestety żadne te nowe języki nie nadają się do pisania wydajnych gier komputerowych, a to właśnie takie gry na PS4 czy PC napędzają technologię. Są tworzone benchmarki, które już wyglądają jak rzeczywistość. Obecnie C++ i nawet D i Rust nie jest dla niego zagrożeniem, a co dopiero języki typu C# czy z maszyny wirtualnej JVM. Większośc ludzi jak i z branży IT nie zachwyca się sklepem komputerowym, stroną banku tylko wydajnymi grami, sorry Winnetou!

Gierki napędzają rynek gier i tyle. Serwerowe maszyny są o rzędy wielkości mocniejsze od konsoli PS4 czy typowego blaszaka. Kilkudziesięciordzeniowe procesory nie są tworzone do gier. Podobnie płyty główne obsługujące setki gigabajtów albo i terabajty RAMu. Nowa technika renderowania trawy nie ma absolutnie żadnego wpływu na życie przeciętnego Kowalskiego. Od bajerów graficznych sklep komputerowy nie będzie działał lepiej

Spłaszczenie tematu po całości. "Gierki" napędzały rynek GPU (i wciąż w jakimś stopniu napędzają), ale GPU, to od bardzo dawna nie są zabawki tylko dla rozwydrzonych dzieciaków, co by im klatki nie uciekły, tylko profesjonalne jednostki obliczeniowe.

Skad pomysl, ze gry sa tylko dla rozwydrzonych dzieciakow?

Spłaszczenie tematu po całości. "Gierki" napędzały rynek GPU (i wciąż w jakimś stopniu napędzają), ale GPU, to od bardzo dawna nie są zabawki tylko dla rozwydrzonych dzieciaków, co by im klatki nie uciekły, tylko profesjonalne jednostki obliczeniowe.

Pisałem algorytmy w OpenCLu, nawet mam projekt na GitHubie: https://github.com/tarsa/SortAlgoBox
Gierki jednak w minimalnym stopniu korzystają z OpenCL, CUDA i tym podobnych, a więc jak niby napędzają technologie serwerowe? W żaden.

Wibowit idąc Twoim tokiem myślenia, języki nowsze takie jak Kotlin, Swift może i Go powinny jeszcze bardziej ułatwiać rozwiązywanie problemów programisty. Więc po co się zatrzymywać na samej Javie? Gnać do przodu za językami wyższego poziomu, celowo nie wymieniłem tu ani jednego języka skryptowego, chociaż mogłem taki Elixir.

Co do języków kaczo typowanych to mam pewną hipotezę, którą tu już na forum wielokrotnie przedstawiałem. Otóż moim zdaniem takie języki nie nadają się do wieloletnich korpo projektów, gdyż brak statycznej analizy utrudnia utrzymywanie dobrej jakości kodu. Do takiej Javy jest multum bardzo silnych narzędzi do refaktorowania, a w Pythonie, JavaScripcie etc jest słabiutko. Kod tworzony przez wiele lat, przez wielu programistów o różnym stopniu zaawansowania trzeba ciągle poprawiać i przerabiać, by nie zrobiło się z niego totalne dziadostwo, więc ten automatyczny i niezawodny refaktoring w Javce jest na wagę złota. Nawigacja po projekcie też kuleje w językach kaczo typowanych. W językach statycznie typowanych IDE bez problemu przeniesie mnie do definicji klasy czy metody, a w Pythonie może tak, może nie.

Wibowit napisał(a):

Spłaszczenie tematu po całości. "Gierki" napędzały rynek GPU (i wciąż w jakimś stopniu napędzają), ale GPU, to od bardzo dawna nie są zabawki tylko dla rozwydrzonych dzieciaków, co by im klatki nie uciekły, tylko profesjonalne jednostki obliczeniowe.

Pisałem algorytmy w OpenCLu, nawet mam projekt na GitHubie: https://github.com/tarsa/SortAlgoBox

Wybacz, że zapytam, ale co to wniosło do dyskusji?

Gierki jednak w minimalnym stopniu korzystają z OpenCL, CUDA i tym podobnych, a więc jak niby napędzają technologie serwerowe? W żaden.

Wytłumaczę (nie sądziłem, że muszę): OpenCL, CUDA i ogólnie tego typu wynalazki powstały, bo tworząc wydajne chipy do gier okazało się, że moc obliczeniowa tych jednostek może się przydać do czegoś więcej, niż tylko do gier. I do tego poszerzyć krąg klientów. Żadna nvidia/ati/3dfx czy inne tworki, które dawniej istniały, nie tworzyły sobie GPU, bo spodziewały się, że za jakieś X lat w przyszłości, przyda się to do łamania haseł, kopania krypto lub BigData, tylko tworzyły, bo chciały zarabiać i wiedziały, że gracze będą chcieć grać w gry i zapłacą za coś, co może im rozrywkę uprzyjemnić. Także OpenCL masz, (m.in) dlatego, że ktoś kiedyś (a dziś pewnie też), chciał sobie zwyczajnie pograć i mieć smooth rozrywkę.

Więc gadanie, że "gierki napędzają rynek gier i tyle", to można potraktować w kategoriach zaklinania rzeczywistości, owszem - można, pytanie czy dyskutujemy o faktach, czy o czyiś wyobrażeniach o nich?

Gierki napędzają rynek gier i tyle. Serwerowe maszyny są o rzędy wielkości mocniejsze od konsoli PS4 czy typowego blaszaka

a po co zwykli ludzie kupują dobre procesory typu i5 i7 ryzen i grafiki, jak nie po to aby grać w gry i ewentualnie raz na X jakiś zwykły program wymagający zasobów?

a czy to nie z tych pieniędzy finansuje się R&D firm typu amd intel nvidia itd?

Kto generuje większy zysk 100 graczy czy 10 pro? 100x400 usd (i7 6700k@newegg) vs 10x1800 usd (ryzen 2990wx@newegg)

Przy tych cenach wystarczy, że 45 grajków kupi takiego procka i włożyli tyle pieniędzy co 10 pro

obstawiam, że ratio gracz:pro (który faktycznie wydaje dużo na hardware) jest pewnie typu 1000:1 (zrób risercz)

@TurkucPodjadek:
Nie zaprzeczam, że rozwój GPU poskutkował wyewoluowaniem GPGPU (chociaż niekoniecznie musiało to w ten sposób wyewoluować, bo OpenCL ma więcej implementacji niż GPU i CPU, ale mniejsza z tym). Napisz mi jak na bieżąco wydawane gierki, którymi zachwyca się większość ludzi (o czym pisał anonim kilka postów wcześniej) napędzają technologie serwerowe.

@WeiXiao:
Rynek procesorów serwerowych to nie tylko Intel i AMD. Jest sporo innych producentów platform serwerowych. Sam Intel na serwerach zarabia bardzo dużo. Natomiast gierki mają spory problem by skalować się na kolejne rdzenie i nikogo nie obchodzi jak działają na prockach serwerowych.

@Wibowit

Rynek procesorów serwerowych to nie tylko Intel i AMD.
Jest sporo innych producentów platform serwerowych

jaki market share?

Sam Intel na serwerach zarabia bardzo dużo.

no ok, a ile %owo?

Natomiast gierki mają spory problem by skalować się na kolejne rdzenie i nikogo nie obchodzi jak działają na prockach serwerowych.

zatem co? procki na gierkach znacznie utrzymują R&D z którego m.in są procki serwerowe (no chyba, że masz dane, z których wynika inaczej)

Napisz mi jak na bieżąco wydawane gierki, którymi zachwyca się większość ludzi (o czym pisał anonim kilka postów wcześniej) napędzają technologie serwerowe.

no np. pieniędzmi, a to prawie najważniejszy czynnik.

wielu "graczy" pewnie co 2/3/4 lata zmienia karty graficzne i procki na nowe :D

W sensie Intel dopłaca do segmentu serwerowego tylko po to by tam istnieć? Bez sensu.

no ok, a ile %owo?

https://www.intc.com/investor-relations/investor-education-and-news/investor-news/press-release-details/2018/Intel-Reports-Second-Quarter-2018-Financial-Results/
5.5 mld $ przychodu z serwerów, a tam marża jest bardzo wysoka.

Do GPU trzeba kopiować dane i z też, a to zajmuje sporo czasu.
Przy obliczeniach nie większych niż kilka mnożeń, GPU marnuje sporo czasu na kopiowanie tych danych i wychodzi ogólnie dużo gorzej niż CPU, na dużych danych.
Chodź jak już są skomplikowane obliczenia, sieci neuronowe, rendering, crypto, albo kilkanaście operacji na pojedynczy element, wtedy ten narzut kopiowania się zwróci.

Lepiej CPU wybrać, a jakiś cięższy element układanki rozbrajać w GPU.
CPU mając te 8-12 rdzeni jest potężnym narzędziem, no chyba że ktoś zapomni użyć wszystkich rdzeni.

@Wibowit:

W sensie Intel dopłaca do segmentu serwerowego tylko po to by tam istnieć? nic takiego nie napisałem.

Ale uważam, że ponad 50% przychodu z PC-centric $8.7 billion vs approx. Data-centric $8 bilion podchodzi pod procki na gierkach znacznie utrzymują R&D

Nie każdy PC to maszyna dla gracza. Nie dość, że większość to laptopy to jeszcze nie każdy blaszak służy do grania.

Wibowit napisał(a):

Nie każdy PC to maszyna dla gracza. Nie dość, że większość to laptopy to jeszcze nie każdy blaszak służy do grania.

Już pomijając fakt, że wszystkie gry nie mają wymagań Witchera 3, to jaki inny typ softu "wymaga" tak częstej poprawy parametrów sprzętu? non-pro. ofc.

Przecież aktualne prawie 5-cio letnie procesory za grosze są pewnie overkillem do typowych biurowych rzeczy typu przeglądarka, outlook, jakiś ERP, excele, office itd.

Jeżeli ludzie nie robią jakichś bardziej obliczeniożernych rzeczy, to po co upgradowaliby PC jak nie do gier?

Akurat procki nie wymagały częstych wymian, bo wydajność rosła powoli. Różnica między podkręconym i7-2600k, a podkręconym i7-7700k nie jest jakaś kolosalna, natomiast jeśli porównasz wydajność kart graficznych z tego odstępu czasowego to różnica będzie ogromna (i7-2600k wchodził jak był GTX 580, i7-7700k wchodził jak był GTX 1080).

Wibowit jaki masz komputer na którym kompilujesz programy?

@Wibowit:

Akurat procki nie wymagały częstych wymian, bo wydajność rosła powoli.

Przecież napisałem o tym, a mimo to taki Intel Core i7-8700K @ 3.70GHz ma prawie 4% share. https://www.cpubenchmark.net/share30.html chociaż ten pomiar jest trochę stronniczy, bo "zwykli" ludzie nie benchmarkują swoich CPU :D

Chociaż...

https://www.amazon.com/Best-Sellers-Electronics-Computer-CPU-Processors/zgbs/electronics/229189

https://allegro.pl/kategoria/podzespoly-komputerowe-procesory-257222?order=qd

Na allegro już bardziej mix - drogi (1k / 1.5k pln) lub mega tanie (50 / 100zł).

Zresztą, to za procka podstaw GPU i argument nadal stoi.