Keresés

Új hozzászólás Aktív témák

  • julius666

    addikt

    válasz Abu85 #37 üzenetére

    Amúgy is, ha normálisan írta a fejlesztő a progit (nem hazsnált a kódban specifikusan egy utasításkészlethez illő részeket), akkor nem nagy kunszt átfordítani ARM-ra.

    Öhm...
    Egészen addig ez működik, amíg a teljes kódbázis az adott cég égisze alatt készült és "tankönyvi mintapélda" jellegű a különböző varázslások nélkül.
    Amint hardver-specifikus dolgok jönnek elő (itt még csak inline assemblyre sem kell gondolni, pedig annyira az sem ritka, területe válogatja, sebességproblémás helyeken bizony szükség lehet rá) akkor mint írtad te is ez borul, illetve 3rd party bináris libraryk esetén is, ha nem jön ki normális ARM verzió a libraryből ugrott annak a portja is ami ráépült, vagy meg kell írni egy saját verziót a cégnek ugyanazzal a funkcionalitással. Ezek baromira nem ritka dolgok pedig.

    Teszteléssel együtt pár hét, és egy pár megás patch az egész.

    Ez sem igaz, a teljes bináris állományt újra kell fordítani és két különbözőt (egy x86-osat illetve egy ARM-osat, feltéve hogy csak 32-bites verzió lesz, egy oprendszerre) postázni az userek felé. Ez nem csak egy "kiegészítés" a programhoz.

    Ezek a dolgok messze nem ilyen egyszerűek mint leírjátok, ARM-os Win8-on biztos vagyok benne sokáig jókora szopás lesz annak aki a jelenlegi Win7-es programjaira számít ott is. Persze aki mint tabletnek veszi a HTML alapú fingós appokkal az lehet elégedett, azok hamar lesznek rá, adott esetben butított Word is.

  • julius666

    addikt

    válasz Abu85 #39 üzenetére

    A libraryk valóban komoly gondot jelentenek, ezen majd segédkezni kell az ARM-os gyártóknak.

    És ezen mit tud segíteni a gyártó?

    Az lehet, hogy a mostani alkalmazásoknál ez nagy probléma lehet, de a jövőben úgy kell majd hozzáállni a programkódhoz, hogy azt fordítod x86-ra, ARMv7-re, és AMD64-re. Vagy legalábbis ezek közül legalább kettőre.

    Ez így jól hangzik, azonban nagyon sok - az említett sebességspecifikus esetben - a hardver-közeli gányolásra egyszerűen szükség van. Itt meg kell írni minden platformra ezeket (a necces részeket legalábbis), nincs menekvés. Láthatóan szeretik az ilyeneket a cégek, pont ezért lett minden hamar 64 bitre is (nem). A 3rd party .dll-ek problémájától még a .NET-ben megírt alkalmazások sem 100%-ig mentesek teljesen. Ha az adott, nem managed kódban írt librarynek már nincs supportja, vagy az b*szik kiadni az ARM-os változatot, akkor ugyanúgy szopás van.

    Persze a legnagyobbak, az adobe, ms, stb. megoldják, a baj a kisebb alkalmazásokkal lesz. Ezeknek nagyon sokáig csak bottal lehet majd ütni a nyomát ARM környezetben. Igazából egyszerű a válasz a velük kapcsolatos kérdésekre: nem lesznek ARM-on elérhetőek ugyanúgy mint most sem azok 64 biten, csak míg a 64 bites rendszerek visszafelé kompatibilisek így ez nem halálos, az ARM az x86-al nyilván nem lesz az. Inkább alternatívák jelenhetnek meg idővel de ha melóhoz kéne valami illetve az egész móka legelején ez nagy vigasz lesz.

    Szóval mindenki úgy várja a Win8-as ARM-os gépeket mint a megváltót, de kb. annyit fognak érni mint az egyéb androidos/iOS-es vackok. Böngészni, mobil médialejátszónak elmegy, de ennyi. Lesz itt pofáraesés bőven, amikor a könyvelőprogi nem fog menni a tableten vagy a speckó alacsony fogyasztású netbookon, "de miért, ha egyszer Windowsos?" jajgatások illetve a programozók családfájának sűrű szidása közepette, mert ugye "lusták megtanulni ARM-ra programozni" (LOL). Már most látom.

    [ Szerkesztve ]

  • julius666

    addikt

    válasz Abu85 #42 üzenetére

    Ezért szerintem ők mindent meg fognak tenni, hogy akár a librarykből legyen normális ARM verzió.

    Persze hogy érdekük, de nem tudnak mit tenni. A játékipar esetén amihez van több száz/ezer? a szakterületen jártas programozójuk, meg alapos tapasztalataik a partnerségi porgamok terén, meg tudják tenni hogy sok mindent betesznek a játékfejlesztők segge alá csak hogy az ő hardverükre fejlesszenek elsősorban. De ez EGY speciális terület. Ha innen továbblépünk és az általános jellegű számításokra kitalált processzorokat nézzük, akkor van kismillió egyéb terület ahová egy nVidianak vagy bármilyen más gyártónak sem erőforrása, sem lehetősége, pláne nem célja ezt megtenni, mert fingja sincs hozzá ráadásul nem is érné meg neki. Nem is értem mire gondolsz, egy tökömtudja költségvetési program xy speckó ősöreg libraryjét amit jóformán már azt sem tudják honnan van az nVidia nem fogja megírni nekem, körberöhögnének még az ötletre is. Az nVidia max kényelmes toolokat fog nekem biztosítani ahhoz hogy ilyeneket megírhassak magamnak. Ez ettől függetlenül továbbra is pénzbe fog nekem kerülni, adott esetben nem is kevésbe amit ha nem muszáj én bizony nem fogok megcsinálni. Már pedig nem lesz muszáj sokáig.

    Itt a szoftverek "long tail"-jéről beszélünk amik speciális igényt elégítenek ki ezért alkalmazásonként viszonylag alacsony számú user használja őket, azonban miután rengeteg ilyen van az össz súlyuk mégiscsak hatalmas, nem beszélve arról hogy ezek a speckó, melóhoz szükséges alkalmazások jellemzően.

    Tudom, hogy programozói szemszögből a heterogén módos programozható lapkák mostohán vannak kezelve.

    Szó sem volt heterogén programozásról, megint kevered a szezont a fazonnal. Itt csak az ARM és az x86 inkompatibilitásáról volt szó, aminek a problémáját ti messze elbagatellizáljátok "majd lesz rá" címszó alatt. Igen, majd lesz rá, de nagyon sok minden (ami közül rengeteg dolog sokaknak életbevágóan fontos) csak akkor amikor az ARM lesz már tényleg az elsődleges platform (az említett régi szoftverek inkompatibilitása pont ezt fogja gátolni így ez egyfajta ördögi kör) és ezért muszáj lesz rá megírni, vagy ha olyan erősek lesznek ezek hogy röhögve elvisznek esetleg egy emulátort a hátukon. Egyik sem holnap lesz, inkább évtizedes távlatokról beszélünk a "kezdetekben kérdéses lesz"-el szemben.

Új hozzászólás Aktív témák