Ahogyan már a legutóbbi keynote alatti közvetítésünkön is leírtuk, az iPhone 5s egyik nagy dobása az immár 64 bites processzor, az A7. Az Apple álláspontja (pontosabban Phil Schillernek a keynote-on elhangzott kijelentése) szerint az új CPU-nak hála, az iPhone 5s 40-szer gyorsabb az első generációs iPhone-nál, a grafikai teljesítménye pedig nem kevesebb, mint ötvenhatszoros. Ez azért – legalábbis a felhasználói élmény direkt hatásait tekintve – természetesen túlzás, amolyan „szülői elfogultság”, az azonban tény, hogy a kerek kétszeres sebességet magabiztosan hozza a csúcsmodell. Ez igaz mind az általános célú felhasználás, mind pedig a grafikus teljesítmény tekintetében.
Az Apple A7 a legelső 64 bites processzor a piacon, ami okostelefonba került. Hivatalos információ nincs igazán róla, sőt, alig lehet tudni bármi pontosabbat vele kapcsolatban. Ez az Apple általános hozzáállása – a cég nem a nyíltságáról híres, pláne akkor, ha egy úttörő fejlesztés technikai részleteinek nyilvánosságra hozataláról van szó. Valószínűleg meg kell várnunk, amíg – reméljük, az iPhone 5s hivatalos megjelenése után nem sokkal – szétszedik és elektronmikroszkóppal szemügyre veszik az eszközt.
Ami eddig kiderült, az az, hogy az egy chipre integrált (SoC) CPU, GPU és memóriaegység gyakorlatilag nem nagyobb méretű, mint az előző generációs A6, viszont támogatja az OpenGL ES 3.0-t, és rendelkezik egy különálló mozgásfeldolgozó koprocesszorral. Álljon itt mindaz, ami eddig hivatalosan elhangzott a cég részéről:
Létezik olyan, hogy „gyors”. És létezik olyan is, hogy „A7-es gyors”. Az új A7 chip akár kétszeres grafikai- és processzorteljesítményt nyújthat. És ami még meggyőzőbb, az az, hogy ez az iPhone-t a világ első és egyetlen 64 bites okostelefonjává emeli. Ez egy asztali gép minősége egy szupervékony készülékben.
Az A7 támogatja az OpenGL ES 3.0 verzióját annak érdekében, hogy olyan részletes grafikákat és künleges effektusokat kaphassunk, amelyeket eddig csak asztali gépeken és játékkonzolokon tapasztaltunk. A különbség lenyűgöző. Vegyük például a játékok képzelt világait. A textúrák és az árnyékok sokkal élethűbbnek hatnak. A napfény megcsillan a víz tükrén. Az egész élmény valóságközelibb.
Az iOS 7 és minden gyári alkalmazás optimalizálva van A7-re. A Fényképező alkalmazás ennek egy nagyszerű példája. Az A7 processzor beépített képjel-feldolgozóját használva kétszer gyorsabb az autofókusz, és a felvett videók képkockasebessége is nagyobb. Azt hihetné az ember, hogy ettől az akkumulátoridő drasztikusan csökken, de nem: az A7-et a lehető legenergiatakarékosabbra terveztük.
Az Apple legelőször az első generációs iPadhez tervezett saját processzort, ez volt az A4. Még ugyanabban az évben, 2010-ben, az iPhone 4 is megkapta ezt a chipet. A 2011-es iPad 2-ben már egy következő széria, az Apple A5 „ketyeg”. Az elődjéhez hasonlóan 45 nanométeres gyártástechnológiájú SoC erősebb grafikus processzort és újabb CPU-t tartalmazott, ez volt az ARM Cortex-A9.
A processzor következő, 2012-es kiadása az A5X nevet kapta, amely 32 nanométeres gyártástechnológiája révén energiatakarékosabb, illetve a retina kijelzős iPad 3 kedvéért egy négymagos GPU is belekerült.
Az iPhone 5-ben elhelyezett A6 tervezésekor már drasztikusabb váltások következtek. Az ARM v7s utasításkészlet licenszének megvásárlása után az Apple tervezőmérnökei egy teljesen egyedi összeállítással rukkoltak elő. A 32 nanométeres, kétmagos proci 800 és 1200 MHz közötti órajellel képes futni, és a „Swift” fantázianevet kapta. Az iPad 4 ennek az összeállításnak egy továbbfejlesztett változatát, az A6X-et tartalmazza, az újítás lényege ismét a nagyobb grafikus teljesítmény a retina kijelző meghajtásának érdekében.
Azt még nem lehet pontosan tudni, hogy az A7-es sorozatba mit pakoltak Cupertinóban, csak az biztos, hogy egy ARMv8 architektúrájú alkatrészről van szó. Az Apple konzervatív álláspontját ismerve, a memória várhatólag 1GB méretű maradt.
Az Apple állítása szerint az A7 a világ első 64 bites processzora, amelyet okostelefonban használnak. A kapacitív érintőképernyő és a retina kijelző mellett – amiktől általában hangos a média – a 64 bites chipset, mivel az nem látható és kézzelfogható, „elbújik” a nagy nyilvánosság elől. Ez viszont nem jelenti azt, hogy ne lenne ugyanolyan fontos és ugyanolyan innovatív, mint a másik két fejlesztés. A 64 bit jobbnak, professzionálisabbnak hangzik, tehát még jól is lehet reklámozni.
A 64 bitre való váltás helyzeti előnyt is nyújt az Apple számára. Már az iOS 7 dinamikus felhasználói felületét és látványelemeit is nehéz lenne utánoznia a versenytársaknak. Nemcsak számításigényes a dolog, hanem egy fragmentált platformon alig lehet hatékonyan és teljesen foganatosítani egy ilyen széleskörű változtatást.
Az A7 csak rátesz erre egy lapáttal. Ha egy versenytárs előáll egy 64 bites készülékkel, milyen hosszú időbe telik, amíg az operációs rendszer és az alkalmazások frissülnek, hogy támogassák azt? Nagyon nehéz ezt elérni, hogyha egy gyártó nem tartja kézben olyan szinten a platformját, ahogyan azt az Apple teszi az iOS-szel.
De mit is jelent valójában az „asztalirendszer-minőségű” architektúra?
A populáris média általában azt emeli ki, hogy a 64 bites rendszer a nagy fájlok kezelésére lesz jó, illetve 4 gigabájtnál több memóriát is kaphatunk ezek után. Ez azonban egy elég távolra mutató cél.
Az igazi előny nem is a kétszer annyi bit, hanem a kétszer annyi regiszter. A regiszterek a processzoron belül elhelyezett kicsi memóriaegységek, amelyek azt az adatot tárolják, amin a CPU éppen az aktuális elemi műveletet végzi. Mivel ezek magába a processzorba vannak integrálva, jobban együtt tudnak azzal működni, így a regiszterek használata sokkal gyorsabb, mintha folyamatosan a RAM-on operálna a gép. Ha kétszer annyi regiszter van, akkor kétszer annyi adatot tudunk bennük elhelyezni, így kevesebb adatot kell a memóriából vagy a memóriába átmozgatni. Márpedig az A7-ben mind általános célú (egész számokon végzett számításokra, adatok másolására, logikai műveletekre alkalmas), mind pedig lebegőpontos (azaz a főleg grafikai feladatokhoz elengedhetetlen, törtekkel való számolásra használatos) regiszterekből kétszer annyi van.
Észrevétlen átállás
Az Apple azt is állítja, hogy amíg a PC-ken a 64 bites rendszerre való átállás éveket vett igénybe, addig az iPhone esetében ők ezt képesek lesznek egyik napról a másikra kivitelezni. Ez ismét a Nagy Testvér szintű, teljes, a platform fölötti ellenőrzés előnye – az iOS 7 és a benne lévő gyári alkalmazások eredendően támogatják a 64 bitet. Ez azt jelenti, hogy a kernel (az OS alapvető komponense), a könyvtárak és a driverek már eleve így készültek. Ahogyan azt egy számítógépen megszoktuk, a rendszer természetesen továbbra is képes a 32 bites alkalmazásokat is futtatni, a fejlesztői eszközök pedig automatikusan olyan végrehajtható fájlt („fat binary”) generálnak a programozók által írt forrásból, ami mind a 32, mind a 64 bites gépi kódot tartalmazza, így régebbi készülékeken is elfut, az iPhone 5s-en viszont profitálhat a 64 bit előnyeiből.
Az egyetlen dolog, ami hátrányt jelenthet az átmenet idejére, az az, hogy noha egy 64 bites processzor tud a saját utasításkészletének megfelelő 32 bites kódot futtatni, az alkalmazások működéséhez azonban szoftveres támogatás is szükséges. Ez azt jelenti, hogy az iOS 7-nek minden szoftverkönyvtárból két példányt kell tárolnia és a memóriába tölteni, egy 32 és egy 64 bites verziót. Ez megnövekedett memóriahasználathoz vezet, ám reméljük, az 5s tervezői erre is gondoltak, és a hardver sikeresen megbirkózik ezzel a feladattal. Lehet, hogy egy ponton majd az Apple is azt mondja: „kész, leálltunk a 32 bit támogatásával”, és akkor ez a – vélhetően minimális – veszteség is eltűnik majd.
Játékfüggők előnyben
A már említett 56-szoros grafikus számítási sebességet úgy kapjuk meg, hogy az A7-ben lévő grafikus processzor is – elvileg – kétszer gyorsabb az A6X-énél. Az OpenGL ES 3.0-t szintén említettem; ami egészen pontosan új a szoftvernek e verziójában, az a továbbfejlesztett renderelési műveletsor (rendering pipeline), az újítások magában az OpenGL programozási nyelvében (shading language), és a textúrák megjelenítésének új módja.
Kamerák, mozgás és zárt biztonsági egységek
Az A7 korántsem csak a CPU és a GPU teljesítményét növelte meg, hanem számos új alegységet is tartalmaz. Az M7 mozgásinformációs koprocesszorról már írtunk is. Azt is tudjuk, hogy az iPhone 5s fotózási képességei messze felülmúlják az elődökét, ebben pedig nagy szerepe van az új ISP-nek (Image Signal Processor, képjelfeldolgozó processzor), illetve a processzorhoz közvetlenül nem tartozó, valósághűbb színeket biztosító, széles spektrumú vakunak is. A Touch ID által felhasznált, érzékeny adatok (az ujjlenyomatból készített hash) tárolására pedig egy külön erre a célra beépített biztonságos tárolóeszköz („enclave”) szolgál (lásd az erről szóló részletes cikket). Ki tudja, lehet, hogy az Apple új szlogenje „van rá egy alkalmazás” helyett az lesz, hogy „van rá egy koprocesszor”? 🙂
33 Comments
Érthető,hogy i4-en miért is lassú az iOS7.Kicsit hiányolja a rendszer a 2 magot.
Kicsit kockás lett a cikk, de tetszik.
Egyre inkább kell az a kis [s] betű az 5 mellé 😀
Elmèletben jòl hangzik de a valóságban a 64 bit ès a 32 bit ugyan az. Akárhány x64 vs x86 videót nèzel…! Marketing az egèsz… ahogy a cikk is írja. Hètköznapokban nem venni èszre…
@janoo: Naná, hogy kockás, én írtam. 😛 Ugye, hogy instant get?
@AppleFan: “a valóságban a 64 bit ès a 32 bit ugyan az” – hm. Arra gondolsz, hogy “ugyanaz”? Nos, nem, nem ugyanaz. Ajánlom a releváns Wikipédia-cikk tanulmányozását.
nekem ios 7 ota jobban szaggat. a RR3… 🙁
@H2CO3: Igen. Én gyakorlatban, hétkoznapokban értettem ! 😀
Csak hogy értsd: RAM gyorsabban kuld és fogad információt mint a HDD. Minnél tobb a RAM annál tobbet tud a rendszer ott tárolni. Ebbol kovetkezik a sebesség.
Na most akkor hány gb RAM rol is beszélunk ? 32 bit 3.25GB ot tud max kezelni, ha tobbed van akkor 64 bit.
Telefonokba mennyi ram van? A note 3 ba van 3GB, LG G2 2GB, Iphone 5S 1GB ram.
Hol jon a képbe a 64 bit és minek? Remélem igy már érted. De ha mégsem akkor nézz meg egy osszehasonlító videót az iphone 5 és Iphone 5s kozott. Ugye az iphone 5s alap alkalmazások 64 bitesek, (apple szerint) semmivel sem indulnak gyorsabban mint az iphone 5 on amin ugyebár 32 bitesek az alkalmazások. Akkor mirol is beszélunk? 😉
@AppleFan:
– “Csak hogy értsd: RAM gyorsabban kuld és fogad információt mint a HDD.” – Huh. Csak hogy értsem? Biztosíthatlak, hogy elég jól értem én ezt a dolgot. Programozóként eléggé meggondolja az ember, hogy mikor nyit meg egy háttértáron lévő fájlt, mert az arra való írkálás bizony időigényes művelet, tisztában vagyok vele.
– “Minél több a RAM, annál többet tud a rendszer ott tárolni” – igen. Ha éppen a virtuális memóriáról van szó (ha a virtuális memória lapozófájljait érted az alatt, amit a nem létező HDD-n tárolunk), akkor ez még sebességnövekedést is jelenthet.
De: ha éppen a VM nincsen használatban, akkor ilyen közvetlen összefüggés a RAM mennyisége és a sebesség között nincs. Egyébként az érvelésed a kezelhető RAM méretével kapcsolatban azért is irreleváns, mert egyik iOS-eszközben sincsen jelenleg 1 GB-nál nagyobb memória, feltehetőleg az iPhone 5s-ben sem. Teljesen kizárt, hogy az iPhone 5s-ben 4 GB-ná több (nem 3,25, ezt nem tudom, honnan veszed – nálam kettő a harminckettediken az még mindig 4 294 967 296) legyen belőle. Akkor pedig hiába tudna a 64 bit miatt többet kezelni, ha egyszerűen nincs benne annyi. Ebben az esetben hogy magyarázod a sebességnövekedést?
Ha pedig te is pont erről próbálsz engem meggyőzni (csak elég összevissza megfogalmazva), akkor nyitott kapukat döngetsz; vagy nem olvastad el a cikket rendesen, vagy nem értetted meg. Senki sem állítja, hogy magától a 64 bites architecktúrától lesz varázsütésre gyorsabb a készülék. A “dupla szóhossz, dupla sebesség” csak egy szlogen. Hadd idézzek a cikkből:
Érthető mostmár?
Èrthetö eddig is az volt a kètszer annyi regiszter. Hurrà. Csakhogy ez a gyakorlatban semmit sem èr. Honnan jön a 3,25gb ? Hàt pl onnan hogy a 32 bites rendszer annyit tud maximum kezelni. Pont azt mondom hogy az iphone 5/s ben sincs 3gb nàl több ram. Programozó lehetsz, de attól mèg szöveget is tudhatnàl èrtelmezni… 😉 Az elsö rèsze a hozzàszolàsnak àltalànosan a 64 v 32 bit re szolt. A màsodik rèsze a telefonokra. Mindegy, nem vitatkozni akartam (kàr is egy programozóval) 😀 . Vegyètek vigyètek… 😀
@AppleFan: Na, arra már igazán kíváncsi vagyok, hogy miért nem ér semmit a kétszer annyi regiszter. Ezt hajlandó vagy kifejteni? Szépen el van magyarázva a cikkben, hogy miért jó a kétszer annyi regiszter. Ha ez alapján nem érted, akkor inkább ne firtassuk, hogy ki nem tud szöveget értelmezni. Továbbá a 32 bites rendszer még mindig 4 GB-ot tud kezelni: amint azt már leírtam,
2 ^ 32 = 4 294 967 296, azaz 4 * 1024 * 1024 * 1024, ami 4 GB. Nem 3,25. De ez már tulajdonképp mindegy is.@AppleFan: Te most trollkodsz, ugye?
Nem trollkodok. Mièrt irnak mindenhol 3,25 gb ot akkor?
http://youtu.be/SfCcvlLEwZo
Mièrt nem èr semmit:
http://youtu.be/OjNtbOGTrsE
Boot gyorsabb ok, alkalmazàsok semmi…
Ez az èn vèlemènyem. Kèsz. 😉
@AppleFan: a 3,25 GB az valószínűleg az a memória lesz, ami az OS által elfoglalt hely után még szabadon marad, kvázi egy “nettó” mennyiség.
A “miért nem ér semmit” videóra: egy teszt nem teszt, majd hosszabb távon meglátszik, azon kívül a regiszterek nagyobb sebessége a RAM-hoz képest ugyanolyan tény, mint az, hogy a fájl I/O lassabb a memóriaelérésnél. További szép napot.
Lol ok szèp napot. 😉 a valaszodon jot rohogtem ! 😀
@AppleFan: Melyik válaszomon?
Jól írtad …nem azon… 😉
Azon rohogtem hogy milyen higadtan válszolsz… 😀
Nagy csávó vagy az fix 😉
Koszonom a beszélgetést. Szép napot ! 🙂
@AppleFan: A 4 GB az 4 GB. Windows-ban azért látsz 4 GB helyet 3,valamennyit, mert a rendszer minden memóriát egyben kezel. A 4GB az összes RAM-ra vonatkozik. Vagyis pl ha van egy 512-es VGA-d, akkor amellett csak 3,5 GB RAM-ot tud kezelni, 1 GB-s VGA mellett csak 3 GB RAM-ot lát, és így tovább. Ha mondjuk dupla vgas laptopod van, akkor az integrált kártya is elvesz ebből a RAM-ból.
@skandigraun: Ez igy van igen kozben rájottem 😉 De már írtam is csak még nem jelent meg 😉
És ebbe persze nem csak a VGA meg a sima RAM számít bele, hanem az összes eszköz, aminek byte-onként közvetlenül címezhető memóriája van.
Szerintem az átlag felhasználó ( mondjuk én ) ebből annyit érez az 5 után az 5s egy kicsit gyorsabb. Ezt csak a látott videó alapján mondom, de 4s- 5 váltásnál sem érzetem duplának a sebességet. Azért jónak tűnik az új cuccos
Tisztel okosok.:)
Én értem én ezt hogy mivel gyorsabb.;) de jelenleg nem gyorsabb, mert a prg át kell faragni.;) viszont lépés előny, mert droidok ezt nem leptek meg. Nekem előny mert iPhone 6 nal remelem már kiforrott lesz a rendszer.;) ha figyeljetek i5 nél sokkal gyorsabban tolt be a rendszer.
Cikkírónak: “Már az iOS 7 dinamikus felhasználói felületét és látványelemeit is nehéz lenne utánoznia a versenytársaknak.” Jéééézusom….. láttál már Androidot Galaxy S3-n vagy S4-en? Tény, hogy az iOS kezdi utolérni az Androidot, másol az Apple rendesen, de ekkora hülyeséget írni egy ilyen cikkben elég ciki, mivel nemcsak Apple fanok olvassák… Ehh.
@Bencissimo: Először is, ugyebár ez a cikk legnagyobb részben fordítás, a linkelt 9t5mac-cikk alapján készült, az általad idézett mondat nem az én saját ötletem. Egyet lehet vele érteni, lehet vele vitatkozni is természetesen, ezen nem szeretnék senkivel összeveszni. Arról, hogy ez “ciki” lenne: hm, nem.
Más: mindenki másol mindenkit, a Samsung pl. rendszeresen másolja az Apple apróbb és nagyobb újításait.
Azt is meg kell hagyni, hogy noha az iOS 7 részben hasonlít az újabb Androidok grafikájára, azt nem lehet mondani, hogy egy az egyben ugyanaz lenne, sőt. Nyilván van egy alapkoncepció: “flat” dizájn, vékony betűk, erősebb kontrasztok, stb., viszont ezzel az erővel az érintőképernyő, sőt, a Touch ID is koppintás – mind a kettő létezett az iPhone előtt.
Nem kell félni a megnövekedett memóriahasználattól csak azért mert a FAT bináris tartalmazza a 32 és 64 bites kódot. A kernel csak azt a MACHO bináris részt tölti be, ami az adott platformnak szükséges (http://www.opensource.apple.com/source/xnu/xnu-2050.24.15/bsd/kern/kern_exec.c).
Árpád dolga nehéz ha nép hülye…
@rastawicc: Árpád vagyok èn is…ès tènyleg nehèz a dolgom ha a nèp hülye 😉 ★☆★☆★☆★
@H2CO3: Abban a kétszer annyi regiszterben konkrétan négyszer annyi adatot tudsz elhelyezni, mivel a regiszterek “szélessége” is duplázódott (64 vs. 32 bit illetve 128 vs. 64 bit FP). Engem inkább az aggaszt, hogy az Apple nem duplázta meg a memóriát, pedig ha egy app eddig 32 bitesre lefordítva 4 byteot használt egy integerre, az 64 bitesre lefordítva 8-at fog. Vagyis másképp szólva az iPhone 5S-ben feleannyi memória van, mint az 5-ösben (128 GW vs. 256 GW) A 32 bit-only alkalmazások előbb-utóbb kihalnak, tehát a régi libraryk betöltögetése nem fog plusz memóriát igényelni (flash helyet még persze igen), de az új appok nagyobb memóriaéhsége ettől még megmarad. Szóval aki 5s vásárlásában gondolkodik, annak számítania kell arra, hogy egy-egy régebb óta használt alkalmazás 64 bitesre való frissülés után már nem fog elindulni, vagy futás közben kilépeget (crashel), jobb esetben csak a minősége romlik (belassul, csúnyább lesz). Természetesen a fejlesztőknek az az érdeke, hogy minél több platformon fusson az általuk készített app, azonban bakik becsúszhatnak, ezért nem lenne rossz, ha az Apple engedélyezné a 64-32 bites binaryk közötti váltást az appok elindításánál, és nem automatikusan a 64-eset töltené be, ha az rendelkezésre áll. Persze nem fogja soha.
@rgbx: Bocsi, lehet részben hülyeséget írtam, hiszen az integerek automatikusan nem méreteződnek át 64 bitesre, csak ha ezt akarod fordításkor.
@rgbx: Ja, mondjuk általában az Apple-ös API-k NS(U)Integer-t használnak, ami “long”, tehát tényleg kétszer olyan hosszú 64 bitre fordítva, ebben igazad van; viszont nem minden egészt deklarálnak így. A memóriaméret meg nem növelése az tényleg nem jó, viszont – gondolom – megvan az oka (nemrég olvastam egy cikket, amiben elég jól le volt írva, hogy nehéz ám egyre nagyobb RAM-ot pakolni egy SoC felépítésű prociba, lehet, hogy egyszerűen nem tudják megoldani).
Az is igaz, hogy nem főleg ezek foglalják a legtöbb helyet. Egy RGBA TrueColor jellegű API (CoreGraphics, CoreAnimation, CoreImage, stb.) ugyanúgy 32 bites egységekben kezeli a pixeleket, úgy, mint 4 “unsigned char”. Tehát az *szerintem* kicsit túlzás, hogy “feleannyi memória van az 5s-ben”, nem gondolom, hogy pont emiatt belassulnának vagy egyenesen összeomlanának az alkalmazások.
@tHeShAdOw: Érdekes, őszintén szólva erre nem gondoltam, köszönöm! 🙂 Ellenben: ez nem inkább a ténylegesen végrehajtható fájlok indítására (
execve()és társai) vonatkozik? Vagy ugyanezek a függvények végzik a dynamic loading-ot is? (Csak azért kérdezem, mert mintha külön lenne a linkernek is forrása valahol a kernelben.)Kicsit továbbgondolva: nyilván a 32 bites binary-hez csak a 32 bites, 64 biteshez pedig csak a 64 bites libek töltődnek be, de mi van akkor, hogyha egyszerre fut egy-egy 32 és egy 64 bites processz, amelyek ugyanazt a könyvtárat használják? Akkor egyszerre jelen kell lennie mind a két verziónak, nem?
@H2CO3: Igen, ez a kód hajtódik végre futtatható állományok betöltésénél és library-k betöltésénél is (az XNU lényegében a kernel része, a dyld is ezt hivogatja, amikor a library-ket tölti be).
Az iPhone esetében nem hinnénm, hogy vegyes környezetről kellene beszélnünk, hiszen minden 64 bites lesz, az új iOS SDK is nyilván univerzális binárist fog gyártani (32 és 64 bites image-ekkel), ha iOS 6 és 7 kompatibilis kódot akarunk fordítani.
Desktop környezetben nem gondoltam még végig. Én 64 bites process-be 64 bites image-et, 32 bites process-be 32 bites image-et töltenék és nem keverném a kettőt.
@tHeShAdOw: Én igazából arra az esetre gondoltam, amire az eredeti cikk szerzője is: mi van akkor, amikor egy régi app 32 bites “kompatibilitási módban” fut, használ egy library-t (pl. UIKit), és mellette fut egy új, 64 bites processz is, ami ugyanazt a libet használja? Ekkor nyilvánvalóan be kell tölteni mind a két architektúrához tartozó fájlt, nem? Hiszen a 32 bites binárisnak a 32 bites library image kell, a 64 bitesnek meg a 64 bites. Ha egy időben mind a kettőre szükség van, akkor az (hozzávetőleg) kétszer annyi RAM-ot igényel.
@H2CO3: Windowsban úgy van, hogy a 32 bites appok 32 bites dll-eket használhatnak, a 64 bitesek meg 64 biteseket. Ergo, ha valami használja őket, akkor felmappeli a memóriába egy példányban a megfelelőt. Ha mind a kettőre szükség van, akkor mind a kettő memóriaterületet fog foglalni. Szerintem nem lehet ez másképp az iOS-es dylib-ekkel sem (vagy hogy a manóba hívják őket). De az is lehet, hogy valami ügyes trükkel meg van oldva.