Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Takže myslíš teda, že je dobré HPET na Intelech vypnout?
Hmm, tak jsem se ho snažil vypnout, ale já ho už mám vypnutý. Tohle téma časovače se jednou za čas objeví, tak je pravděpodobné, že jsem ho už vypnul před pár lety. Přeci jen mám už pátým rokem stejný instal windows 8.1 upgradnutých na 10. To je asi nejdéle co jsem kdy nějaký instal měl. Ten už prošel hodně upgradema, zbyla vlastně už jen deska :-D
"šokézní skutečnost"
Ďalej som nečítal. To robíš prijímačky do Blesku alebo čo ???
Mozna jsi mel, mozna by si nas usetril sveho zbytecneho prispevku.. ;)
Ty problémy s měřením času se táhnou už fakt dlouho a tak jsem dostal nápad, jak měřit přesně. Na MB by byl separátní a autonomní zdroj přesného času. Mohlo by se to jmenovat třeba Real Time Clock, navrhuji použít zkratku RTC. Byl by řízený krystalem a jeho čas by se dal nastavit a číst. Přesnost času by byla dána pouze krystalem a nedala by se ničím a nijak ovlivnit. To je vše. Myslíte, že je to dobrý nápad? Jo a k tomu měření. Já si naopak myslím, že recenze se povedla a už bych do toho nešťoural. Taky se může stát, že se objeví ještě nějaký další, mnohem horší, kostlivec ve skřni.
"Problemy" se tahnou, protoze lidi delaji pitomosti a hraji si s vecmi, kterym nerozumi (jako treba zapinani a vypinani HPET).
Strucne: OS ma zdroje casu alespon dvou druhu, prvni z ktereho lze jenom cist (napr instrukce RDTSC), a druhy typ, ktery vam po jistem case vyvola preruseni procesoru (sem patri RTC a HPET). Ty prvni jsou obvykle presnejsi na mereni casu, ty druhe se pouzivaji na nacasovani ruznych udalosti.
K vasemu "napadu" : RTC dela preruseni pravidelne s frekvenci jakou si nastavite, ale pri vysoke frekvenci bude vas CPU zahlcen, a pri nizke frekvenci budete mit nahovno presnost. HPET ma presnost v radech mikrosekund, a namisto pravidelneho preruseni si muzete zazadat PRESNE kdy chcete to preruseni (trebars "1300500 tiku od tohto okamziku"). Vas uzasny napad mel smysl pred triceti lety v dobach DOS. Vypinat dnes HPET doporucuji hlavne masochistum, idiotum a lidem kteri si vychutnavaji prehravani videa kde zvuk je zcela jinde nez obraz.
Jeste k RDTSC: to *puvodne* tikalo stejnou rychlosti jako frekvence procesoru, jenomze Intel i AMD rychle prisli na to, ze s procesorem ktery neustale meni frekvenci je to k nicemu. Proto se RDTSC uz dost davno zmenilo, a ted ma vlastni hodiny, stabilni a nezavisle od frekvence procesoru.
zpatky k clanku:
> Zásahy do taktů procesoru totiž mohou způsobit desynchronizaci skutečného a systémového času.
... tady bud ten overclocker nebo Microsoft neco brutalne zkonil, ale pravdepodobnejsi je to prvni. Tipuji ze vypnul HPET, nacez system pouzil druhy nejlepsi dostupny zdroj casu (typu 2), coz je LAPIC (ktery ale opravdu zavisi na frekvenci CPU). Shrnuti: doporucuji nesahat na low-level veci kterym hovno rozumite, a nechat OS at si nastavi zdroje casu sam; obvykle to dokaze lip nez vy.
Jo, je škoda, že něco takového v PC chybí
Nemůžu se ubránit pocitu, že RTC v počítači už dávno mám...
jop je tam :P
32.768 kHz a je to streleny primo na chipset u dnesnich desek
Je tam od pradávna..
jednalo se o sarkasmus reagující na něco, co musel být taky sarkasmus. protože když někdo navrhuje, aby v PC bylo 'něco' co bude mít reálný čas / RTC, nemůže to být myšleno zcela vážně (na technickém webu)
Ono i na technickém webu ne každý je programátor a rozumí low level vrstvám HW a systémů. Osobně o tom mám také jen mlhavé znalosti. :-)
Víte co ne nejvíce funny? Že má retro 486 mněří čas přesně ale mé moderní systémy se za cca mněsíc o pár minut rozejdou. Jak Sandy bridge tak coffe lake. Používány win7 a na HPET nesaháno. Jako to že budeme mít v roce 2018 na PC problém s přesností digitálních hodin je jeden velkej joke. Je jím i ono SW mněření ve win8/10 závislé od FSB procesoru které se rozhodí jakmile dojde k delšímu komplet výtuhu nebo se za běhu OS FSB zmnění a ona se pořád lehce mnění, žádnej clockgen neni 100% přesnej, to si můžete ověřit samy přesnym sledovánim taktu CPU.
> Že má retro 486 mněří čas přesně
opravdu ? rekl bych ze je to trochu v rozporu s vasim pozdejsim vyhlasenim: "žádnej clockgen neni 100% přesnej"... vase retro 486 ma asi clockgen od Gandalfa...
> Jako to že budeme mít v roce 2018 na PC problém s přesností digitálních hodin je jeden velkej joke
Mozna vy mate problem, nebo Win 7 dela neco spatne. Kazdopadne vec zvana NTPD uz davno existuje, a s funkcnim NTPD vam cas o par minut ujit nemuze. NTP neustale meri "drift", jinak receno o kolik se rozchazi zdroj systemoveho casu s realnym casem, a podle toho upravuje systemovy cas. Mimo jineho to na linuxu umi takove finty, jako mirne "zrychlit" a nebo "zpomalit" systemovy cas na jistou dobu aby se zrovnal s realnym casem, bez vzniku vetsich "mezer" v systemovem case.
drift je meren v PPM (miliontiny) a me zrovna ukazuje 4.38 PPM, coz dela za den 378 milisekund. Takze jo, za mesic se vam to rozjede o desitky sekund az jednotky minut. Zadna tragedie a jak rikam, reseni uz davno existuje.
Žádnej clockgen neni přesnej, a proto čas počítanej dle taktu CPU a jeho FSB nikdy nebude úplně přesnej. Mněření času musí bejt komplet nezávislé spešl čipem, staré stroje na to maj RTC clock čip, kterej pracuje sám nezávisle a přesně, nepočítaj čas dle FSB jak je to dnes v móde.
A online synchronizace času typu NTPD a pod věci obcházej problém, neřešej ho. Naopak když tohle musíš používat je to jen důkaz toho že je u tebe problém taky. Pokud potřebuje systém mít extra jemné časovače ať si je spočítá dle FSB, ale mnělo by se to pravidelně synchronizovat s RTC čipem s tim že RTC čip má pravdu a případnej rozdíl se opraví dle něj. Ne že FSB drift mi způsobí posun času a systém to bere jako správnej čas a zapíše jej do biosu. WTF. Kam jsme to dopracovali.
V počítači přesný čas není potřeba a když, tak se to řeší synchronizací se siťovými normály, GPS nebo dříve DCF. Tyhle jemné čítače jsou důležité spíše pro synchronizaci procesů mezi jednotlivými výpočetními vlákny, protože v zásadě není jisté ani to, že daný výpočet bude prováděn na jednom jádru (pokud není zaparkovaný) a dneska může mít každé jádro jinou frekvenci a v rámci desky může být i více procesorů, takže čítače dostupné v rámci jádra jsou obecně nevyhovující (mám takový dojem, že u novějších procesorů už můžou ty čítače být na frekvenci jádra nezávislé). Další problém nastavá s tím, že díky "out of order" zpracování nejste schopni přesně přiřadit čas, kdy stav čítače přečtete/nastavíte respektive, pokud to chcete udělat přesně, tak zhoršíte efektivitu kódu.
> staré stroje na to maj RTC clock čip, kterej pracuje sám nezávisle a přesně
LOL urcite. A to RTC bere "presny" cas dle tebe odkud, taha ho ze svy zadnice ? Prozradim ti desive tajemstvi, to RTC pouziva krystal (stejne jako to "FSB" ktere nenavidis), a kazdy krystal ma omezenou presnost z vyroby. Bezne 20-50ppm, ty lepsi maji 2-5ppm, ale furt maji nepresnost. Navic se ta nepresnost meni s teplotou a dalsimi faktory.
> A online synchronizace času typu NTPD a pod věci obcházej problém, neřešej ho.
No jedine lepsi a definitivni reseni jsou atomove hodiny, klidne si je kup jestli te ten cas tak trapi. NTP je podstatne levnejsi a nejaka synchronizace je **nutna** pokud nemas absolutne presne hodiny (ne, RTC neni presne, laskave toho nech, se jen ztrapnujes).
> RTC čip má pravdu
RTC cip nema pravdu, to jen ty mluvis o vecech o kterych vis kulove.
Dobře, uznam že ani RTC jako takovej neni asi 100% přesnej ale na starších baordech se mi rozešel o naprosto nicotné hodnoty za roky, ne minuty za mněsíc. Takže ať se zmněnilo cokoliv udělali jsme krok zpět, ne vpřed, o to mi jde.
Přesnost RTC závisela na přesnosti krystalu (a jeho teplotě respektive změnách teploty). U některých boardů to bylo vcelku přesné - asi jako hodinky, ale u některých se to rozjelo i o ty minuty za měsíc. Pozorováno na 286 -> Pentium, pak už se čas synchronizoval přes síť.
P.S. zajímalo by mě co to jsou naprosto nicotné hodnoty za roky, když přesnost velmi dobře teplotně kompenzovaného krystalového oscilátoru je cca 5ppm - chyba až 3 minuty za rok
Jo , to odpovídá cca 3 minuty za rok asi jo. Když si to porovnam s mym hlavnim PC (Asrock Z370 pro4 s I7-8700K) kterej udělá cca 2 minuty za měsíc, nebo nedej bože druhej PC kde je Gigagybte Z77 deska s 2600K a ten teď trhnul rekord a spozdil se cca o 12 minut za 2 měsíce.
Dříve to ale byl samostatný čip, jako třeba DS1387, ale pak to integrovali do jižního můstku a tam už si o teplotní stabilizaci může nechat jen zdát, a kdo ví, jestli to vůbec má samostaný krystal.
Asi by meli upravit ty testy, kdyz jejich trvani je pod rozlisitelnosti zjistovani presneho casu. HPET ma 15 az 18 MHz, vyvola preruseni po dosazeni prednastavene hodnoty a po jine nastavene hodnote zacne pocitat znova. A tohle je jadro pudla - pokud si OS HPET prekonfiguruje na nesmyslne kratkou dobu preruseni a pak je nestiha obsluhovat, jde cely koncept mereni casu do haje. Mit driver na HPET pres OS nebo ACPI je uplny nesmysl. K presnemu mereni potrebujete vedet kdy ten cas ctete a nemit tam nekolik vrstev ktere se muzou preplanovat.
Idealni pro benchmarkery by bylo pouzit jednoduche udelatko na PCIe zbernici s pocitadlem ktere se neresetuje a umi si zapamatovat zacatek/konec (prostrednictvim zapisu, aby se vyloucila latence cteni).
> Idealni pro benchmarkery by bylo pouzit jednoduche udelatko
U benchmarku (kde potrebujete jenom merit, ne casovat) staci pouzit RDTSC(P), ktere na novejsich procesorech (tusim od Nehalemu) ma jednak konstantni frekvenci, a jednak je synchronizovano pres vsechny jadra (tj i kdyz se vam presune thread/proces na jine jadro, TSC hodnoty muzete porad odecist).
RDTSC zabere zhruba 100-200 cyklu CPU, komunikace s PCI bude mit daleko vyssi latence. Pochybuju ze na *mereni* najdete dnes neco lepsiho. A mit driver na HPET dava smysl, protoze hlavnim ucelem HPET neni mereni, ale *casovani* udalosti...
Po precteni Anandtechu kde odkazovali na utilitu od Overclockers kde bylo nejake demo se zjistilo ze samotna testovana aplikace vola funkce na casovace asi 100-200 tisic krat. Takze nejde ani o chybu mereni, jenom aplikacni problem. Clovek by cekal ze vykonnostni benchmark proste bude delat sve veci nezavisle od toho jak plyne cas, ale ne jako. Takze proto ty drasticke rozdily.
Je to ekvivalentni k problemu s merenim FPS kdyz mate zapnuty vsync a monitor vam jede 60 :) taky se asi pouzitelnych cisel nenamerite.
> samotna testovana aplikace vola funkce na casovace asi 100-200 tisic krat.
.. umim si predstavit nejake legitimni duvody proc volat casovace tak casto, ale zrovna tady si je predstavit neumim :) takze asi mate pravdu, aplikacni problem. 100K krat RDTSC zabere mozna 1-5% procesoru, ale 100K krat cist HPET uz rozhodne neni zanedbatelne %.
Zajimave pocteni ve svatek. Diky
Intel prehral, nieco musi byt zle.
Pretestujte, pretestujte dovtedy pokial intel nevyhra...
Ano, presne tak nejako by na to reagovali kokoti. Rozumnym ludom (vratane autorov testu sammotnych) je jasne, ze, ked niekto nameria uplne ine vysledky ako zvysok sveta, treba to preverit.
Ukaz na tejto babike kde sa ta AMD dotklo.
Takže AnandTech měřil tentokrát jinak než měřil dříve? Když jsem to před pár dny četl, tak jsem dospěl k názoru, že to je jejich standardní měřicí metoda. A v takovém případě je Bager-ův vtip celkem přesný.
Že to všem vyšlo jinak přece neznamená, že to měření je špatně, jen odráží konkrétní nastavení. A ta úporná snaha "najednou" najít důvod "proč to nevyšlo" jen ukazuje, že vítěz byl všeobecně očekáván, a že to nedopadlo. Svým způsobem je to něco jako perverze "Obrnamajerova testu," záměrně sestaveného tak, aby vyhovoval jedné značce.
To je sice naprostá pravda, ale cílem těch testů bylo ukázat čtenářům, jak by se dané procesory chovaly u nich doma... A jelikož většina uživatelů by si asi přesné měření času na svých strojích nevynucovala, tak jsou ty výsledky sice bezchybné, ale pro čtenáře zcela zavádějící - což je stav, který si žádný seriózní IT zpravodajský server nemůže dovolit.
Pak se ale ptám znova: pokud tyto výsledky jsou systematicky špatně, proč se na ně přišlo (že jsou špatné) až tehdy, když to uškodilo Intelu?
Jestli to uškodilo nebo neuškodilo intelu nebo amd nebo jakékoliv jinému výrobci bylo přeci úplně jedno. Tady právě z tebe mluví ta zaujatost jedním nebo druhým směrem. Šlo přeci o to, aby ty výsledky byly realistické a replikovatelné na PC skrz celý PC segment. Jak už někdo výše podotkl, zajímalo je proč se jejich výsledky tak liší od ostatních a ne jestli to někomu uškodilo. To by podle tvé logiky ty původní výsledky nepublikovali vůbec. Anandtech je nejobjektivnější IT portál co je a tím, že ty původní výsledky zveřejnil to jen dokazuje. Zkus být taky trochu někdy objektivní a ne si jen přihřívat tu tvoji polívčičku furt dokola a nést se na vlně toho, že DIIT není editoriálně nestranné tak jako Anandtech.
Zřejmě jsi to nepochopil, tak ještě jednou: Srovnávají-li se několikery testy, je přece logické, že máš stejný baseline, tj. stejně (nebo co nejvíce stejně) nastavené prostředí. Tudíž i historické testy by měly mít (a podle toho co jsem četl to tak i bylo) stejné nastavení. A nyní je tu test, kde najednou AT tvrdí, že měli něco špatně, a že teď už je to správně. A já se ptám, PROČ po tom pátrají až nyní, resp. PROČ změnili konfiguraci testovacích prostředí. Obě varianty jsou totiž naprosto špatně, každá ovšem z jiného důvodu, ta první proto, že všechny předešlé testy jsou postiženy stejnou chybou. Ta druhá proto, že zřejmě nedokáží udržet stejné nastavení, a tedy jakákoli důvěryhodnost jejich testů je tímto značně ohrožena, protože nikdo nedokáže garantovat, že v testovacím prostředí nemají ještě další chyby. A když si přečteš celý článek, tak zrovna toto téma tam není úplně jednoznačně vysvětleno. Pročpak asi?
Mně to přijde spíše zábavné sledovat to nervózní rojení v okamžiku, kdy ty výsledky neodpovídají všeobecnému očekávání. (a pak se ptám, zda má nějaké testování smysl, když všichni očekávají určitý výsledek). Ale to je jen tak pro pořádek a vysvětlení pro ten tvůj logický faul ohledně "AT to přiznal, tak je nejobjektivnější".
Co je ovšem IMHO nejhorší, v podstatě tu nikdo neřeší to nejpodstatnější, tedy fakt, že existuje (další) nastavení, které procesory intelu dost brutálně penalizuje na výkonu. Celé se to smete se stolu s prohlášením, že "HPET stejně nikdo nezapíná" (pokud to k ničemu není, proč to tam tedy je?)
Proč teď? Protože se lišili od jiných webů, tak začali pátrat. Je to takhle jednoduché. To není o všeobecném očekávání, ale že deset lidí udělalo tu samou věc a jeden výsledek se kategoricky lišil - a jeho autor měl dost soudnosti na to, aby pátral "proč" - a to i u sebe.
Osobně se mi také nelíbí náhlé měnění metodiky, ale oni prostě fakt neměli jinou možnost, pokud své výsledky chtějí prohlašovat za relevantní.
Že v Inteláckém procesoru NEBO přesném měření času bude asi něco shnilého, to je ale očividné.
A proč se tedy výsledky nelišily dříve? Rozumím tomu jednoduchému vysvětlení, to ale klade další, daleko závažnější otázky, nemyslíš?
Mně osobně to je celkem jedno, já mám svůj názor (a své testy, byť ty jistě nejsou tak kvalitní), který jeden výsledek testů nemůže nijak ovlivnit (stejně tak to neudělají výsledky z PCT nebo DDW).
To proč se výsledky nelišili dříve tam taky vysvětlují. Protože meltdown a spectre záplaty...
To je ovšem pouze odhad, byť pravděpodobný. Navíc jsme zase u toho, že "když to najednou nevychází, změníme metodu měření."
Nic proti, je to relevantní, když je to takto default, ale pak zase nechápu, proč předtím měřili v nastavení, který nikdo normálně nepoužívá? Samotné patche na Meltdown/Spectre byly prohlášeny za pro běžné použití neproblematické, a teď zase tohle...
Není to odhad, měřili to s i bez záplat. Se záplatami to mělo výrazně větší dopad.
Podle článků o záplatách na záplaty na záplaty na Meltdown/Spectre atd. bych o bezproblémovosti pochyboval. Ale jak jinak o nich můžou mluvit? Jakože párkrát dostal Intel/MS pokutu za likvidaci konkurence a tak se zastyděli a budou už jen čestní a budou říkat, že záplaty jsou pořád problém? To je naivní představa.
Ej TYNYT stary Ajťak :) Des kupovat ku ATI 6450 , nejaky ultra zlepenej Ryzen ?
Tynyte, fundemantalni fandove Intelu uz tak trpi, misto toho, aby meli radost, ze maji konecne na vyber ;) a rozpada se jim jejich virtualni modra modla. Mej s nemi taky trochu soucit. Vzdyt jsou toho plne diskusni fora :))
Vem si, ze kdyz se takovy spravy Intel fanboy podiva treba na tenhle test a zjisti, ze ten procesor AMD, ktery preci nemuze byt zadnou konkurenci (viz prohlaseni Intelu), ma vyssi fps nez 8700k..tak ho jebne ;)
https://www.computerbase.de/2018-04/ryzen-2600-2700-fortnite-pubg-overwa...
mrk mrk ;)
Jsou tam i uklidňující obrázky: https://www.computerbase.de/2018-04/ryzen-2600-2700-fortnite-pubg-overwa...
mrk mrk ;)
Když považuji původní test Anandtechu za chybný a jsem rád, že to přetestují, jsem zřejmě fundamentální fanda Intelu. To je dobré vědět.
jj, dříve se nějak takto podobně ujištovali, že Země je placatá (nebo Náckové zase o tom, že Země je dutá) :-) Chtít se dostat k meritu věci, to je přece fuj, to chce myšlení a vůbec, máme tu krásně vystavěnou nějakou teorii a ono nám ji to bourá. Na hranici s heretikem!
Až za mnou přijde kamarád a řekne "Poslechni, chtěl jsem supr herní dělo, cos mi to postavil? Si říkal, že Ryzen je lepší, ale Fanda má stejnej komp s Intelem a má lepší výsledky než já!", mám mu na to říct "To je Fandova chyba, nemá vynucený HPET"?
No a to je další docela demagogický výrok. Kromě toho, že se výkony v hrách liší řekněme maximálně o 10-15% v nejhorších případech, tak se jedná o hodnoty (typicky) daleko za běžnou obnovovací frekvecí, tudíž rozdíl je znatelný pouze v pindíkoporovnávači (alias benchmarku). Dále je vždy třeba říct, k čemu má PC sloužit, protože existují hry, které těží z více jader a existují hry, které běhají dobře jen na vysoko taktovaném dvoujádru.
Já počítače stavím a vždycky mě docela vytočí takové ty hlášky "jedině intel/nvidia" protože jsem stavěl vždy na tom, co bylo výhodné a mělo nějaký výhled do budoucna. Spálil jsem se s Haswellem, který, zejména v K-čkových modelech po několika letech začal topit jako kamna a nic mě nepřesvědčí, že stejný osud nestihne i Kaby a Coffee. Proti tomu můj Sandy jede už x-tým rokem bez potíží. A BFU tohle neřeší, protože netuší, a řešit začne až za tři roky, až když to přestane fungovat.
Jestli dám přednost aktuálnímu výkonu, možnému odhadovanému budoucímu výkonu, provozním vlastnostem nebo jiným kriteriím, to už je moje věc. K rozhodování potřebuji informace. Výkon, teploty, spotřebu atd. Test s HPET mi výkon neřekne, stejně jako většině lidí, protože jej standardně nemáme vynucený. Chápu, že jej Anandtech využíval k testování. Chápu, že podmínky byly pro všechny platformy stejné. Nevím, jestli to způsobily záplaty Spectre/Meltdown, nebo jestli bylo ovlivněné měření už dřív. Ale mají dál pokračovat beze změny s tím, že jejich výsledky budou směrodatné pro malou část lidí?
Ale vždyť oni se k podstatě věci chtěli dostat a dostali. Si fakt trošku mimo, tak jako já jsem někdy mimo s napadáním objektivnosti některých článků nebo jejích částí. Každý objektivní IT fanda přeci chce silné AMD ale i Intel, silnou Nvidii apod. Chce konkurenci a ne monopol aby jsme měli v dobách upgradů co nejlepší ceny a výběr... Nic není černobílé...
Možná jsem mimo. Možná sleduju tyhle IT šarvátky už moc dlouho a slyším trávu růst, ale tahle souhra náhod mi prostě nesedí.
Co se týká silné konkurence, tak s tím naprosto souhlasím. Zejména když si člověk uvědomí, kdo je "moloch" a kdo malý výrobce.
Tak s tím "molochem" taky souhlasím, ale to je zase jen výsledek lidské činnosti a intelektu. Taky máš např. obrovské a malé státy. Takže ten "moloch" tam nevnímám negativně, ale jenom jako fakt. Buďme rádi, že máme dravou konkurenci, aspoň v tady tomhle odvětví, a regulace na to, aby nevznikl monopol na úkor zákazníka/spotřebitele...
Na jednej strane pozitívny na druhejnstrane negatívny darček na dnešný deň.
Tak jedine happy birthday
1st May 1969
AMD Advanced Micro Devices is founded
http://www.computinghistory.org.uk/det/5944/AMD-Advanced-Micro-Devices-i...
Nevim jestli jsem to prelouskal spravne, ale v clanku se mluvilo o hpet prepinatku na desce a potom o hpet prepinatku ve widlich a defaultne ten hpet na desce je aktivni jen tehdy, pokud to widle vyzaduji, coz treba vyzaduji u ryzenu, pokud si nainstalujete ryzen master utility, coz v podstate udela skoro kazdy. Takze vlastne u ryzenu je to aktivni porad, kdezto u intelu si podobnou vec instaluje malokdo a spis taktuje pres desku.
Zajímavý, jak selektivně vybíráš informace. V zásadě se dá říct, že se jedná o velký problém u Intelu a malý u AMD. A ty si vybereš zrovna AMD. HPET totiž ve Windows zapne skoro každá taktovací utilita. Dokonce i utility na přetaktovaný GPU.
No u AMD byl rozdil 1% v produktivite, takze se spis da rict, ze je to velky problem u intelu a to je cele. Co jsem tak cetl, tak jsou to v zasade utility k hw vyzadujici restart po instalaci... nicmene zapnuty hpet ve windows jeste nezpusobi tenhle intel retard efekt
HPET v OS Windows odjakziva vypinam, davno pradavno som o tom cital, ze je to lepsie vypinat pre hraca :) ci je to pravda uz nemozem vediet ale predpokladam ze to pravda je kedze to aj tymto clankom potvrdzuje :)
V originálním článku je poměrně pěkně vysvětleno, jaké časovače se používali v prúběhu času a proč. Nejstarším zpúsobem měření času u PC je generátor na základní desce. Ten běží řádově na jednotkách KHz. To je na některé věci nedostačná přesnost a navíc čtení z něj není příliš rychlé. Proto byl u X86 architektury implementován časovač přímo do CPU - TSC(Time Stamp Counter). TSC však nepočítalo s vícejádrovými CPU, rúznými dynamickými změnami frekvence a pod. Proto přišlo HPET. To je u Intelu realizováno HW v chipsetu a dotaz na čas tak vyžaduje IO operaci(procesor se ptá po sběrnici chipsetu), která trvá několik set cyklú CPU. Oproti tomu dotaz na TSC je jediná instrukce. Nejnovější zpúsob je invariantní TSC (ITSC), tedy TSC, které na HW úrovni řeší problémy TSC se změnamy frekvence jednotlivých jader. Čtení z něj se opět provádí jedinou instrukcí.
Tyto věci víceméně zajímají spíše programátory než běžné uživatele. Pro uživatele pak úplně stačí, když si ve windows nebudou vynucovat HPET a nebudou si instalovat aplikace, které HPET ve windows aktivují.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.