[j.cs.]

Idézet: cx.core - Dátum: 2005. aug. 3., szerda - 22:02

Én voltam az a valaki. Azt tudom neked tanácsolni, hogy ne próbálj megítélni, mert nem ismersz.

Meg sem próbáltalak megítélni, csak arra szerettem volna rámutatni, hogy a JVM == interpreter meglátás eléggé idejétmúlt a mai világban.

Idézet

Mondjuk egy 8086 natív kódot valamilyen RISC architektúra kódjára "lefordító" program létrehozása feltehetõleg nem jár különösebb nehézségekkel (mivel a 8086-on nincs védett mód), de a "lefordított" x86 kód kevésbé lesz hatékony, mintha eredetileg arra a bizonyos RISC-re kódolták volna.

Én ezt így kategórikusan nem merném kijelenteni. Ha elég mérnökévet beleölsz abba a fordítóba...

Idézet

A Java filozófia erre még rátesz egy lapáttal: (a fenti példánál maradva) az eredeti x86 kódot sem kézzel (vagy ASM-ben) írták, hanem mondjuk C-ben. Tehát az eredeti algoritmusnak, amit kigondoltak, a C implementáció már csak tökéletlen vetülete, amelynek az x86 szintén, és amelynek az ominózus RISC kód megint csak. És ez szerintem nem vezet semmi jóra.

C esetén tökéletesen igazad van. Egyszer lefordítod, az onnantól olyan amilyen. Java esetén viszont egy virtuális CPU nyelvérõl beszélünk (a JVM byte code egyfajta idealizált assemblynek is tekinthetõ, amire a javac tegyük fel, hogy optimálisan fordít). A Java byte code és az adott hardver közötti minél optimálisabb kódkonverzió nem egyszerûen az adott processzorcsalád sajátosságait tudja figyelembe venni: hanem akár magát a konkrét gépet, amin fut. Hány szálnyi végrehajtóegység, mekkora cache méretek, milyen utasításkészlet (annak milyen kiterjesztéseivel: nem véletlenül írtam azt az SSE-t odafent). Konkrétan: vegyünk egy több szálon futó algoritmust thread local változókkal, többszálú végrehajtást támogató core-ral rendelkezõ gépen. Ki fogja ügyesebben optimalizálni az eredeti kódot? A C fordító, ami x éve egy akkori SMP gépre optimalizálta a pthread-es C kódot, vagy egy teoretikus JVM ami az adott hardver sajátosságainak megfelelõen optimalizál?

Ha azt nézed csak, hogy egy adott feladatot a jelenlegi hardverek segítségével hogyan lehet minél optimálisabban, gyorsabban megoldani: valószinûleg nem a java, c# és társai lesznek a barátaid (de ebben az esetben úgyis valamilyen beágyazott rendszeren dolgozol). Ha fontos, hogy az adott kifejlesztett alkalmazás az idõ és a technológia változásával minimális továbbfejlesztéssel legyen piacra dobható, eladható és karbantartható... akkor nem igazán van más választás. A C az én szememben a legportábilisabb assembly nyelv, amit tervezni lehetett a 70-es években. A Java byte code pedig a 90-es évek elejének legjobb próbálkozása egy hardverfüggetlen assembly kód megteremtésére. Az, hogy azt egy adott JVM manifesztáció interpretálja, JIT-teli, a kettõ keverékét használja, vagy átfordítja majd valami egészen más megközelítésû dologra teljesen hidegen hagy. A lényeg, hogy az algoritmus, amit leírtam a nyelven elfusson 1, 5, 10 év múlva is egy akkori számítógépen - nem a legoptimálisabban, hanem eléggé optimálisan. Persze lehet, hogy ez naivitás...

[j.cs.]

Idézet: marczi - Dátum: 2005. aug. 4., csütörtök - 14:04

Gyanítom, hogy nincs olyan messze, amikor újabb nyelvi kiegészítések és absztrakciók jönnek be (akár valami Objective C-szerû, akár valami Eiffel szerû), illetve jönnek az újabb rétegek

Hmm. Láttam mostanában milliárd forint környéki projektet ahol a vizuális fejlesztõeszköz gyaníthatóan csak webszolgáltatásokat és BPEL leírókat fog gyártani (najó, lesz talán néhány portlet is) a fejlesztendõ rendszer implementációjaként. Úgyhogy ez az idõ tényleg nincs már olyan messze. Mondjuk ez egy kiragadott példa...

[j.cs.]

Idézet

Amikor fordítást végzel két nyelv között (...), akkor mindig pazarolsz egy kicsit - hogy mennyit, az esetfüggõ

Egyre többször olvasom ezt a kijelentést, annál inkább nem értek egyet vele.

A klasszikus fordításelmélet szerint ugye minden programozási nyelv egy adott szintû virtuális gép nyelve. A nyelvek pedig egymással ekvivalensnek tekinthetõek kifejezõképességük szerint. Az a pazarlás, amirõl te írsz az tulajdonképpen a fordító hibájának tekinthetõ. A fenti kijelentésed pedig azt mondja ki, hogy ideális fordító (ami 0 hibával fordít át egyik virtuális gép nyelvérõl a másikra) nem konstruálható.

A gyakorlati tapasztalatok persze inkább a te oldaladon állnak (bár...), de nem érzem azt, hogy formalizáltan be lehet bizonyítani azt, amit a fenti mondatod kifejez, és azt sem érzem, hogy kategórikusan ki lehetne jelenteni, hogy egy magasabb szintû nyelven átlagos programozói képességekkel megírt programot alacsonyabb szintre hozó (tfh. kimagasló programozói képességû emberek által fejlesztett) fordító mindig garantáltan rosszabb kódot alkot az alacsony szintû nyelven, mint egy átlagos programozói képességekkel az adott problémát alacsonyabb szintû nyelven megoldó egyén. Ha meg a gazdasági oldalát nézzük:

fordító ára + átlagos programozó havi bére * t(magas szintû nyelven megírni)

vajon milyen korrelációban van az

átlagos programozó havi bére * t(alacsony szintû nyelven megírni)

értékkel? És azt is érdemes vizsgálni, hogy a két érték különbségébõl mennyivel nagyobb teljesítményû hardvert lehet az adott feladat alá tenni.

Ha tudtok publikációt/cikket ami a témát vesézi szórjátok a linkeket:)

[cx.core]

Már tényleg csak széljegyzet gyanánt:

Idézet: j.cs. - Dátum: 2005. aug. 4., csütörtök - 22:25

A gyakorlati tapasztalatok persze inkább a te oldaladon állnak (bár...), de nem érzem azt, hogy formalizáltan be lehet bizonyítani azt, amit a fenti mondatod kifejez [..]

A kijelentésem természetesen csupán gyakorlati, semmi esetre sem elméleti kijelentés.
Bár eredetileg van mögötte egy másik gondolat is, amit sajnos nem sikerült kifejeznem:
A tökéletes fordító sem tud megakadályozni egyfajta "absztrakciós pazarlást". A programokat ugyanis emberek írják, és a programok célját, a mögöttük álló algoritmusokat csak az emberek értik meg. A tökéletes fordító csak azt garantálja, hogy a célkód ugyanúgy fog mûködni a célarchitektúrán, ahogyan a forráskód mûködik a forrásarchitektúrán. A forráskód mögötti algoritmus megértésére nem képes. Tehát a tökéletes fordító csupán arra biztosíték, hogy a célkód ugyanolyan hatékonyan fogja kihasználni a célarchitektúrát, mint a forráskód a sajátját - arra viszont nem, hogy a célkód ugyanolyan hatékony implementációja lesz az eredeti algoritmusnak, mint a forráskód. Ez persze korunk architektúrái esetében - általában - elhanyagolható pazarlás, a nagymértékû hasonlóság miatt.

Bizonyára igazad van, hogy a JVM == interpreter meglátás idejétmúlt, csak arra szeretnék újfent rámutatni, hogy ez nem ekvivalens az én állításommal (ld. fentebb). Egy szavam nem lenne, ha a Java világosan olyannak készült volna, hogy adott egy magasszintû nyelv, amelyen készült forráskódokat valamilyen technikával betömörítenek - hangsúlyozom, hogy nem egy köztes "nyelvre" fordítják le, csupán az emberi érthetõséget biztosító sallangoktól fosztják meg -, majd a célgépen, közvetlenül futtatás elõtt fordítják le. De az én szememben az eredetileg interpretálgatósdi, majd késõbb hirtelen felindulásból futtatás elõtt fordítgatósdi hasonló méretû szálka, mint az x86 toldozás-foldozások (avagy mankózások, a'la marczi ).

Ja és szerintem a C nyelv nem a legjobb "hordozható assembly", amelyet a hetvenes években tervezni lehetett, talán abból kifolyólag, hogy nem tiszta lappal indult, hanem volt neki elõdje.

Nem kell félni, körülbelül két hétig nem leszek itthon. :Ð

[j.cs.]

Ok, ezt így el tudom fogadni (mankózás). Goslingék teljes egészében interpretáltnak tervezték a byte code-ot. Persze ettõl még akár alkalmas lehet JIT-re vagy inkabb AAW-ra (After A While Compiling - a'la HotSpot).

BTW, ezt a cikket olvasta valaki közületek? A szerzõ Bruce Eckel (a TIC++ és a TIJ szerzõje)
http://www.javacoffeebreak.com/articles/th...collection.html

"This might sound a bit odd at first - that storage release affects storage allocation - but it's the way some JVMs work and it means that allocating storage for heap objects in Java can be nearly as fast as creating storage on the stack in C++."

[h1ghland3r]

Idézet: SFIJ - Dátum: 2005. aug. 4., csütörtök - 14:56

nem eleg. a 'vonszold at a beled' az lenyegeben azonos az objektum szerializalasaval. ezt megtenni alapbol csak interpretalt nyelvvel lehet, c++-szal csak akkor ha azonos a CPU, az OS es a futasi kornyezet.

Megoldhato akkor is, ha kozos ose van az osszes osztalynak. Vagy tevedesben vagyok. Az OODBMS-ek legalabbis igy csinaljak (es mukodik eltero platformok kozott is C++-bol).

[marczi]

Kíváncsi vagyok a véleményetekre: szeretnék magamnak egy-két, levelezéssel kapcsolatos programot gyártani, ami Linuxon futna. Pl. autoreply, levlista. (tudom, hogy van ilyen, de spécik az igényeim, úgyhogy alternatív programokra vonatkozó javaslatokat nem várok ). A fõ kérdés, hogy miben érdemes megírni egy ilyet. A következõket néztem eddig:

Python: szép, de nem tetszik, hogy nincsenek interface-ek (vagy valami hasonló), nem lehet típust deklarálni...

Pike: ez igazából egész szimpi, csak úgy látom, nagyon gyorsan változik, gyakran inkompatibilisen, meg nincs túl nagy fejlesztõi bázisa. Tulajdonképpen nem is szeretem annyira a scriptnyelveket

Java: mivel kb. 7-8 éve programozok Javaban, a legszimpatikusabb választás lenne, de valahogy mindig elborzadok, amikor mondjuk egy autoreply programhoz foglal a memóriából 20-25MB-ot, plusz még indul vagy nyolc thread a JVM mindenféle disznósága miatt. Próbáltam GCJ-vel is, ami valamivel jobb, de ott meg ha egy JDBC drivert kell betölteni, akkor máris interpreter módba vált, és tökörészig jópár másodpercig

C++: eddig csak nagyon pici programokat készítettem benne, nincs túl sok tapasztalatom. A legnagyobb félelmem, hogy nagyobb programnál valami memóriát nem szabadítok fel, és ott a gebasz. Ez mondjuk egyértelmûen a Java felé húz, illetve ami még fáj, hogy nincs egy egységes library. Úgy értem olyan, ahol tényleg rendesen tudsz Unicode stringeket, threadeket, szinkronizációt, adatbázist kezelni.

Pascal: komolyan elgondolkodtam rajta, jó sok ideje használok Delphit, gyakorlatilag végtelen mennyiségû komponens van hozzá, így igazából minden meglenne hozzá, kicsit hasonló a sztori a C++ memóriakezeléséhez, meg úgy valamiért nem születnek Pascalban programok, legalábbis ilyesmik.

Összefoglalva valami olyan megoldást keresek, ahol nem kell túl sokat foglalkoznom azzal, hogy file-okat, socketet, adatbázist, stringeket hogyan is kell kezelni, valamennyire védve legyek memória hibák ellen, és egy ilyen nyomorult kis program ne zabálja fel a rendelkezésre álló memória 5-10%-át...

[kroozo]

Idézet: marczi - Dátum: 2005. aug. 24., szerda - 8:01

Kíváncsi vagyok a véleményetekre: szeretnék magamnak egy-két, levelezéssel kapcsolatos programot gyártani, ami Linuxon futna. Pl. autoreply, levlista. (tudom, hogy van ilyen, de spécik az igényeim, úgyhogy alternatív programokra vonatkozó javaslatokat nem várok ). A fõ kérdés, hogy miben érdemes megírni egy ilyet. A következõket néztem eddig:

Python: szép, de nem tetszik, hogy nincsenek interface-ek (vagy valami hasonló), nem lehet típust deklarálni...

Pike: ez igazából egész szimpi, csak úgy látom, nagyon gyorsan változik, gyakran inkompatibilisen, meg nincs túl nagy fejlesztõi bázisa. Tulajdonképpen nem is szeretem annyira a scriptnyelveket

Java: mivel kb. 7-8 éve programozok Javaban, a legszimpatikusabb választás lenne, de valahogy mindig elborzadok, amikor mondjuk egy autoreply programhoz foglal a memóriából 20-25MB-ot, plusz még indul vagy nyolc thread a JVM mindenféle disznósága miatt. Próbáltam GCJ-vel is, ami valamivel jobb, de ott meg ha egy JDBC drivert kell betölteni, akkor máris interpreter módba vált, és tökörészig jópár másodpercig

C++: eddig csak nagyon pici programokat készítettem benne, nincs túl sok tapasztalatom. A legnagyobb félelmem, hogy nagyobb programnál valami memóriát nem szabadítok fel, és ott a gebasz. Ez mondjuk egyértelmûen a Java felé húz, illetve ami még fáj, hogy nincs egy egységes library. Úgy értem olyan, ahol tényleg rendesen tudsz Unicode stringeket, threadeket, szinkronizációt, adatbázist kezelni.

Pascal: komolyan elgondolkodtam rajta, jó sok ideje használok Delphit, gyakorlatilag végtelen mennyiségû komponens van hozzá, így igazából minden meglenne hozzá, kicsit hasonló a sztori a C++ memóriakezeléséhez, meg úgy valamiért nem születnek Pascalban programok, legalábbis ilyesmik.

Összefoglalva valami olyan megoldást keresek, ahol nem kell túl sokat foglalkoznom azzal, hogy file-okat, socketet, adatbázist, stringeket hogyan is kell kezelni, valamennyire védve legyek memória hibák ellen, és egy ilyen nyomorult kis program ne zabálja fel a rendelkezésre álló memória 5-10%-át...

Hát. én igazából azt mondanám, hogy vagy perl/python, ha meg tudod emészteni, hogy gyengén típusos (hidd el, egész kellemes is tud lenni). Perl talán kicsit rugalmasabb, viszont elég svájci bicska jellegû. Ha nem, akkor c/c++, neked gondolom inkább c++, mert úgylátom szeretet az ojjektumorientálódott nyelveket...

[marczi]

De meg lehet engem gyõzni Valóban elegánsabbnak tartom a ojjektumokat, mert hatékonyan írják le a való világból kezelendõ, modellezendõ dolgokat. Egyszerûbb programnál abszolút hajlok egy python jellegû megoldás felé.

Nagyobbacska programnál viszont két alapvetõ bajom van:
1. az interface-ek nagyon hasznosak tudnak lenni, hiszen mindenképp azt kell megvalósítani, amit az deklarál, és így bátran oda lehet adni másnak, hogy figyelj öreg, ezt implementáld. Nem véletlen, hogy a Perl6 és a Python 2.5 is tartalmaz interface-t.
2. ha nincs típusa a változóknak, akkor ha én garantálni akarom, hogy valami márpedig szám, akkor azt folyton ellenõrizgetni kell, de akkor már jobb egy erõsen típusos, deklarált nyelv, nem?

[kroozo]

Idézet: marczi - Dátum: 2005. aug. 24., szerda - 15:44

De meg lehet engem gyõzni Valóban elegánsabbnak tartom a ojjektumokat, mert hatékonyan írják le a való világból kezelendõ, modellezendõ dolgokat. Egyszerûbb programnál abszolút hajlok egy python jellegû megoldás felé.

Nagyobbacska programnál viszont két alapvetõ bajom van:
1. az interface-ek nagyon hasznosak tudnak lenni, hiszen mindenképp azt kell megvalósítani, amit az deklarál, és így bátran oda lehet adni másnak, hogy figyelj öreg, ezt implementáld. Nem véletlen, hogy a Perl6 és a Python 2.5 is tartalmaz interface-t.
2. ha nincs típusa a változóknak, akkor ha én garantálni akarom, hogy valami márpedig szám, akkor azt folyton ellenõrizgetni kell, de akkor már jobb egy erõsen típusos, deklarált nyelv, nem?

õ, én is szeretem az objektumokat, nincs azzal gond, nagy projektekre valóban jobb (hmm, most úgy beszélek, mint valami nagyon gyakorlott kóder ), kis projektre viszont a java/c[++] egy kicsit idõrablós nekem.

Igazából azt tudom mondani, hogy Perlben nem nagyon okoz gondot ez a változó típusozás, elég elegánsan, és jól kezeli a dolgot (pl kétféle boolean van, pl == és eq), nem nagyon szokott ez bajt jelenteni (fõleg, hogy nagyobb projektben úgyis van sql, akkor meg majd az ellenõriz ), bár kétségtelen lehet vele misztikus dolgokba szaladni (a másik oldalról meg folyamatosan lehet szenvedni a típusossággal. float vs int, báh) Viszont amit írtál, ott nem látom nagyon ennek reális veszélyét...

De csak jön valaki, aki tényleg programozó, nem csak ilyen korlátozott gyakorlattal rendelkezõ szakbarbár

[Asker]

Szvsz a Java elõtt áll az egyik legfényesebb jövõ

[h1ghland3r]

Idézet: Asker - Dátum: 2005. aug. 25., csütörtök - 14:36

Szvsz a Java elõtt áll az egyik legfényesebb jövõ

pedig nincs okunk kedvelni...

[kroozo]

Idézet: h1ghland3r - Dátum: 2005. aug. 26., péntek - 21:03

pedig nincs okunk kedvelni...

de fényes jövõ áll elõte, mert ha megindul, izzik a ház oldala, hogy lesz fényesség

[marczi]

Idézet: h1ghland3r - Dátum: 2005. aug. 26., péntek - 20:03

pedig nincs okunk kedvelni...

Azt kell, hogy mondjam, hogy a legkisebb rossznak kell tekintenem. Ha ugyanis olyan a projekt, hogy nem én egymagam fejlesztem, hanem mások is, akár olyanok is, akiket nem is ismerek, akkor a memóriafolyás miatt messze valami hasonló nyelv a legbiztonságosabb (vagy scriptnyelv, vagy C#/Java). Bár akkor is gyomorforgató, hogy vért kell izzadni, ha valami natív kódot szeretnél.

[Hasse]

Idézet: marczi - Dátum: 2005. aug. 27., szombat - 7:47

Azt kell, hogy mondjam, hogy a legkisebb rossznak kell tekintenem. Ha ugyanis olyan a projekt, hogy nem én egymagam fejlesztem, hanem mások is, akár olyanok is, akiket nem is ismerek, akkor a memóriafolyás miatt messze valami hasonló nyelv a legbiztonságosabb (vagy scriptnyelv, vagy C#/Java). Bár akkor is gyomorforgató, hogy vért kell izzadni, ha valami natív kódot szeretnél.

Ügyes ember Javában is meg tudja enni a memóriát.

[marczi]

Idézet: Hasse - Dátum: 2005. aug. 27., szombat - 10:29

Ügyes ember Javában is meg tudja enni a memóriát.

Persze, az igaz, de mondjuk egy olyan programnál, ami eléri a 10.000 sort, sokkal valószínûbb, hogy kifelejtenék egy free/delete-t, mint az, hogy akkora körbehivatkozást csinálok, hogy még a GC is megszédül tõle

[Haderach]

Idézet: marczi - Dátum: 2005. aug. 24., szerda - 8:01

C++: eddig csak nagyon pici programokat készítettem benne, nincs túl sok tapasztalatom. A legnagyobb félelmem, hogy nagyobb programnál valami memóriát nem szabadítok fel, és ott a gebasz. Ez mondjuk egyértelmûen a Java felé húz, illetve ami még fáj, hogy nincs egy egységes library. Úgy értem olyan, ahol tényleg rendesen tudsz Unicode stringeket, threadeket, szinkronizációt, adatbázist kezelni.

Van c++-hoz is tobb elerheto, ingyenes GC, pl a Böhm-féle C++ Garbage Collector nagyon elterjedt es hacsak nincsenek nagyon kulonleges igenyeid a memoriaval kapcsolatban (ha a Java is felmerult mint lehetoseg akkor szerintem nincs ) valoszinuleg megfelelo valasztas. egyszeru hasznalni, mindossze a heapen letrehozando ojjektumok operator-new -janak kell adni egy parametert(*) es akkor nem kell a delettel foglalkozni.  bar en javaban irnam 

(*) pl.

#include <gc/gc_cpp.h> //Ez a Bohm headerje

/*...*/

Foo *FooPointer  = new (UseGC) Foo(1,2,3,4);
//                    ^^^^^^^^

[giotto]

Idézet: kroozo - Dátum: 2005. aug. 24., szerda - 20:01

õ, én is szeretem az objektumokat, nincs azzal gond, nagy projektekre valóban jobb (hmm, most úgy beszélek, mint valami nagyon gyakorlott kóder ), kis projektre viszont a java/c[++] egy kicsit idõrablós nekem.

nekem ilyenkor mindig egy idezet jut eszembe:

Idézet

az kulonbozteti meg a kezdo programozot a profitol, hogy amig a kezdo arra buszke, hogy a kodjat teljes mertekben o irta, addig a profi arra, hogy a kodjanak nagy reszet ujrafelhasznalta.

szerintem az objektumok remekul kihasznalhatoak ujrahasznosithato kodok eloallitasara, a program meretetol fuggetlenul

[kroozo]

Idézet: giotto - Dátum: 2005. aug. 28., vasárnap - 17:12

nekem ilyenkor mindig egy idezet jut eszembe:

szerintem az objektumok remekul kihasznalhatoak ujrahasznosithato kodok eloallitasara, a program meretetol fuggetlenul

egyetértünk.

spec általában perlben is OO interfaccel dolgozom, az esetek nagy részében sokkal gyorsabban lehet benne kódolni (nekem, persze ebben a hátulgombolós voltom is benne van).

És valóban nem vagyok profi programozó

[h1ghland3r]

Idézet: h1ghland3r - Dátum: 2005. aug. 26., péntek - 19:03

pedig nincs okunk kedvelni...

Majd lejatszak a C#/.NET-tel, hogy ki marad eletben.

Bevallom oszinten (lesutott szemmel), nekem a Redmondiak megoldasa szimpatikusabb. Persze nekik konnyu, ok mar lattak, hogy mi a szopas a Javaban.