Novice » Apple iPhone/iPad/iPod » Apple se poslavlja od 32 bitov
MrStein ::
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
hojnikb ::
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.
#brezpodpisa
MrStein ::
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Zgodovina sprememb…
- spremenil: MrStein ()
Lonsarg ::
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...
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...
Zgodovina sprememb…
- spremenil: Lonsarg ()
Modri dirkač ::
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...
Kateri proizvajelec že ponuja alternativo, kjer je HW/SW tako optimiziran?
Ne morem se spomnit, emmm, uuugh, mmm ...
Everybody lies!
Lonsarg ::
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..
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..
Zgodovina sprememb…
- spremenil: Lonsarg ()
Furbo ::
Modri dirkač je izjavil:
Kateri proizvajelec že ponuja alternativo, kjer je HW/SW tako optimiziran?
Ne morem se spomnit, emmm, uuugh, mmm ...
Noben, pri tablicah so se praktično predali.
i5-13600K, Noctua NH-D15, STRIX Z790-F, 32GB DDR5, 2TB Samsung 990PRO,
Toughpower GF3 1000W, RTX3070, ALIENWARE AW3423DWF, Dell S2722QC
Toughpower GF3 1000W, RTX3070, ALIENWARE AW3423DWF, Dell S2722QC
noraguta ::
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.
Pa če nabijaš že o tvojem ljubljemem kodeku. Kolikokrat je bil že citiran izven taiste obskurne ustanove na kateri se je šel šerifa.
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: tuser32 + tsyscall32 + a*tcs
64 bitov: tuser64 + tsyscall64 + b*tcs
Iz strojne kode je razvidno, da je tuser32 ≅ tuser64, torej ju lahko nadomestim z tuser.
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: tuser * tsyscall32 + c*tcs
64 bitov: tuser + tsyscall64 + c*tcs
Iz tega sledi, da razlika prvenstveno izhaja iz razlike med syscall32 in syscall64. Oba izmed teh pa se lahko nadalje razdelita na:
32 bitov: tsyscall32 = tswitch_utk_32_64 + tkernel64 + tswitch_ktu_64_32
64 bitov: tsyscall64 = tswitch_utk_64 + tkernel64 + tswitch_ktu_64
Zaradi namerne izbire "knjigovodske" funkcije getpid() sem lahko prepričan, da se bodo klic tkernel64 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 tswitch_utk_32_64 + tswitch_ktu_64_32 na eni strani ter tswitch_utk_64 + tswitch_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.
Pust' ot pobyedy k pobyedye vyedyot!
Zgodovina sprememb…
- spremenilo: noraguta ()
AndrejO ::
Tvoji traktati nebuloz limitirajo v razliko med syscallom in sysentrom.
Razlog za to je:
Intel 64 allows SYSCALL/SYSRET only in 64-bit mode (not in compatibility mode), and allows SYSENTER/SYSEXIT in both modes. AMD64 lacks SYSENTER/SYSEXIT in both sub-modes of long mode.
Vir
Preostanek tvoje argumentacije in natančna pojasnila o tem, kje in kako se motim, pa bom pustil spodaj, da se bo lahko vsak bralec sam odločil glede tega, kdo ima malo več in kdo ima malo manj pojma o tej temi. Me pa veseli, da sem v tvojih očeh že napredoval od ZX Spectrum do 8088 in celo 8086.
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.
Pa če nabijaš že o tvojem ljubljemem kodeku. Kolikokrat je bil že citiran izven taiste obskurne ustanove na kateri se je šel šerifa.
Researchgate pravi, da 416-krat, recimo da jih 10% ustreza tvojem kriteriju.
Kolikokrati pa si bil citiran ti izven S-T?
Q.E.D.
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Apple se poslavlja od 32 bitov (strani: 1 2 3 )Oddelek: Novice / Apple iPhone/iPad/iPod | 27066 (22050) | AndrejO |
» | Applove novosti na WWDC: macOS Sierra, iOS 10, watchOS 3Oddelek: Novice / Apple iPhone/iPad/iPod | 12762 (10299) | hojnikb |
» | ne zazna 3 G ramov ampak 2558 zakaj ??Oddelek: Pomoč in nasveti | 2984 (2446) | Zheegec |
» | Smrt Windows XP Home prestavljena na 30. junij 2010Oddelek: Novice / Operacijski sistemi | 6255 (3085) | 1fris |
» | Apple se boji PC platforme (strani: 1 2 )Oddelek: Novice / Tožbe | 9369 (7983) | borchi |