Új hozzászólás Aktív témák
-
#75
quailstorm
félisten
ddekany
#74
quailstorm
félisten
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) -
#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.
-
#73
quailstorm
félisten
ddekany
#71
quailstorm
félisten
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. -
#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.
-
#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.
-
#70
quailstorm
félisten
quailstorm
félisten
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. -
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.
-
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. -
#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. -
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.)
-
#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.
-
#64
quailstorm
félisten
namaste
#63
quailstorm
félisten
É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.
-
#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. -
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 ... -
#61
quailstorm
félisten
ddekany
#56
quailstorm
félisten
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. -
#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). -
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.
-
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.
-
#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.)
-
#54
quailstorm
félisten
P.H.
#53
quailstorm
félisten
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. -
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. -
#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.
-
#51
quailstorm
félisten
nyunyu
#50
quailstorm
félisten
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. -
#50
nyunyu
félisten
quailstorm
#49
nyunyu
félisten
válasz
quailstorm
#49
üzenetére
Mivel nem a linux futtat VM-eket, és elszigetelt VM-ekben futtatja a java appleteket, hanem van egy nagy java VM, és annak az erőforrásai oszlanak szét
Ha minden alkalmazasnak kulon VMje lenne, akkor osszessegeben sokkal tobb eroforrast hasznalnanak, hiszen a VMek kozott is lenne context switching, annak minden proci+memoriaigenyevel egyutt.
Igy viszont egy szarul megirt app siman bedontheti a nagy VMet, tobbiek elol elszivva a processzort.
Elvileg egy preemptiv oprendszernek pont az lenne a lenyege, hogy idonkent elvegye a procit az eppen futo alkalmazastol, es ujrautemezze a tobbit, hogy egyik taszk se maradhasson prociido nelkul.
-
#49
quailstorm
félisten
ddekany
#47
quailstorm
félisten
Az hogy atomra lezabálná az erőforrásokat. Mivel nem a linux futtat VM-eket, és elszigetelt VM-ekben futtatja a java appleteket, hanem van egy nagy java VM, és annak az erőforrásai oszlanak szét, egy gyengébb telefonnak már a PowerAMP, az Antutu CPU master, és a super taskkiller is gondot okoz a launcher mellett. Míg ugyanaz a modell linuxszal alázza a 80k-s mobilokat (mondjuk azért az a droid nincs még kész de attól még látszik hogy kínlódik)...
" Tud egyszerre is futtatni" nem vettem észre, azonnal kinyomta a gameservert ahogy home-ot nyomtam. Pedig RAM ban volt mert 2 másodpercen belül újraindította az appot ugyanott.
Más kérdésem, használtál már Symbian Bellét, N900-at vagy N9-et? Mert szerintem azért nem tudod mi a multitask... Majd ha bebukik a droid mert nem tud túllépni a korlátain, és lesz más OS ugyanazon HW-n, akkor rájössz miről beszéltem, vagy nem...
Tudniillik az N900(OMAP3430, 256MB RAM 1GHz, SGX530) tud futtatni JavaSE appleteket párhuzamosan multitaskolva embedded JRE7u6-tal, PhoneME-vel J2ME-n közben, flasht meg natív appot is, csak ez így más értelmetlen meg sok. De ha nem a Minecraft server(nem nem pocket, desktop) az egyik ezek közül, akkor még értelmes marad a sebesség is. Meg a 3d ablakváltás tudod az élő frissítésű bélyegképekkel. Na ezt csináld meg droidon. Már az ICS állóképeinek örültetek... (tudom ilyen Belleben nincs grafikusan, de multithreadet se tud a CPU...) Viszont ha érdekel azon a platformon is tudom bizonyítani hogy igenis akár két 3D alkalmazást is tud párhuzamosan futtatni.
(#48) devast: igen amiket fentebb felsoroltam, azok a services kategóriába tartoznak, főleg hogy a médialejátszónak van egy külön mag a DSP. Nem taskok. "PowerAMP, az Antutu CPU master, és a super taskkiller" háttérben ez service, a minecraft pocket server meg task lenne, a flash webrádió is. -
#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?
-
#45
quailstorm
félisten
freeapro
#44
-
freeapro
senior tag
Nekem az ARM kicsit Cyrix utánérzés.
Ők se tudták teljesítményben utolérni az intel/amd párost majd elkezdték nyomatni az energiahatékonyságot. Ugyanezt látom ARM-ra is, csak szerencséjükre éppen jött az okostelefon boom amikor erre volt szükség és az androidot (gondolom ez már inkább politika) rájuk építették -
#43
quailstorm
félisten
ddekany
#40
quailstorm
félisten
Aha, veled már vitáztam erről. AZ OS NEM DÖNT ÚGY HOGY BEZÁRJA A FOLYAMATOT VILÁGOS? Arról csakis ÉN döntök, az aktuális user. Persze tegnap örültem neki hogy végre előfordult hogy megjegyezte hol volt nyitva a play store, vagy a totalcommander, de ez nekem édeskevés. Fejlettebb platformról jövök. Vita lezárva. 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...
A managed kód szinte automatikusan hozza magával a többi nyavalyát, írtad is, azt a sok réteget én se szeretem. Én úgy vagyok vele hogy legyen a rendszer linux alapú, mondjuk debian emberbarát shellel. És OPCIONÁLIS dalvik, mint ahogy PC-n a java. Ha kell fut, de ha nem, akkor nem pazarolja a ramot. Meg managed kódban ilyen gyenge ARM gépeken nehezebb megvalósítani a multitaskot mint natívan.
(#42) dezz: powerAMP natív, nem számít. Majd ha flash alapú webrádiót hallgatsz webböngészőből, a haverod melletted nyomja a tableteden futó MC pocket szerveren a minecraftot, te meg pl a gmail appban levelet írsz, akkor szóljál ok? -
#42
dezz
nagyúr
quailstorm
#30
dezz
nagyúr
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)"
Érdekes, nekem akadásmentesen megy pl. a PowerAMP, miközben mindenféle mást csinálok (web, filekezelés, játék [utóbbit ritkán, kislányom miatt vannak fent játékok])...
"2 folyamatot nem tud lekezelni."
2-t!? Jóval többet is!
"Nem fogok kibékülni azzal, hogy amit nem használok az le van fagyasztva."
Ez az app beállításaitól függ.
(#41) Mister_X: Mindezeket csak utólag írtad... Szerintem egyébként a Porshe egy szar autó. Egyszer láttam egyet lerobbanva...
Amúgy igen, az sem mindegy, pl. milyen PC-hez hasonlítjuk. Az már nem volt olyan rossz, mint a korábbiak. Bár Amigával is hozható volt az szint, jobb OS-sel (A1200/A4000, 68060, esetleg videokártya, OS3.1 [felcsinosítva]).
-
Mister_X
nagyúr
Írtam, hogy Amiga 500. Írtam, hogy nem sok tapasztalatom volt vele. Írtam is, hogy miért hittem azt, hogy nem volt 32 bites a rendszer. Írtam, hogy hány éves voltam akkor. Írtam, hogy utána Windowshoz több közöm volt, annyi idősen csak annyit tudtam viszonyítani. Ezek után te még mindig belémkötsz. Nem baj, te vagy a nagyokos, kapsz egy szóbeli vállveregetést.
(Egyébként igen kellemes volt az első PC-m: Pentium 133, 32MB RAM, S3 SavageIV 8MB, 1.6GB vinyó, CD-ROM - ehhez tudtam viszonyítani az Amigát)
-
#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ű.
-
dezz
nagyúr
Jó, akkor félig cooparative volt, félig pre-emptive. Maga az OS is, és a korábbi (16 bites) programokat is a cooperative scheduler kezelte. Lassan kezdtek szállingózni a 32 bites appok.
(#37) Mister_X: És most azért volt kezdetleges az Amiga, mert te csak az A500-at ismerted, 1.2-es OS-sel (a kinézetet leszámítve mellesleg az sem volt rossz), vinyó nélkül? (Turbókártyáról nem beszélve.) Most erre mit lehet mondani? Ilyen alapon bizony nem lehet szakmai véleményt alkotni. Ha mégis megteszed, ne csodálkozz az eredményen...
Így néz ki egy AOS4.1: [link]
-
Mister_X
nagyúr
Aha, ennyi erővel csak az írjon a fórumra véleményt, akinek van 2-3 év szakmai tapasztalata
De mindegy, én abbahagyom itt, mert nincs meg a kellő tapasztalatom és lexikális tudásom, hogy vitába bonyolódjak egy Szakértővel. 
Nekem a PC a család Amigájához képest megváltás volt. Utóbbin gondolom az 1.1/1.2-es WB volt mert grafikailag elég vérszegény volt. És nem kellett a lemezeket cserélgetni.
-
dezz
nagyúr
Jó, de akkor ilyen korlátozott tapasztalatokkal nem érdemes véleményt alkotni.
"Enterprise meg grafika terén szinte volt Amiga szintű"
Hát Nagyon nem! Az Amiga500 640x512-ben (overscanben 768x576-ban) tudott 256 színt, illetve HAM-ban 262k-t. (Az A500+ már 1280-ban is [oc 1536].) Az Enterprise 2 színnel tudott 640x512-t, 4-16-tal 320x512-t és 256-tal 80x512-t... Aztán Amigán még ott volt a Copper (saját programot futtató cooproci, ami képernyősoronként ~100x tudott átírni kvázi tetszőleges custom chip regisztereket [mint pl. színek, bitmap pointer és modulo, vagy éppen a Blitter regiszterei], sorra és 4 pixelenkénti pozícióra időzítve) és a nem csak memcopy-t tudó Blitter, továbbá az akár 16 színű, korlátlan hosszúságú sprite-ok. A memóriával sem kellett sprórolni, lévén a többszöröse volt.
Mit nem lehetett Workbenchben csinálni, amit Win95-ben igen? (Mellesleg ugye a Win95 10 évvel később is csak cooperative multitask volt, azaz ha egy program terhelte a procit, minden akadozott, nem beszélve arról, ha lefagyott. És még a GUI kezelés is butább volt.) Ismerted a 2-est, vagy csak a grafikailag kezdetlegesebb 1.2/1.3-at? Mi akadályozott meg, hogy akár a Workbench screenen, akár saját screenen mindenféle egyéb programot futtass?
Egyébként csak annyira volt előremutató, hogy világszerte több ezren még mindig használják, na nem az A500-at (játékra talán), hanem az A1200/A4000-et, PPC-s turbókártyával, újabb OS-sel...
-
Mister_X
nagyúr
Egy hét-nyolc éves gyerek mit csinállt volna vele? Játszott, mint én. És nem beszólásnak szántam, egyszerűen "rámragadt az IBM PC mocska", ahol a 32bit eljövetele magával hozta a 3D-t is.
Enterprise meg grafika terén szinte volt Amiga szintű, sőt, a nyolc bites gépek között a legjobb volt. Persze ilyenkor nem A1200-ra meg A2000-re gondolok, az már más kategória volt.
Nameg azért a Workbench. Hááát. Azért egy Windows 95-tel több mindent lehetett művelni, de lehet ezt azért mondom, mert több közöm volt hozzá. Aláírom, majdnem tíz év van a kettő között, ezért az AmigaOS a maga módján előremutató volt.
-
dezz
nagyúr
Itt csak te szóltál be az összes (ex-)amigásnak... Ha egy "vélemény" sértő és megalapozatlan, akkor talán nem kellene leírni. Az pedig modortalanság, hogy nem válaszoltál a #15-ösre. Én nem tudom, mit csináltál te az Amigával, de messze nem Enterprise szint. Sem prociban (Z80 vs. 68k, nem egy súlycsoport), sem grafikában, sem OS-ben. (Az utóbbit talán nem is ismerted. Lemez be->game.)
Annyiban van igazad, hogy az A500 HW-e (proci környezete [turbókártya nélkül] és a custom chipek) 16 bites. De az OS környezet messze nem 16 bites benyomást keltett, hiszen túlmutatott a Win95-ön is (ami akkor még sehol sem volt...). Ugyebár az első kisgépes preemptive multitasking oprendszer volt, jóféle ablakkezeléssel és sok egyéb újítással. (Bár szerintem te csak az AOS 1.2-t ismerhetted, ami még kicsit nyers kinézetű volt alapból. De gondolom, még ezt is ritkán láttad. Volt hozzá egyátalán vinyód? Turbókártyát nem is kérdezem.) Csak hát az Amiga != A500.
(#31) Alchemist: Fizikailag is 32 bites a 68000, csak kifelé multiplexelt az adatbusz (és mint korábban írtam, automatikusan intézi a 32 bites adatok írását/olvasását). A címvezetékek A1-A23-ig "tartanak". A programok mind 32 bitesek voltak és azonnal profitáltak a 68020-asból és társaiból.
-
Alchemist
addikt
abban a hitben voltam, hogy a processzor 16bites.
Fizikailag 16 bites, de az architektúra 32 bites, mint a 386SX esetében (olcsóbb volt a fizikai 16 bit).
Tessék, Enterprise: szinte Amiga szint, de csak nyolc bites.
Az Enterprise jó kis gép volt, anno assembly-ben fejlesztettem rá, de azért az Amiga nyers erőben és továbbfejlődési potenciálban felette állt. A M68k családot assembly-ben jóval kellemesebb volt programozni, mint akár a Z80-at, akár az Intel 32 bites korszak előtti procijait.
-
#30
quailstorm
félisten
Remus389
#28
quailstorm
félisten
Bocs, végig se néztem. A cím elég volt. Boot, nem érdekel, ha 5 percen belül van. Multitasking, egyik rendszer se tudja. Pont.
Ismerős a neved, nem emlékszer arra a Nokiás, Symbian+Maemo őrült elmebeteg egyénre aki minden másik rendszert szid(kiv WinMO)? Mert az én vagyok.
Az Apple cuccai nem érdekelnek, sose volt. Üzletpolitikájuk egy fos, kockákra nem gondolnak. Jailbreak nélkül nekem nem kell iPhone, semmiképp. Úgy is csak telefon+PSP pótló lenne. Számomra nem tud sokat nyújtani a cucc. Azt viszont elismerem, hogy az iOS3-mal, de főleg a 4gyel nagyon összekapták magukat, és összeraktak egy bitang optimalizált rendszert. Highgend cuccokkal nem foglalkozok, a legerősebb cucc amiről lehet véleményem az az SGS2. Ott is csak a fejemet csóválom. Eleget csodálkoztam azon is hogy az Adreno 205-öt földbe döngölő GPU-t nem használták, az iPhone-ban lévőt meg a 3-mas frissítéstől kezdve igen. Méghozzá elég szépen. Pedig az a lite verzió, nem volt nagy gaming jövőre tervezve...
Nem az android nem reumás csiga, sokkszor már az S60v3-mason akaszt ki. 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. Sokszor egyet sem. Kívülről szép, belül rohad. Nem fogok kibékülni azzal, hogy amit nem használok az le van fagyasztva.
Na mindegy hagyom a dumát, az a lényeg hogy iOS optimalizált, 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. Multitaskról meg akkor beszélj ha futtattál Symbian Bellén, vagy Maemo5-ön (esetleg Meegon) 40-50 appot egyszerre. Ja és 256MB RAM-on. Nem nem fog összeakadni, kivéve ha 4 webböngészőt használsz egyszerre, akkor lassú lesz.
Az ilyen CPU-k android alatt integer meg float pontszámnövekedést okoznának, a dalvik maradna 32bites, és sokáig egy két appon kívül semmi értelme nem lenne az egésznek. Meg nézd meg az SGS3-mat, kisírja az exynos-szal a 180MFlopsot 4 magon, az iPad2 meg dob rá 250-et. Ahha, jólvan, pedig elméleti síkon fordított az erőviszony csakhát emulátor.
Én anno nem jósoltam nagy jövőt a droidnak, annyira nevetséges és hülye ötlet volt a kezdetektől fogva. Csak a többi rendszernél megállt az idő, így előtérbe kerülhetett. Ez van.
Egyébként meg nem érdekel semmilyen mobilvallási háborútok, de azt illik elismerni hogy az iOS és appjai igenis optimalizáltak. A multitask meg nem abból áll hogy emlékszik melyik menüpontnál hagytad ott az appot. -
Mister_X
nagyúr
Szerintem meg leírhatom a véleményem anélkül, hogy beszólnál
Attól, mert még 'szakértő' vagy, leszállhatnál a magas lóról...Én rengeteget amigáztam kiskoromban és máig abban a hitben voltam, hogy a processzor 16bites. Mert szerinted a látványra mekkora hatással vannak? Tessék, Enterprise: szinte Amiga szint, de csak nyolc bites.
Megadom neked, hogy bizonyítsd az igazad. Hajrá.
-
#28
Remus389
veterán
quailstorm
#23
Remus389
veterán
válasz
quailstorm
#23
üzenetére
annyira bírom hogy egyesek még mindig azt hiszik az android egy reumás csiga egy szupersportkocsihoz képest(ugye az iOS)
a valóság nem ennyire kiélezett(inkább kiegyenlített) [link]
kicsit van lemaradva, már ha számít az a pár tizedmásodperc, századmásodperc
mondjuk itt az iphone van előnyben, az A6 chip jóval erősebb, még ha csak kétmagos
az ilyen új processorok lehetővé teszik hogy elérjék a mostani iphone5 szintjét, ami tök jó
-
#26
quailstorm
félisten
hcl
#24
quailstorm
félisten
Amiket nagyon bírok, azok az androidos 3D benchmarkok. Az ismertebbek 99%-a olyan mint a hányás. Az N95-ömre a 3DMarkMobile06 az legalább ki is néz valahogy... A másik amit nem szoktam tudni felfogni, hogy az AnTuTu pár polygonból álló lovagjai hogy a retekben tudnak laggolni? A legotrombább GPU elvinné 120FPS-sel, főleg mivel nem is csontvázanimált, hanem olyan mint a quake1 engine... Ehhez képest egy DOOM resurrection iPhone 2G-n megint kinéz és halad. Valamit nagyon elszúrtak a droiddal, és az az optimalizálás lehetősége. Túl messze kerültek a HW-tól, nagyon sok layeren keresztül kell menni.
-
#24
hcl
titán
quailstorm
#23
válasz
quailstorm
#23
üzenetére
Na ja, a droidban az opensource mivolta nincs kihasználva, a Java felület meg megöli az egészet.
Pedig jól indult. -
#23
quailstorm
félisten
quailstorm
félisten
Nagyon örülök hogy végre bekerült a 64-bit az ARM-re, de örömöm nem felhőtlen. A legnagyobb hardvereket mindig az android kapja meg. Miért? Mert azzal is szar. A többi platform meg még a mostani csúcsot se használta ki, ha Almáékat vesszük, 2 magra optimalizálnak, nem 6-meg 8-ra. De még csak 4-re sem. Ennek ellenére a legjobb teljesítményeket érik el ARM-on. Szeretném ha a szoftverfejlesztés nem csak távolról loholna a hardverek után... (a WP meg csak most váltott nem elavult HW-ra, bár mire kijönnek...)
Majd jönnek gondolom válaszként rám a flamelők. Előre szólok, hogy ugyebár rühellem az androidot, de nem azért, mert nagy a support, testreszabható, nyílt vagy sok az alkalmazás. Ezt én is szeretem. Hanem mert egy elcseszett emulátor, ami nyomorba dönti a legerősebb HW-t is, a galaxy S3 meg egyenesen sír alatta, miközben az iPad2 röhög rajta. Nem az egész rendszert kéne emulátorba építeni, csak lehetőséget adni a nagyon egyszerű appok java-ban futtatására. Mert akkor tényleg sok app lenne, könnyű fejlesztéssel. De hogy a telefonkönyv, a tárcsázó, meg a NOVA3 mit keres a dalvik keretein belül, azt nem értem... Vagy nézzük a flash plugint. Hardveresen gyorsított emulátorban emulált hardveresen gyorsított emulátor. Ennek ellenére az egyetlen platform a droid, amire van normális hatásfokú mobil flash. WTF?
Kérdem én, hol fog kijönni a droidban az új platform előnye? És mikor fogja a többi platform a rendszer alá pakolni az ARMv8-at? Lehet még év(ek) kérdése. -
Az egy dolog, hogy 32 bites valami, meg egy másik, hogy milyen körítéssel van körberakva, illetve pl. attól, hogy 32 bites a proc, nem lesz magasabb az órajele, sem a mellé pakolt RAM menniyége.
Lehetett volna akkoriban is 4Gb RAM egy PC-ben, ha megérte volna hozzá chipsetet fejleszteni, meg megfizethető lett volna
Az i386 is meg tudta címezni... -
Nagyon zsír, az x86-os procikhoz képest nagyon nagy előrelépések vannak ezekben a cuccokban.
@ Abu: 85 HSA meg kell, főleg az AMD APU-knak lesz jó... Az is egy nagyon tuti architektúra, ha lesz végre, ami kihasználja...
-
Alchemist
addikt
Motorola... hát valahogy nehezen jött össze nekik a 32bit.
Izé... a korabeli MacIntosh, az Amiga, az Atari ST és TT már akkor 32 bites grafikus oprendszert futtattak a Motorola 68k-s procikon, amikor a MS még az első kapavágásoknál tartott a 16 bites, DOS-on csücsülő Windows-zal (nyolcvanas évek közepe).
-
Abu85
HÁZIGAZDA
Ezt az Intel is tudja, így nem is az ARM-tól vannak megrettenve, hanem az ARM-tól és a HSA-tól egyszerre. Ez megadja a fejlesztőknek azt, hogy ne törődjenek a fizikai ISA-val. Megírják HSA-ra és fut bármin a program módosítás nélkül. Az Intelt ez a dolog azután érinti kellemetlenül, hogy megváltoztatták az 1.0-s tervezett speckókat, így anélkül is fut a program bármilyen hardveren, hogy az direkten támogatná a runtime-ot. Ez a legacy mód.
-
dezz
nagyúr
"Aztan a Pentiumra mar nem tudtak valaszolni."
Már a 68060 is hozta a Pentium teljesítményét. A PowerPC-k pedig a P2-P3 szintet. Ami a desktopot illeti. Szerver szintem sem voltak(?) rosszak a Powerek.
(#14) Mister_X "hát valahogy nehezen jött össze nekik a 32bit."
Már a legelső 68k is 32 bites volt belülről (amit hw-esen fordított 2x16 bites írásra/olvasásra kívülről, a programok számára átlátszóan). 1979-ben! Aztán a 68020 már kívülről is, 1984-ben! A Power/PowerPC meg persze eleve kívülről/belülről az volt.
Nem a 64 bitre gondoltál véletlenül?
-
Mister_X
nagyúr
Gyárilag van rajta Office, irodába maximum ezen felül egy browser kell, arra meg ott az IE. Miért éri meg egy vállalatnak az irodáiba pakolni?
- olcsó
- keveset fogyaszt
- Office
- nem áll fenn a veszélye annak, hogy a dolgozó a munkaidőt végigdiablózza
Aztán szépp lassan csordogálnak majd az appok, az oroszok meg már úgy is dolgoznak valami x86->ARM fordítón.Motorola... hát valahogy nehezen jött össze nekik a 32bit. Na meg akkoriban az IBM (kompatibilis) PC egyenlő volt az Intel processzorral, apám még rendesen szidta is a programozókat (vagyis inkább a legközelebbi női ágú felmenőjüket), mert sok program nem volt hajlandó futni Cyrixen
Én már 2001-ben is olvastam az x86 elavulását, halálát
-
nyunyu
félisten
Na jo, de azon a herelt Winen mi fog futni?
Mostani desktop alkalmazasok biztosan nem.
Elmult tizen-huszonevben parszor mar temettek az x86 platformot, aztan meg lehet nezni, mire vitte pl. a Motorola, aki egy idoben minimum olyan jo procikat gyartott, mint az Intel. Aztan a Pentiumra mar nem tudtak valaszolni.
Vagy Intel hazatajan ott volt a vilagmegvalto Itanium. Egy idoben meg Windows is futott rajta.
-
#12
Mister_X
nagyúr
Ł-IceRocK-Ł
#10
Mister_X
nagyúr
válasz
Ł-IceRocK-Ł
#10
üzenetére
Én meg akkor arra, hogy a Win8 RT-t meg lehet-e majd külön venni, moduláris lesz-e az ARM-es PC meg ilyenek.
Már mondjuk az megvalósítható, hogy csinálnak egy ARM-es set-top-box-ot és azt adják el RT-vel. Ami nem is lenne hülyeség, irodákba kapkodnák őket, mert olcsó lenne és keveset fogyasztana - elég egy tabletből kiindulni amit megfosztunk az aksijától, képernyőjétől, kamerájától.
-
#10
Ł-IceRocK-Ł
veterán
Ł-IceRocK-Ł
veterán
Egy asztali ARM alapú rendszerre nagyon kíváncsi volnék.
"félelmetes jó" , itt lemaradt az "en" a végéről. szerintem.
-
#9
Speeedfire
félisten
Speeedfire
félisten
Egyre több az ARM hír.
"
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).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De mindegy, én abbahagyom itt, mert nincs meg a kellő tapasztalatom és lexikális tudásom, hogy vitába bonyolódjak egy Szakértővel. 
fejlődnek a kis kütyük 
Az i386 is meg tudta címezni...
Új hozzászólás Aktív témák
- Apple Watch SE 2020 ezüst, 44mm // Számla // Garancia // Válaszható szíj //
- HIBÁTLAN iPhone 14 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3093, 91% Akkumulátor
- ÁRGARANCIA!Épített KomPhone Ryzen 9 5900X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- GYÖNYÖRŰ iPhone 13 mini 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3447, 94% Akkumulátor
- Bomba ár! Lenovo ThinkPad X280 - i5-G8 I 8GB I 512GB SSD I 12,5" FHD I HDMI I Cam I W10 I Gari!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest