Programozási nyelveket tesztel a Google
Jelentkezz be a hozzászóláshoz.
#11
MerlinWVIP
Mindig jót röhögök, mikor egy mondatban látom a gyors és Java szavakat :DD
[merlinw.org]
#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.
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.
#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.
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.
#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.
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.
#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.
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.
#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.
#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...:)
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...:)
#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.
Nem hiába csinálnak minden sebesség igényes dolgot C++-ban.
#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.
De mint mondtam helyzetfuggo, attol fugg konkretan mi is az algoritmus amit programozol.
#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.
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.
#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
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
Im beginning to have less and less interest in what you think is possible or impossible. (Dr. Strangelove)