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.
Kdyby vyšel článek včera, tak bych ho považoval za vtip.
+1
Je to strasna moda s tema notebookama na hry.
Sice se asi najde clovek, ktery neco takoveho potrebuje, protoze vetsinu casu travi na cestach ovsem v nejake (mobilni) kancelari s privodem energie, protoze tyhle monstra se daji na baterku provozovat tak pul hodiny. Bude to ale vyjimecne. Vetsinou si to porizuji BFU, kteri by mohli mit na hrani normalni spickovy herni pocitac nebo konzoli, ale poridi si notebook a pak se divi, ze se jim to prehriva.
Ovsem je to kazdeho vec, jestli se nekdo chce trapit s obludnym hernim notasem, jeho rozhodnuti.
Co furt máte lidi s tema "notebookama na hry" normálního člověka nezajímá jestli je to označené na hry či na práci nebo cokoli jiného, zajímají ho parametry. A jelikož potřebuji NB nosit každý den do práce a z práce a chci, aby uměl i něco spočítat (a to jak doma tak v práci), tak v něm potřebuji, jak dobrej procesor , tak použitelnou grafiku a nechci za něj dát raketu. Že je označený jako "herní"? I kdyby byl označený jako "sexistické prasátko" tak to nehraje roli...
Sny muzes mit jake chces, to je ciste tva osobni vec. Realita je ovsem takova, ze i 65W "sumitko" v desktop PC je v notebooku totalni monstrum, ktere musis uchladit a pokud tu autor pise, ze notas vazi 2,6 kg, tak inteligentnimu cloveku musi byt jasne, ze chladic v notebooku neni zadna slava a ze ty vypocty neuchladi. Takze se to bude prehrivat.
Nebo si muzes koupit notas 5 kilovy, ktery bude chladit mnohem lepe, ale zase se pekne proneses.
Proste naroky, pozadavky, sny muzes mit zcela libovolne ale fyzika plati vzdycky stejne a na tebe se neohlizi! Smir se s tim. :-)
Mimochodem, taky by me bavil vykonny notas, ale misto toho jezdim na chalupu vlakem s kufrem s pocitacem (minitower). Monitor + klavesnici mam dvakrat, jednou doma, jednou na chalupe. Ver mi, ze nadsen z toho nejsem, ale proste moje naroky notas neda a rozhodl jsem se naroky nesnizovat a resim to takto.
Řešit to můžeš jak chceš. Pro někoho je lepším řešením obludný notebook, protože to holt potřebuje tahat i na místa, kde nemá stabilní pracoviště s monitorem a další nezbytnou bižutérií. Důvody jsou a budou různé. Nikdo netvrdí, že tvoje řešení je špatné. Špatné je, že se vysmíváš řešení a potřebám jiných uživatelů. Přitom na tom nezáleží, nikoho to nepoškozuje, tak proč se navážet do řešení, které zjevně nikoho nepoškozuje a naopak někomu vyhovuje (leda by měl někdo zásadní mindrák asi)?
Coze???
O tri komenty nahoru, prosim:
"Sice se asi najde clovek, ktery neco takoveho potrebuje, protoze vetsinu casu travi na cestach ovsem v nejake (mobilni) kancelari s privodem energie, protoze tyhle monstra se daji na baterku provozovat tak pul hodiny. Bude to ale vyjimecne."
Ano mezi takovým tím shazováním "strašná móda" a "BFU" :)
jediny BFU je tady RedMaX nebo jak se to individuum prave ted pise
To není pravda, je jich tu víc, ale momentálně mlčí.
Tak jeste jedou:
1. Vyjimecne jsou lide, co to potrebuji a musi pocitat s kompromisem, vykonu, ceny, opotrebeni.
2. Vetsinou si to porizuji BFU, kteri nechapou zaklady fyziky a pak breci, kdyz jim to po dvou letech chcipne.
"Vyjimecne jsou lide, co to potrebuji a musi pocitat s kompromisem"
Si spad z višně ne? Naprosto každý člověk musí u jakéhokoliv počítače počítat s nějakým kompromisem, natož u NB.....
"Kdyby vyšel článek včera, tak bych ho považoval za vtip"
Ale dneska je to realita.
Hustý :D Už aby AMD měla i nějakou grafiku k tomu, aby tam furt nemuseli cpát nV.
byť vývojár, idem do toho - konfigurácia GeForce 2060, 16c Ryzen 3950X, 32GBRAM, 1TB SSD za 2.377,00 € inkl. MwSt. zzgl. Versand ... dosť dobrá cena (keď to človek porovná s Lenovami a pod), otázna samozrejme kvalita chasi / klávesnice a pod
Vývojář čeho?
Developeri embedded SW, ktori obcas potrebuju s niecim on site, alebo do testovacieho labaku, na stand, kamkolvek a potrebuju tam upravovat software. Napriklad.
My mame presne z tohto dovodu laptopy a vykon mobilnych 4jadier intelu je smutny. Ak ta masina dokaze akukolvek formu docking station (co je pri takom pouziti tiez dolezite), tak aj keby stala 4k eur, tak sa na usetrenom case stravenom kompilaciou pomerne rychlo zaplati.
Tam vyuzijes 32vlaken pro kompilaci nejakeho embedded systemu a potrebujes sebou tahat 3kg potvoru s nabijeckou??
Generovanie zdrojakov OS z konfiguracie trva radovo niekolko minut, scasti je ten proces paralelizovany, scasti nie. Vysledkom je niekolko (desiatok MB) kodu, ktory treba skompilovat. Na latest shiniest 7th Gen mobile i7 to trva asi 8 minut. Controllery mame v projekte 4, takze full rebuild bez generovania zdrojakov zabere zhruba pol hodiny. S generovanim zdrojakov slabu 3/4 hodinku. Kvoli tomu ako su zdrojaky zorganizovane je bohuzial potreba full rebuildu castejsia, nez by bolo vitane.
Keby som taky cas tahal len potvoru s nabijackou. Ked som raz na letisku v Mnichove vylozil z vaku vsetok svoj HW pred bezpecnostnou kontrolou, teta bezpecacka len prehlasila "Kreiss Gott (alebo nieco take?)". Na taketo vylety so sebou tahas JTAG debugger/programator, CAN simulator, prepojovaciu kabelaz, laptop, nabijacku a za hrst licencnych donglov. Ak ides na testovacie stanovisko tak este jeden / dva / tri / styri debug controllery podla potreby. A dufas, ze tam kam ides sa ti ujde zvysny laboratorny zdroj.
Nebylo by jednodušší něco takového dělat dálkově? Nebo se to děje na místě, kde lišky dávají dobrou noc a připojení neexistuje?
Nie, pretoze:
1) mnozstvo dat, ktore sa prenasaju v takom pripade ide do radov desiatok MB a v zapadnej europe je to s internetom biedne. Aby rozumne fungoval debugger, treba navyse preniest aj debug symboly, co uz ide radovo do stovak MB. To moze byt na nejakom prasivom DSLku v zapadnom nemecku smutny zazitok.
2) Jedna sa o profi tooling, takze je to totalny odpad a polovica workflowu nejde automatizovat. Embedded obvetvie zo znacnej casti zije v 80. prinajlepsom 90. rokoch a razi retoriku Microsoftu, ze najlepsi kamarat vyvojara je mys a graficke klikatko. CI/CD je do znacnej miery bud pojem uplne neznamy, alebo preberany len v teoretickej rovine.
3) nejde len o kompilaciu samotnu. CAN simulator napriklad, ak sa zacne riadne pouzivat, moze kludne na posedenie spraskat 16 GB RAM.
No tak zvláště tu dvojku cítím s vámi, po zkušenostech s Tornadem a podobnými nesmysly. Upřímnou soustrast ale ohledně všech bodů.
Slovami frontmana Visaceho Zamku: je to peklooo, absolutni peklooo
embedded SW - tzn. něco jako Arduino nebo ESP32? S tím si taky občas hraju a zkompilováno je od minuty v jednom vlákně, do 15 sekund při využití všech vláken.
Tak hrát si můžeš s čím chceš, ale některé projekty mají statisíce řádků kódu. Ne každý vyvíjí embeded systémy na školních pomůckách. A nejde jenom o samotnou kompilaci, ale i odezvu IDE a nástrojů, které ten kód analyzují a pomáhají při vývoji. A tam ten Intel inside dost smutně kulhá na všechny 4 :/
A to je problém mít extra výkonnou mašinu někde v kanceláři a mít přenosnou ULV žiletku na které se přes RDP připojím, když potřebuju? Mám ten výkon pořád s sebou aniž bych musel tahat nějaký laptop narvazný zbytečným železem
Jenze pak budes nekde on-site bez moznosti pripojeni a vis kde ses...
No a on je tu este jeden aspekt firiem, ktore nie su primarne IT oriented. Ak ma mat developer dva pocitace - jeden nevykonny, ale prenosny a druhy neprenosny, ale vykonny, tak to je z pohladu menezmentu plytvanie prostriedkami. Vela menezerov tam je este z cias, ked sa vykresy kreslili pekne perom na papier a nedokaze si spocitat, kolko vykonnejsia masina dokaze usporit nakladov na personal tym, ze za nou necaka, atd.
> A to je problém mít extra výkonnou mašinu někde v kanceláři a mít přenosnou ULV žiletku na které se přes RDP připojím, když potřebuju
Ne, problem to neni. Problem je, ze 80% sveta ma nahovno internet.
Treba ja zkousel RDP na svoji pracovni masinu, 100Mb symetricky internet, pracovni masina ve stejnem meste, a pouzitelne to sice jakz takz je, ale ze bych na tom chtel pracovat hodiny, tak to nee. Ten lag je citit a cloveka to po par hodinach prestane bavit. A to jsem jeste v krajine co ma pomerne dobrej internet, takove Nemecko s jejich DSL je ciste peklo.
Tak v lidsky příčetných jazycích se statisíce řádků kompilují maximálně desítky sekund, a navíc jsou kompilátory inkrementální, takže změny trvají pod sekundu, úměrně jejich velikosti. Ale to, že v historii opakovaně zvítězilo programovací VHS, to je zase další problém.
Tak se jeste pochlub, jaky ze to jsou ty "lidsky pricetny jazyky". At se zasmejeme...
Většinou ty, které existovaly před rokem 1990 (s výjimkou C++, které bylo rozbité od začátku). Tedy ty před "postmoderními" prostředími, co jsou teď tak v módě. (Mírnou dnešní výjimkou je Go, ale to asi proto, že je odvozeno z Oberonu, který tehdy už existoval.)
Nejpouzivanejsim jazykem v embedded svete je C. Existovalo pred rokem 1990. A o kompilaci statisicu radku za par desitek sekund si muzeme nechat jen zdat.
Neřekl jsem, že *všechny* jazyky z doby před 1990 tam patří. Jen že pak se nějak přestaly objevovat, takže pokud člověk nějaký chce, musí sáhnout po dospělejších prostředích.
Pokud jde o pomalost kompilace céčka, tak to si musíte stěžovat autorům kompilátorů. Status quo zřejmě pro céčkaře není až tak bolestný, když se s těmi časy kompilace zas až tak neobtěžují pohnout. Pokud vím, třeba v Planu 9 se na to soustředili a na svou dobu se jim to docela povedlo, takže kdyby se chtělo, tak s tím céčkaři určitě něco zmůžou. Ale to se nejdřív musí chtít...
Stale cekam az uvedes priklad alespon jednoho z tech uzasnych jazyku o kterych si psal. Zatim furt jedes teorie o tom, ze nekde v minulosti nejaky jsou...
No já osobně používám Common Lisp, kde i celá kompilace prostředí (CCL i SBCL, která obě mají tak půlmilión řádků) sebou samým trvá asi tak půlminutu až minutu (na nepříliš rychlém stroji), a navíc běžný vývoj používá kompilaci inkrementální (typicky pod sekundu; nový build prostředí potřebuju pouze pokud vyjde nová verze).
Bohužel nemohu posloužit tím, jaká prostředí mohou použít uživatelé jiných jazyků, protože to si musejí vypátrat ti uživatelé sami.
<flame>
((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((
lisp bohuzial nie je rozumne pouzitelny beznymi human beings
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
</flame>
ref: https://toggl.com/blog/save-princess-8-programming-languages
No subsekundová doba kompilace mi přijde rozumně použitelná. ;) Obzvlášť když člověk třeba zjistí, že by mu v nějaké aplikaci bodlo nějaké vlastní, aplikačně specifické JITovaní.
Lidsky příčetné závorkové šílenství. Tak ten byl dobrej!
Pokud jde o dobu strávenou kompilací? Rozhodně! Samozřejmě to není jediná dobrá volba v tomhle směru. Někdo tu už třeba zmínil, že Delphi stále kompiluje pekelně rychle.
Kompilacny cas vsak zdaleka nie je jediny faktor. Pekelne rychlo kompiluje napriklad aj D. To v com C-cko a jeho rodina uspeli je, ze su vysoko univerzalnym jazykom a poskytuju zhruba rovnake pohodlie na prakticky akejkolvek architekture a pri akomkolvek pouziti. Nenesu si so sebou burden dynamicky typovanych jazykov, takze dynamicka alokacia pamate a rekurzia nie su potrebne, znesu aj beh na hardvardskej architekture, ale na druhej strane sa v tom istom jazyku da napisat aj mnohamilionSLOC aplikacia a vsetky tieto vyhody vyuzit.
Drtivá většina programů v C/C++ bude používat dynamickou alokaci paměti, protože neví předem, jak velká data bude potřebovat. I když chápu, že třeba v MISRA C to možná bude jinak, už vzhledem k aplikační oblasti. Takže tady není moc rozdíl ve většině (ne-embedded) případů. (Ovšem užitečné programy zcela nebo téměř bez alokací se dají psát i v CL.) Rekurze samozřejmě není potřebná ani v CL, není to Scheme (i když běžně používané kompilátory CL automaticky převádějí všechny tail cally na skoky, pokud není zvýšená úroveň ladění).
Ono to napisat samozrejme ide. Otazka je, ci tym clovek nieco vyhra. Pouzitim dynamicky typovaneho jazyka a naslednym nepouzitim dynamickeho typovania, lebo mam zakazane dynamicky pamat alokovat robim dost samoucelnu vec.
Ja osobne som teda dynamickemu typovaniu na chut neprisiel a dynamicke jazyky pouzivam len na quick and dirty veci. Uz u Pythonu je vidno, ze ked sa projekt dost rozlezie, dynamicke typovanie je dost na skodu veci a chce nemalu snahu udrzat veci pokope.
Ale dynamické typování a dynamická alokace jsou dvě různé věci. Není přeci nutné používat oboje najednou. Třeba C má jen to druhé.
Predpokladam, ze to prve bude bez aspon ciastocne dynamickej prace s pamatou len tazko realizovatelne. Specificky kvoli tomu, ze to v Lispe interne bude reprezentovane ako list.
edit: samozrejme, niektore aspekty dynamickeho typoveho systemu pouzit pojde, ine naopak vobec nie
Co bude interně reprezentované jako list?
(Mimochodem, jakákoli statická pracovní data lze v CL předalokovat z datových souborů nebo zdrojového kódu a v podobě jakkoli složitých datových struktur uložit do image programu v podobě, která nevyžaduje jejich dynamickou alokaci při spuštění z image - rozumné implementace budou image zavádět jeho mapováním z disku. Tedy v zásadě můžu docílit téhož, co v podobné situaci udělá Cčko.)
Dynamicky skonstruovany objekt
Pouze věci obsahující cons buňky mohou v CL být seznamy, kromě symbolu T, který je jediným seznamem, který neobsahuje cons buňku. Objekty nejsou seznamy, ani je interně neobsahují.
C, resp. moderne C++ sa sice nekompiluje hviezdne rychlo, ale kompilatory dost zasadne zrychlili. Presuvanie ton hackov z Boostu do jazyka tiez kompilaciu zrychluje, kedze sa prekladace nemusia prehryzat milionmi riadkov Boostovych headerov. Ked som este robil aplikacneho developera, tak cisto prechod na C++11 a z VS2012 na VS2015 zrychlil preklad asi o 50%. A da sa to zrychlit este viac.
Pri embedded je tak trocha problem, ze kdekolvek, kde je tem embedded aspon trocha "profi" je clovek zaseknuty na osekanom C89, alebo este horsie - MISRA C. To su potom zdrojakov snadno a rychle megabajty a megabajty a jeden embedded projekt moze mat s kludom 12 mega SLOC. Tak sa mi zda, ze tolko ukazoval audit na jednom inom projekte, ktory bol "polovicny" oproti nasmu. Z tych 12 mega SLOC, ktore boli v projekte (OS, SDK, toolkity) sa realne do binarky dostalo tak 3 mega.
Bohužel ty headery pořád dělají už jen analýzu C/C++ ve velkém projektu asymptoticky kvadratickou, aspoň pokud je mi známo. Čili člověk si sice možná trošku pomůže, ale fundamentální problém v návrhu celého prostředí tam zůstává. Kdyby se aspoň někdo obtěžoval udělat memoizující kompilátor (jelikož korektní kompilátor by měl být bezestavový, tedy opakovatelný transformační proces), tak se dá trocha času vyměnit za prostor, ale jak říkám, asi jsou na to céčkaři zvyklí, když jim to zas až tolik nevadí.
Take veci samozrejme dlhe roky (mozno aj desatrocia) existuju a su volitelne zapnutelne. Vela toolchainov umoznuje zapnut precompiled headre, ktore umoznia usetrit cas vyplytvany opakovanym parsovanim tych istych headerov, ktore su vlozene v polke projektu. C++17, mozno uz 14 podporuje moduly, kde nie je vobec potrebne kompilovat ziadne headre, potrebne informacie su sucastou modulu.
Vela casu sa da usetrit aj tym, ze sa headre nesprasia, ale trocha sa pri ich pisani rozmysla. To sa potom da z kompilacie vacsiny modulov vyhodit tak 80% headerov, ktore sa tam dostali len preto, ze niekto niekde nieco includol kvoli jednemu makru.
Ale precompiled headery jsou jen začátek. I zobrazení z AST do mezikódu, všechny optimalizační kroky nad mezikódem, a nakonec i generování kódu by všechno měly být memoizovatelné funkce. A přitom to vypadá, že vývoj kompilátorů dnes tíhne ke stále nákladnějším optimalizacím, kde by ten tlak na redukci neustále opakovaných identických operací nad identickými daty měl být znatelný.
"C++17, mozno uz 14 podporuje moduly, kde nie je vobec potrebne kompilovat ziadne headre, potrebne informacie su sucastou modulu."
Výborně, takže C++ konečně dohnalo Modulu-2 z 80. let. A přitom to trvalo jen třicet let. :)
Pravda je, ze vyvoj C++ bol na 20 rokov v podstate zmrazeny. Posledna velka zmena prisla v C++89 (templaty) a v podstate az do roku 2011 sa nic zasadne vyznamne neudialo. Microsoft napriklad nikdy ani C++89 plne nepodporoval (a dodnes asi nepodporuje).
To deprimovalo roznych ludi a preto moderne vlastnosti do C++ prudili cez 3rd party kniznice, ako napr. Boost. Samozrejme s nalezitym nevyhnutnym hnusom a spomalenim. To, co dnes v roznych reviziach C++ do toho jazyka prudi su jednak featury naprojektovane v Booste a jednak featury pretiahnute z jazyka D.
Spíš je smutnější to, že tohle neměli od začátku. Spoustu problémů si mohli ušetřit. Přeci to není fíčura, která se někde objevila po C++89. Tou dobou už existovala aspoň dvanáct let.
Ano, ono v podstate este relativne donedavna (10 rokov?) platilo, ze generovanie binarky v C ekosysteme su tri nezavisle kroky - preprocessing - kompilacia + optimalizacia a linkovanie. Prva vlastovka, ktora toto rozbila, boli precompiled headre, ktore umoznili do kompilacnej fazy vlozit predchrumanu podobu headerov. Stale to ale preprocessing a kompilaciu uplne neprepojilo, pretoze tento krok nebol obojsmerny. V podstate az s nabehom link-time optimalizacii sfuzoval krok kompilacie a linkovania, to podnietilo zasadnu zmenu architektury. Podpora modulov na tomto stavia, ale prepojenie taha este dalej, pretoze je v podstate treba prepojit semanticku reprezentaciu objektov vypadnutych z kompilacie (a potencialne linkovania) s kompilaciou ineho modulu a to cele este okorenit LTO.
Ano, pipeline kompilacie C-ckoveho programu je v podstate brutalne zastarala, co pridava na tom, ze je to pomale.
Jeden z našich projektů - necelé 2 Miliony LOC za 15s včetně linkování na Ryzen 2500U (Thinkpad E585) jako Target Win32, u Androidu tak velké projekty nemám a brzdí to hodne linker (cca 100 000 radku za 20s) - poslední verze Delphi z konce minulého roku
Ano, pascaloidní prostředí v tomhle směru právě historicky patřila do té příčetné skupiny. ;)
Jenze Delphi ma omezeny pouziti. Kompletni embedded vyvoj v tom moc delat nejde...
Já jsem myslel, že jde o rychlost kompilace, ale OK, tak FreePascal ma podobnou rychlost (jen o chlup pomalejší) kompilace a tam to jde. Je fakt, ze Delphi podporuje krome Windows z embedded pouze iOS, Android a Linux, ale to pro FreePascal neplatí, ten podporuje všechny myslitelné platformy. Takže argument neberu.
Vyzera to tak, ze bare metal programming je s FP stale dost exoticky vylet. 5 minut googlenia mi vratilo jediny - RasPi 3-specificky toolkit umoznujuci nieco take.
Jo, mne neprijde - https://wiki.freepascal.org/Lazarus_on_Raspberry_Pi
To sa bohuzial nerozumieme v pojmoch. Pod pojmom "bare metal" sa mysli, ze pod aplikaciou nie je bud vobec ziaden OS, alebo len velmi tenka vrstva HAL-u. Neexistuje process management, neexistuje resource management, neexistuje malloc(), rekurzia a preempcia su deklarativne zakazane.
Jo, az tak, tak to jedine asi https://wiki.freepascal.org/Ultibo_core
To je prave to jedine riesenie, ktore som vygooglil. Rasperry Pi je bohuzial ako zariadenie na embedded vyvoj dost nepouzitelna volba pre kohokolvek ineho nez hobbyistu. Nehovoriac o tom, ze svet embedded procesorovych architektur je divoky a rozmanity a ARM tam nie je nijako podstatny hrac.
"Pod pojmom "bare metal" sa mysli, ze pod aplikaciou nie je bud vobec ziaden OS, alebo len velmi tenka vrstva HAL-u"
Na tohle se z pascalovských jazyků ideálně hodí Oberon. :) Ten si dělá všechno svoje, koneckonců začal svůj život jako operační systém. Kompilace 10k řádků sebe sama v polovině 80. let na 20 MHz procesoru (NS32032): asi 15 sekund nebo tak nějak. Škoda, že dnes není populárnější. Ale na https://www.astrobe.com mají docela zajímavé prostředí pro bare-metal aplikace Oberonu.
Tak ono skompilovat 10k riadkov v C-cku tiez nebol problem ani na vsivavej 386tke. Problem nastal, ked sa k tym 10k riadkom prilepilo 1M riadkov z headerov. Pamatam si, ako som v Borland C++ for Windows nechal kompilit ukazkovu aplikaciu sachu a ako pocet riadkov zavratnou rychlostou narastol o 2-3 rady oproti tomu, na co som bol bezne zvyknuty a trvalo to hodiny. Tiez si pamatam, ze kompilacia TurboVision aplikacii v TP 7 na tom istom stroji nebola ziadna rychlostna slava, ale nepamatam si, ci som TurboVision buildoval aj s Turbo C++ alebo nie.
edit: Ale toto som chcel: z ohavnosti pascaloidnych jazykov by mali ludia majuci pod palcom MISRA-C standard radost. Niektore veci, ktore sa v C musia misrou prikazovat alebo zakazovat su v Pascale implicitne.
Vlakno v kterym pises je celou dobu o embedded. Treba takova prumyslova automatizace. Zadny windows, zadny ios, zadny android. Sem tam mozna ten linux v nejaky omezeny mire. Bezne se kompiluje kompletni sw pro zarizeni vcetne nejakeho real-time os, pokud to neni primo bare metal.
"Zadny windows, zadny ios, zadny android."
Vždyť on taky říká, že to nemusí být zrovna Delphi.
V Delphi jako takových pochopitelně ne. Ale to nebude otázka technické nemožnosti. Otázka spíš je, proč to neudělal někdo jiný.
Třeba Java? Jestli se chcete zasmát, podívejte se na
https://hovnokod.cz/java
To sem prave cekal, ze ten vtipalek do embedded pritahne javu nebo neco podobnyho :o)
smutne je, ze Java sa v embedded pomerne bezne pouziva
Povodne ale Java vznikla ako jazyk pre vyvoj embedded systemov.
to je este smutnejsie :)
v hard embedded prve dve veci, ktore cloveku zakazu este len otvori dvere su dynamicka alokacia pamate a rekurzia.
A prave preto, ze C++ nemalo dynamicku alokaciu pamati vymysleli Javu :-)
"The team originally considered using C++, but rejected it for several reasons. Because they were developing an embedded system with limited resources, they decided that C++ needed too much memory and that its complexity led to developer errors. The language's lack of garbage collection meant that programmers had to manually manage system memory, a challenging and error-prone task. "
https://en.wikipedia.org/wiki/Java_(software_platform)#History
Tak kromě toho, že - jak jsem již zmínil výše - dynamické typování není totéž, co dynamická alokace paměti, tak ani automatická správa paměti není dynamická alokace paměti. ;) C++ pochopitelně dynamickou alokaci má, úplně stejně, jako ji má C a Pascal.
https://hovnokod.cz/4741
"#define private public"
ded
Taketo nieco podobne som videl aj v nasich produkcnych kodoch vytvorene nasimi cinskymi kamaratmi. Aj je mozne, ze som to na hovnokod hodil.
A ja sam musim mat z roznych dovodov v testovacom frameworku
#define const
:)
Tohle sem videl v ramci unit testu a kdyz se to pouzije spravne, tak je to uzitecna vec...
To su detske hracicky. Nasa binarka ma slabo cez pol MB a to je v embedded svete este jedna z tych mensich. Ovela mensie budu len legacy zariadenia, alebo totalne slavy, za ktore vacsinu roboty robi ich master a su v podstate len inteligentnymi ovladacmi aktuatorov.
64 ALU !
128 ALU!
256ALU :P
Hliník se odstěhoval do Humpolce!
„Budoucnost patří ALUminiu“ - Jára Cimrman
Tady je porovnání 3900X (a 3700X) v Normal a Eco-Mode:
https://www.hardwaretimes.com/testing-eco-mode-on-the-amd-ryzen-3000-cpu...
Tady je pak super porovnání 3950X (a 3700X):
https://www.reddit.com/r/Amd/comments/eb5xxl/real_world_3950x_analysis_w...
Pro připomenutí Ryzen 3000 s Eco-Mode (modely 105/95W -> 65W a modely 65W -> 45W):
Ryzen 9 3950X
Ryzen 9 3900X
Ryzen 7 3800X
Ryzen 7 3700X
Ryzen 7 3700
Ryzen 5 3600X
Ryzen 5 3600
Ryzen 5 3500X
Hmm, tak ten 3950X v ECO modu uz na tech 16 jader moc neskaluje, spis mi to prijde ze MT vykon je tak 12x ST vykon. Jinak diky, moc uzitecne.
Velmi zajímavý je Ryzen 3950X v módu ECO+PBO (patrně se nedá tato kombinace nastavit na všech základních deskách) - stejná průměrná spotřeba jako Ryzen 3700X, ale o hodně vyšší více-jádrový výkon.
Aky je rozdiel medzi ECO modom a PBO(PPT) nastavenym na 65W (alebo kolko to ECO ma?)?
Aky je celkovo zmysel zapinat ECO a PBO sucasne?
z tabulky ve výše uvedeném odkazu má 3950X v ECO módu průměrně 66W, ale ECO+PBO módu 89W, tedy výkon není tolik striktně omezován (pro srovnání - průměrná spotřeba v PBO módu je 145W)
ECO mode nie je nic ine ako PBO/PPT nastavene na 65W. Cize stacit zvolit vyssie PBO/PPT - 89W a mate to iste, respektive si viete zvolit max spotrebu akukolvek.
...tak jednoduché to asi nebude.
PPT (Package Power Tracking) je maximální povolený příkon celé patice procesoru (AM4) - ECO mode 88W, STANDARD mode 142W.
Aktivní mód PBO (Precision Boost Overdrive) podle popisů umožní procesoru překročit nastavené limity PPT (plus TDC a EDC), a ten je nadále limitován prakticky jen teplotou (a FIT). PBO+PPT mi tedy nedává moc smysl.
PS: Možná i kombinace ECO+PBO není úplně standardní, a proto ji některé desky nepodporují, ale ve výše uvedeném odkazu je zajímavá reálným výkonem.
PSS: Všiml jsem si, že ve všech nalezených testech procesorů Ryzen 3..0X je v ECO mode Vcore 825mV, což může být technologické optimum.
"PBO+PPT mi tedy nedává moc smysl." Ide o to, ze PPT sa da menit len pri zapnutom PBO (teda aspon u mna na Gigabyte, ale v Ryzen Master je to tusim tiez tak). No stale je mozne nechat TDC a EDC nezmenene a ist s PPT nizsie.
Chapeme sa?
...pokud sedí popis funkce PBO, tj. její aktivací dojde k uvolnění nastavených limitů PPT, TDC a EDC, tak podmínka pro nastavení PPT mít zapnuté PBO (default je "auto" = disabled) je nesmysl, neboť zapnutím PBO ("enabled", "advanced") uvolním limit PPT ?!? ...něco je tedy jinak nebo to výrobci implementují nejednotně.
PS: Výše mám překlep Vcore pro ECO je 925mV !!
"pokud sedí popis funkce PBO, tj. její aktivací dojde k uvolnění nastavených limitů PPT, TDC a EDC".
Spravne, ale nikto netvrdi, ze uvolnenie = zvysenie. Tak isto mozu byt aj znizene.
ECO mod nefunguje nijak inak, len ze znizi PPT (a mozno aj TDC a EDC). Ak to tak nie je, chcem nejaky dokaz a kludne uznam, ze sa mylim :)
Cize si viem vytvorit vlastny ECO mod cisto tym, ze zapnem PBO -> mozem editovat PPT, TDC a EDC hodnoty -> znizim PPT na akukolvek hodnutu aka sa mi hodi a mam vlastny ECO mod.
úložiště:
1× M.2 2280 SSD via PCI-Express 3.0 ×4 nebo SATA III
1× M.2 2280 SSD via PCI-Express 2.0 ×4
Proč je druhé M.2 připojené přes PCIE 2.0 a ne 3.0? Myslel jsem, že dnes jsou u AMD všechna PCIE 3.0 a u novějších Ryzenů část 4.0.
Moja domnienka: Pretoze to druhe M.2 ide cez chipset B450, ktory podporuje iba PCIe 2.0.
Opravte ma niekto ak sa mylim...
Ryzeny mají 24 linek Gen4, nicméně v tomhle notebooku je chipset B450 a ten umí pouze PCIe Gen2.
Tedy přímo do CPU je připojený ten první x4 slot, x16 je pro grafiku a x4 pro komunikaci s chipsetem B450, který pak poskytuje Gen2 linky. X570 by asi bylo pro mobilní použití trochu maso.
Teoreticky by mohli bifurkovat těch x16 z CPU na x8x8 a oněch x8 rozdělit pro dva NVMe disky na x4x4, ale možná taková konfigurace není podporovaná. x4x4x4x4 podporované je. Nebo by byla možnost použít nějaký extra řadič, co by z těch osmi linek udělal třeba čtyřikrát x2 pro ultimátní mobilní NVMe RAID :D
STOP, INTEL IS ALREADY DEAD !
Koukám, že primárně nechápou význam těchto notebooků lidi, co je moc nepotřebujou. Jako na hry taky ok, ale kolem mě je dost lidí, co to kupujou kvůli cpu. Jsou to primárně vývojáři sw, co si lokálně potřebuji oddebugovat /zkompilovat hromadu kódu. Doma mají ještě staré hedt 8jadra od Intelu, v ntb pak 4jadra od Intelu. Pro ně je díky amd malá revoluce. A to nejen v desktopech ale teď i v ntb viz Asus zephyrus případně toto s desktop cpu ale větší váhou. Ta gpu je zrovna pro ně nezajimava. Menší část z nich ji využije k hraní, na to by ale zase nepotřebovali 8,12,16 jadrovy procesor. Takže cílovka tu je poměrně velká. Já jsem běžnej uživatel, co si občas něco zahraje, občas dělá něco s databází (jen jako klient), občas reviduju nějaký dokumenty. A pro mě je 6jadro tak akorát. Víc absolutně nejsem schopen využít.
Ona ta cílovka zas až tak velká není a ve chvíli kdy bude reálně dostupný Renoir se ještě zmenší.
Je pravda že teď s 8jadry v ntb může vypadat 16jadro jeste díky váze jako zbytečnost. A ještě když je k tomu seskrceny na 65w. Ideální by bylo vidět nějaký benchmarky. Fakt by mě zajímal rozdíl toho seskrcenyho 16jadra 3950x oproti tomu 4900h(s). Je možný, že to taková nálož nebude. Nicméně i tak si myslím, že vývojáři (a nemyslím teď phpkare ale spíš core systémy, databáze) tohle využijí.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.