Apple se poslavlja od 32 bitov

The result is a tablet that beats most Windows laptops on the Geekbench 4 benchmark, which measures overall performance.

v tem benchu ima stvar podoben performance kot intelovi dual core U cpuji.

Pa saj to že nekaj let drži, da je ARM ujel intela pri perf/Watt. Če govorimo torej recimo o U procesorjih, ki imajo max W nekaj takega kot latest ARM procesorji potem bodo zaradi zgornjega tudi podobno hitri. Zdaj načeloma imajo ARMji vseeno manjši max W, ampak zadnja leta so se praktično približali.

Skratka v podrobnosti se mi ne da spuščati (Geekbench devicacije so komot nekaj 10% od realnega stanja recimo) ampak velikosti rang performans so pa najbolši ARMju zdaj tam-tam z Itelovimi low-power zadevami, ki jih najdemo v teh entry ultrabookih. Skratka to velja splošno za ARM, Apple je samo eden izmed mnogih, ampak ker je pač Apple se naredi cel pomp iz tega...

Noben ni nič o softwerju govoril v tej temi, debata je bla ujetje Intela.

In govoril sem o tem, da so ste Intelu približali vsi. Tukaj imaš Apple, ki ga v enem benchu celo prehiti, potem imaš Qualcomm 820, ki kljub emulaciji brez štekanja odpira x86 Photoshop in podobne fore, itd..

Tvoji traktati nebuloz limitirajo v razliko med syscallom in sysentrom. V rezultatih pa vidiš kar hočeš. Nikakor pa ne manjši footprint etc. Pa pustimo da si poprej sanjal o cs in virtualnih adresah kater naj bi po kodekovih litanijah opravljal operacijski sistem. Dolgovezenje traparij je res specijalnost ljudi kateri so obtičali nekje pri kompatibilnosti z 8088 (8086 je bol že bolj napreden) in seriji 360 ， 370 bomo pa izpustili iz znanih razlogov. Pa pozdravi bivšega dekana brez resnega akademskega članka.

AndrejO je 15. jun 2017 ob 16:26 izjavil:

noraguta je 15. jun 2017 ob 11:46 izjavil:

Najprej potrebujem enostaven program, ki bo večino časa izvajal sistemske klice in nič drugega.

V celem si dosegel 3 csje. Ker pid bere iz cacha. In je le računovodska vrednost. Slabšega primera nebi mogel najti . veliko napisanega brez kakršnekoli vrednosti.

Tck, tck, tck. Še bi trolal?

Nihče ti ne brani pognati primer tako, da dosežeš 0 preklopov niti. Trivialno je in takšen mojster, kot si ti, lahko takšen test izvede kadarkoli in se prepriča, da bo rezultat enak.

Za PID ne moreš trditi od kje v pomnilniški hirearhiji se ga bere, bistveno pa je, da se ga bo za vse praktične namene najverjetneje bralo iz istega nivoja in, da bo to branje tako za 32-bitno, kot tudi za 64-bitno uporabniško kodo trajalo natančno enako število operacij v 64-bitni kodi v jedru.

Dejansko bi težko našel boljši primer (če sploh), ker ta primer izloči ali omeji vpliv praktično vse spremenljivk razen samega prehoda med CLP=3 in CLP=0, kar pomeni, da bo imel zgolj ta prehod bistven vpliv na celoten porabljen čas (št. ciklov). Razlika, ki se jo pri tem testiranju ugotovi za primer izvajanja 32-bitne in 64-bitne kode se lahko zato pripiše zgolj razliki, ki nastane pri tem prehodu.

Kar se pa tiče primera:
Majhno število preklopov kontekstov na končno ugotovitev ne more vplivati, čeprav lahko vpliva na absolutne številke. To pa zato ne, ker lahko privzamemo, da je strošek preklopa konteksta na drugo nit izvajanja približno konstanten. To pomeni, za:
32 bitov: t_user32 + t_syscall32 + a*t_cs
64 bitov: t_user64 + t_syscall64 + b*t_cs

Iz strojne kode je razvidno, da je t_user32 ≅ t_user64, torej ju lahko nadomestim z t_user.

Nadalje je pri približno enakih pogojih testiranja (torej povprečeno preko dovolj ponovitev in brez nalaganju ali odvzemanju dodatnega dela sistemu) možno trditi, da je a ≅ b, torej ju lahko nadomestim s c.

Torej dobim:
32 bitov: t_user * t_syscall32 + c*t_cs
64 bitov: t_user + t_syscall64 + c*t_cs

Iz tega sledi, da razlika prvenstveno izhaja iz razlike med syscall32 in syscall64. Oba izmed teh pa se lahko nadalje razdelita na:
32 bitov: t_syscall32 = t_{switch_utk_32_64} + t_kernel64 + t_{switch_ktu_64_32}
64 bitov: t_syscall64 = t_{switch_utk_64} + t_kernel64 + t_{switch_ktu_64}

Zaradi namerne izbire "knjigovodske" funkcije getpid() sem lahko prepričan, da se bodo klic t_kernel64 pri enakih pogojih izvajal približno enako, predvsem pa neodvisno od uporabniške kode. Približno enaki pogoji se tukaj nanašajo predvsem na morebitno zaklepanje pomnilnika in preklope konteksta. Ker je funkcija kot celota lock-free, zaklepanje pomnilnika in bariere odpadejo. Ker ni različnih pogojnih skokov, odpade vpliv branch prediction na število porabljenih ciklov. Ostanejo še preklopi konteksta, ki pa so, na podlagi opažanja iz prvega dela izpeljave, izločeni kot uniformen dodatek, ki na oba testa vpliva uniformno (ne pozabi, da se meri cikle in ne zgolj wall-clock - ti podatki pridejo neposredno iz procesorja).

Vse, kar še ostane sta tako:
- razlika med t_{switch_utk_32_64} + t_{switch_ktu_64_32} na eni strani ter t_{switch_utk_64} + t_{switch_ktu_64} na drugi strani.
- "skrita" razlika, ki izhaja iz stroška dostopanja do pomnilnika zaradi odstranitve vnosov v TLB, ki so pri prehodu iz CS.L=0 v CS.L=1 nujni. To pomeni, da čeprav sta GDT in LDT v L1 ali L2, bo moral MMU še vedno narediti poizvedbe in ne bo mogel izkoristiti CAM. Posledično bo takšna operacija v pomnilniku za magnitudo ali dve počasnejša (Za Sandy Bridge bo vpogled v CAM vzel 1 cikel, vpogled v L1 vzame ranga 10 ciklov, vpogled v L2 pa ranga 100 ciklov).

Rezultati eksperimenta so s to razlago konsistentni. Lahko pa sam ponudiš alternativno razlago, če že nisi sposoben pokazati na konkretno kodo, citirati konretnih specifikacij procesorjev oz. spisati kaj več kot enovrstičnice, ki v celoti temelji na tem, da ti to tematiko obvladaš mnogo bolje kot jaz, čeprav dokaza za to implikacijo ne ponudiš.

Kodek se te bi sramoval.

Pa če nabijaš že o tvojem ljubljemem kodeku. Kolikokrat je bil že citiran izven taiste obskurne ustanove na kateri se je šel šerifa.