- Nvidia GPU-k jövője - amit tudni vélünk
- Rekordmagasba lökte az EPYC és a Ryzen az AMD-t
- E-book olvasók
- A Princeton újraértelmezte az ultrakompakt hordozható SSD fogalmát
- Milyen alaplapot vegyek?
- Vezetékes FÜLhallgatók
- Androidos tablet topic
- Gaming notebook topik
- Hobby elektronika
- Épített vízhűtés (nem kompakt) topic
Hirdetés
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Grafén meghajtó, térhangzás és UV-tisztítás az LG új fülhallgatójában
ma Bejelentették, hogy hamarosan érkezik az LG Tone Free T90S.
-
Ingyenes az Epic Store-ban a Dragon Age: Inquisition – Game of the Year Edition
gp A fullos kiadás tartalmazza az alapjáték mellett az összes nagy DLC-t is.
Új hozzászólás Aktív témák
-
#40
ddekany
veterán
quailstorm
#30
ddekany
veterán
válasz
quailstorm
#30
üzenetére
"Node hiába használtam most android 4.0.4-es tabletet, amiben már-már néha tudjuk szimulálni a multitaskot (ugyanott nyitja újra az alkalmazást) de egy lószar. 2 folyamatot nem tud lekezelni."
Ez az egész mit jelent? Ha az OS úgy dönt, leállítja a folyamatot, ha nem, akkor tényleg ott marad a háttérben, tudtommal. Így is tűnt, amennyit droidot nyomkodtam.
"Android emulátor. Sose semmilyen mennyiségű CPU nem lesz elég reprodukálni a teljesítményt pont. Max ha 10év korkülönbség és generációkülönbség lesz köztük."
A PC-s Java-s cuccok nem ezt igazolják, ennél sokkal összetettebb a dolog. JIT-et feltételezem tudod mi. A sebesség gondok tán nem is a nem-natív programozásból adódnak, sokkal inkább az egész szoftver stack megtervezéséből (API rétegek egymáson, rakás absztrakció). Mellékesen a kritikus részeket, ahol lehetőség van valami cselre, ami csak C/C++/ASM-ban elérhető meg lehet natívban írni. Azaz én azért nem temetnék valamit, mert managed code. Attól függetlenül persze lehet valami tetű.
-
#47
ddekany
veterán
quailstorm
#43
ddekany
veterán
válasz
quailstorm
#43
üzenetére
"AZ OS NEM DÖNT ÚGY HOGY BEZÁRJA A FOLYAMATOT VILÁGOS?"
Lehet nem szeretni, de ettől még nem lesz fejletlenebb az OS... Tud egyszerre is futtatni, meg automatikusan bezárni is.
"Egyébként nekem még mindig az a multitask hogy az app FUT valamit csinál, használja a CPU-t, mert sokáig tart a folyamat, én meg közbe írom az e-mailt stb..."
De ezt szerinted nem tudja az Android, csak ha a háttérben futó alkalmazás natív? Mi akadálya lenne két dalvikos alkalmazás párhuzamos futásának?
[ Szerkesztve ]
-
#56
ddekany
veterán
quailstorm
#49
ddekany
veterán
válasz
quailstorm
#49
üzenetére
Nem fejlesztettem soha Androidra, úgyhogy csak csodálkozok miket mondasz... meg nagyon erős kétkedéssel fogadom. Többke közt mert világít arról miket írsz, hogy nem vagy programozó (vagy ha igen, junior vagy hasonló). Amúgy nem tudom mi van Dalvikkal (mert hogy az nem JVM), de a Java-nak már a kezdetektől vérében volt a többszálú futtatás. Igazából ez az egyik fő előnye a legtöbb más platformmal/nyelvel szemben, hogy eleve arra tervezték. Az, hogy egy Dalvik VM van... gondolom igen, minek lenne több? Nagyon de nagyon megdöbbennék, ha nem tudna egy időben több szálat futtatni, elvégre erős Java-s gyökerei vannak, ha még nem is tekinthető Java-nak. (A Service-knél meg oda volt írva, hogy indíthatnak saját szálat, stb.)
-
ddekany
veterán
"Szerintem mar a Java alapkoncepcioja is kelloen zavaros, miszerint egy nemletezo szamitogep utasitaskeszletere forditsuk le a forraskodot, majd a kapott "gepi" kodot egy futtato kornyezet ertelmezze utasitasrol utasitasra, es probalja vegrehajtani az adott fizikai vason+oprendszeren."
Nincs ebben semmi zavaros. A hagyományos ISA-k veszélyesek. Elsősorban mert lehet bennük pointerekkel bűvészkedni; ennek köszönhető a legtöbb biztonsági hiba. Másrészt a Java alkalmazások és főleg a könyvtárak hordozásán bizony sokat könnyít a közös virtuális gépikód és a szép nagy standard API.
Ezen kívül jellemzően nem utasításról utasításra történik az értelmezés, hanem az egész átfordul rendes gépikódra. Csak persze ez minden alkalommal lejátszódik, mikor elindítasz egy alkalmazást, ami még nem fut. (Bár lehetne elmenteni a gépikódot... nem tudom ezt valahol alkalmazzák-e.)
Másfelől én is nagyra értékelném ha a system programing nyelvek közt (mert hogy a Java nem az) is történne valami megújulás, a C++ nevű szörny tovább masszírozása helyett. Próbálkozik pl. nagyon rég a Digital Mars a D-vel (igaz, az GC-s, innentől nem mindenhova jó), de egyszerűen annyira beleette magát már mindenhova a C és C++, hogy semmi esélye a megújulásnak. A managed kódos cuccok viszont valahogy megteremtik maguknak az ökoszisztémát. A programozók átszoknak kevésbé szopatós nyelvekre... ha nem managed code lenne, akkor valószínűleg arra is átszoknának, de az új próbálkozások vagy olyanok, vagy dinamikus nyelvek (Ruby), ami aztán már tényleg lassú. Szóval az a vicces helyzet, hogy sokan egyáltalán nem a managed code miatt szoktak át Java-ra, hanem mert attól függetlenül hatékonyabb volt a fejlesztés benne mint a többiben.
"Gyakorlat meg azt mutatja, hogy a kulonbozo architekturak+oprendszerek kulonbsegeit csak baromi sok abszrakcios layerrel sikerult elfedni, ez meg feleslegesen sok eroforrast pazarol."
Nem feltétlenül azért van sok réteg... Egyszerűen a modern környezeteket máshogyan tervezik már. Sokkal kevésbé szempont a gép terhelése, sokkal nagyobb a karbantarthatóság meg hasonlók.
[ Szerkesztve ]
-
ddekany
veterán
Nem tudok róla, hogy kiherélt lenne... Azt tudom róla, hogy a Java VM-je (a Sun-féle, de akár az IBM-féle) már rengeteg fejlesztésen esett át, mikor a Dalvik jött. Így primitív volt a megvalósítás eleinte a JVM-(ek)hez képest, pl. nem volt benne JIT, de ez a sebességet befolyásolja, nem a funkcionalitást. Most már van JIT amúgy, de gondolom még sokat kell küzdeniük, hogy elérje a Sun JVM színvonalát. Viszont azt nem hinném el, ha a több szálú futtatás ne lett volna már kezdetektől szerves része, annál inkább nem, mert a Java-s világ eleve ilyen. Szerverek, sok-sok szál, konkurens programozás... Meg hát ilyen cuccok, mint a Clojure, ami aztán kifejezetten a sok mag kihasználására hajt.
-
#60
ddekany
veterán
quailstorm
#54
ddekany
veterán
válasz
quailstorm
#54
üzenetére
"de ki volt az az állat aki kitalálta a java szervert?"
Tudod te mikben programoznak szerver oldalon, ha nem valami abszolút infrastrukturális dologról van szó, mint egy adatbázis szerver vagy hasonló? Hát nem C/C++-ban... PHP-ban, Python-ban, Ruby-ban, Perl-ben... és Java-ban. CPU használat tekintetében az utóbbi messze a leggyorsabb. Sőt, az egyetlen a bagázsban ami támogatja, vagy legalábbis rendesen támogatja a több szálú futtatást (több szál alatt azt értem, amikor azok közös memóriaterület használnak, ellenben a több folyamattal). -
#65
ddekany
veterán
quailstorm
#61
ddekany
veterán
válasz
quailstorm
#61
üzenetére
"De hogy az Androidnak szokása akkor is bezárni valamit ha még bőven van RAM az biztos."
Nem tudok erről a konkrétumot... De simán el tudom képzelni, hogy egy mobil OS igyekszik elfojtani ami a háttérben megy, hiszen egy háttérben futó alkalmazás (amiről a felhasználó jó eséllyel már rég elfeledkezett), rossz hatással lenne az akkura. De bizonyosan kérheti egy alkalmazás, hogy ez és az a szál fusson háttérben is, csak nem ez az alapértelmezés. PC-s OS-eknél tök más volt az alap szitu... és bizony nem ritkán találkozok azzal, hogy valami eszi a háttérben a CPU-t feleslegesen, csak mert szartak bele.
"Single thread appokat. Magonként"
Most azt akarod mondani, hogy nem indíthat új szálat egy app? Elég alap része a Java API-nak, ős idők óta... nehogy már kivették, mert nem tudom mit csinálok. És a "magonként" mit jelent itt?
"Java [...] Nem arra használják amire való."
Mire való szerinted?
"Persze managed kód meg biztonságos. De manapság annyi rés van, hogy ez számít a legkevesebbet."
Gyanítom, ha megnéznék a hibákat, amiket felfedeznek 80+ %-uk olyan dolgokból adódna, ami managged kódnál nincs. Azért ez nem mindegy. Eleve pont mert mindig lesz biztonsági rés, arról szól az egész, hogy a számukat próbáljuk leszorítani.
"Nem beszélve arról hogy vannak kevert layerek javaban."
Attól még nyereség, hogy a Java-ban írt részben már nem fognak bizonyos hibák előfordulni... Nincs abszolút megoldás, az esélyeket lehet módosítani.
-
ddekany
veterán
"Egy ISA sosem veszélyes, ha megfelelően le van kezelve OS-oldalról."
De az OS nem tudja kellő részletességgel kezelni a jogokat. Minden alkalmazásnak (vagy aminek épp hívják) kellenek bizonyos jogok ahhoz, hogy működjön. Ezeket a jogokat az alkalmazás általában tovább finomítja. Pl., hiába fér hozzá a POP3 daemon az összes levélládához, a lekérdezésnél megadott felhasználónév/jelszóhoz illően korlátozni fogja, hogy mit érhetsz el. Ám ha az alkalmazást aljas módon kialakított bemenettel össze lehet zavarni, akkor rá levehet venni olyanokra, amit a programozó szándékai szerint nem szabadna csinálnia, de az OS szerint van rá joga. És erről van itt szó. Ilyen hibát millióféleképpen el lehet követni, de fajsúlyosak azok, amik abból adódnak, hogy zsonglőrködhetsz memóriacímekkel (kivonás/hozzáadás, vagy akár egy int-ből pointer csinálsz).
"mégsem határozhatja meg a programozó fordítási időben, hogy mi a futtatható része a programjának, hogy képzeli
"Ezt a témát meg nem értem. Tudtommal olyan korlátozás van, hogy nem állíthatsz elő natív kódot te magad (de az MS cuccai, mint mondjuk a .Net JIT-je igen). Ami szopás, ha te magad akarsz valami nyelvet megvalósítani. De mi köze ennek a managed code témához? (Amúgy valószínűleg managed code-ot, azaz CIL kódot, generálhatsz.)
-
ddekany
veterán
"azt rossznak lehet nevezni, de megfelelő OS mellett kárt nem tesz"
Dehogynem, előbb írtam le, hogy miért. Nézz meg szinte bármilyen szolgáltatást, teli vannak olyan alkalmazásspecifikus szabályokkal, amiket az OS nem valósíthatna meg, hiszen egy alacsonyabb szintű réteg. Vagy kilépve a szerveres/szolgáltatásos gondolkodásból, egy asztali alkalmazásnak általában kell arra adni jogot, hogy a felhasználó bármelyik fájlját (dokumentumát) olvashassa, és hogy kommunikálhasson az Interneten, és ez a kettő együtt máris alkalmas arra, hogy átküldje a felhasználó akármelyik (bizalmas) dokumentumát Neten akárkinek. Az OS nem tudja eldönteni, hogy a felhasználó szándékosan küld át egy dokumentumot, vagy valami elszabadult (sőt, igazából azt sem látja, hogy dokumentumot küldesz át, csak hogy fájlt olvasol, aztán később kommunikálsz valamit a Neten). Vagy, még jobb példa, a weboldalak mögötti programok. Pl. a PH! mögött álló PHP scripteknek joga van belepiszkálni bármelyik cikkbe az OS szempontjából, de PHP script ezt csak az adminisztrátorként bejelentkezetteknek engedi. Amúgy ez is lökést adott a szerver oldali managed code-nak (CLI, JVM) és dinamikus nyelveknek a C/C++ és társaival szemben, hogy egy Netes szolgáltatásra sokkal több veszély leselkedik, mint egy asztalira, hiszen állandóan bombázni lehet bemenettel bárkinek. Így persze, hogy kerülendő olyan nyelvet (és ISA-t) alkalmazni, ahol az alkalmazás össze tudja barmolni a saját memóriának tartamát.
"Az MS kódjaiban pedig megbízunk manapság ...vagy mi."
Esélyekről van szó, mint mindig, ha biztonságról beszélünk. Egyrészt az MS kódját az MS írta, nem X ismeretlen cég, így azért jobban bízhatsz benne, hogy nem rosszindulatú. Másrészt az a kód, amit mindenki mindenhol használ, és amit folyamatosan karbantartanak, általában jóval kevesebb hibát tartalmaz, mint az, amit csak egy-egy alkalmazás használ.
-
#71
ddekany
veterán
quailstorm
#70
ddekany
veterán
válasz
quailstorm
#70
üzenetére
Ez... mi? Ez két különböző teszt (linpack és RgbenchMM). Csak mellékesen ez Dalvik (tehát csak a nyelv Java), ha már Java-huszárság. Ennek akkor már több értelme van: [link]. Mediánok: C++ 1.12, Java 1.78. Ez sem jelent sokat, eleve csak micro benchmarkok, de sokkal értelmesebb, mint amit te csináltál.
-
#74
ddekany
veterán
quailstorm
#73
ddekany
veterán
válasz
quailstorm
#73
üzenetére
"Be ne beszéld nekem hogy a java a gyorsabb, mert még elhiszem."
Segítek: 1.12 < 1.78, tehát ez alapján lassabb. Sőt, mindig azt mondtam, hogy a leggyorsabb változat adott problémára szinte mindig a C++-os (ritkán nem, mert a JIT tud olyat, amit ez előre-fordítás nem). A léptékekben vannak egyesek eltévedve. És általában a legnagyobb szájúakról kiderül, hogy lövésük sincs az egészről...
"Kész játékmotorral és SDK-val szállították az OMAP2420-at. Kb. Quake 3 szintű grafikát tudott"
A játékmotor speciális terület. Pl. sokszor lefuttatott mag algoritmusoknál sokat számíthat, ha a heap allokációkat/felszabadítások számát redukálod, pl. úgy hogy egyben foglalsz területet sok objektumnak, de ezeket a trükköket a managed code szigorúbb/kötöttebb memóriakezelése nem engedi. Amúgy a Java játékok területén alkalmazásának egyik fő gondja a garbage collection, ami néha kis időre megakasztja a programot. Ez viszont nem Java vagy s managed code sajátosság, hanem lényegében az összes modern nyelv alkalmazza, mert minden más elég kínos (hibalehetőségek!). Mellékesen a Sun/Oracle JVM-nek van kb. a legfejlettebb garbage collection-ja is, mert ezer éve küzdenek vele.
"Persze én is kaptam ilyen fals eredményeket mint amit mutogatsz, de kiderült hogy volt más akadály a natív kód előtt."
Mert azon az oldalon arra verik, hogy csaljanak a Java javára, vagy miről beszélsz? Tudtad egyáltalán értelmezni az oldal tartalmát? Egyébként küld be a C++ megvalósításodat az egyes feladatokra ami gyorsabb mint amit eddig beküldtek... ez így működik.
"Egyébként az MFlops felfogható mértékegységnek."
Ha rögzíted, hogy milyen műveletekkel (ops) méred... akkor talán, kb.
"Új hozzászólás Aktív témák
ph Az ARM 64 bites processzorarchitektúrái Cortex-A53 és Cortex-A57 néven érhetők el.
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen