» »

Apple se poslavlja od 32 bitov

1
2
3

hojnikb ::

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).
#brezpodpisa

Zgodovina sprememb…

  • spremenil: hojnikb ()

7982884e ::

Potem je bolje, da štartajo z novim naborom ukazov (like arm64) in nardijo ven highperformance jedro (kot to recimo počne apple).

ce microsoftu uspe laufanje windows na ARM z high-level emulacijo x86 (intel grozi s patenti), se mogoce lahko celo res kaj premakne v tej smeri. sploh ce intel da svojo podporo.

hojnikb ::

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

Zgodovina sprememb…

  • spremenil: hojnikb ()

noraguta ::

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.
Vsak proces , nit ali pa preklop med user in kernel spaceom zahteva context switch.
Legacy x86 koda v 32 bitih ni v niçemer podoben real modu na 16bitih. 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. Mogoçe bolje optimizira$ kot kompajler ampak taki ste redki.
In ooeracijski sistem ne izvaja nobenih preslikav med naslovnimi prostori je vse v abiju od procesorja.
Pust' ot pobyedy k pobyedye vyedyot!

AndrejO ::

noraguta je 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 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 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 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 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 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 ::

Andrej, hvala :)

          ::

pegasus je izjavil:

Andrej, hvala :)


Jap! Ni kaj dodati.

zmaugy ::

leiito je 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...>:D

Furbo ::

zmaugy je izjavil:

leiito je 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...>:D

Ja, tvoj poiskus osebne diskreditacije brez enega argumenta.. res spominja na kako preganjanje čarovnic.
i5-13600K, STRIX Z790-F, 32GB DDR5, 2TB Samsung 990PRO, Toughpower GF3 1000W
RTX3070, ALIENWARE AW3821DW, DELL U3014

Dr_M ::

Furbo je izjavil:

zmaugy je izjavil:

leiito je 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...>:D

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


Ubistvu se je ze sam deskriditiral z lepim opisom pralnice mozganov.
The reason why most of society hates conservatives and
loves liberals is because conservatives hurt you with
the truth and liberals comfort you with lies.

zmaugy ::

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.

Zgodovina sprememb…

  • spremenilo: zmaugy ()

mojster_joni ::

>Mimogrede ima MacOs veliko bolje rešeno 32-64 bitne zadeve kot Windows ali Linux.

kako točno je lahko bolje rešeno od tega da si po želji lahko namestiš zadevo tako da je čisto 64 bitna, 64 bitna s podporo za 32 bitne aplikacije, 64 biten kernel vse ostalo 32 bitno ali pa vse 32 bitno? s tem da tbh podpore za 32 bitne aplikacije načeloma ne rabiš, ker praktično ves linux sw dela normalno če je preveden v 64 biten program

MrStein ::

Točno v tem, kar si napisal. ;)
Je pa težko zaradi vseh teh dreves videti gozd.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

mojster_joni ::

Huh?

Če se ti ne ljubi s tem ukvarjat se ti ni treba in to že nekaj časa... pač naložiš 64 biten sistem in vse dela kot je treba (32 bitnih librarijev niti ne rabiš če nimaš kakega 32 bitnega zaprtokodnega programa ki ne obstaja v 64 bitni verziji (ali pa obstaja ampak te hoče lastnik avtorskih pravic nategnit da še enkrat plačaš za isto reč v 64 bitih), ampak glede na velikosti današnjih diskov jih komot pustiš gor za zihr in se nič ne pozna)... če imaš veselje lahko pa čaraš in nastavljaš kakor hočeš....

Mislim ne vem kako točno je lahko reč rešena boljše od 'če se nočeš s tem ukvarjat se ti ni treba in vse dela kot je treba, če maš veselje pa lahko čaraš in čaraš'?

MrStein ::

Ne kapiraš. Tega vprašanja tam sploh ni.
Ni čaranja. Sploh. In nikoli ni bilo.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

mojster_joni ::

Kapiram kapiram, tam nimaš izbire ali boš čaral ali ne - dobiš kar dobiš in to je to. Pri linuxu pa lahko pustiš vse pri miru in dela normalno ali pa čaraš če hočeš... noben te ne sili...

Ko so prišli prvi athloni64 si moral malo čarat če si hotel da reči optimalno delajo, ampak to je blo kakih 15 let nazaj, sedaj pa reči delajo brez čaranja.

MrStein ::

Vidiš, če bi oba imela Mac, te debate sploh ne bi bilo. Bi si oba (in bralci) prihranila čas. ;)
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

mojster_joni ::

Če bi imel maca bi ga prodal in kupil dva računalnika po delih in dal gor linux :)

leiito ::

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?

Zgodovina sprememb…

  • predlagalo izbris: zee ()

mojster_joni ::

A govoriš samo o tablicah/telefonih ali na splošno?

Ker za računalnike se že nekaj časa dobi zaslone z 120Hz+

Furbo ::

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.
i5-13600K, STRIX Z790-F, 32GB DDR5, 2TB Samsung 990PRO, Toughpower GF3 1000W
RTX3070, ALIENWARE AW3821DW, DELL U3014

hojnikb ::

120Hz monitorji so na voljo za PCje že ene 20 let
#brezpodpisa

MrStein ::

Ja, kot exotika. Enako kot leteči avtomobili.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

mojster_joni ::

zdj bo crapple izdal iZaslon z 120Hz in enim vhodom za sliko in samo eno tipko (več ne sme bit ker to je že preveč komplicirano) in hitro tn matriko ki bo prvi ne eksotični zaslon z višjo frekvenco osveževanja in ga bodo kupili vsi iIdijoti

stal bo pa več od 'eksotičnih' 144Hz zaslonov s kupom vhodov, nastavitev, freesync podporo in ips matriko za nas klošarje

bo pa crapplov prvi, to pa

Zgodovina sprememb…

  • predlagalo izbris: zee ()

tomaz- ::

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

mojster_joni ::

Boljše v jok kot po crappla.

Zgodovina sprememb…

  • predlagalo izbris: zee ()

noraguta ::

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.
Pust' ot pobyedy k pobyedye vyedyot!

AndrejO ::

noraguta je 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: tuser32 + tsyscall32 + a*tcs
64 bitov: tuser64 + tsyscall64 + b*tcs

Iz strojne kode je razvidno, da je tuser32 &cong; 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 &cong; 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.

Zgodovina sprememb…

  • spremenil: AndrejO ()

blackbfm ::

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 :))

Furbo ::

Joj so dosadne te erekcije, ker lahko na droidu narediš kaj že več? Aja font spremeniš v facebuku. Yay.
i5-13600K, STRIX Z790-F, 32GB DDR5, 2TB Samsung 990PRO, Toughpower GF3 1000W
RTX3070, ALIENWARE AW3821DW, DELL U3014

hojnikb ::

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

MrStein ::

Lahko pove, kaj lahko naredi na enem, kar na drugem ne gre, če je že načel temo.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

blackbfm ::

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 :))

Zgodovina sprememb…

  • spremenilo: blackbfm ()

hojnikb ::

jokes on you, samo opice v kameni dobi se uporabljajo 3.5mm >:D

quck charga nerabi,ker je tko mala baterija :)
#brezpodpisa

Zgodovina sprememb…

  • spremenil: hojnikb ()

blackbfm ::

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)

Zgodovina sprememb…

  • spremenilo: blackbfm ()

MrStein ::

Kako dolgo se polni?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

hojnikb ::

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 ?
#brezpodpisa

Zgodovina sprememb…

  • spremenil: hojnikb ()

Furbo ::

Ravno danes sem videl enega tekati za cesto s takimi, ki verjetno rabijo še ta debelo bananco. ;)
i5-13600K, STRIX Z790-F, 32GB DDR5, 2TB Samsung 990PRO, Toughpower GF3 1000W
RTX3070, ALIENWARE AW3821DW, DELL U3014

hojnikb ::

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

blackbfm ::

2h, seprav glih malo vec kot drugi uber fast charging foni.


Bolj tko nekak uro in pol vs 3h na tavelkem iphonu. Ce ga uporabljas vmes ga lahk kr cel popoldne do večera vrjetno filas :p pa ni samo to, prednost fast charga je visja napetost, manjsi tok, torej loh spravis vec moci cez dolg ali manj kvaliteten kabel

Pa se spontano ti ne vzge hise in the process.


Je tut apple imel recalle, sicer chargerjev ki so se vzigal. Se vec, sam sem imel iphone iz tiste serije...tko da ja, ne bit prevec glasen glede tega:))

kolikokrat mas scenarij k poslusas musko in filas baterijo ?


Vsak vecer, pa tut cez dan na kaksne zvocnike, ce nimam bluetooth receiverja

aborko ::

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

no comment ::

Upam, da se nikakor ne da (brez jailbreak-a).

VaeVictis ::

Č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.

MrStein ::

Saj to na večini Androidov tudi ne gre (brez rootanja).
Če pa kdo pozna način, sem odprt za predloge.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

leiito ::

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.

hojnikb ::

da je a10x hitrejši od intel procov je ena velika bučka.
#brezpodpisa

mojster_joni ::

od 386ke :)

MrStein ::

Numbers are welcome.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

leiito ::

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...

hojnikb ::

geekbench je pac dalec od zanesljivega indikatorja performanca.
#brezpodpisa
1
2
3


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Apple se poslavlja od 32 bitov (strani: 1 2 3 )

Oddelek: Novice / Apple iPhone/iPad/iPod
10825665 (20649) AndrejO
»

Applove novosti na WWDC: macOS Sierra, iOS 10, watchOS 3

Oddelek: Novice / Apple iPhone/iPad/iPod
2912194 (9731) hojnikb
»

ne zazna 3 G ramov ampak 2558 zakaj ??

Oddelek: Pomoč in nasveti
282893 (2355) Zheegec
»

Smrt Windows XP Home prestavljena na 30. junij 2010

Oddelek: Novice / Operacijski sistemi
446017 (2847) 1fris
»

Apple se boji PC platforme (strani: 1 2 )

Oddelek: Novice / Tožbe
609064 (7678) borchi

Več podobnih tem