11
-
#11
Mindig jót röhögök, mikor egy mondatban látom a gyors és Java szavakat :DD -
Sydra #10 Ja mert a reference counting meg a dinamikus típus ellenőrzés ingyen van. A statikus fordítók meg megragadtak az előző évszázadban. Nem lehet ám ugyanazt a lefoglalt memóriát többször felhasználni.
Látom nálad ez is ilyen vallási téma. Azt hiszed a kedvenc nyelved jó mindenre. Feladathoz választunk nyelvet a nyelv sajátosságait mérlegelve. A Java pont nem jó sebesség kritikus problémák megoldásához. Ha ezt nem érted, akkor kezdő kis nudli vagy akinek csak nagy a szája. -
Sequoyah #9 Tudod hogy mukodik a Java garbage collection?
Garbage collection nelkuli nyevlekben minden egyes objetkumot kulon le kell foglalni a memoriaban, amihez keresni kell egy megfelelo meretu helyet. Majd a vegen fel kell szabaditani a helyet MINDEN EGYES objektum eseten.
Java fele garbage collection eseten a memoriafoglalas idoigenye a 0-val hataros, es a memoria felszabaditasanak az ideje az objektumok tulnyomo tobbsegenel is a 0-val hataros, es ezzel throughputot merve a Java memoriakezelese magasan veri a C++-ot.
Latencyvel mar lehetnek problemak mert ha pont akkor fut a garbage collection amikor erkezik egy request, akkor megakadhat egy picit, de erre vannak mar eleg regota pauseless garbage collectorok. -
Sydra #8 "Viszont a memoriakezeles sokkal gyorsabb Javaban (garbage collection), es sok a runtime optimalizacio"
A garbage collection nem a gyorsaságot, hanem a kényelmet és a biztonságot szolgálja (bár Java-ban ezeket is próbálták elszabotálni default mutability-vel meg default nullability-vel). Ha gyors szoftvert akarsz akkor nem használsz garbage collector-t, vagy csak a nagy méretű és kis számú objektumokra.
Szoftvertervezésben meg eleve nincsenek általánosan tökéletes megoldások. Az általános, automatizált memóriakezelőd soha nem lesz olyan gyors mint az adott feladathoz illesztett speciális megoldás (amiknek a nagy részét Java-ban nem is tudod megvalósítani csak C++-ban). A runtime optimalizáció meg fabatkát sem ér a static type introspection-höz képest.
Akárhogy is nézzük a Java egy erősen specializált nyelv, a C++ meg egy általános célú nyelv. Bizonyos feladatkörökre a Java tartalmaz rengeteg automatizációt és ezeken a területeken jóval gyorsabban is lehet benne fejleszteni, mint C++-ban. Minden másra a C++ jobb. -
Sequoyah #7 Viszont a memoriakezeles sokkal gyorsabb Javaban (garbage collection), es sok a runtime optimalizacio ami szinten nem elerheto C++-ban, mert az build timeban fordul nativ kodra.
Egyebkent meglepoen sok mindenhez hozza lehet ferni direktben, bar akkor mar nem feltetlenul egyszerubb hasznalni mint a C++-t. De ha csak egy limitalt kisebb kodreszletet kell nagyon optimalizalni, akkor ez is egy opcio. -
Sydra #6 Java-ban nem férsz hozzá direktben semmihez ami sebesség szempontból igazán számít. Meglehetősen korlátozott az eszközkészleted C++-hoz képest. -
Sequoyah #5 Nagyon sok sebessegigenyes dolgot csinalnak Javaban, pl low latency/high frequency trading rendszereket, amik tobb millio tranzakciot dolgoznak fel masodpercenkent.
A Java azt csinalja amit szeretnel. A kulonbseg az az, hogy a Java egyszerubb, ezert tobb amator kezdo programozo van akik osszebarmolnak benne valamit, mig aki elkezd C++-ozni az altalaban elhivatott annyira hogy rendesen megtanulja. Tudom, interjuztatok ilyeneket, es latom hogz aki C++ hatterrel erkezik, az jo esellyel nem amator...
De ha a programozo rendesen erti a Javat, annyira mint amennyit a C++-hoz kell erteni hogy barmi eletkepes dolgot osszerakjon, onnantol a Java egy nagyon hatekony programnyelv.
Persze ha valaki azt sem tudja hogy hogy mukodik a garbage collector, es milyen alternativak vannak, attol nem fogom elvarni hogy gyors programot irjon...:)
-
Sydra #4 Ez nagyon esetleges és ritka, hogy pont azt csinálja, amit szeretnél.
Nem hiába csinálnak minden sebesség igényes dolgot C++-ban. -
Sequoyah #3 Azt azert igy nem jelentenem ki hogy gyorsabb mint pl a Java. Helyzettol fugg, es sokesetben a Java a gyorsabb a nativ gepkozelibb nyelveknel, mert runtime tud optimalizalni, es sokkal gyorsabb a memoriakezelese mint pl a c++.
De mint mondtam helyzetfuggo, attol fugg konkretan mi is az algoritmus amit programozol. -
kvp #2 A rust az olyan, mint amikor a c-t egy 1970-es evekbeli makro assemblerrel keresztezik. A hasznalatarol valahogy egy rozsdas sajtreszelo jut eszembe.
Ettol fuggetlenul elvileg biztonsagosabb nyelv mint a c, ellenben statikus, igy elvileg gyorsabb mint a nativ kodra forditott java. A belinkelt irasban olyanokrol irnak, hogy egy c++-os stringet nem igazan lehet elerni nativ modon rust alol, de egy c++-os string-et tartalmazo strukturat meg annyir sem. Na most a legtobb rendszer szintu api es kulso programkonyvtar az vagy c vagy c++ strukturakat hasznal. A rust direkt ugy lett megirva, hogy ezeket a feluleteket fajdalmasan nehez legyen biztonsagos (szabalyos) modon elerni.
"We think the hardest part of this is imagining a safe way to pass types between Rust and C++. That requires auto-generated shim code on both the Rust and C++ side. That’s already achieved by cxx with terrific emergent safety properties. And so that’s our basic model.
But, we don’t want to specify a cxx::bridge section for every API. We therefore need the cxx::bridge to be generated using a bindgen-like tool.
We don’t believe Rust language changes are needed. Some C++ types can’t be owned by value in Rust — for example std::string with its self-referential pointer — but we believe that good C++ interoperability can be achieved even if Rust can only own such objects by pointer. We may be wrong here as well!"
Tehat vagy generalnak egy rakat folosleges kodot, ami oda-vissza konvertalja az adatokat vagy meg egy string-et (sima szoveget) tartalmazo valtozot sem fognak tudni elerni. Egy jo programnyelvnek nem kell generalt kod ahhoz, hogy egy olyan alap funkciot elerjen, ami mar 40 eve a Commodore-ok idejen is magatol ertetodo volt. Ertem, hogy biztonsagos, csak nekem tovabbra is egy nagyon biztonsagosra tervezett rozsdas sajtreszelonek tunik. Ehhez kepest meg az Ada is egy felhasznalobarat nyelv. -
noland #1 "Az tehát egyelőre kérdéses, hogy a Rusttal kiegészített Chrome-változatokkal találkozhatnak-e és ha igen, mikor a felhasználók."
Döcög a magyar, nemde? :D
"A Rust gyakorlatilag az utolsó szalmaszálat jelentheti"
Fene se gondolta, hogy ilyen problémák vannak a chrommal :O