Apple se poslavlja od 32 bitov

fora je, ker sam procesorski del (brez cachov) predstavlja zelo mizern delež celotnega die placa. Če bi odstranl backwards kompatabilnost, bi mogoče profitiral 1mm2 die placa. To pri 100mm2+ ni nič in naredi več škode kot koristi.

Če se že gremo odstranjevanje legacy ukazov, potem je brezveze da sploh to počnejo na x86, ker stvar zgubi svoj pomen.
Potem je bolje, da štartajo z novim naborom ukazov (like arm64) in nardijo ven highperformance jedro (kot to recimo počne apple).

če ms-u to uspe, se lahko pojavijo drugi igralci z highperformance jedri, kar intlu sigurno nebi blo všeč.

noraguta je 11. jun 2017 ob 19:44 izjavil:

Hkrati pa upoštevaj, da se 32-bitne aplikacije v 64-bitnem OS izvajajo nekoliko drugače, saj mora operacijski sistem izvajati preslikavo med 32-bitnimi in 64-bitnimi podatkovnimi strukturami pri sistemskih klicih, shranjevati kontekst na drugačen (in bolj potrošen) način in zapravljati več ciklov za preklapljanje CPU med 32-bitnim "legacy mode" in 64-bitnim "long mode" načinom delovanja.

Zgleda da raçunala nisi videl od blizu tam od spektruma naprej.

Pogumna izjava ...

noraguta je 11. jun 2017 ob 19:44 izjavil:

Vsak proces , nit ali pa preklop med user in kernel spaceom zahteva context switch.

Ja in? Mimogrede, kadar se lahko, se izogibam preobloženem izrazu "context switch", ker je lahko govora o celi vrsti različnih stvari. Recimo tri različni primeri, ki si jih naštel, se bistveno razlikujejo glede na to koliko operacij in časa bo za njih porabljeno, zato jih je težko medsebojno primerjati.

Mimogrede, pozabil si na prekinitve in pasti, če ostanem pri x86 arhitekturi, pa tudi to, da v npr. nesegmentiranem, "flat" modelu preklop konteksta SS npr. pri prehodu iz CPL=2 v CPL=0 ni potreben.

noraguta je 11. jun 2017 ob 19:44 izjavil:

Legacy x86 koda v 32 bitih ni v niçemer podoben real modu na 16bitih.

In kje v citatu piše, da je?

noraguta je 11. jun 2017 ob 19:44 izjavil:

Tisto $e mmu ni imelo. Pa raçunovodstvo naslavlanja je bila svoja reç. V praksi je 90 % programja pravzaprav hitrej$a v 32 bitnem naaçinu kot x64 çe govorimo o intlu.

Nope. Dejansko danes že velja obratno. 90% aplikacij je že zgolj na račun tega, da so prevedene za 64-bitov pri izvajanju na 64-bitnem OS-u preprosto hitrejših. Koliko so hitrejše je odvisno od narave aplikacije, ampak najbolj profitirajo tiste, ki imajo največ preračunavanja. Na drugi strani pa najbolj nasede in se upočasni programje, kjer so se programerji odločili, da je bolje imeti polje kazalcev na "int", kot pa kazalec na polje "int"-ov - pač stvari, ki raje prekladajo kazalce na podatke, kot pa podatke same. Zaradi velikosti kazalcev v svojih lastnih strukturah porabijo več pomnilnika z vsemi slabimi posledicami tega, da premetavajo 2x več podatkov, kot bi jih sicer.

x86 in ARM sta si tukaj precej podobna.

Kot ena možnih rešitev ima Linux svoj x32 ABI (ILP32). Aplikacija je 64-bitna, vendar pa sama sebe omejuje na 32-bitne naslove s čemer izkoristi dobrobiti obeh svetov, z minimalno negativnih posledic. Zakaj ima Linux za to poseben ABI? Zato, da omogoči tudi 32-bitne sistemske klice. To sicer obremeni jedro, vendar pa razbremeni razvijalce uporabniške programske opreme.

noraguta je 11. jun 2017 ob 19:44 izjavil:

Mogoçe bolje optimizira$ kot kompajler ampak taki ste redki.

Dejansko prevajalnik opravi vse potrebno delo, predvsem pa izkoristi vse dodatne registre, ki jih ima na voljo pri x86-64/AArch64, nima pa jih na voljo pri ia32/AArch32. Če še nisi slišal, registri so hitrejši, kot pa delo s pomnilnikom, pa tudi če se potujejo samo do L1 in nazaj in več registrov pomeni manj potrošenih ciklov.

Sam se takšne optimizacije ne bi lotil niti v sanjah in tudi poznam ne nikogar, ki se bi loteval česa takšnega iz tako neumnih razlogov. Kdor si misli, da imajo 64-bitne optimizacije karkoli za opraviti z ročnim delom namesto prevajalnika, si misli narobe, ali pa mu je ime Chris Lattner.

noraguta je 11. jun 2017 ob 19:44 izjavil:

In ooeracijski sistem ne izvaja nobenih preslikav med naslovnimi prostori je vse v abiju od procesorja.

Daj še enkrat preberi, kaj si citiral in poskusi ponovno komentirati.

Najraje ti bi rekel, da nimaš pojma in prenehal zapravljati čas s tvojimi enovrstičnimi spakedranščinami. Bistven problem je, da lahko vsak trol tvojega tipa trdi karkoli hoče, ne glede na to, kaj je res, kaj je mlatenje slamnatih možicljev in kaj je samo globoko neznanje in nepoznavanje tematike. Edini način, da se takšno trolanje zatre, pa je, žal, obširen in natančno obrazložen odgovor, ki terja mnogo več časa in dela, kot pa tvoja mentalna driska.

Pa naj tokrat bo, ker je tema zanimiva in se bo morda še kdo kaj naučil o tem, kaj se dejansko dogaja "pod havbo". Za takšne je vredno napisati kaj več. Za tvoje kalibre, pa pač ne.

"... saj mora operacijski sistem izvajati preslikavo med 32-bitnimi in 64-bitnimi podatkovnimi strukturami ..."

Linux:
x86-64 platforma vsebuje "common", 32-bitne in 64-bitne syscall vmesnike. Konkretno se jih lahko za trenutno verzijo jedra (4.11.4) pogleda tukaj. "Common" so tisti sistemski klici, ki se med 64-bitno in 32-bitno platformo ne razlikujejo ali pa se razlikujejo zgolj v bitnosti argumetov. Tam pa, kjer to ne velja, pa obstaja 64-bitna verzija in k njej še dodatno 32-bitna verzija sistemskega klica. Pri tem bo 32-bitna verzija opravila potrebno konverzijo, preden se bo interno poklicalo 64-bitno verzijo.

Primer "common" sistemskega klica, ki vključuje zgolj pretvorbo operandov je npr. "lseek". 64-bitna verzija je definirana tukaj, 32-bitna verzija pa tukaj. Če se primerja argumente, lahko bralec ugotovi, da se klica razlikujeta zgolj v tipu argumenta "offset", in sicer 64-bitna verzija uporablja 64-bitni odmik (off_t), 32-bitna verzija pa 32-bitni odmik (compat_off_t).

Primer malo bolj kompleksne preslikave podatkovne strukture pa je npr. "readv". 64-bitna verzija klica je tukaj, 32-bitna verzija pa tukaj. Kdor bo sledil kodi za oba sistemska klica, bo lahko hitro ugotovil, da se razlikujeta zgolj v tem, da 64-bitna verzija kliče neposredno VFS funkcijo, dočim mora 32-bitna verzija naprej pretvoriti 32-bitne kazalce v strukturi, ki jo je pripravila uporabniška koda, v 64-bitne kazalce in odmike, ki jih uporablja jedro, oziroma, v tem primeru, VFS (gl. struct iovec vs. struct compat_iovec).

Windows:
Aplikacije v Oknih tipično uporabljajo Win32 ali pa Win64 API, tudi če je govora o novodobnih .NET, WPF, UWP in stalih jajcih, je pod njimi še vedno Win32 in/ali Win64 API. Vendar pa, ker 64-bitna Okna pomenijo 64-bitno jedro, to pa uporablja 64-bitne sistemske klice, je znova potrebna preslikava. Microsoft se je tukaj odločil za drugačen pristop in je zagotovil WoW64 podsistem, ki implementira večino ustreznih Win32 API-jev v uporabniškem naslovnem prostoru, nato pa sproži 64-bitni sistemski klic.

Konkretnih povezav na izvorno kodo seveda nimam. Je pa zadeva sledljiva v navideznem okolju z razhroščevalnikom, kjer je lepo videti prednaložitev WoW64 knjižnic (wow64.dll, wow64cpu.dll, wow64win.dll), popravljanje podatkovnih struktur in nato tudi sistemski klic v 64-bitno jedro. Bistvena implementacijska razlika je tako v tem, da se del procesiranja opravi v CPL=3, del pa v CPL=0, kjer je to potrebno zaradi ohranjanja hitrosti. V vsakem primeru pa to pomeni dodatno delo, ki ga 64-bitne aplikacije ne rabijo trpeti.

... shranjevati kontekst na drugačen (in bolj potrošen) način ...

Verjetno bo najlažje, če za primer podam primerjavo kako izgleda obnova vrednosti FPU registrov za x86 platformo. Namig: poglej kaj nadzoruje spremenljivka "ia32_fxstate" in razmisli zakaj in kako.

... zapravljati več ciklov za preklapljanje CPU med 32-bitnim "legacy mode" in 64-bitnim "long mode" načinom delovanja.

Tukaj bo žal potrebno malo več mahanja z rokami, ker to niso podatki, ki bi jih AMD in Intel javno objavljala. Najlažje mi bo šlo z uporabo perf in Linux ...

Najprej potrebujem enostaven program, ki bo večino časa izvajal sistemske klice in nič drugega. Pri temu moram izbrati tudi takšen sistemski klic, ki bo imel čim manj režije.

#include <unistd.h>

#define REPEATS 100000000

int main() {
        int i;

        for (i = 0; i < REPEATS; i++) {
                getpid();
        }

        return 0;
}

Funkcija "getpid" je pripravna, ker ne sprejema nikakršnih argumentov, vrača pa 32-bitno vrednost in to tako v 32-bitnem, kot tudi v 64-bitnem Linux ABI. Pri tem, pa ima naslednje lastnosti:
- Celoten klic znotraj jedra je lock-free, kar pomeni, da ne bo umetno vstavljenih barier.
- Hkrati pa koda kliče funkcije in dostopa do struktur v poljih, kar bi moralo pokazati efekte spremembe preslikave CS in DS registrov (potencialno tudi GS, FS), ko se TLB izprazni.

Če naj drži, da obstaja skrit strošek prehoda iz 32-bitnega načina v 64-bitnega in nazaj, bi morala biti 64-bitna koda bi morala biti merljivo hitrejša. Pri tem pa se bi moralo dati izločiti vpliv same kode, ki deluje v 32-bitnem oziroma 64-bitnem načinu.

Kodo sem prevedel z:

gcc -m32 -static test.c -o test32
gcc -m64 -static test.c -o test64

Koda je prevedena statično zato, da se izloči vpliv dinamičnih knjižnic in vsiljene preslikave VDSO, ki prestreže klic getpid() iz uporabniške kode.

Izvleček prevedene strojne kode za 32 bitov izgleda tako:

; main
  mov    $0x5f5e100,%ebx
  lea    0x0(%esi,%eiz,1),%esi  ; poravnava
loop:
  call   __getpid
  sub    $0x1,%ebx
  jne    loop

; __getpid
  mov    $0x14,%eax  ; syscall 0x14(20d)
  call   __kernel_vsyscall
  ret

; __kernel_vsyscall
  push   %ecx
  push   %edx
  push   %ebp
  mov    %esp,%ebp
  sysenter

Izvleček prevedene strojne kode za 64 bitov izgleda tako:

; main
  mov    $0x5f5e100,%ebx
  nopw   %cs:0x0(%rax,%rax,1)  ; poravnava
loop:
  callq  43e760 __getpid
  sub    $0x1,%ebx
  jne    loop

; __getpid
  mov    $0x27,%eax  ; syscall 0x27(39d)
  syscall

Razlika v številu operacij je vidna, ni pa zgolj iz tega jasno kakšen bo dejanski vpliv na čas izvajanja oz. število ciklov. Bi pa to moralo biti razvidno iz merjenih vrednosti.

Testiranje z perf je enostavno:

perf stat -e 'instructions,cpu-cycles,ref-cycles,cs' ./test32
perf stat -e 'instructions,cpu-cycles,ref-cycles,cs' ./test64

Na svojem testnem računalniku sem fiksiral frekvenco jeder, da sem izločil ta vpliv na dejansko porabljen čas.

Primer rezultata za 32-bitno kodo:

 Performance counter stats for './test32':

    16,819,203,298      instructions              #    0.97  insn per cycle
    17,341,923,314      cpu-cycles
    13,830,223,626      ref-cycles
                 3      cs

       4.478471216 seconds time elapsed

Primer rezultata za 64-bitno kodo:

 Performance counter stats for './test64':

     8,515,126,835      instructions              #    0.62  insn per cycle
    13,716,035,010      cpu-cycles
    11,037,496,742      ref-cycles
                 3      cs

       3.574182768 seconds time elapsed

Tako, kot sem sumil, je lepo vidno, da izvede 32-bitna koda mnogo več operacij (cca. 2x toliko kot 64-bitna), vendar pa izgleda, da večina teh operacij vzame zgolj en cikel. V povprečju 0,97 operacije na cikel, oz. 1,03 CPI za konkreten primer.

64-bitna koda pa po drugi strani deluje z bistveno manjših 1,61 CPI. Kljub temu pa je skupno porabljen čas za te operacije krajši, kot pa za 32-bitno kodo.

Potem, ko sem izločil večino spremenljivk, ki jih je možno enostavno izločiti^(*), to pa so preslikave struktur (kopiranje pomnilnika) pri netrivialnih klicih, uporaba barier, morebitna razlika med 32-bitnim in 64-bitnim naslavljanjem v uporabniški kodi (testna koda uporablja izključno registre), mi ostane samo še strošek dela procesorja pri preklapljanju med CPL 3 in 0 (ter nazaj). Ker naj bi bil strošek domnevno enak, rezultati pa kažejo opazno razliko, si upam trditi, da bodisi sam skok porabi bistveno več časa za prehod med L=1 in L=0 ali pa se po preskoku izgubi toliko TLB-ja, da je nekaj naslednjih dostopov do pomnilnika v jedru zaradi tega penaliziranih. Eno ali drugo pa pomeni, da je strošek za 32-bitno aplikacijo v 64-bitnem sistemu netrivialen. YMMV.

Anyways ... to je nekako to. Če sem se pa kje zmotil, me bo pa že kdo popravil s kakšno konkretno povezavo ali koščkom kode. Priznam, da se s tem nisem ukvarjal že kar nekaj časa. Ne pa ravno od Z80 naprej. In pa ... doma sem začel z 6502C (Atari XE130).

(*) Linux ni RTOS in, kar pomeni, da na se lahko na jedru, kjer deluje aplikacija, dogajajo tudi prekinitve ali poljubno drugo delo. Števec "cs" mi pove koliko takšnih preklopov konteksta se je dejansko zgodilo. Če bi imel mnogo več časa in volje bi lahko izločil tudi to spremenljivko tako, da bi napisal namensko aplikacijo, ki bi se zagnala neposredno iz EFI-ja. Prostodušno pa bom priznal, da se mi zdi razlika dovolj velika in tudi konsistentna med več ponovitvami, da si upam trditi, da tudi bolj kontroliran test ne bi prinesel bistveno drugačnega rezultata. Komur se pa da, pa lahko prevede test z dovolj nizko vrednostjo za REPEATS, da se bo aplikacija na danem sistemu (pač odvisno od zasedenosti sistema, hitrosti procesorja, števila jeder, ...) konsistentno izvedla brez preklopa konteksta.

pegasus je 14. jun 2017 ob 07:14 izjavil:

Andrej, hvala :)

Jap! Ni kaj dodati.

zmaugy je 14. jun 2017 ob 08:39 izjavil:

leiito je 8. jun 2017 ob 17:49 izjavil:

Apple je imel svoj redni junijski event, kjer je predstavil nabor novih izdelkov, ki jih je brez pretiravanja mogoče označiti za revolucionarne. Ko smo že mislili, da Apple ne zmore več preseči pričakovanj, nas je demantiral na celi črti. In da bo mera polna, so se izdelki pocenili. Hvala.

Mislim da bi ti celo Kim Jong Un rekel, da curb your entusiasm. Ne bom ti napisal na kaj me spominja tale tvoj zapis, bom pa omenil socializem...

Ja, tvoj poiskus osebne diskreditacije brez enega argumenta.. res spominja na kako preganjanje čarovnic.

Edit: po premisleku sem se odločil, da ne bom izgubljal časa s komentiranjem tega. V osnovi pa sem svoje itak povedal v prvem komentarju, ane.

Točno v tem, kar si napisal.
Je pa težko zaradi vseh teh dreves videti gozd.

Ne kapiraš. Tega vprašanja tam sploh ni.
Ni čaranja. Sploh. In nikoli ni bilo.

Vidiš, če bi oba imela Mac, te debate sploh ne bi bilo. Bi si oba (in bralci) prihranila čas.

Medtem pa reviewerji kujejo novi iPad v zvezde z opisi tipa "ridiculously fast" in pozivajo ljudi naj grejo v živo pogledat 120Hz zaslon. Sam sicer ohranjam izrazito kritičen odnos do Appla, se pa strinjam z njihovimi ugotovitvami, da je Apple letos res pošolal konkurenco in da se, kdor enkrat preide na njihovo napravo, ne vrača več h konkurenci.

Zakaj npr. se nihče drug ni spomnil 120Hz zaslona, saj s tivijev vemo kako velika je razlika in kako zelo blagodejno vpliva na uporabnika, gre samo za inovativnost, ali pa drugi tehnološko niso zmogli tega preskoka?

Hja dobilo se jih je še v času CRT, ampak ne dvomim, da bo zdaj to postalo popularno še kje in bo kdo privlekel ven telefon/pad s 130Hz. Kar je dobro za vse.

Ja, kot exotika. Enako kot leteči avtomobili.

In spet bo podiral prodajne rekorde, ti pa v jok :-)

kdor enkrat preide na njihovo napravo, ne vrača več h konkurenci

Apple realno sploh nima konkurence..ne zato ker bi bil tok dober ampak enostavno zato ker sta dva tipa ljudi.. Taki ki zelijo nek omejen pokriplan telefon pa taki ki nam pase mal vec fleksibilnosti..

Pa sem svoj cajt stal v vrsti za iphone haha.. Nikol vec

pa custom rom lahko daš gor, ker proizvajalec pozabi na tebe še predn je mimo koledarsko leto

dostop do filesistema, za quick charge se pri applu niso slisal cez leto dve bo to revolucija ziher..

Joj so dosadne te erekcije, ker lahko na droidu narediš kaj že več?

Loh istocasno predvajas glasbo (na 3.5mm) in zraven normalno polnis napravo

Ne rabi predvsem zato ker se applu bolj splaca prodajat eno in isto sranje ze 5 let.. Ti kr lepo preplacuj proprietary kable in adapterje :p jz mam rajs 3.5mm (pa se istocasno lah filam)

2h, seprav glih malo vec kot drugi uber fast charging foni. Pa se spontano ti ne vzge hise in the process.

kolikokrat mas scenarij k poslusas musko in filas baterijo ?

in koliko ljudi je sploh taksnih ki rabijo vec k stock slusalke, ki pridejo zram ?

mel verjetno kakega samsunga z uber shit slusalkami out of the box...

Cisto banalna zadeva, a je meni ze veckrat prisla prekleto prav na androidu - shranjeno wifi geslo se da pogledat na iphonu?

Če se ne motim, se ne da.

Razen v primeru, da imaš Mac računalnik in pogledaš Keychain datoteko v kateri so napisana gesla.

Greš na Keychain Access in najdi wifi ime in geslo.

Ma 64/32 je koristno, da se App Store spuca solate razvijalcev, ki ne spremljajo razvoja.

Sicer pa prijetno presenečenje, iPad Pro 10.5 se da že prednaročit pri nas, goodies so že na poti, tko da gremo samo še parkrat spat in bomo že na "buttery smooth" 120Hz HDR zaslonu s 500 niti, poleg tega iPad Pro na benchmarkih poje v solati vse notebooke vključno z letošnjim MacBook Pro-jem, tako da v kombinaciji z iOS11 zdaj res dobivamo napravo, ki povsem nadomešča prenosni računalnik in s tako živalsko močjo najbrž še bolj future-proof, pa že itak so Applove naprave glede tega zgledne, 4 leta za tablice in vsaj 6 let za notebooke je pohvalno. S tem, da je pa treba priznati, da medtem ko MacBook Pro tudi po 5 letih še vedno dela isto kot prvi dan, iOS naprave pa se upočasnjujejo oziroma na sledijo zahtevnosti aplikacij in je 3 leta tam nekje max, da upočasnjevanje ne postane moteče.

Zakaj je gap do android tablic tako ogromen? Razumem, da je android v osnovi OS za telefone in se samo raztegne slika, ampak a je res tako težko narest uporaben OS za tablice? Jasno, da nikoli ne bo pariral iOS, ampak to zdaj je že skoraj kršenje človekovih pravic.

od 386ke :)

When I first saw the new iPad Pro's test results from our lab, I thought there was a big mistake. This new 10.5-inch tablet turned in performance scores so high that they blow away most laptops. In fact, the iPad Pro (starting at $649 for 64GB, $907 with keyboard and Apple Pencil) smokes the new 12-inch MacBook and rivals the 13-inch MacBook Pro. That's how powerful the new A10X Fusion chip is inside this 1-pound powerhouse.

https://www.laptopmag.com/reviews/table...