- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- OLED TV topic
- Milyen alaplapot vegyek?
- Alulról bővítette professzionális VGA-it az NVIDIA
- Gaming notebook topik
- Projektor topic
- VR topik (Oculus Rift, stb.)
- Azonnali informatikai kérdések órája
- Május 7-én lesz az új iPadek bemutatója
- Fejhallgató erősítő és DAC topik
Hirdetés
-
Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
ph A szokatlan külsejű CineBeam Q képes a 4K felbontás megjelenítésére.
-
A TikTokon marakodik Trump és Biden
it Trump szerint ha betiltják a TikTokot, annak a felelőse Biden lesz. A betiltás Trump szerint csak a Metát tenné még gazdagabbá.
-
Megjelenési dátumot kapott a Metaphor: ReFantazio
gp A tervek szerint a végső kiadás októberben lesz elérhető PC-re és konzolokra.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Az iOS termékeknél sokkal kedvezőbb a memória kezelése, mint más platformon. Ezért tud sokkal kevesebb memóriával is sokkal jobb lenni.
Kicsit hasonló a helyzet, mint a konzolnál, hogy PS4-en 4 GB-ba teljesen befér egy olyan program, amely PC-n 8 GB rendszermemóriát és 6 GB VRAM-ot igényel a jó sebességhez. Persze az iOS előnye nem ilyen extrém, de egyértelmű, hogy ez az operációs rendszer sokkal jobb lehetőségeket rejt a memória kezelésére vonatkozóan, mint mondjuk az Android.Nagyon sok múlik azon, hogy a szoftvert mit tesz lehetővé a hardver kihasználása szempontjából.
(#6) vicze1: Nem. Jóval többet tud még az OpenGL ES 3.1-nél is. Viszont az említett tesztprogramban még nincsenek OpenGL ES 2.0-s igénynél túlmutató effektek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Persze az iOS előnye nem ilyen extrém, de egyértelmű, hogy ez az operációs rendszer sokkal jobb lehetőségeket rejt a memória kezelésére vonatkozóan, mint mondjuk az Android."
Igy van. Az Android borzaszto memoria es eroforras pazarlo oprendszer. Alapvetoen olyan elvre (Java) epult, ami desktop vagy szerver kornyezetben, sok-sok memoriaval es nagyon fontos: virtualis memoriaval (lapozofajl) megtamogatott rendszerekhez idealis. Az Android memoria kezelese botrany, es amig nem raknak ala lapozofajlt (ami a flash memorias hattertar miatt nem lehetseges), vagy nem alakitjak at gyokeresen, addig sajnos kenytelenek a keszulek gyartok 2-3x tobb memoriat berakni a keszulekekbe, mint amit a rendszer tulajdonkeppen igenyelne. Az Android alapjaiban rossz, es hiaba faragjak, patchelgetik, sosem lesz igazan jo, sajnos. Nagyjabol olyan, mint a Windows, amit mindenki szeret kopkodni, mert regi szutyok es sok a baj vele -- na az Android is ilyen, csak me'g nem erzik a felhasznalok elegge a borukon, hogy kiboruljanak miatta
De elobb-utobb sajnos eljon majd az a pont, amikor vagy atalakitjak az Androidot, vagy a felhasznalok fellazadnak... -
vicze
félisten
"Alapvetoen olyan elvre (Java) epult"
Ez se igaz teljesen mert ugye alapvetően még anno ARM-es környezetre szánták setoboxokra, ezért is volt/van az ARM CPU-kban Java HW gyorsítás (Jazelle,Thumb). Tehát alapvetően beágyazott rendszerekhez.
Amit később műveltek vele és erőszakolták meg egyre durvábban, az teljesen más történet. Teljesen elmebeteg dolog, hogy egy VM-ben fut valami, amihez HW gyorsítás van a CPU-ban... Most hogy az ART-al átlép LLVM-é, meglátjuk változik-e valami ezen a téren. Ha szerencsénk van eltűnnek a memória kezelési gondok hosszútávon."es amig nem raknak ala lapozofajlt" - Ott a SWAP partíció mindegyiken, külön fájlrendszerrel. A Linux attól még Linux marad...
-
Az iOS termékeknél sokkal kedvezőbb a memória kezelése, mint más platformon. Ezért tud sokkal kevesebb memóriával is sokkal jobb lenni.
szép és jó, de ettől még elférne minden mobil kütyüjükben +100% memória. Az eszköz teljes árához képest filléres összeg lenne és hosszú távon biztosítaná az eszköz jövőállóságát, ami persze csak a usernek érdeke nem az apple-nek, neki az asz érdeke, hogy tervezhesse és kényszeríthesse az eszközeinek az elavultatását amihez a legjobb eszköz a limitált memóriamennyiség.
Az hogy az Androidnál jobb a memóriakezelése az evidens, de hogy Windows Phone-nál vagy akár egy Linux telefonnál jobb lenne az bizonyítást igényel. Van erre valami kézzel fogható (nem fejtegetés alapú) forrásod?Kicsit hasonló a helyzet, mint a konzolnál, hogy PS4-en 4 GB-ba teljesen befér egy olyan program, amely PC-n 8 GB rendszermemóriát és 6 GB VRAM-ot igényel a jó sebességhez.
Persze persze..
Ami PCn 8GB RAM-ot és 6GB VRAM-ot foglal azt vagy direkt baszták el vagy minőségileg szebben és jobban fut mint PS4-en. Az összehasonlítás akkor lenne releváns, ha PC-re a programokat JVM-re írnák.J
-
vicze
félisten
Igen igen. Úgy hogy a GC teljesen újra lett írva, drasztikusan jobb teljesítménnyel.
"Under Dalvik, apps frequently find it useful to explicitly call System.gc() to prompt garbage collection (GC). This should be far less necessary with ART, particularly if you're invoking garbage collection to prevent GC_FOR_ALLOC-type occurrences or to reduce fragmentation."Olvastam egy összehasonlító cikket(amit nagyon nem találok épp...
), ahol elég mélyen kielemezte a srác a Dalvik és ART(még 4.4, ha jól emlékszek) alatt az app futást a GC-re kihegyezve. Nagyon tisztán látszott, hogy a GC futási idő drasztikusan lecsökkent, azok a mikrolagok amiket a GC okozott futásidőben szinte teljesen megszűntek, és a teljes "GC pause" idő 90%-kal csökkent.
Próbálom megtalálni...Szerk: "Csodás" az emlékezetem... AnandTech
[ Szerkesztve ]
-
Igy van. Az Android borzaszto memoria es eroforras pazarlo oprendszer. Alapvetoen olyan elvre (Java) epult, ami desktop vagy szerver kornyezetben, sok-sok memoriaval es nagyon fontos: virtualis memoriaval (lapozofajl) megtamogatott rendszerekhez idealis. Az Android memoria kezelese botrany, es amig nem raknak ala lapozofajlt (ami a flash memorias hattertar miatt nem lehetseges), vagy nem alakitjak at gyokeresen, addig sajnos kenytelenek a keszulek gyartok 2-3x tobb memoriat berakni a keszulekekbe, mint amit a rendszer tulajdonkeppen igenyelne. Az Android alapjaiban rossz, es hiaba faragjak, patchelgetik, sosem lesz igazan jo, sajnos.
Az Android a konzumerelektronika szemete, nem kell ezt ragozni...
Nagyjabol olyan, mint a Windows, amit mindenki szeret kopkodni, mert regi szutyok es sok a baj vele -- na az Android is ilyen, csak me'g nem erzik a felhasznalok elegge a borukon, hogy kiboruljanak miatta
De elobb-utobb sajnos eljon majd az a pont, amikor vagy atalakitjak az Androidot, vagy a felhasznalok fellazadnak...Ezt nettó hülyeségnek érzem. Mióta lehozták desktopra az NT kernelt mindig is a Windowst tartottam a legmodernebb általános célú oprendszernek, legalábbis ami a motorháztető alatti részt illeti.
A hasonlatod viszont szerintem tökéletesen igaz abban az esetben, ha az Androidot a Win 9.x-hez hasonlítod. Na az arhitektúrálisan egy botrány volt, nem a minősége, hanem a szoftverellátottsága illetve beágyazottsága miatt használta mindenki, egyébként meg folyamatosan viccek céltáblája volt. Na az Android (kiforrottságban) most tart ott, ahol a Windows tartott 1995-ben.
-
vicze
félisten
Illetve még ez:
"The Dalvik garbage collector needed to pause your app twice in order to mark objects for collection. ART halves GC pausing, and parallelizes processing during the remaining pause cycle. It also introduces a new collector that cleans up short-lived objects with a lower pause time, and maintains larger primitives (like bitmaps) in a separate pool. Finally, one of the biggest improvements ART brings is concurrent garbage collection scheduling, which will all but remove the dreaded GC_FOR_ALLOC statements that developers see in their log statements."És most térjünk vissza a Metálhoz.
#7-esre valaki? [ Szerkesztve ]
-
Fiery
veterán
Koszi, ez erdekes iromany. Vegul is, ha osszeadjuk az ART-ot, a hatekonyabb GC-t, a large object space-t, meg a (ha jol ertelmezem) me'g nem mukodo defragmentalast, akkor mar kezd kozeliteni a hasznalhato szinthez. Mondjuk ezzel me'g mindig nem oldodik meg a memoria pazarlas, hiszen tovabbra is fix heap szeletek lesznek leosztva az appoknak, de legalabb a memoria allokacioknal gyorsabb es kevesbe exception dobalos lesz a cucc. Haladas, de ez me'g mindig csak tovabb faragasa az alapvetoen rossz koncepcionak
-
Fiery
veterán
A Windows kernel maga jo a Windows 2000 (oke, legyen XP) ota. A Windows azonban sokkal tobb, mint csak egy kernel, es nagyon sok resze borzaszto elavult
Pl. az ablak kezelo resz botrany: az elso full-HD notebookok ota nem tudjak megoldani az UI skalazast rendesen, es me'g tervben sincs az -- legalabbis en nem lattam ilyen terveket --, hogy megoldjak azt az elkovetkezo par evben. Aztan ott a hardveres es szoftveres fragmentacio (remelhetoleg a Windows RT kuka, azzal kicsit javulna a helyzet), es a rettenetes nyakatekert, pazarlo megoldasok, pl. Java, .NET, DirectX es tarsaik. Teny, hogy az Android jobban hasonlit a Win9x-re, de a modern Windows rendszerekkel is rengeteg problema van, hiaba jo a kernel Az Android kernele sem rossz egyebkent, ha minden app C++-ban keszulne es nativan leforditva futna, nem is lenne sok baj vele Az Androidnal a hardveres fragmentacio joval kisebb problemat jelentene, ha kevesbe lenne eroforras pazarlo a rendszer... -
#17
Oppenheimer
veterán
Fiery
#15
A WP a CLR-jével meg annyival jobb, hogy ott alapból ment a defragmentálás. Akkor az is egy alapjaiban hibás rendszer?
A fixen leosztott heap dologról megdobsz 1 linkkel? A VM-eknek nem változik a rendelkezésre álló memóriájuk a tényleges igénytől függően?
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
#18
Fiery
veterán
Oppenheimer
#17
Fiery
veterán
válasz
Oppenheimer
#17
üzenetére
En nem mondtam, hogy a WP egy jo oprendszer
Azon remekul latszik, mennyire gyorsba' lapatoltak ossze.Heap --> [link] Diohejban csak annyit, hogy ha van mondjuk 16 MB kiosztott fix heaped, hasznalsz belole minimalis mennyiseget, es le akarsz foglalni mondjuk egy 6 MB-os tombot, akkor a legtobb esetben kapsz egy out of memory exceptiont, mert tul fragmentalt a heap a GC miatt. Agyrem, ennek nem igy kellene mukodnie, ez igy rohadt nehezen hasznalhato a gyakorlatban, ha egy kicsit is komolyabb appot keszit az ember. Persze mindenre van megoldas, meg az Android 5.0 es az ART majd segit, csak kozben meg fejlesztokent az ember nem szamithat arra, mint az almas cuccoknal, hogy 1-2 honap alatt a felhasznalok legalabb fele hipp-hopp atall a legujabb oprendszer verziora
Tok jo, hogy fejlodik az Android, de ha meg is oldodik varazsutesre egy-ket ilyen problema az ujabb verziokon, attol me'g az appodnak futnia kell sajnos a regebbi Android verziokon is, ahol me'g megvannak az ilyen hulyesegek...[ Szerkesztve ]
-
#19
Oppenheimer
veterán
Fiery
#18
Még nem foglalkoztam android fejlesztéssel, de tervezek belevágni amint lesz időm.
Egyelőre csak felhasználóként kerestem annak a okát, hogy egy 3GB RAM-mal szerelt androidos telefonon miért rosszabb a multitasking egy 1GB RAM-os iOS-nél.
GC, fragmentálódott heap az megvolt, de ezt az oldalt olvasva látom, hogy vannak itt bajok bőven ezen kívül is...Mondjuk iOS-en meg a ciklikus referencia gráfokkal szívnak a fejlesztők a reference counting miatt. Nem tudom melyik lehet rosszabb.
[ Szerkesztve ]
https://play.google.com/store/apps/details?id=com.lovemap.lovemapandroid
-
#20
Fiery
veterán
Oppenheimer
#19
Fiery
veterán
válasz
Oppenheimer
#19
üzenetére
SZVSZ az Androidnal nem igazan van rosszabb
Ha csupan a hardveres es szoftveres toredezettseget ki lehetne vonni a kepletbol, mar sokkal jobban allna az iOS-hez kepest. Szivesen molyolnek a referenciakkal, ha az lenne a legnagyobb problemam De amikor az Android app tesztelesre azt javasoljak a feketeoves fejlesztok, hogy forgasd a telefonodat landscape-portrait-landscape-stb. 25 alkalommal, es ha kibirja, akkor valoszinuleg nincs memory leak ... haaat ... DOS-os/windowsos fejlesztokent ez nehezen megszokhato terep, na 
-
#21
cipofuzo87
tag
cipofuzo87
tag
Nos, elárulom, hogy az "A" kategóriás játékokat nem Java-ban írják. Teljesen mindegy, hogy teljesít a GC Dalvik vagy az ART alatt. Az mezei android appok és az Android framework nagy részét Java-ban írták, ezért tényleg sok memóriát esznek, és tényleg problémát okoznak a GC pause-ok. DE! Ha elindítasz egy C++ban írt játékot, a többi Android app háttérbe kerül, és ha nem szorgoskodik a háttérben egy service, akkor semmilyen memóriakezeléssel kapcsolatos probléma nem jön elő. Egy 2GB RAM-os Androidon több memória jut a játéknak mint egy 1 GB-os iOS-en.
[ Szerkesztve ]
-
mikk2000
őstag
a rettenetes nyakatekert, pazarlo megoldasok, pl. Java, .NET, DirectX es tarsaik.
A java nem a microsoft terméke, a platformfüggetlenség nyilván lassulással jár.
A .Net megkönnyíti a programozást a mai felgyorsul világban, ára persze az hogy sokszor tetű lassú (lásd annó mikor a ATI .Net control panelja miatt +fél perc lett a windows indulás), de ma már jobb a helyzet, és a processzoroknak nem kell mindig 1%-on tekerniük üzemidejük 99%-ában. Tehát ez egy lehetőség, hibának nem rónám fel. Nem kötelező .Net programokat készíteni / használni egyáltalán. A KeePass egy üdítő példa, hogy a fejlesztő egyszerre két verziót készít, egyik .Net, a másik talán sima C.
DirectX. Persze visszamehetünk a DOS korszakba, de vissza is megyünk, hiszen a DX12 egy Mantle koppintás lesz, egy nagyon alacsony szintű felület, ami már nem fogja pazarolni az erőforrásokat, hiszen a programozó közvetlenül tudja majd programozni a kártyát (Mint DOS alatt. Hurrá fejlődés!). Persze hogy mondjuk 5 év múlva egy AMD kártyára megírt alacsony szintű kód hogy fog futni egy akkori architektúrájú Nvidia kártyán, hát.... és mi lesz 10 vagy 15 év múlva... Ha pedig nem lehet gyökeresen új architektúrát tervezni, akkor nem lesz fejlődés, nem vesznek új kártyát a népek... Akkor meg kitalálják a DX13-at, ami mondjuk a régi játékokhoz emulál egy DX12 ATI/Nvidia hardvert, csak az emuláció meg megint... erőforrásSosem értettem miért szidják a Windowst mindig. A leghasználhatóbb PC-s desktop oprendszer. A linux a fasorban sincs hozzá képest, abban aztán vannak olyan elmebeteg megoldások hogy az ember sírni tudna, nincs megoldva a legalapvetőbb dolog, az alkalmazások szeparált telepítése. Mindenáron mindent fordít a szerencsétlen, és ha valamelyik programnak régebbi függvénykönyvtár kell hát... És egyáltalán nem stabil. Alapvető dolgok alatt képes halálba fagyni. A GUI újraindítással történő "javítás" hányinger keltő egy operációs rendszernek nevezett valaminél. Bele kell nézni linuxos fórumtémákba, persze amit nem törölnek ki hogy védjék a marketinget. Teljesen alapvető dolgokért vért kell izzadni. Tehát nagyon jó hogy van Windows, egy biztos alap, akkor kéne szerintem szidni, ha lenne nála jobb, de jelenleg nincsen.
[ Szerkesztve ]
-
A DX12-féle alacsony szintű kód nem azt jelenti, hogy minden architektúrára külön kell írogatni mindent, mivel a DX12 inkább egy "köztes nyelv", a driver fogja lefordítani a GPU számára értelmezhetővé, így mindenhol futni fog, ahol van ilyen fordító. Kompatibilitási gond nincs (ha specifikus a kód, akkor az adott effekt egyszerűen csak nem látszik), később max sebességbeli lehet az eltérő architektúrák miatt, hogy melyiknek milyen DX12 kód fekszik.
Gondolom jó régen vagy valami nagyon elcseszett disztribet sikerült linuxként kipróbálnod, mivel nagyon el vagy tévedve. Alkalmazások telepítetőek önállóan, csak van függőségi fa, így behúz bizonyos egyéb csomagokat is, melyeket használ, pl hangfájl / kép esetén kodekre van szükség. Ez azért van így, hogy ne külön legyen már minden alkalmazásnál redundánsan 600 féle megoldás ugyanarra a problémára. Meg hát amit egyszer már jól megírtak, akkor azt minek még egyszer? Windows alatt is van ilyen, csak nem látod, bár a linuxos az jóval szebb. Ilyen "régebbi fv könyvtár kell és nemmegy" jelenséggel meg sosem találkoztam. Az, hogy stabil vagy nem stabil az a használt csomagoktól (illetve repótól) függ, esetleg disztribúciótól. Ha mindenből a legújabbat akarod használni egy unstable repo-ból, nagyobb eséllyel találsz bugot, hisz nincs még rendesen kitesztelve. Izzadni meg általában akkor kell, ha valami minimalista disztribbel próbálkozol, vagy ha nincs a disztrib repójában bent a szükséges csomag, s magadnak fordítod. Valaki azt szereti, mert széjjel testre lehet szabni. Viszont ma már vannak elég egyszerűen kezelhető, halandók számára is könnyen használható, stabil disztribek.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
Reggie0
félisten
A linux a fasorban sincs hozzá képest, abban aztán vannak olyan elmebeteg megoldások hogy az ember sírni tudna, nincs megoldva a legalapvetőbb dolog, az alkalmazások szeparált telepítése.
dpkg --instdir=<dir>
Mindenáron mindent fordít a szerencsétlen, és ha valamelyik programnak régebbi függvénykönyvtár kell hát...
Ezek szerint tul korai volt a dpkg-t felhozni neked. De ha mindent forditani kell, akkor mar forditaskor megadhatod a telepitesi konyvtarat, felteve hogy telepited es nem manualisan masolod be valahove, igy az elobbi kerdes felvetese nyilvan csak azert merulhetett fel, mert fogalmad sincs az alapokrol sem.
És egyáltalán nem stabil.
reggie@xxxxxxx:~$ uptime
08:03:33 up 434 days, 20:16, 1 user, load average: 0.24, 0.11, 0.03De persze a repules is nagyon veszelyes, foleg ha nem kikepzett pilota probalja.
Alapvető dolgok alatt képes halálba fagyni.
Minden OS ilyen. (vagy egyik sem...)
A GUI újraindítással történő "javítás" hányinger keltő egy operációs rendszernek nevezett valaminél.
Igen, mas rendszerek alatt a teljes gep ujrainditasa sokkal jobb megoldasnak tunik.
Bele kell nézni linuxos fórumtémákba, persze amit nem törölnek ki hogy védjék a marketinget.
Eppen most szolt Linus, hogy a kozpontban orjongenek a hozzaszolasodtol, most intezik a prohardver forummotorhoz a hozzaferest es mar elkezdtek felberelni a ninjakat, hogy ejjel linuxot telepitsenek meg az ebresztooradra is.
Teljesen alapvető dolgokért vért kell izzadni.
Persze, de minel nem kell, ha nem ertesz hozza?
-
Cathulhu
addikt
Aláírom, egyszerűen nevetséges, ahogy az android próbál működni. Emlékszem még a 2.1es időkben kezdtem beletanulni, de azok a rendszerszintű workaroundok, amik benne voltak, higgy a heap korlátozásokat megkerüljék, az valami vicc. Tudták ezt ők is, mert folyamat mókolták ezt a részt, az az app ami sok szenvedés útán vége kifogástalanul működött 2.x-en, darabjaira hullik 4.0 felett.
Ashy Slashy, hatchet and saw, Takes your head and skins you raw, Ashy Slashy, heaven and hell, Cuts out your tongue so you can't yell
-
haddent
addikt
A heap, az pont a dinamikus, nem automatikusan kezel memóriaterület
Leírom én is a véleményemet/tapasztalataimat:
Android 1.6 -al kezdtem ami egy ócska windows mobile (nem winphone! régi rezisztív szenny!) után egy álom volt. Utánna jött 2.0, 2.1 stb.. egy ideig maradtam (mindkét esetben csúcskészüléken..). Gyári romot el kell felejteni, hetente volt kernelcsere romcsere és így tűrhető volt az akksiidő.
Na ezután jött egy iphone4 (közel 1 évvel megjelenése után!) az akkori ios -sel (talán ios4) és jó, akkor soha többet semmi mást. Ezután egészen ios7 -ig megmaradtam. Nincs mit hozzáfűzni, teszi amit kell.
Nem tudom mi ütött belém de valami érthetetlen idióta módon "ráuntam" (de mire? arra, hogy valami működik...) és megint "tweakelgetni" akartam. Egyébként valamiért az akksi idő elég gyatra volt, bár lehet, hogy a készülék volt hibás (ip5). Jó hát úgyis Android KitKat teljesen más új jó stb, lett is egy csúcs készülék. Most a gyártó hanyagságáról és a fizikai felépítéséről (málik szét) nem beszélek, de a szoftver annyira pocsék, szar használhatatlan...
Eleinte jónak tűnt, mindig annak tűnik, de kevesebb mint fél év után (nem kell félreérteni, 2 napja telepítettem újra. Szó szerinte, flasher-rel, nem ilyen gyártói szar megoldásokkal..) nem tudok telefonálni. Elindítom a hívást és nem lehet letenni. Elmegy a képernyő és ott marad. Máskor meg a fülemmel még nyomkodom. Lassú.
Pocsék.. borzalom gány munka az android és akkor v2, másodszorra is megígérem, soha többet egy percig se. Windows phone, blackberry, iphone vagy egy nokia 3310 nem érdekel, csak ezt ne, mert azt hiszi az ember, hogy minőséget vesz ugyanolyan áron mint egy iphonet és egy látszólag használható amúgy hulladék gagyi szart kap.
Elnézést a hosszúra sikeredett offért.
[ Szerkesztve ]
-
#27
PandaMonium
őstag
cipofuzo87
#21
PandaMonium
őstag
válasz
cipofuzo87
#21
üzenetére
Lehet tévedek mivel mi a stúdióban csak Java-t használunk ha Androidról van szó (elsősorban casual játékokkal foglalkozunk, így nincs szükség komoly teljesítményre), de én úgy tudom, hogy C/C++ban még mindig nem lehet natív appot írni, csak shared library-kat amiket Java-ból JNI-n keresztül tudsz meghívni, így nem igazán értem ezt a "ha elindítasz egy C++ban írt játékot, a többi Android app a háttérbe kerül, ..." dolgot. Egyébként ha valaki ért a Java-ban való játékfejlesztéshez annak nem nagy probléma a non-deterministic GC, kis ésszel és profilozással simán megoldható a legtöbb gond. Most pedig, hogy jön az ART és lecserélik a JIT fordítást AOT fordításra így már nem lesz/lenne nagy előnye a natív alkalmazásoknak.
What I cannot create, I do not understand
-
mikk2000
őstag
Ez nem igazán a topik témája, és nem is neked regáltam
A DX12-féle alacsony szintű kód nem azt jelenti, hogy minden architektúrára külön kell írogatni mindent, mivel a DX12 inkább egy "köztes nyelv", a driver fogja lefordítani a GPU számára értelmezhetővé, így mindenhol futni fog, ahol van ilyen fordító. Kompatibilitási gond nincs (ha specifikus a kód, akkor az adott effekt egyszerűen csak nem látszik), később max sebességbeli lehet az eltérő architektúrák miatt, hogy melyiknek milyen DX12 kód fekszik.
Nem azt mondtam hogy nem fog futni más architektúrán, hanem hogy akár jóval lassabban is futhat akár. Oké, visszaolvasva a hozzászólásomat nem fogalmaztam egyértelműen hogy a sebességre célzok, mert gondoltam egyértelmű. De a DX12 (mantle) lényege pont az hogy a driver/DX nem fog belepofázni abba a kódba amit programozó készít, hiszen ha elkezdene nagymértékben játszani vele, akkor megint visszaugrunk "magasszintű" programozásra, azaz visszakapjuk a lassúságot, és amire panaszkodtak a játékfejlesztők - a nehézkes debugolhatóságot. Szóval szerintem olyan lesz a DX12 mintha kapnánk egy assemblert a magasszintű nyelv helyett.
Gondolom jó régen vagy valami nagyon elcseszett disztribet sikerült linuxként kipróbálnod, mivel nagyon el vagy tévedve.
Olyan egy-két évente ha nagyon van időm hülyeségre, kipróbálok egy-két linux disztribet. A vége mindig az hogy "úristen". Aztán felmegyek a disztrib fórumára, és hasonlókat látok, olyan problémákkal küzdenek, ami windows alatt egyszerűen nincs. De ha valami alapjaiban rossz, abból normális rendszer abból sosem lesz.
Alkalmazások telepítetőek önállóan, csak van függőségi fa, így behúz bizonyos egyéb csomagokat is, melyeket használ
Nem olvastad el amit írtam vagy nem értetted. Ha régebbi függvénykönyvtár kell az adott programhoz, akkor mit csinálsz?
Ez azért van így, hogy ne külön legyen már minden alkalmazásnál redundánsan 600 féle megoldás ugyanarra a problémára. Meg hát amit egyszer már jól megírtak, akkor azt minek még egyszer?
Mivel nem értetted mit írtam, ezt a hibás gondolatmenetet folytatod tovább. Egy függvénykönyvtár fejlesztése során olyan változások következhetnek be, ami miatt egy régebbi program nem fogja tudni használni (paraméterezés megváltozik, függvények működése megváltozik stb.) Hogy kicsit megvilágítsam neked, ez olyan mint egy program által használt dll-t (mondjuk a videólejátszásért felel, amit folyamatosan fejlesztenek) felülírnál egy jóval újabb verzióval. Nagy eséllyel a program fejreáll. Tehát nagyon is van létjogosultsága annak, hogy egy program, amit a fejlesztő megírt, az települjön pontosan azokkal a függvénykönyvtárakkal, amire a programot megírta, és letesztelte. Lehet hogy DOS korszakban számított az a pár kilobyte is, amit mondjuk "redundáns" függvények okoztak volna, de ma már a méretük elhanyagolható.
Ilyen "régebbi fv könyvtár kell és nemmegy" jelenséggel meg sosem találkoztam.
Pedig cikk is volt róla talán itt a ph!-n is, hogy a linux nagy hibája hogy régebbi programok nem mennek, például mert nem tudsz régebbi függvénykönyvtárat hozzárendelni. Windows alatt meg feltelepíted és kész. Mondjuk ez utóbbi valódi operációs rendszer, nem véletlenül jóval népszerűbb is.
Az, hogy stabil vagy nem stabil az a használt csomagoktól (illetve repótól) függ, esetleg disztribúciótól.
Ezzel most nem mondtál semmit. ha egy oprendszer, vagy csak a GUI-ja összeomlik, akkor azon nem magyarázkodni kell, csak el kell felejteni a neve után az hogy "oprendszer"
Azt az operációs rendszer dolga megoldani, hogy a felhasználó ne tehessen olyat, amitől összeomlik.Ha mindenből a legújabbat akarod használni egy unstable repo-ból, nagyobb eséllyel találsz bugot, hisz nincs még rendesen kitesztelve.
Senki sem beszélt instabil változatokról, az evidens hogy azzal szopás van. Tehát kifejezetten én tuti nem keresek olyan tárolót, amiben csakis alfa és egyéb verziók vannak, mivel az inkább a fejlesztőknek van tesztelgetni, vagy annak akinek nagyon sok ideje van szórakozni meg hibajelentést küldözgetni.
De jobban belegondolva, van ez az ubuntu nevű valami amit nagyon nyomnak kezdőknek, amire sajnos sok más disztró épül, és sajnos pont ennél van olyan gond hogy mindig mindenből a legújabbat rakják bele, szóval miről beszélünk, ha egyszer rá van kényszerítve az emberre a használata?
Izzadni meg általában akkor kell, ha valami minimalista disztribbel próbálkozol, vagy ha nincs a disztrib repójában bent a szükséges csomag, s magadnak fordítod.
Nem. Pont ez a probléma. Mondjuk fenn van egy alkalmazás ami telepíthető szabványosan az "alkalmazásközpontból" két kattintás, oké. Már le van fordítva eleve, hiszen az adott disztribhez készült (lett lefordítva).
Jó, de van benne egy olyan hiba ami miatt nekem az újabb verzió kell. Az meg nincs fenn még, és nem is lesz mondjuk egy évig, hiszen mi munka lenne minden kis build verzió miatt minden disztribhez lefordítani. Tehát magadnak kell. És ott kezdődik a szopás, vadászd le az összes csomagot ami ahhoz kell, és kínlódj órákig vagy tovább. Ha nem megfelelő az adott leírás, akkor nem is fog sikerülni. Windows alatt meg katt a telepítőre és kész van! Tehát már itt ugrott az ingyenesség "marketingje" mert nekem mondjuk megér 10-20e forintot, hogy szopás és idegeskedés nélkül tudják bármilyen programból új verziót telepíteni. Munkaórában kiszámolva is veszett pénz az, ha az ember olyannal foglalkozik, amivel nem kéne, egy normális rendszert használva./Azért jegyezzük meg hogy milyen egy elmebeteg dolog az hogy van egy alkalmazás, és 8 felé kell fordítani különböző disztribúciók miatt, ez olyan szocialista rendszerre emlékeztet engem, és persze hogy nem lehet mindenből minden naprakész emiatt. Windows alatt a programozó elkészíti a programot (telepítőt) és az futni fog minden varázslás nélkül, minden támogatott Windows rendszeren./
Viszont ma már vannak elég egyszerűen kezelhető, halandók számára is könnyen használható, stabil disztribek.
Nem lesznek sosem, és amire azt mondtam hogy talán játéknak jó, az mondjuk a Mint, ott tudják hogy a lInus alapvetően egy fos, és emiatt a problémák megoldására törekednek, és nem azok eltusolására meg a marketingre. Tehát ha az embert azt felteszi, akkor alapvető dolgok működnek.
Ez a téma nem annyira tartozik a topik témájához, de mivel "HÁZIGAZDA" díszeleg a neved alatt gondolom a neked írt válasz miatt nem fogod törölni a hozzászólást amit neked reagáltam, de nem fogok többet írni ebben a topikban ebben a témában, kivéve ha az akinek írtam eredetileg, vitatkozni kíván.
-
Reggie0
félisten
Mint ha win alatt nem lattunk volna olyat,hogy egy sw az SP1-el megy, az SP2 alatt meg lehalt. Az, hogy nem erted a koncepciot, nem azt jelenti, hogy szar a rendszer. Ha nem megy egy progi, mert regebbi lib kell neki, akkor felrakod a regebbi libet, vagy leforditod statikusan linkelve, kulon rakod chroottal a regebbi lib tarsasagaban, stb. stb.. Annyi lehetoseg van, hogy felsorolni nincs ido. Az, hogy win alatt lassan valtoznak a dll-ek, bizonyos szempontbol elony, masbol meg hatrany.
-
Ez egy fórum, bárki bárkinek válaszolhat.
De, ebből eléggé úgy tűnik: Ha pedig nem lehet gyökeresen új architektúrát tervezni, akkor nem lesz fejlődés, nem vesznek új kártyát a népek... Akkor meg kitalálják a DX13-at, ami mondjuk a régi játékokhoz emulál egy DX12 ATI/Nvidia hardvert, csak az emuláció meg megint... erőforrás
Emuláció az kompatibilitás miatt kell, és nem az oka, hanem a következménye gyengébb teljesítmény.Gyanítom azért "úristen" a vége egy kis linux-próbálgatásnak, mert nem neked találták ki vagy csak szimplán nem érted a koncepcióját az egésznek. Ha a kacsa nem tud úszni, nem a víz a hülye. Viszont abban legalább egyetértek, hogy jobb ha nem írsz ide többet, mert így is már hatalmas off-tengert sikerült generálnod.
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
De elobb-utobb sajnos eljon majd az a pont, amikor vagy atalakitjak az Androidot, vagy a felhasznalok fellazadnak...
Az a cucc legnagyobb rakfeneje.
Új hozzászólás Aktív témák
ph Az Apple új API-ja egy érkező Relative Benchmark alatt 30%-os előrelépést kínál négyszeres élsimítás mellett.
