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.
NO-X, si myslel něco jako 7640HS pro AM5?
aleluja už si ho idem stiahnuť, bo toto čo teraz mi botuje je pomalšie ako v minulim tisicroči, ked mi 7950 nabotuvava za každym vyše 30s je strašne...
Otestoval som a prdlais 30s len tak si huči ked zapnem po tom až začne štartovať, nabehne za 22s dokopi 52s štart do windowsu, pred tym mi PC bežne štartovali za 10-15s proste hruza žiadne zlepšenie :(
Tuto generaciu AMD biosi dodrbalo najhoršie za 25 rokov ...
Mě to taky startuje 52s, ale mě to nevadí, protože komp zapnu ráno, jdu na záchod a tak a pak to stejně běží celek den a pak to vypnu, jak jdu spát...tak mě těch 30s navíc nezabije, když to udělá pořádnej training pamětí a je to pak stabilní...
Prostě to působí blbě, když ti o 10 let starší PC startuje výrazně rychleji než to nejnovější a hodně drahé. Snad se aspoň někdy v budoucnu dozvíme, čím to přesně bylo, protože je to unikátní situace.
Ono je to blbý když ladíš bios ,jakmile máš vše nastaveno tak už jen zapneš komp a těch 20s navíc při jednou zapnutí není žádná hrůza. Podotýkám že mám B650 Asus.
S tím jsem si hrál na začátku hodně, to bylo možná trochu otravný, ale jakmile jsem to vyladil, tak už mě to netrápí, ale tento BIOS zkusím, jestli tam budu mít nějakej rozdíl...
Tak je to stejný, 52s při vypnutým Fast bootu a Memory Context Restore...
Ja to mam za cca 25s na AsRock B650 PG od stlacenia tlacitka po windows. Bios je stary cca 2 mesiace. A nove AsRock to maju i za 16s. https://youtu.be/ekeTA1rds1s?t=459
Ja mam od Asus 670E plus WIFI, ked som kupoval ina možnosť nebola, aj na ňu som čakal 3 tyždne.
tie 650 očividne urobili lepšie BIOSi.
proste 52s a potom už je to bez problemov len ten štart. Určite to bude nejaka kravina, ale stale to neodladili.
Čtu si tyhle nářky a nechápu to. Jako jasně, taky mi Windows 11 na mým notebooku s Ryzenem 7 5800H (Lenovo Legion 5 Pro) nabíhaj 20 - 30 sekund, ale to neřeším, protože se to děje jednou za čas, když je potřeba restart, což jsou v rámci aktualizací OS časové drobné. Jinak notebook standardně hibernuju a to je pak od zmáčknutí tlačítka asi 10 sekund do přihlašovací obrazovky a to je imho OK.
Kdyby AM5 vydali o čtvrt roku později, tak se nejen že vůbec nic nestane, ale ještě vydělají víc na serverech a zlepší image AM5 i samotného AMD v podobě věčného vydavatele nedodělků. Tohleto co předvádí AMD je tolerovatelné na úrovni nějakého startupu a ne zavedené společnosti řízené inteligentními lidmi. Lisa je blbka co těží z existence ještě větších blbců v Intelu.
Předpokládám, že BIOSy jsou nepříliš rozsáhlý SW (max. 16 MB) psaný v céčku nadprůměrně dobře placenými programátory s dlouhatánskou praxí a specializací právě jen na BIOSy, přičemž větší část práce je spíše rutinního charakteru. Pokud je výsledkem taková chyba a odstranění trvá tak dlouho, tak tu něco hodně smrdí (a já to nejsem).
Pane vy jste slušný idiot....
Argumenty by nebyly? Rád se nechám poučit od zkušených céčkařů. Vím, že C++ je v rozsáhlejších věcech peklo, ale čisté C pod 20 MB?
no tys taky k tem svejm poznatkum zadny argumenty nepridal.. ukaz mi firmu, co ma bezproblemovej hardware.. at apple, samsung, nVidie, Intel.. vsichni maj vetsi nebo mensi prusery..
Apple nedělá chyby.
Think Different
Jó srandičky, ale já si neumím představit vydání nějakého nového jabka, které bude startovat viditelně déle než předchůdce, s řešením až po půl roce - to by ředitel skončil a pravděpodobně i s žalobou na krku. U Intelu si to aspoň umím představit.
Tak to by mě samotného zajímalo:
1. Který ředitel skončil za bentgate.
2. Který ředitel skončil za umírající fotomoduly iP6/7/XS na motorkách.
3. Který ředitel skončil za brutální glow iPad Pro.
4. Který ředitel skončil za kauzu baterií a zpomalování iP 6/6S/7
5. Který ředitel skončil za rychlé opotřebení pájených SSD na M1 Mac.
6. Který ředitel skončil za mizerné zabezpečení Mac OS, které kulminovalo tím, že systémy s Mac OS byly terčem 2× vyšší množství útoků než systémy s Windows.
7. Který ředitel skončil za explodující baterie MacBook Pro 15″.
8. Který ředitel skončil za to, že Apple nelegálně používal software Qualcommu.
9. Který ředitel skončil za problémy s dotykovým rozhraním iPad Pro.
10. Který ředitel skončil za blikání obrazovky MacBook Pro.
Spousta těch bodů se snaží naznačit, že to AMD udělalo úmyslně? Protože jinak je zbytečné vypisovat příklady co z ředitelů jabka dělají šmejdy, ale ne debily. V budoucnu explodující akumulátor by odhalil jen ředitel s nadpřirozenými schopnostmi a je tudíž dost divné to uvádět jako vhodný argument. Bezpečnost SW to samé - on je totiž OS podstatně rozsáhlejší než nějaký debilní BIOS, tudíž zajistit jeho skorodokonalost je 1000x těžší.
Bentgate je klasický a široce rozšířený příběh poddimenzovávání výrobků a nejde to označit za zjevnou vadu - každý výrobce si může zvolit tuhost svého výrobku jak chce a sledovat jestli mu to u zákazníků projde. Obecně tahle chyba AMD nemá s HW/SW kurvítky a určitou krátkozrakostí vedení Applu vůbec nic společného.
Ne. Spousta těch bodů se snaží naznačit, že za daleko větší problémy, které nikdy nebyly plně vyřešeny a zásadně omezovaly použitelnost zařízení, Apple žádného ředitele neodvolal. Apple odvolal ředitele za problém se zařízením jedinkrát, šlo o kauzu antennagate.
Velmi rychle si v Applu uvědomili, že kdyby kvůli každé podobné kauze měli odvolávat ředitele, tak za pár let nebude mít Apple kdo řídit. O něco později si pak v Applu uvědomili, že vyhazováním schopných ředitelů za bugy zařízení servírují tyto schopné lidi konkurenci. Právě to se stalo s Markem Papermasterem, kterého obratem najala AMD, do níž přivedl lidi jako Jim Keller a Lisa Su, v důsledku čehož je nyní AMD na poli mobilního high-endu jedním z největších konkurentů Applu.
AMD dela pocitace? To jsem nevedel. A ktery pocitac AMD startuje pomaleji, nez jeho predesla verze?
Pane, neviem ako si predstavujete objem zdrojakov, ktore vygeneruju 16MB blob. Moj hruby odhad je, ze su to statisice riadkov cisteho kodu + komentare + hlavicky. Navyse sa tu bavime o DDR5, ktore zasadne menia hru:
https://www.cnews.cz/pameti-ddr5-detaily-az-8400mhz-zlepseni-vykon-ochra...
A teď si představte, že Intel zvládl i kombinaci DDR4/DDR5. Zde se přeci nebavíme o vytvoření něčeho, ale nalezení zjevné chyby v něčem.
Co si představuješ pod tím, co nazýváš zjevnou chybou?
Jako, že třeba "zbytečně" důkladně testovali paměti?
Zjevná chyba je samotná příliš dlouhá doba bootování, kterou v AMD museli objevit ještě před vydáním v září.
S výmluvou na důkladné testování pamětí bych byl hodně opatrný.
Memory test bylo to první, co se při bootu začalo přeskakovat, jakmile velikost paměti trochu narostla.
Kde vidíš problém? V BIOSU to bude defaultně vypnuté a kdo bude chtít či potřebovat větší jistotu, tak si to zapne. Kromě toho to asi nebude ten hlavní problém, když Intel startuje lépe.
rychleji nemusí znamenat lépe.
Intel byl v lecčems rychlejší, než se ukázalo, že ošulil bezpečnost.
Tento komentár mi pripomenul starý vtip
"Proč je pentium rychlejší než 486? Protože 486 výsledky počítá, pentium je odhaduje!"
Či to nebude rovnaké "riešenie" aj v tomto prípade. :)
Intel nezvladl mechanicky zajisteni procesoru v socketu, to mi prijde daleko vetsi prohresek nez pomalejsi boot, ktery se muze casem zrychlit. Narovnat Aldera bych asi nedoporucoval :-)
O ohýbání většina zákazníků neví a jako správné kurvítko se projeví až později. Start 20 vs 60 sekund, to už BFU vnímá jako že má dělo nebo šneka.
BFU ví prd, jak věci fungují. Co bych ocenil, je test paměti u nové sestavy, po HW změně, po změně nastavení v BIOS, nebo po předchozím pádu OS. Možnost ručního puštění při bootu je s ohledem na rychlost spíš hypotetická, ale pokud by měla svou klávesovou zkratku jako vstup do nastavení biosu, pak by to šlo. Jinak by systém měl bootovat rychle, pak by si nikdo neztěžoval. Ale lidem, co ví, proč se to děje, by to vadit nemuselo. Start počítače s výkonem jako takovým moc nesouvisí, to ale BFU neví.
To je mylná představa. Binárky z C jsou naopak menší než z C++. C++ přidává do výsledného programu více balastu pro standartní knihovnu, RTTI atd. To znamená, že pro 20MB binárku v C je většinou potřeba více řádek kódu než pro C++. A 20 MB je poměrně dost. Uvedu příklady velikostí binárek u mně na notebooku.
gcc 13 (GNU překladač) - 1MB
mariadb (SQL server) - 5MB
gimp (grafický editor) - 10MB
Linuxové jádro - 111MB (komprimovaný 15MB).
Něco je v C++ něco v C a využívá i další moduly, takže nevím kolik řádků kódu to je, ale 20MB v C nemusí znamenat jen nějakou utilitku.
Proc by vetsi projekt v C++ mel byt peklo? Pokud ma program dobrou strukturu a programatori nejsou prasata, tak na velikosti projektu v podstate nezalezi....
Neměl bych tak přehnané nároky na lidi. Dneska už se běžně uznává (firmy i jednotlivci), že C++ byl přešlap, protože lidem nesedí. Víc se potí, častěji si trhají vlasy a jsou hnusný na ostatní. Je jedno jak to kdo formuluje, ale realita je taková, že i ti co C zbožnují, tak o C++ nemluví hezky a to je prosím skupina hardcore programátorů co těmi nejrozšířenějšími jazyky opovrhuje. Jakpak se bude na C++ tvářit normální-průměrný programátor je lehké odvodit.
Ja teda v C a C++ delal neco naposledy jeste na fakulte, ale pokud si dobre pamatuji, tak C++ byla OO verze C-cka. Jak znamo OOP prinasi temer vzcy nejaky "code overhead" protoze napr. tvorbou obecnejsich objektu, vyuzitelnych jinde a ruznyma jinyma technikama, dochazi automaticky k bobtnani vysledneho kodu. Nicmene to neni pak nic jeste proti pouzivani ruznych frameworku postavenych pak na OO. Tam to teprve zacne bobtnat.
Asi jsem naivní, ale vždy jsem měl pocit, že BIOS by měl být kombinací kódu v C a samotných utilit v něčem na ještě nižší úrovni kvůli rychlosti.
Ona ta efektivita kódu v BIOSu není nijak důležitá, protože se využívá v zásadě jen při bootu. Důležité je, aby se ten kód vypořádal se všemi možnými zařízeními, která mohou byt připojená, aby se ten boot mohl provést a nahrály se vlastní (efektivní) ovladače.
Nezapomnělo se na řízení napájení CPU, taktování CPU, řízení ventilátorů, TPM...?
Muze to byt kombinace assembleru a nejakeho vyssiho jazyka, treba C, nebo klidne i C++.
V cem pisou BIOS, to opravdu netusim
Prave naopak, kdyz pouzijes OOP, tak mas mnohem mene zdrojoveho kodu a kod je mnohem prehlednejsi, nez v C, pokud neni napsany prasecky.
Ale i v C++ muzes psat v podstate jako v C s efektivitou kodu, jako ma C. A s dobrym prekladacem to bude temer stejne, jako kdyby to bylo v assembleru. Ono jde o to, ze assembleru se pisi prevazne veci, ktere nejdou napsat ve vyssich jazycich, protoze na to nemaji vyrazove prostredky....
Prave naopak, kdyz pouzijes OOP, tak mas mnohem mene zdrojoveho kodu a kod je mnohem prehlednejsi, nez v C, pokud neni napsany prasecky.
.. sorry ale to neni principilene pravda. Uz jen tim, ze kdyz definujes typove nejakou tridu/objekt musis napsat nebo generovat construktor te tridy/objektu a dale jeho metodu na jeji zanik. Generujes pro nej nejake 'vnitrni' promenne, konstatnty, atd. To samo o sobe je kod navic a ta trida/objekt jeste nenapsala ani "Hallo world". Dalsi vec je, ze si pridedis tridy (zalezi jak jsou ty knihovny napsane, nekde dedis hodne, nekde ne) a pouzijes napr z 20 metod te tridy napr jen jednu. Kdyz by jsi si na to napsal vlastni proceduru, tak tech 19 dalsich metod vubec ani ve vyslednem kodu nebude, atd. ok, muzes linkovat knihovny i bez OO, ale s OO ten kod bobtna mnohem rychlejsi. A jak jsem psal, nejvetsi 'pruser' co se tyce bobtnani jsou ruzne typy frameworku a "typologii" programovani. Je to neco jako "excell", pouzivas 10 'prikazu' ale cely excell jich ma treba 1000, kdyz to hodne zjendusim laicky.
Ja delam v ruznych OO 20+ let, takze si myuslim, ze o OOP neco trosku vim. A ono vicemene jina cesta pro slozite veci dneska ani neni mozna, ale je to vzdycky neco na neco.
Assembler sel vzdycky mimo mne jako 'low level' jazyk.
Nechápu jednu věc. Pokud nepotřebuji grafický výstup (ano chápu obecné objekty v rámci struktury programu) proč nestačí klasicky funkce a procedury? Pro jednoduchý program. A přiznávám, učil jsem se na Pascalu.
Na to by existovala cela knihovna jako odpoved :)
OOP ma svoje vyhody, dam Vam priklad napriklad z databazi. Mate relacni databazi s tabulkou Clovek. Pokud Vam dany 'framework' umozni jednotlive zaznamy te tabulky nahlizet jako objekty, tak s tim muzete 'vicemene' nakladat uplne stejne jako s nejakou interni datovou strukturou. Mate tabulku clovek, vytahnete si jeden zazanam a zavolate si na ni metodu/zpravu "jmeno" treba takto: clovek.jmeno a mate to. Muzete mu definovat treba metodu "vek" tim, ze kdyz znate datum narozeni, ktery je v tom zazanmu ulozen, tak zavolanim clovek.vek a vrati vam hodnotu, kterou by jste jinak musel delat jako treba stored proceduru a davat ji jako parametr cely zaznam nebo jen to datum, nebo to resit treba jinak. Je to jednoduse pohodlnejsi a svym zpusobem jednodussi , prehlednejsi a logictejsi. Tim nerikam, ze je jednodussi to vzdy dobre naprogramovat :))
To je jen jednoduchy priklad. Principielne muzete vsechno delat bud OOP nebo proceduralne, zalezi na Vas. OOP vam treba umoznuje mit spojenou dohromady "logiku" s "daty"(promennymi) v jeden logicky-funkcni celek
Ano, ale v čem je výhoda pro malý program typu třeba zrovna BIOS, který jen umožní nastavení hodnot formou výběru či přímého zadání, u té grafické části to je jasné, i když to uměl i starý Turbo Pascal. Jiný příklad, třeba program který jen zpracovává datový proud mezi dvěma programy a žádnou grafický ani textový výstup nemá, jen počítá data.
"Ano, ale v čem je výhoda pro malý program typu třeba zrovna BIOS, "
.. nevim. Mozna maji nejaky "prototyping" udelany v OOP a ten pak jednoduseji diky tomu upravi. Ale to jen hadam.
Napise se genericky interface a podrobnosti pak resi objekty pro jednotlive rodiny procesoru, jednotlive procesory, steppingy procesoru, .... A totez pro cipsety, pripadne RAM, atd....
Tedy nevim, jak to delaji, jen nahazuji, jak by se to dalo objektove delat.
Jde o to, ze kdyz by pribyl novy HW, tak se doprogramuje jen, co je pro nej specificke/jine a zbytek by se zdedil od predchudcu. Kdyz by se neco opravovalo, tak by se to opravilo jen na jednom miste pro celou rodinu, nadrodinu. A tak podobne.
Jasne, kdyz budes v C++ psat helloworld, tak to napises bez dedeni a tak, bude to stejne radku kodu, jako v C. Nebudes to psat objektove.
Kdyz mas velky projekt, kde se dobre uplatni dedeni a sablony, tak na kodu vetsinou usetris a vysledna binarka muze byt i mensi nez v prasecky napsanem C.
Prave konstruktory a destruktory jsou dobrym prikladem, kdy casto usetris na kodu. O prehlednosti a bezpecnosti kodu nemluve... V C bys ten kod take musel napsat a to pri kazdem pouziti dane funkcnosti, tedy mnohokrat, pokud jde o nejakou knihovnu.
Vyhody a nevyhody OOP vs proceduralnimu programovani jsou podle typu prikladu. Ted se nebavim o tom, jak to zpracuje prekladac, protoze to je level, ktery sel vzdycky mimo mne. Na mensi veci, typicky na urovni skriptu nebo i vetsich skriptu, je OOP typicky overhead => zbytecny. Na vetsi projekty ma OOP samzorejme svuj smysl, protoze se ten kod da snadneji "designovat", je (nebo aspon muze byt) logictejsi, atd. Principielne jde ale vse napsat uplne stejne proceduralne. Jak jsem psal, problem OOP jsou pak ruzne "styly" nebo "systemy" programovani v OOP, kdy se vytvareji ruzna obecna rozhrani, obecne moznosti volani method na tridach, cele frameworky pro urcite funkcionality, atd, atd. Nerikam, ze to ma nema svuj smysl, ale jsou pripady, kdy se z toho vyuziva tak mala cast, ze ten vysledny kod je proste obrovsky a vyuzita funkcionalita minimlani. Ale dnes to uz jinak asi nejde, jedine, ze by si to clovek napsal od piky sam, coz je vetsinou nemozne.
Jasne, ale bavime se o C++. A i v nem se da psat jak proceduralne, tak objektove. Zalezi na slozitosti ulohy a programatorovi. A samozrejme pak treba na zamestnavateli, co vyzaduje....
Znam lidi, co psali v C++ ciste proceduralne. Neco jako streamy, operatory, dedeni, sablony, STL, vyjimky slo zcela mimo ne.... Ani new a delete nepouzivali.... A kopirovali data pomoci ceckovych rutin.....
I tak se da psat v C++. ;-)
Nevim, komu se zda ze, C++ byl preslap. V C++ muzes psat v podstate jako v C a vetsinu vlastnosti C++ nepouzivat, nebo pouzivat vsechny prvky jazyka, nebo neco mezi tim.
Neprehledny program se da napsat v kazdem jazyce. C++ je pohodovy jazyk, ktery umoznuje psat jak nizkourovnove veci jako treba drivery, tak vysoce abstraktni koncepty. Vse slusne strukturovane a prehledne.
Neznam jedineho slusneho programatora, ktery by si na C++ stezoval.
To jsou vážně perly.
"C++ je pohodovy jazyk" ULTRAMEGAHYPER LOL!!!
Jenom ze srandy - který jazyk tedy není pohodový? Assembler?
"Neznam jedineho slusneho programatora, ktery by si na C++ stezoval."
Tolik neslušných programátorů to C++ nakonec zabije...
Ty uz radsej nic nepis, lebo je to jedna chujovina za druhou. :) Hanba na tri zimy.
Který jazyk je méně pohodový než C++? Mohl si místo zbytečného výblitku odpovědět.
C je menej pohodovy. Ja pouzivam denne C i C++ uz 20 rokov a na rovnaku vec potrebujes v C viac riadkov. V strukture v C nemozes inicializovat premenne pri ich deklaracii co je otravne. Nemozes deklarovat premennu vo for cykle. Nemas konstruktor, co je niekedy tiez otravne.
C++ je zlozitejsi len ak si uchyl na OOP.
Takže nakonec kvůli využívání té jediné věci kvůli které C++ vzniklo (OOP) vynikne negativum toho jazyka. Je to bláznivé, ale s C++ je spojeno spousta šíleností, takže souhlasím.
Objektově orientované programování možná vzniklo při evoluci C, ale C++ přece není jediný jazyk, který ho umí.
Objektově orientované programování je o dost starší než C++. Jeden z prvních jazyků postavených na OOP byla Simula.
Bjarne Stroustrup používal Simulu, ale potřeboval výkon Céčka, tak problém vyřešil po svém. Vymyslel si OOP nadstavbu nad C (C with Objects), napsal překladač z "C with Objects" do C a publikoval to v rámci Bell Labs. Až o řadu let později to přejmenoval na C++.
Dokonce o tom všem napsal knížku "Design and Evolution of C++".
Pozn.: Jsem C++ developer, pracoval jsem řadu let v jedné firmě s Bjarnem, účastním se s ním pravidelných diskusí okolo novinek v C++ (včetně veselých historek ze standardizačního procesu) a můžu jen potvrdit, že je to mimořádně chytrý, pracovitý a skromný člověk, který ví co dělá.
To, jak C++ teď vypadá je výsledek spousty let práce, (bohužel) zpětné kompatibility s C (např. makra...), velké komunity snažící se protlačit svoje zájmy do standardu (Google, Microsoft...) a také snaha, aby miliardy již napsaných řádků programů v C++ byly i nadále podporované a plně funkční (až na drobnosti).
Jak pravil on sám: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
Omlouvám se za informačně prázdnou reakci. Hlasování +/- sice hovoří jasně, ale musím explicitně poděkovat za velmi zajímavý komentář. Historky ze zákulisí (a z první ruky) o průkopnících IT jsou vzácné a nečekal bych, že na ně narazím v diskuzi o nových BIOSech. Díky! :)
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
Zrovna tohle je hloupá a lehce vyvratitelná lež, takže bych ze Stroustrupa nedělal poloboha, když se takhle zbytečně ztrapní. Perfektně to ukazuje jeho omezenost, která se odráží v C++.
Programovací jazyky jsou tady pro lidi a ne naopak, jak si on myslí. Ono tu "skvělost" C++ krásně ukazuje fakt, že ani dnes nedokázalo v používání výrazně porazit C, což je dost zvláštní...
OOP naopak veci zjednodusuje ak sa pouziva s rozumom.
Superpočítače stále programují ve Fortranu a ten OOP neumí. Bude to hodně o konkrétním jazyku a kompilátoru.
Počítačům je úplně jedno v čem je program napsaný. Zpracovávají strojové instrukce. Můžete je předem vygenerovat jak ve Fortranu, C, C++ nebo i za běhu (JIT) v Javě, C#, nebo prostě kód interpretovat: opět Java, Python, Perl, ...
Osobně by mě zajímalo kdo ještě programuje současné (super)počítače ve Fortranu. Matematici? Strojaři? Lidi zvyklí na osvědčené desítky let staré nástroje a knihovny? Za 30 let praxe jsem ještě ani jednoho nepotkal (nebo se tím nechlubil). Podobné je to i s COBOLem.
Obvykle vědci, ti chtějí snadno napsat matematické vzorce a ne se učit programování.
Když jsem byl ještě v akademické sféře, tak okolní výzkumníci používali zejména Matlab. Velmi silný a relativně přístupný nástroj pro vědce. Zápis vzorců byl poměrně intuitivní (řekl bych že snazší než ve Fortranu). Já jsem se s Matlabem osobně setkal v oboru zpracování signálů (DSP).
Na druhou stranu chápu, že jedna konkrétní zkušenost nemůže pokrýt rozmanitost celého světa.
Take bych rekl, ze akademici pouzivaji spise Matlab, nebo neco podobneho. On Matlab umoznuje vygenerovani kodu v C (nebo mozna C++).
Ale dokazi si predstavit, ze jsou ve FORTRANu tuny kodu... Kdo by to prepisoval? Je take jednoduchy, takze jde mozna lepe paralelizovat....
Nebavím se o akademicích, ale programování na superpočítače. Chápu, že Fortran je starý, ale co vím, stále se vyvíjí. A to programování v něm se táhne od prvních superpočítačů co ještě konstruoval sám pan Seymour Cray. Ale taky je pravda, že americké úřady mají spoustu starých systémů IBM na kterých běží ve starém Fortranu programy a opravdu na to nikdo nechce sahat aby to předělal. To jsou ale dost rozdílné příklady.
Akademici take programuji pro superpocitace..... A superpocitace tu jsou velmi dlouho a tehdy nebyly modernejsi jazyky, nez FORTRAN..... A od te doby se pouziti FORTRANu na nich muze tahnout.....
Navic, FORTRAN byl postupne rozsirovan, takze ma i podporu paralelizace a objektoveho programovani... A jak jsem koukal ma nektere pekne veci, ktere se hodi pri numerickych vypoctech....
https://cs.wikipedia.org/wiki/Fortran
Mohou byt hromady kodu psane ve FORTRANu, ktere nikdo nechce prepsat do jineho jazyka. Ja lidi, co programuji ve FORTRANu poznal, ale vetsina z nich uz neni mezi nami. I COBOListy jsem poznal.
Ale ja zazil jeste derne stitky a pasky....
Pamatuju si jak jsem v 90tých letech předělával program z fortranu do turbopascalu pro jednoho profesora. A nepřišlo mi to nijak složitý se v tom vyznat a to i přesto že jsem se fortran nikdy neučil..
Právě na to byl udělaný Fortran.
Vyznat se v tom nebylo složitý, ale některé věci se dost blbě přepisovaly. například ty GO TO konstrukce, nebo pokud byly použity COMPLEX proměnné.
Nevedel jsem to, ale nejnovejsi standard FORTRANu ma OOP.
FORTRAN si asi prosel podobny vyvoj jako C, jen se neprejmenoval na C++.
S C++ je mozna spojeno mnoho silenosti, ale ty silenosti jsou efektivni. Kdybych pouzil primer, tak C je neco jako zlomky, trojclenka, goniometricke a logaritmicke funkce v matematice, C++ pridava derivace, integraly, rotace, divergence, funkcionaly, ......
C++ umoznuje mnohem vice abstrakce, nez C. Nekomu to muze pripadat silene, stejne jako prodavacce z Lidlu asi nepojedou derivace a integraly a mnohym vysokoskolakum ani rotace, divergence, funkcionaly, linearni algebra, grafy.
Matematika je mnohonasobne silenejsi, nez C++.
Mene pohodove nez C jsou treba C, BASIC, ... A mnoho dalsich, ktere se z mnoha duvodu neprosadily ve vetsim meritku.
Zrovna Basic je špatný příklad, chodily na něm všechny osmibity a část šestnáctibitů, co vím tak byl i součástí DOSu. U CP/M si nejsem jistý. Na všechny Amigy a další z toho těžily. Běžně byl napálený v ROM těch počítačů. Kdo ví, jak by bez Basicu vypadala ta doba.
Nějaký Basic pod CP/M určitě byl, my jsme používali Pascal a Asembler, ale jinak tam podle http://www.retroarchive.org/cpm/lang/lang.htm byl i Fortran a Cobol.
Joo, psal jsem v nem pro vojaky evidenci brancu....
To, ze jazyk pouzivaly prevazne domaci pocitace neznamena, ze to nebyla dost velka haluz. BASIC snad nikdy nebyl standardizovany, kod tedy nebyl prenositelny. A to casto ani v ramci jednoho pocitace. Kazdy vyrobce si vytvoril vlastni verzi. Nejaky serioznejsi program se v tom snad ani nedal napsat...
To ano, někdy to bylo zajímavé s přenosy programů. Ale nějaké standardy byly, spíš se jich výrobci mikropočítačů nedrželi.
Pascal a podobné mají pevnou strukturu, to v Céčku není. Pamatuji, že když začínal a toto, co popisuji bylo vyzkoušeno, kompilátor neměl debugger vůbec žádnou kontrolu, takže doslova šlo na klávesnici namačkat náhodný řádek a kompilátor to schroustal. Proto zpočátku mezi váženými programátory byl C přehlížen.
No, ti co C zboznuji nikdy nepokrocili k tomu, aby se naucili C++. Ano C++, pokud se je clovek ma naucit cele vcetne knihoven je podstatne narocnejsi, nez C. Ovsem v C++ napises vetsi kod rychleji a bezpecneji nez v C. A vysledna binarka bude podobne velka, nebo i mensi. Delal jsem v C a presel na C++. A jedno vim jiste, delat pouze v C bych rozhodne nechtel.
Assemblerista se bude usklibat nad C....
Píšu ve svém zaměstnání vysoce výkonný kód v C++ a když ho potřebuju ještě trochu víc zoptimalizovat, tak ho disassembluju, najdu zbytečnosti a složitosti ve strojovém kódu (a že jich je...), upravím zdroják v C++, přeložím, změřím výkon, disassembluju, a tak dokola...
Ano, jsem assemblerista, který píše assemblerové programy v C++ (dříve v C). :)
Tiez to tak robim pri optimalizacii. Priamo v assembleri som pisal len par krat, uz je to vyse 15 rokov.
Ja neoptimalizuji, nepotrebuji to. Ale prve kody jsem psal primo ve strojovem kodu CPU (prekladace nebyly), pak v assembleru, pak v nejakych vyssich jazycich a nakonec jsem zamrzl u C++. A k tomu homeopaticky SQL.
Viděl jsi někdy startovat server?
Problém je,. čo je obsahom tej zmeny, lebo ak to spôsobil test dynamického mikrokódu (napr. mikrokód pre Epyc optimalizuje výkon na server-ové aplikácie a mikrokód pre Ryzen optimalizuje výkon na desktop a mikrokód pre Threadripper je optimalizovaný na HEDT, či mikrokód pre Threadripper Pro je optimalizovaný pre Workstation a to je ešete iný mikrokód pre MS Windows a iný pre GNU/Linux a BSD). Dynamická zmena mikrokódu za behu podľa záťaže je super príprava na Zen5 a využije ju aj Ryzen 7950X3D a pradepodobne aj 7040 séria Ryzenov
U procesorů AMD je nyní pozdní nahrávání mikrokódu CPU považováno za bezpečné
David Ježek Dnes
AMD si oproti Intelu připisuje jedno další sympatické vedení. Pro oba výrobce x86 CPU dosud platilo, že Linux považuje nahrávání mikrokódu CPU za špinavou praktiku, která může kernel rozhodit a učinit nedůvěryhodným. Jediná přípustná praktika byla, že se mikrokód CPU nahraje standardně ještě před startem operačního systému, jak se sluší a patří. Nyní AMD ale hlásí, že práce jsou hotovy a na současných procesorech AMD lze považovat pozdní nahrávání mikrokódu CPU u již běžících linuxových systémů za důvěryhodné a bezpečné. Vše doprovází příslušný patch.
Patch, který do Linuxu zaslal Borislav Petkov z AMD, v jednoduchosti dělá to, že dosavadní praktiku, kdy pozdější nahrání mikrokódu označovalo systém za tainted, nyní platí jen pro x86 procesory Intel (či obecně ne-AMD procesory, abychom někomu nekřivdili).
https://www.root.cz/zpravicky/u-procesoru-amd-je-nyni-pozdni-nahravani-m...
AMD CPUs Are Safe For Late-Loading Microcode, Will No Longer Taint The Linux Kernel
AMD on 11 April 2023
So with this pending patch, the CPU microcode updating on late-loading will only trigger a kernel taint for non-AMD systems. Ideally though all CPU microcode updates should be early-loaded during boot time.
https://www.phoronix.com/news/AMD-Late-Loading-Microcode
Nejlevnejsi Ryzen 5 7600 stoji 250€ coz neni vubec spatna cena kdyz si uvedomime ze architektura Zen IV oproti Zen III pridava virtualne +4 jadra navic(kombinace IPC a ziskanych frekvenci) a iGPU, podobnou castku stoji jiz obstarozni Ryzen 7 5800X, co ale citelne AM5 chybi sou prave moderni APU(RNDA II+) nabizejici prave vyssi graficky vykon, mozna AMD nechce pro AM5 vydat generaci Rembrandt prave proto ze je jeste postavena na Zen III+, jednoduse ona chce pro tuhle platformu nabizet jen Zen IV a vys, pote vsak nechapu zpravu o priprave modelu Ryzen 5 6600G a Ryzen 7 6700G, co vim meli byt jiz v obchodech...(no-X).
"jednoduse ona chce pro tuhle platformu nabizet jen Zen IV a vys, pote vsak nechapu zpravu o priprave modelu Ryzen 5 6600G a Ryzen 7 6700G"
<= Buď pro desktop APU Rembrandt nebudou a nebo pro AM5, protože dosud neexistují informace o kombinaci APU Rembrandt + DDR4.
"Víme dvě podstatné věci. Rembrandt jsou určeny pro LPDDR5 či DDR5, zatímco o DDR4 nepadlo ani slovo. Je to logické, neboť DDR5 mohou oproti DDR4 nabídnout především vyšší celkovou propustnost, kterou ocení právě výkonnější integrované GPU, čili bez DDR5 by byla APU Rembrandt jen poloviční. Pak to ale znamená i to, že případné desktopové verze budou potřebovat už patici AM5 a ta by mohla dorazit někdy v druhé polovině roku společně s novými 5nm Ryzen 7000 "Raphael" generace Zen 4."
"Zatím není jasné také ani to, zda AMD vůbec bude mít v nabídce jako Intel přechodovou generaci podporující paměti DDR4 i DDR5, což by mohla být asi jedině právě generace Raphael." (10.1.2022)
<= No, dnes už je zřejmé, že pokud vůbec za přechodová generace někdy bude, tak to nebude Raphael, ale spíš APU Rembrandt ...
Když i teď restart a těsně přes minutu je černo, tak to teda dětské nemoci ještě zdaleka vyřešené nejsou :D
Ono to nebude až tak strašné
AMD Ryzen 7 7800X3D: Nejlepší herní procesor roku 2023? Zřejmě ano!
Z. Obermaier
Nejlevnější model řady Ryzen 7000 s 3D cache nabízí sice jen osm jader, k maximálnímu hernímu výkonu mu to ale jednoznačně stačí. Reálná herní spotřeba je navíc na úrovni nejúspornějších mobilních procesorů. Pro hráče absolutní bomba.
https://pctuning.cz/article/amd-ryzen-7-7800x3d-nejlepsi-herni-procesor-...
Paráda. Podle recenzí je pomalý boot jediná slabina ASUS ProArt X670E-CREATOR.
Jinak to je super deska co má podporu ECC.
AGESA 1.0.0.5 by obecně měla přinést podporu ECC pro všechny AM5. Ale záleží na výrobci MB jestli podporu nezavře.
Jestli AGESA 1.0.0.6 přidá rychlí boot a 48GB moduly, tak není o čem přemýšlet.
Nenachadzam slov. Len rozmyslam ci toto fenomenalne zrychlenie patri na prvu alebo druhu priecku tohto rebricka. https://ehistory.osu.edu/articles/greatest-inventions-past-1000-years
Takze na internet a miny, BFU zaplati odhadom okolo 700 EUR a ako bonus dostane minutovy boot time. :)
už druhé miesto toho rebríčka je hlúposť rovnako ako tvoj ehm.. príspevok
"Nové BIOSy pro AM5 přinesly 2× rychlejší boot"
Zrejme sa jedná len o prvý boot po zostavení PC. Včera som to skúsil na dvoch PC na ktorých išiel dať upgrade BIOSu a žiadne zrýchlenie sa nekonalo. A pokiaľ máte 128GB RAM je to poriadna osina v zadku :(
Sorry vážený, ale toto keby predviedol Intel, tak už organizujete verejné popravy.
"Sorry vážený, ale toto keby predviedol Intel, tak už organizujete verejné popravy."
To je přesně to co mě napadlo při čtení diskuze a obhajoby, že dlouhý boot je proto, aby pořádně otestovali paměť, nebo přirovnání k tomu vtipu o 486 a pentiu.
"Sorry vážený,"
.. cece, kdo vi kolik ma No-X hmotnost ;)
" Sorry vážený, ale toto keby predviedol Intel, tak už organizujete verejné popravy."
Suhlas, a to hovorim ako niekto, kto kupoval Intel CPU na domace pouzitie naposledy na prelome milenia. Ryzenov mam niekolko a sam som ich do sveta poslal este viac, ale AM5 je (este stale) vysmech zakaznikom v niekolkych urovniach (za mna najma cena, dostupnost a ponuka MB, masivny ubytok AM4 MB, + porodne bolesti (o ktorych pise clanok) este pol roka po vydani). Tazko najst rozumny dovod na upgrade aj napriek skvelym Zen4.
".. Sorry vážený, ale toto keby predviedol Intel, tak .."
to bude prezentováno jako "průmyslový standard".
Jako že už mi to se 4mi moduly, napoprvé či při přenastavení biosu, nebude startovat snad 10minut? Momentálně mi bootuji w11 nadvakrát (nepřišel jsme na to proč).
Zkusil jsem a dokonce jsem se odvážil opět zapnout u mých 4 modulu expo na zkoušku. No a jede to. Tak paráda. Pro ty co nevědí. Ryzeny 7000 mají uvedeno, že 4 moduly umí jen na základní frekvenci. Když jsem zkoušel drive jet 4 moduly na expo nastavení, chvíli to bylo ok, pak to padalo do bsod. Teď je to v pohodě. Zkoušel jsem i nějaké paměťové testy a drží to. Za mě teda cajk.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.