- DVB-T, DVB-S (2), DVB-C eszközök
- VR topik (Oculus Rift, stb.)
- Videós, mozgóképes topik
- Gigabyte GA-P35(C) alaplapok
- Kormányok / autós szimulátorok topicja
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- Google Chromecast topic
- Egérpad topik
- Internet Rádió építése (hardver), és programozása
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Idén elmarad a BlizzCon
gp A hírek szerint más eseményeken lehet számítani a Blizzard idei bejelentéseire.
-
Olimpia előtti Samsung Galaxy Unpacked?
ma Több forrás is állítja, hogy a július 26-án kezdődő olimpia előtt Párizsban fogja megtartani második 2024-es Unpacked eseményét a Samsung.
Új hozzászólás Aktív témák
-
#51
quailstorm
nagyúr
nyunyu
#50
quailstorm
nagyúr
Jó de nem addig veszi el a prociidőt, amíg kézzel vissza nem adod neki. Nem tudom meggyőzni ezt a ddekany-t hogy az Android nem tud teljes értékűen alkalmazásokat párhuzamosan futtatni.
A HW igényt megértem, ha minden olyan szép és mesebeli lenne akkor ok. De sokszor az van amit mondasz, hogy mindent lefoglal magának az app. Ráadásul ha valami crashel úgy igazán, akkor a dalvik is rebootol. Én személy szerint hülyeségnek tartom azt hogy VM-re építsenek rendszert. A kompatibilitást nem oldotta meg, de legalább problémás.[ Szerkesztve ]
-
#52
nyunyu
félisten
quailstorm
#51
nyunyu
félisten
válasz
quailstorm
#51
üzenetére
Én személy szerint hülyeségnek tartom azt hogy VM-re építsenek rendszert. A kompatibilitást nem oldotta meg, de legalább problémás.
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. *
Elmelet ugye az lenne, hogy egy platformfuggetlen, barhol, barmin futtathato programot kapjunk.
Gyakorlat meg azt mutatja, hogy a kulonbozo architekturak+oprendszerek kulonbsegeit csak baromi sok abszrakcios layerrel sikerult elfedni, ez meg feleslegesen sok eroforrast pazarol.
Radasul a futtato kornyezetek sem ugyanazt tudjak, egyik erre, masik arra van kihegyezve, lasd J2ME, J2SE, J2EE (plusz a Microsoft is pofatlankodott tizeneve a sajat JVMjevel, de aztan birosagi uton leallittattak oket.)
Igy a programozonak tovabbra is figyelembe kell vennie, hogy megis mire fejleszt.De ezt a koztes kodos kapufat a Microsoft is ellotte a .NET Frameworkkel, ott sem kompatibilis egymassal az asztali Windowsok, meg a Windows CE/Phone CLIje, utobbiak joval kevesebbet tudnak.
Raadasul ez a kettosseg a Win8/Phone 8/8 RT-nel is megmarad, max a mobil alkalmazasok fognak futni asztali gepen, de forditva biztosan nem.
Mondjuk ahhoz kepest, hogy pl. egy WP7-re forditott alkalmazas eddig sehogy sem futott asztalin, mar ez is nagy szo.![;]](//cdn.rios.hu/dl/s/v1.gif)
*: Emlegettek a kilencvenes evek vege fele (vagy 200x elejen?), hogy akar olyan szamitogepet/procit is lehet epiteni, ami nativan futtatja a Java bajtkodot, de mint tudjuk, ez azota sem valosult meg.
[ Szerkesztve ]
Hello IT! Have you tried turning it off and on again?
-
P.H.
senior tag
"Emlegettek a kilencvenes evek vege fele (vagy 200x elejen?), hogy akar olyan szamitogepet/procit is lehet epiteni, ami nativan futtatja a Java bajtkodot, de mint tudjuk, ez azota sem valosult meg."
ARM Jazelle
[link]
Elég régi, ARMv5-tel került be, de mindenhol azt olvastam, hogy lassabb, mint az aktuális ARM-arch. natív végrehajtására JIT-fordított kód.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#54
quailstorm
nagyúr
P.H.
#53
quailstorm
nagyúr
Sose tudtam belemélyedni, te tudomásom szerint ez J2ME gyorsítónak készült(consumer electronics kateóriában). Legalábbis az N900-zam JRE7-tel sose használja...
Bár gyanús hogy anno a szerverekbe is belekerült(de ki volt az az állat aki kitalálta a java szervert?).
Egy biztos, nem a dalvikért csinálták, akkor az még ötletnek se létezett. A Qt, meg a natív c, c++ is van annyira portable mint ez a java baromkodás, csak hatékony is, szóval nem értem miért erőltetik. Nem nagy cucc lefordítani ARMv4-5-6 6VFP11, 7-re. Bár régen a WinMO-val kicseszett olyan úton az Opera hogy a 10-es is még ARMv4-re van fordítva. Nesze neked Omnia2 meg HTCHD2.
Egyébként van java proci. Csak nem terjedtek el: [link]
Egyébként tök jó hogy a legtöbb telefon ARMv4-et használ. V5-től meg okostelefonok. Bezzeg a Sony Ericsson megoldotta a gyors és szép 3D-t bztosító J2ME-t ARMv4-en is. A FishLabs játékok elérték az eredeti n-gage szintet, igaz dupla/tripla hardveren.
Azóta se vették ki a Jazelle-t, kérdés mi az oka. Biztos nem lenne benne hagyva ha olyan fos.[ 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). -
#61
quailstorm
nagyúr
ddekany
#56
quailstorm
nagyúr
Attól még hogy nem vagyok pro programozó, tudom mikor van multitask, mikor nincs. Nem azt mondtam hogy nincs többszálú futtatás java-ban, PC-n, N900-on használom. De hogy az Androidnak szokása akkor is bezárni valamit ha még bőven van RAM az biztos. Meg az is hogy nyögve tud teljes értékű folyamatokat futtatni egymás mellet vagy sehogy. Hol van még az a rendszer a kisablakokban futtatott áttekintő nézettől... Majd a 48 magos intellel max 48 alkalmazással... Ja és egyébként sry, van benne multitask és tud több appot egyszerre futtatni. Single thread appokat. Magonként. Galaxy S2-n 2.3.4-gyel legalábbis működött. De szerintem ezt hagyjuk. Látom Te a java mánia nevű betegségben szenvedsz. Én meg rühellem azt a nyelvet, öli a számítástechnikát. Nem arra használják amire való. Persze managed kód meg biztonságos. De manapság annyi rés van, hogy ez számít a legkevesebbet. Nem beszélve arról hogy vannak kevert layerek javaban. Nézd a z lwjgl-t. Az csak X86-on megy. Szóval ez sem egyértelmű megoldás amiről beszélsz. Biztonságost nehéz az informatikában csinálni. Minél inkább kutakodsz, hogyan tudod biztonságossá tenni a hálózatod, annál inkább tudod hogy sebezhető. Persze vannak jó módszerkombinációk, de sokszor látom hogy a lehetősége a usernek ott lett volna, van valami brutál védelem, csak hagyott egy baromi nagy kiskaput, amin órák/percek alatt be lehet menni. Ha valaki akar, be is megy.
Egyébként meg próbáld ki a droidot, aztán meg egy N900-at. És utána alkoss véleményt. Droid nélkül már fényévekkel előrébb lenne a mobiltechnika. Engem kifejezetten idegesít hogy a régi gépek multitaskoltak, a mostaniak nem. Vagy senki nem emlékszik már a WinMO+Symbian+Linux kombóra? Csak a hátrányokra emlékeztek? [link] [link] És a maemo5-re mindent lehet mondani csak azt nem hogy kiforrott vagy jó. Egy összegányolt fos. A mostani multitask ennyi ilyen béna szintű appnál sokkal gyorsabb nálam. De az user mod, egyedi kezelőfelület smoothítás, meg a közösségi fejlesztésű CSSUThumb2 eredménye. Ekkora laggot most nekem 4 webböngésző egyidejű futtatásánál produkál.
Egyébként nem tudom mit programozol java-ban, de szerintem rendszert, webböngészőt, játékot, maplesoft matekos cuccát nem kéne java-ban futtatni. GeoGebra se így menne a telómon ha natív lenne. Soroljam még? A gyakorlat nem azt mutatja hogy neked van igazad. Hiába lehetséges minden elméletben, általában a droid amit nem használsz, eltakarítja. Függetlenül RAM-tól, verziótól. Csak nem maradt ellenfele, úgy meg könnyű nyerni.
Elég szánalmasnak is tartom hogy ezeket a nyelveket használják. Itt valóban kijön a JIT miatt a ~10% veszteség, amit bőven kárpótol a multiplatformitás, az egyszerű kezelhetőség, módosíthatóság, meg a könnyebb programozás. De én nem tartozok a lusta gépesek táborába. Mindig HW gondokkal küzdök, és mindig elavult eszközöket használok. Általában megtalálom viszont azt az utat, amivel szoftveresen tartom a lépést. Nomeg a híresen a legtovább stabil és gyors windowst rakom össze egy gépen. Évekig nem kell hozzányúlni. Az enyém már lassulgat (csak az XP), 400alkalmazás, tonnányi driver a telefonszervíz miatt.[ Szerkesztve ]
-
P.H.
senior tag
Egy ISA sosem veszélyes, ha megfelelően le van kezelve OS-oldalról. Az x86-sebezhetőségeknek is az a legnagyobb esélyük, hogy bár az x86 kínálna lehetőséget a 2 GB/app szegmentálására 386 óta jogkörökkel (read-write-execute) felruházva, mégsem használják (ki is került az x64-ből, helyette a lapozást faragják). Persze ez túl bonyolult (de nem lehetetlen) lenne managed kód esetén (a W8 legalább egy idétlen próbálkozás, fúj is rá mindenki, főleg a böngészőfejlesztők), ahol futásidőben készül a végső gépi kód: ami valaminek a kimeneti (adat)területe, az futtatható is.
Dehát managed kód, ez a jövő; mégsem határozhatja meg a programozó fordítási időben, hogy mi a futtatható része a programjának, hogy képzeli
...[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#63
namaste
tag
quailstorm
#61
namaste
tag
válasz
quailstorm
#61
üzenetére
Androidon minden alkalmazás egy Linux folyamat, egy alkalmazás annyi szálat indít amennyit akar és minden futó Java szál egyben egy kernel szál is.
A háttérben futás a fejlesztő döntése, pl. a gyári böngésző nem fut a háttérben, se az oldalon lévő JavaScript kód, se a flash. Ezért nem megy a böngészőben a flash rádió, ha nincs az előtérben. Sőt, ha az OS akarja, be is zárja.
Az Android egy mobil OS, korlátosak az erőforrások, ha szüksége van memóriára egy alkalmazásnak, akkor a többit a prioritásuknak sorrendjében leállítja. -
#64
quailstorm
nagyúr
namaste
#63
quailstorm
nagyúr
És a Symbian meg a Maemo jól mutatja hogy a korlátozásnak semmi értelme. Egy fokig értelmetlen, utána védelem. De előtte nagyon akadályoz. A gyerek meg majd rájön hogy nem kell minden egyszerre. Mint gépen. Symbian is bezár egyébként mindent ami nem sysappként van jelölve, pl ha az Opera kéri a RAMot. Szóval ez sem zárja ki a normális multitaskot. Értem én, megvalósítható. Látom hogy olyan játékok mennek dalvikon amiről nem is álmodtam. De ha az csak egy kapcsoló a programírásnál, akkor miért nem teszik lehetővé hogy párhuzamosan fusson? Mondjuk 6 app? Számomra felhasználói szögből elég szokatlan és idegesítő mindig szembesülni vele, hogy már megint bezárta... Máshoz szoktam. Bocs, ha ez a normális.
-
#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.)
-
#67
namaste
tag
quailstorm
#64
namaste
tag
válasz
quailstorm
#64
üzenetére
Talán túl agresszívan zárja be az alkalmazásokat. One X-re is sokan panaszkodtak, túl hamar kilövi a háttérben lévő appokat.
A háttérben futás nemcsak egy kapcsoló kérdése, sokszor az a helyzet, hogy ha háttérbe kerül egy program, akkor az indított szálakat is leállítja vagy felfüggeszti (maga program). Egy játéknál nem gond, de valószínűleg ez történik a Minecraft szerver részével is. Ha a háttérben is futna, akkor merítené az akkumulátort.
Hogy ez normális? Inkább döntés kérdése. Azt választották, hogy előre felszabadítják a memóriát, nem csak akkor amikor kell és azt ajánlják a fejlesztőknek, hogy csak az fusson a háttérben, ami fontos. -
P.H.
senior tag
Ki kezelje a jogokat, ha nem az OS? (Végülis ez a neve.)
Egy alkalmazás finomíthatja, de túllépni nem tudja a saját hatáskörét. Amelyik túllépi, azt manapság vírusnak hívják, vagy legalábbis biztonsági kockázatnak (ez az böngészők másik neve lassan).
Azt az alkalmazást, amelyet "aljas módon kialakított bemenettel össze lehet zavarni", azt rossznak lehet nevezni, de megfelelő OS mellett kárt nem tesz; a programozó szándékai szerint nem megtörténhető eseteknek pedig nem (csak) a programozó az oka, hanem a nem megfelelő környezet, ami megengedi azt a kimenetelt. Vagy Te írsz olyan programot, ami direkten lehetőséget ad arra, hogy lefusson futásidőben generált programrész?"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)."
Leírtad a lényeget. A legegyszerűbb kártevő se törvényszerűen közvetlen executable ma már. Az MS kódjaiban pedig megbízunk manapság ...vagy mi.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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.
-
#70
quailstorm
nagyúr
quailstorm
nagyúr
Javahuszároknak üzenem: [link]
Smartq T20 AOSP 4.1.2 linpack ~100MFlops multithread, (max 120), 2 thread RgbenchMM:1050MFlops, one thread 404MFlops stock órajelen volt
Nokia N900 AOSP Nitdroid 2.3.4@900MHz: linpack single thread 14-15 közt (MFlops), RgbenchMM:58MFlops single thread. -
#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.
-
#72
dezz
nagyúr
quailstorm
#43
dezz
nagyúr
válasz
quailstorm
#43
üzenetére
"powerAMP natív, nem számít."
Nem tudok róla, hogy az lenne, de szerintem nem is kell annak lennie. Itt nagyon fontos szempont az energiagazdálkodás, úgyhogy a default a befagyasztás, de van lehetőség a háttérben futásra.
-
#73
quailstorm
nagyúr
ddekany
#71
quailstorm
nagyúr
Be ne beszéld nekem hogy a java a gyorsabb, mert még elhiszem. Teneked fingod sincs hogy 2006-ban mikre készült a Nokia. Csak senki nem kapott az ajánlatra. Kész játékmotorral és SDK-val szállították az OMAP2420-at. Kb. Quake 3 szintű grafikát tudott, és a Futuremarkkal gyártatták le(ha már finnek). Ehhez képest a droid miatt most tartunk ott mint 4 éve. Csak nem elég látványos. De mindegy, hagylak a tudatodban, így legalább boldog vagy. A java akkor sem a leggyorsabb. 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. A biztonságot a hatékonysággal összeegyeztetni nehéz. És ilyenkor jön be a java, hogy hamarabb, könnyebben megvalósítják. De normál körülmények közt lassabb mint a natív kód érted?
Egyébként az MFlops felfogható mértékegységnek. Szóval nem értelek. Nem 3Dmarkokat osztogat. MFlops, alapmértékegység. De Te csak bele akarsz kötni...
(#72) dezz: amit csinál, az külön procin, a DSP-n megy. Amit grafikusan csinál, azt meg honnan tudod nem-e lefagyasztja mikor nem látod? És igen, van egy service folyamata ami megy háttérben tudom. De ez közel sem olyan hardverigényű mint amiről beszéltem, a flash player a böngészőben. -
#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.
-
#75
quailstorm
nagyúr
ddekany
#74
quailstorm
nagyúr
Ja, nem tudtam értelmezni az oldalt, nem néztem elég ideig. Mindegy, pótolom.
Azzal egyetértek hogy amit a RGbench művel az se egyezik a linpackkal. De valami alapot ad a c++ vs. dalvik összehasonlításra. És a Linpack oldalán is le van írva googleplayen, hogy a dalviktól függ. 2.1-ről 2.2-re volt a legutóbb giganagy ugrás HW kezelésben.
Már nem találom, de valami atomrégi i386 architektúrán futtatott benchmark volt ahol a java nyert. És ugyanazt a kódsort futtatták többféle programnyelvből fordítva. Már a rendszerre se emlékszek, de sztem windows.
(a java7 is jóval jobb lett mint a 6. Legalábbis ARMv7 platformon biztosan)[ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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.
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-