Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Zamyšlení kam směřovat s výukou předmětu Architektury počítačů.
V první řadě děkuji všem za zájem o předchozí zápisek a kultivovanou diskuzi. Takto velký zájem jsem vůbec nepředpokládal. Velmi mě potěšily příspěvky s názory na výuku a i mě těší, že se ukázalo, že se na ABClinuxu schází lidé se zájmem o programování a diskuze se přirozeným způsobem přenesla k technickým tématům, která zajímala diskutující nejvíce. Jediný ne zcela korektně napsaný příspěvek byl, co se týče informační hodnoty, také k věci. Naplňuje mě to optimizmem.
V tomto zápisku chci prezentovat, jak jsme Architektury počítačů (APO) učili v minulosti a otevřít diskuzi jakým směrem se vydat dále.
Byl bych rád, pokud se kromě hodnocení a kritiky v diskuzích objeví i nápady, které by nám pomohly výuku zlepšit. Vzhledem k tomu, že tento článek píši právě pro získání zpětné vazby, nikoliv jako předchozí odlehčený zápisek z výletu, tak by mi pomohlo, pokud se diskuze udrží u tématu. Pokud se vyvine diskuze k tématu výrazně nesouvisejícími, prosím, založte někdo další zápisek a přidejte odkaz, kde v diskuzi pokračovat.
I na základě zpětné vazby studentů, jsem se již pokusil v roce 2017 diskuzi k předmětu otevřít na diskuzním fóru naší fakulty. I přes přidání odkazů do odpovědí anket k výuce se nikdo (ani z těch kritizujících) ze studentů do diskuze jak pomoc v pochopení a absolvování předmětu svým následovníkům (nebo i sám sobě v případě opakovaného zápisu) nezapojil. I nyní se mohou studenti a kolegové zapojit do diskuze na fóru. Ale na základě vlastně všech mých příspěvků někdy od roku 2006 na ABClinuxu předpokládám mnohem cennější diskuzi zde.
Kormě prostoru pro diskuzi chci dále zápiskem nabídnou i možnost se výuky našeho předmětu i pro zájemce mimo ČVUT FEL zúčastnit jako studenti v rámci kurzů celoživotního vzdělávání (zápisné do předmětu B3B35APO je 3250 Kč) nebo jako cvičící.
(Převzato převážně ze zápisku na fóru FEL z 24.09.2017)
Moje zkušenost a představa studia (již od opuštění gymnázia) a výuky na vysoké škole vychází z modelu, že na školu přichází studenti, kteří si chtějí rozšířit/získat znalosti v určitém, ideálně širším, směru. Na základě zkušeností, odhadu jejich možností a potřeb základů pro zvládnutí dalších předmětů je pak zvolený určitý okruh znalostí, který pokryje do akreditace zařazený předmět. Stejně tak je zvolená požadovaná úroveň minimálních znalostí a naopak, co může a má předmět poskytnout k rozvoji těch, kteří patří k těm nejlepším a do budoucna mohou obor rozvíjet dále za omezené hranice znalostí a schopností jejich současných učitelů.
Přitom v žádném případě nelze kýženého výsledku dosáhnout přístupem, jsem zákazník, nakupuji znalosti, a je na vás, vyučujících, abych je měl.
Přemýšlení v daném oboru je trénink a přesto, že rozhodčím pro daný předmět jsme my, jeho vyučující, tak se více považuji za partnera studentů, který investuje spolu s nimi úsilí do získání vědomostí, překonání nastavené laťky a osobního rozvoje tak daleko, jak to danému studentovi jeho schopnosti umožňují. Jsem přesvědčený, že ta část studentů, která na tento model přistoupila, byla i s naším předmětem, tak jak jsme ho koncipovali, spokojená. Do kurzu se nám přihlásilo i několik studentů z magisterského studia, kteří předmět APO neabsolvovali a cítili potřebu znalosti získat a to i přes to, že již řešili jiné, náročné projekty, a věděli, že vstupují do náročného kurzu, kterému budou muset čas věnovat.
Ano, není ideální, že rozhodčím kurzu jsou přímo jeho vyučující, jak vím od kamarádky, která vyučuje jazyky, tak v jejich smluvně placené výuce je zvykem, že úspěšnost firmami nasmlouvaného studia prověřují jiní lektoři, někdy i školící firmy, než prováděli vlastní výuku. Přitom u nás je požadovaná úroveň k absolvování jednotlivých testů i celku přibližně 50% správných odpovědí/znalostí. Byl jsem překvapený, že při studiu čínštiny neznalost třeba 2% z tisíců znaků znamená neuspěl. Ano náš obor je náročnější na logické myšlení atd. ale i tak je 50% velmi nízká hranice.
Na druhou stranu jednotlivou zkoušku na vysoké škole stejně považuji spíš jen za měřený trénink, reálným měřítkem je úspěšnost v profesním životě, v menším měřítku pak připravenost a znalost základů pro další kurzy, zvládnutí samostatného vývoje, výzkumu v rámci řešení absolventských prací, případně poměření sil v studentských soutěžích a testech. A mezinárodní konkurence je na vysoké úrovni, když se program OI zaváděl, studovali jsme radou předložené příklady z Computer Science Test Practice Book (GRE). A byli jsme překvapeni náročností otázek a hloubkou požadovaných znalostí pro oblast HW, které musí mít i studenti především programátorsky zaměřených oborů. Pokud vím, tak rada OI i našim studentům testy po absolvování OI bakaláře před lety zaplatila, ale ukázalo se, že v konkurenci obstáli hůře, než jaký byl předpoklad. Za roky, co kurz APO s kolegy vedeme a rozvíjíme, rozšiřujeme materiály atd. se úroveň požadavků mírně zvedá, ale stále si myslím, že zdaleka nedosahujme úrovně, která je nutná k efektivnímu využití současného HW a ani perfektnímu zvládnutí GRE testů.
Dnes děti na základní škole odmítnou rodiči nabízený čtyřjádrový mobilní telefon, a raději rozbijí prasátko, aby si mohly doplatit cenu a koupit osmijádrový (reálná zkušenost kolegy). Přitom největší nezájem o předmět vnímám právě u studentů, kteří se vidí jako budoucí významní programátoři mobilních a webových aplikací a cloudových technologií. Neumím si představit, jak chtějí tito, často na svoje schopnosti až příliš spoléhající, programátoři takovéto aplikace navrhovat.
Předmět APO nabízí opravdu jen ty základní nezbytné znalosti nutné k pochopení běhu a ovlivnění výkonu aplikací na jednom procesoru. Z paralelismu se zabýváme jen překrývajícím se/zřetězeným zpracováním na jednom procesoru a v otázkách se omezujeme v podstatě jen na jeden pětiřezový model určený pro jednu architekturu. O problémech souvisejících s využitím více procesorů v rámci jedné aplikace, případně pro běh operačního systému se zmiňuji jen přehledově v druhé části přednášek a to spíš proto, aby studenti se zájmem věděli, kde hledat, případně mohli navázat na námi předané znalosti v rámci některého dalšího předmětu. Přitom ignorování fyzikálních základů, pravidel dostupnosti dat z různých jader, omezenosti vyrovnávacích pamětí atd. obvykle vede k zásadní degradaci výkonu při použití více procesorových jader (10x, i 100x). Je celkem pravděpodobné, že špatně implementované programy a nevhodně vybrané algoritmy (to je již spíše mimo náš předmět) mají za následek zbytečnou potřebu 50% ale možná i 80% celkové energetické spotřeby výpočetní techniky na světě. Takže kromě toho, že si i samotní kritici potřeby námi nabízených znalostí určitě ztěžují i na své vlastní telefony za malou výdrž a pomalou práci, tak jsou špatní programátoři i reálnou světovou ekologickou hrozbou. Podle některých odhadů již spotřeba výpočetní a komunikační techniky přesáhla 10% celosvětové spotřeby elektrické energie a číslo se bude zvyšovat. Například v autonomním vozidle zbytečně plně zatížený systém Nvidia Drive PX2 spotřebuje 250W. To je podle mého velmi hrubého odhadu na tuto jedinou jednotku více než 1% až 2% výkonu nutného pro udržování rychlosti 100 km/h.
Přitom techniky pro dobrou škálovatelnost algoritmů vyžadují dobré znalosti paměťového modelu procesorových architektur při návrhu knihoven a běhových prostředí a pak znalost jak přenositelně, efektivně a správně tyto základy používat. To druhé je důležité pro každého programátora, to první jen pro ty nejlepší, kteří mají na to se zúčastnit vývoje takových prostředí a operačních systémů. Předpokládám ale, že ČVUT nechce být jen generátorem levných kodérů aplikací na míru, ale chce aby její nejlepší studenti zvládli vyvíjet nové technologie, programovací jazyky, operační systémy a rozvíjet obor.
Historicky na Elektrotechnické fakultě existovaly dva týmy spolupracující na výuce procesorové techniky na Karlově náměstí. Pro obor Elektrotechnika a informatika tým na Katedře řídicí techniky vedl pan docent Jiří Bayer a pan docent Jan Bílek (přespříští týden slaví 80. narozeniny, tak mu zde chci popřát hodně zdraví a budu rád, pokud se další přidají). Na Katedře počítačů po odchodu kolegů na Fakultu informačních technologií s relativně omezeným týmem setrval pan docent Miroslav Šnorek (díky za knihu Připojování periferií k PC, podle ní jsem si nadrátoval ISA kartu se sériovým portem pro myš a navíc s budičem RS-485, počátek projektu uLAN). Při přípravě oborů Kybernetika a robotika (KyR) a Otevřená informatika (OI) se dohodlo spojení sil pod vedením pana docenta Šnorka. Na přípravě jsem se sešel s Michalem Štepanovským. Panem docentem byla za základ kurzu zvolená učebnice Computer Organization and Design, The HW/SW Interface (CA) kterou napsali páni profesoři Patterson a Hennessy. Při přípravě materiálů pan docent komunikoval i přímo s autory a pro procvičení a pochopení základních principů procesorové činnosti byl zvolený simulátor Mips It, jehož instalační soubory byly i na CD přiloženém ke knize.
Náplň předmětu se zaprvé odvíjela z prostudování podobných kurzů na světových univerzitách a dále pak především od požadavků ke státním zkouškám oboru OI a ty vycházely z požadavků na studenty na amerických a kanadských univerzitách ‒ Computer Science Test Practice Book (GRE). Dostali jsme k dispozici materiály k přednáškám a prezentacím autorů knihy.
Výsledná náplň není zaměřená na předvádění novinek (na mírně pokročilejší techniky, které jsou základem zpracování instrukcí na moderních procesorech je zaměřený předmět Pokročilé architektury počítačů ‒ B4M35PAP), pár zajímavostí je jen pro motivaci uvedeno v úvodu. Za zásadní cíl předmětu si bereme ukázat studentům základy odpovídající návrhu a vzestupu RISC procesorů po roce 1980. Právě tyto základní znalosti jsou nutné pro schopnost alespoň pochopit techniky pokročilejší a bez nich není možné porozumět alespoň základním faktům při čtení technologických novinek pro veřejnost o procesorech jako je Ryzen nebo RISC-V, natož vědeckým článkům nebo se dokonce do vývoje zapojit. Je trochu s podivem, že principy RISC byly používané již dříve v šedesátých letech minulého století (CDC 6600 ‒ počáteční počiny Seymoura Craye), ale nebyly takto nazývané. Později byly tyto principy opuštěné. Důvodem byly velmi omezené možnosti prvních integrovaných obvodů integrujících celé mikroprocesory. Dále pak snaha o snížení toku objemu načítaných instrukcí vedla ke kombinaci přístupů do paměti s aritmetickými operacemi v jedné instrukci a tím vzniku komplexních (CISC) procesorů s nutností využít mikrokód a až zpětně dochází ke korekci vývoje směrem k RISC a SIMD. Velmi dobrou ukázkou je vývoj architektury x86, u které lze ale předpokládat, že díky kompatibilitou fixovanému kódování instrukcí nelze mnoho chybných rozhodnutí již napravit.
Schopnost porozumnět dokumentaci a informacím o současných procesorech je jen jedním z cílů, další je naučit i budoucí programátory ve vysokoúrovňových prostředích a jazycích, jak se vyvarovat základních chyb, které vedou ke zbytečnému zpomalení programů. Znalosti poslouží i těm, kteří se chtějí zabývat stavbou vlastních, na mikroprocesorech založených, řídicích jednotek (například pro roboty nebo do automobilů).
Vlastní přednášky začínají seznámením s reprezentací dat, především numerických, čísel v paměti počítače (APO:Pisa20EN:1, ODP, YT, APO:Susta19:1, APO:PisaStepanovsky18EN:1, ODP). Vysvětlené je počítání s čísly bez znaménka a se znaménkem v binární soustavě a poté reprezentace (podmnožiny) reálných čísel (plovoucí řádová čárka a IEEE-754). U počítání s čísly v plovoucí řádové čárce (APO:Pisa20EN:2, ODP, YT, APO:Susta19:2, dříve v 1) ukazujeme vznik nepřesností a chyb. Odpovídající kapitola knihy ‒ CA:3 - Arithmetic for Computers. První kapitolu (CA:1 Computer Abstractions and Technology) částečně pokrývá velmi rychlý úvod a přehled. V běhu LS 2018/2019 přidal doktor Richard Šusta základní informace z kapitoly CA:2 Instructions: Language of the Computer do přednášek (APO:Susta19:2). Dříve jsme spoléhali na pochopení jazyka symbolických adres (assembleru) z výkladu vystavění jednocyklového procesoru dohromady s materiály a vedením studentů na cvičeních. Postupem zespoda nahoru je z jednotlivých funkčních bloků podle požadavků na prováděné operace vystavěný procesor (CA:4 The Processor)(APO:Pisa20EN:3, ODP, YT, APO:Susta19:3, APO:PisaStepanovsky18EN:2, ODP). Přednáška končí přechodem od hardwardské architektury na architekturu se společnou pamětí, která již umožňuje nahrání programu operačním systémem běžícím na shodném procesoru. Zvětšení a vyjmutí paměti z čipu vede k problémům s její rychlostí a nutnosti se zabývat hierarchií pamětí (CA:5 Large and Fast: Exploiting Memory Hierarchy).
Po vyhovujícím (vyžaduje kvalitně napsané programy, správně volené algoritmy a datové struktury) vyřešení problémů s rychlostí pamětí (APO:Pisa20EN:4, ODP, YT, APO:Susta19:5, APO:PisaStepanovsky18EN:3, ODP) se vracíme k urychlení vlastního vykonávání instrukcí ‒ zpoždění na kombinační logice lze rozdělit do stupňů a překrýt výkon za sebou jdoucích instrukcí ‒ zřetězené zpracování (opět CA:4 The Processor) (APO:Pisa20EN:5, ODP, YT, APO:Susta19:7, APO:PisaStepanovsky18EN:4, ODP). Dále se zabýváme predikcí skoků (opět CA:4 The Processor)(APO:Pisa20EN:6, ODP, YT, APO:Susta19:8), voláním funkcí (APO:Pisa20EN:10, ODP, YT, APO:Susta19:10, APO:PisaStepanovsky18EN:9, ODP) tak aby bylo možné předávat argumenty a návratové hodnoty mezi funkcemi, zkompilovanými různými kompilátory například do knihoven nebo běhových prostředí. Další krok v oddělení aplikací od běhového prostředí je použití operačního systému. Systémová volání jsou vysvětlena na příkladu jejich implementace v jádře systému GNU/Linux (aktuální tabulka podporovaných volání pro různé architektury).
Protože procesorový systém lze smyslupně využít pouze tehdy, pokud je možné do něj data pro dávkové zpracování nebo ze senzorů dopravit a poté výstupy nějak reprezentovat nebo aplikovat na aktuátorech tak přidáváme popis vstupně výstupního systému (APO:Pisa20EN:7, ODP, YT, APO:Susta19:, APO:PisaStepanovsky18EN:5, ODP). Nejdříve v nejjednodušší formě periferie mapované do paměťového adresního prostoru, poté již s obecnějším systémem PCI, který umožňuje vkládat karty s možností automatického zjištění jejich typu a požadavků na adresové rozsahy. Řídicích registry karet jsou adresované topologicky (podle pozice ve slotu). Adresové rozsahy/mapování funkčních skupin registrů a pamětí se nastavuje přes řídící registry. Není tedy potřeba používat žádné manuální nastavování propojkami jako v předchozí generaci počítačů se sběrnicí ISA. V rámci výkladu funkce sběrnic se zabýváme klasickou paralelní sběrnicí PCI (APO:Susta19:12, APO:PisaStepanovsky18EN:6, ODP). Ta sice již není v klasické paralelní variantě příliš používaná, ale lze na ní názorně vysvětlit principy arbitrace a adresování, které se používají a budou stále používat například při návrhu vlastních procesorových a periferních obvodů (sběrnice AXI, APB, Avalon, Wishbone) ať již přímo v podobě křemíkových čipů nebo systémů využívajících programovatelné obvody FPGA. Na nich se sice již nepoužívají obousměrné linky, ale problémy s čekáním na připravenost periferie, její odpověď a serializaci přístupů z více nadřazených procesorů a periferií s přímým přístupem do paměti zůstávají. Naopak pro propojení obvodů a funkčních celků se již přechází ze série slov posílaných paralelně po více vodičích na posílání vlastních symbolů sériově po jedné nebo více diferenčních jednosměrných linkách. Důvody přechodu na sériové propojení demonstrujeme na standardu PCI Express i s ukázkou zachování programového modelu.
Dále se zabýváme architekturou x86 (APO:Stepan20:11, YT, APO:PisaStepanovsky18EN:11, převzato Dr. Konstantin Levit-Gurevich, Intel Israel), která stále je a pravděpodobně ještě 10 let bude dominantní v oblasti personálních počítačů a běžných serverů. Na této architektuře předvádíme jak zrychlit multimediální operace využitím SIMD instrukcí. Nakonec přichází krátký souhrn vývoje procesorových architektur (InstallFest21:Pisa:1, YT, APO:Pisa20EN:12, ODP, APO:Pisa19:13, APO:PisaStepanovsky18EN:12, ODP) se zaměřením na příklady některých důležitých inovací, které vedly ke zvýšení výpočetního výkonu. Závěr je pak věnovaný výhledu do budoucna a přehledu perspektivních směrů a architektur. Vše ve velmi omezené míře tak, aby bylo možné si alespoň základní představu odnést i s těmi omezenými znalostmi, které jsme schopní v rámci jednoho kurzu předat. Vlastní zkouškové testy se z tohoto výkladu zaměřují opravdu jen na několik základních faktů, nikde se neptáme na konkrétní registry, typová označení, instrukce zahrnuté do jednotlivých instrukčních sad.
V loňském běhu jsme přešli na vlastní simulátor architektury MIPS (QtMIPS, ke stažení, video, preznetace, webová verze). Simulátor nahradil dříve používaný Mips It, který existuje jen ve verzi pro Windows a je tak starý, že se již i na nich pouští problematicky. Náš simulátor jsme začali v loňském letním semestru používat i přesto, že množtví funkcí bylo potřeba doprogramovat za běhu.
Postupně byla přepracovaná tabulka pro dekódování základních i dalších instrukcí a doprogramované zvýrazňování slov paměti, která jsou v dané chvíli pro procesor dostupná z vyrovnávací paměti.
Dále přibyly některé periferie odpovídající VHDL návrhu periferií k výukovému kitu MZ_APO na bázi Xilinx Zynq navrženého primárně pro výuku předmětu Programování systémů reálného času a další pokročilejší projekty. Protože se jedná o relativně drahý systém, není možné poskytnout každému studentovi kit domů a právě přidání periferií do simulátoru (sice s jádrem MIPS na rozdíl od ARM pořípravku) jsem viděl jako pomoc v řešení semestrálních projektů.
Dále byl přidaný sériový port, který datovými a řídicími registry odpovídá sériovému portu z emulátorů QtSPIM a MARS tak jak jsou popsané v knize Computer Organization and Design, The HW/SW Interface (CA) od profesora Pattersona a Henessy.
Zde se někdo může zeptat, proč nepoužíváme tyto velmi povedené simulátory vyvíjené již desetiletí. Když jsme s Karlem Kočím prováděli analýzu jestli se vydat vlastní cestou nebo rozšířit tyto simulátory, dospěli jsme při analýze jejich implementací k názoru, že doplnit/přepsat jejich jádra tak, aby poskytovaly signály a obecně stav odpovídající zřetězenému zpracování instrukcí znamená v podsatě přepsat kompletně jádro simulátoru. Přitom přepis cizího kódu se zachováním výsledné funkce by byl náročný a bez delšího jednání s autory by byla šance na začlenění mizivá. Kompletní rozbor je součástí diplomové práce Graphical CPU Simulator with Cache Visualization Karla Kočího.
Protože jsme věděli, že naše síly jsou velmi omezené, rozhodli jsme se, že simulátor nebude obsahovat vlatsní editor kódu a bude nahrávat spustitelné sobory ve formátu ELF MIPS32 big endian generované vývojovým řetězcem GNU.
Během diskuze na výstavě Maker Faire, iniciované kolegy z naší ketedry, byl náš přístup kritizovaný s tím, že v dnešní době nikdo nechce instalovat binární program (přesto, že máme podporu pro GNU/Linux, Window i Mac OS) a vše má běžet přímo z Internetu v prohlížeči. Od kolegy Františka Vacka jsem se dozvěděl, že Qt5.13 přidávají podporu běhu přes WebGL v prohlížečích, které podporují "instrukční sadu" (ISA z pohledu APO) WebAssembly. Nainstaloval jsem tedy překladač Emscripten postavený nad LLVM a překompiloval Qt5.13 (viz dokumentace) i náš simulátor. Výsledek sice není dokonalý, ale pro mnoho úloh je již použitelný.
Při použítí v prohlížeči omezuje použití externího kompilátoru vlastní tvorbu, lze sice nahrávat binární přiklady distribuované se simulátorem, ale modifikace je obtížná. Proto jsem do aplikace přidal i editor a jednoduchý jednoprůchodový asssembler, který překládá přímo do datové struktury reprezentující paměť simulovaného systému.
Pro překlad byl implementovaný jednoduchý systém pro zpracování a vyhodnocování výrazů.
Po skončení přemětu i na základě sledování velké zátěže na studenty i hardware, kdy měli problém se vystřídat u vlastních výukových kitů, jsem připrogramoval i emulaci jednoduchého grafického výstupu (framebuffer), který odpovídá formátem RGB 565 displejům použitým na kitech.
Simulátor dále implementuje i emulaci základní sady systémových volání MIPS O32 ABI používané jádrem Linux a základní podporu koprocesoru COP0. Jím je možné předvést na simulátoru i zpracování přerušení a teoreticky i po vypnutí emulace O32 ABI i vlastní implementaci systémových volání.
Náš dlouhodobější cíl je pak přejít s výukou i simulátorem na otevřenou architekturu RISC-V. O té jsme uvažovali již před začátkem projektu, ale příprava všem materiálů (přednášky, generátory sekvencí pro zkouškové testy, cvičení) bude vyžadovat tolik času, že jsme zvolili v počáteční fázi pouhou náhradu implementace simulátoru.
Naopak o náš projekt je zájem i na dalších fakultách a univerzitách i v zahraničí, takže věříme, že se nám i díky tomuto projektu podaří sestavit tým zájemců natolik silný, že bude možné provést přípravu pro výuku na architektuře RISC-V na světové úrovni. Stejně, jako příprava tohoto simulátoru a záměru inovace MipsIT sahá pět let zpět, tak i další kroky jsou na roky. Tedy zpět k výuce.
Předmět je zařazený jak do programů Kybernetika a robotika (KyR) a Otevřená informatika (OI) a byl naplánovaný pro čtvrtý semestr. Vzhledem k potřebě znalostí v navazujících předmětech operační systémy a dalších byl v rámci poslední úpravy akreditace přesunutý do druhého semestru. Vlastní logické operace a základ Boolovy algebry by již studenti měli mít probraný v předchozích předmětech. V programu OI mají studenti již jazyk C probraný (předmět B0B36PRP), v programu KyR bereme ohled na to, že se studenti jazyk C (předmět B3B36PRG) učí paralelně s naším předmětem. S kompilací jednoduchého programu v jazyce C pro výpis hodnoty z paměti se sice studenti setkají již na prvním cvičení, ale důraz je kladený na reprezentaci čísel v paměti a jazyk C je vlastně jen prostředek na zobrazení několika hodnot a k demonstraci k na tabuli probraným příkladům počítání s plovoucí řádovou čárkou. Dále pro první dvě třetiny cvičení vystačíme se schopností kombinovat sekvence několika málo instrukcí v assembleru.
Na dalším cvičení si studenti vyzkouší jednoduchou sekvenci instrukcí LW/SW, pro překopírování hodnoty mezi dvěma adresami v paměti. Výpočet součtu dvou proměnných načtených z paměti, součet dvou vektorů a jeho nároky na počty přístupů do paměti podle parametrů a způsobu využití vyrovnávací paměti. Další úkol je implementace jednoduché rekurzivní funkce (předávání parametrů podle MIPS O32 ABI) Fibonacciho posloupnosti. Další příklad na pochopení vlivu vyrovnávací paměti je algoritmus jednoduchého třídění. Po probrání faktorů limitujících maximální hodinovou frekvenci sekvenční logiky (jednocyklového procesoru) je na simulátoru předvedené zřetězené zpracování instrukcí. Zřetězení sice přináší zvýšení propustnosti, ale přináší problémy s dopravením výsledků z ještě nedokončených instrukcí do následujících instrukcí. Simulátor nabízí konfiguraci, kdy není problém závislostí/hazardů ošetřený. Studenti si tedy mohou vyzkoušet, jak přizpůsobit sekvence strojových instrukcí pro vyřešení tohoto problému na softwarové straně. Kromě procesorů DSP většina dnešních architektur sice řeší závislosti na straně hardware, ale často s penalizací výkonu a moderní kompilátory se rozplánováním instrukcí podle počtu funkčních jednotek a jejich zpoždění a vzájemných propojení musí pro dosažení dobré propustnosti zabývat. Vysvětlení hardwarového ošetření na přednáškách je možné v praxi otestovat na simulátoru (jak pozastavení, tak přeposílání).
V souladu s postupem přednášek přecházíme na propojení systému s vnějším světem. Nejdříve jen čtením otočným voličem nastaveného čísla z adresy v paměťovém prostoru a jeho výstupem na "RGB LED" (na přípravku MZ_APO již skutečné RGB LED) a do výstupního slova (na přípravku MZ_APO pak realizovaného řadou 32 malých SMD LED diod). Dále je možné vyzkoušet výstup na sériový port a to jak v režimu dotazovacím tak s přerušením (architektura MIPS je simulovaná včetně základních funkcí koprocesoru COP0).
Podle schopností studentů lze již tyto příklady demonstrovat v jazyce C a přejít i k volání služeb jádra operačního systému. Studenti s hlubším zájmem si mochou vyzkoušet i obsluhu systémového volání přímo ve vlastním kódu, protože simulátor umožňuje vypnout zachycení a emulaci systémových volání.
Poslední až třetina cvičení je věnovaná přechodu k programování shodné sady periferií realizované v námi připraveném VHDL návrhu pro výukové kity MZ_APO. Zde se již programuje plně v jazyce C. Pro zjednodušení ladění se programy pouští v uživatelském prostoru a pro přístup k periferiím je využito mapování periferií s využitím systémového volání mmap() do virtuálního adresního prostoru procesu. Pro všímavé studenty je to i příklad na využití překladu virtuálních adres na fyzické, které je probrané na přednáškách.
První domácí úkol slouží k procvičení kódování numerických hodnot do paměti (little-endian, big-endian), jednoduchých operací v pevné řádové čárce a procvičení ručního převodu hodnot do a z formátu plovoucí řádové čárky. Přitom na operaci s reálnými čísly je předvedený i vliv zaokrouhlení při operacích. Ti studenti, kteří úkol vyřeší pečlivě a mechanizmy pochopí, by neměli mít potíže ve zkouškových příkladech zaměřených na kódování. V případě plovoucí řádové čárky jsou do testu generované příklady, které pro uložení reálných čísel využívají menší počet bitů, okolo 11, aby bylo možné příklady počítat i z hlavy nebo na papíře bez potřeby využít kalkulátor.
Druhý úkol je zaměřený na optimalizaci/minimalizaci počtu výpadků vyrovnávací paměti při realizaci algoritmu ostření obrázku. Tento úkol již vyžaduje základní znalost programovacího jazyka C. Termín odevzdání je volený tak, že i studenti, kteří se učí programovací jazyk C paralelně s naším předmětem by již potřebné základy měli mít probrané. Vlastní vyhodnocení úkolů v odevzdávacím systému provádí kontrolu práce s pamětí programem Valgrind. Stejný program (v režimu cachegrind) je pak použitý pro vyhodnocení náročnosti implementovaného algoritmu na počet přístupů do paměti. Opět, kdo se nad úlohou zamyslí, by neměl mít problémy s mnohem jednoduššími otázkami k efektivitě využití paměti ze zkouškového testu.
Třetí úkol je zaměřený na zřetězené zpracování instrukcí a řešení dodržení závislostí mezi instrukcemi změnou pořadí instrukcí a po přidání hardwarové podpory i analýzou potřebných pozastavení v případech bez a s přeposíláním výsledků. Opět přímo odpovídá obdobným analýzám sekvencí (jiných) kódu ve zkouškových testech. Modul v jazyce Python, který analyzuje a vyplňuje správné výsledky při generování zkouškových testů je již od jeho prvního použití v testech k dispozici jako opensource (git clone https://github.com/ppisa/apo-simarch).
Analyzátor kódu je schopný i jednoduché sekvence instrukcí odsimulovat včetně práce s pamětí a provádět permutace pořadí instrukcí při zachování jejich vzájemných závislostí. Studenti si stěžují na nedostatek materiálů a nedostatečnou přípravu ke zkouškové písemce. Ale zde mají jak domácí úkol tak i nástroje na přípravu vlastních cvičných úloh. Připadá mi celkem smutné, že neuronová síť tvora, který se cítí na vrcholu vývojového řetězce, prohlašuje za nadměrný výkon postavit se jednoduchému logickému algoritmu, který zvládá několik řádek kódu v jazyce Python. Analýza vzájemné závislosti dvou instrukcí je vyřešená ve funkci depanalyze() na 13 řádkách kódu. Kompletní analýza sekvence instrukcí je bez použití přeposílání vyřešená ve funkci analyze() na 26 řádkách kódu. Pro případ s přeposíláním ale s latencí jeden cyklus mezi načtením a dostupností hodnoty čtené z paměti pak ve funkci analyze_stall_forward() pak vychází na 43 řádek kódu, ale pro tvora vybaveného přirozenou inteligencí je ještě jednodušší než předchozí případ. Komu činní potíž mechanizmus pochopit z ilustrovaného popisu na přednáškách (slide 37 až 45 přednášky o zřetězeném zpracování) a šestého cvičení (Pipeline a hazardy), tak si může prostudovat algoritmus. Vše je vyučované i zkoušené na stále jednom a tom samém modelu pětistupňového zřetězeného procesoru, který si lze do detailů "osahat" na grafickém simulátoru QtMIPS a případně se zeptat i na cvičeních.
Poslední úkol je již náročnější, jednoduché programy pro zpracování textového vstupu a jeho přeposlání na výstup jsou zkompilované pro cílovou architekturu x86 32 bitů a MIPS O32 ABI ve formě programů pro operační systém GNU/Linux. Úkolem studentů je z výpisu v assembleru těchto architektur nalézt volání mezi hlavním programem a jednou funkcí. Dále vyhledat veškerá systémová volání, přitom ta jsou do programu vložená v jednoduché podobě přímo do sekvencí instrukcí funkcí s využitím extended assembleru GCC. Díky tomu není potřeba analyzovat knihovní funkce a propojení hodnot na argumenty systémových volání je minimálně v případě MIPS zcela zřejmé. Odevzdává se seznam nalezených systémových volání a k funkci binárního programu ekvivalentní program v jazyce C. Zdrojový kód je odevzdávacím systémem zkompilovaný do 64 bitového režimu x86, poté jsou ladící informace analyzované ladícím programem GDB. Nalezený prototyp volané funkce je porovnaný proti výsledku analýzy původního binárního programu. Přitom při porovnání datových typů ukazatelů i přímých číselných argumentů se nekontrolují shoda na použití znaménkového typu a další nepodstatné rozdíly. Nakonec dojde k záznamu sekvencí volaných systémových volání pro různé vstupní soubory programem strace. Sekvence jsou porovnané proti sekvencím získaným při volání 32 bitové binární varianty programů (zadání). Na příkladu je demonstrovaná i přenositelnost programů mezi různými architekturami (MIPS big-endian, x86 little-endian, 32 bitový a 64 bitový procesor). Vzorové řešení mírně náročnějšího úkolu než jsou vlastní zadání pro studenty je k dispozici v české a anglické verzi na stránce se zadáním úkolu.
Původní přípravky pro předmět realizovaly jednoduchou periferii připojenou ke sběrnici PCI Express. Byly založené na programovatelném obvodu FPGA a instalované do PC počítačů v laboratoři. Pro PCI rozhraní i připojené periferie jsme naimplementovali i jejich simulaci v emulátoru QEMU. Jednalo se o pokračování diplomové práce Prostředí pro výuku vývoje PCI ovladačů do operačního systému GNU/Linux Rostislava Lisového.
V létě roku 2016 probíhala diskuze o předmětěch v rámci nové akreditace OI studia. Sám jsem prosazoval na schůzkách použití nebo návrh vlastního malého a levného procesorového kitu, který by bylo možné získat v potřebném počtu tak, aby minimálně na celý semestr měl každý student jeden kus k dispozici.
V současné době použitý hardware s FPGA a velkým procesorem jsem vybíral pro diplomové prace a pro použití v předmětu Programování systémů reálného času. Pro tyto případy se jedná o excelentní volbu. S direktivním rozhodnutím použít nakoupená procesorová jádra MicroZed pro předmět APO, jsem nesouhlasil, přesto jsem vznesené deklarativní vyjádření pana profesora Zdeňka Hanzálka v mé firmě (PiKRON) s kolegou (Ing. Petr Porazil) vyrobit kyty použitelné i pro předmět APO splnil. Možnosti navrženého kitu (MZ_APO) jsou široké, používáme ho i v projektu otevřené implementace (CTU CAN FD) automobilové komunikační sběrnice. Umožňuje řídit motory (GNU/Linux a řízení po sběrnici CAN s využitím generovaného kódu a FPGA Video, Prezentace), pro kity máme připravené i stereokamery a v rámci BP nebo DP by bylo možné navrhovat zpracování obrazu s využitím FPGA. K dispozici jsou i serva a řízení laserového paprsku a další zajímavé náměty na DP a BP. Studenti jsou s kity seznámení na přednášce (APO:Pisa20EN:8, ODP, YT) a poté n acvičeních. Zajímavá je i možnost navrhnout RISC-V jako koprocesor v FPGA části řízený z nadřazeného GNU/Linux systému běžícího na architektuře ARM. Minimálně ještě jeden, dva běhy budeme kity i pro předmět APO používat.
Investujeme ale i čas do výběru nebo návrhu vlastní cenově dostupné platformy založené v ideálním případě na architektuře RISC-V s možností alespoň zapůjčit kit každému studentovi.
I na základě diskuze budeme uvažovat o kompletním přechodu na malé kity nebo ponechání možnosti použít plnohodnotný systém se zajímavými periferiemi například jen pro obor KyR. Případně nabízet kit jako alternativu pro schopné studenty, kteří mají o studium zájem. V rámci semestrálního projektu nebo individuálního projektu další semestr mohou na kompletním systému navrhovat a testovat vlastní periferie a koprocesory. A nechat studenty, pro které je předmět jen zdrojem nejnutnějších základních znalostí pro další studium, pracovat jen s levnými malými kity. Ale i u nich bych však byl rád, aby si vyzkoušeli práci na úrovni OS, zvažujeme NuttX nebo RTEMS, se kterými mám značné zkušenosti včetně příspěvků do vývoje jejich jader (RTEMS příspěvky, DP Přemysl Houdek, DP Petr Beneš EDF scheduler, vedení dalších asi čtyř GSoC studentů v cizině).
Tento zápisek shrnuje koncepci předmětu Architektury počítačů. Vykládá jak obsah vznikal, vazbu cvičení, přednášek a domácích úkolů atd. Náš zájem je, abychom v předmětu předali znalosti potřebné pro další studium (pro předměty Operační systémy, Programování systémů reálného času, studium kompilátorů, antivirů i třeba pro návrh nových procesorových architektur a jejich implementací) a aby absolventi díky znalostem chování procesorů, vyrovnávacích pamětí i vstupně výstupních subsytémů programovali aplikace s větší propustností, menšími nároky na pamět, energii (baterie) atd.
Do budoucna máme zájem kurz aktualizovat a pro výuku využívat otevřenou procesorovou architekturu RISC-V. Hledáme i studenty a kolegy kteří se do dalšího vývoje zapojí (BP, DP, atd.). Pokud Vás oblast procesorových systémů zajímá, může pro Vás být zajímavý i předmět Pokročilé architektury počítačů.
Hledáme i spolupracovníky, kteří by měli zájem se do výuky nyní/časem zapojit třeba i jako externisté z firem a využít možnosti udržovat i nadále vztahy s fakultou a případně motivovat další studenty k získání znalostí a třeba i práci na zajímavých projektech firem, pro které budete pracovat, v rámci dalších DP a BP.
Budu velmi rád za kultivovanou diskuzi a připomínky, jak předmět zlepšit. Velmi mě zajímají názory studentů, kteří již předmět absolvovali. Nejvíce mě pak zajímají názory těch, kdo již měli možnost znalosti využít v praxi. Především pro studenty a i ty, kdo jsou ochotní přispět k hodnocení předmětu a přispět k jeho směřování odpovědí na otázky jsem na jednom svém pomocném serveru zprovoznil systém Odoo (nechci dávat všechna data k analýze jedné velké společnosti). Všechny odpovědi na otázky jsou volitelné, není potřeba odpovídat na vše. Adresa dotazníku http://pisa-virt.felk.cvut.cz:8069/survey/start/8fd10db1-e0bf-47e7-850b-b0c96c96915c
Zápisek je celkem dlouhý a neměl jsem na jeho pečlivou kontrolu dostatek času, přitom ho potřebuji kvůli koordinaci přípravy cvičení publikovat již nyní. Prosím, na překlepy mě upozorněte v soukromých zprávách. Text budu pravděpodobně i na základě diskuze mírně upravovat.
Tiskni
Sdílej:
S QEMU zkušenosti máme, například emulaci PCI SJA1000 (CAN bus) jsem kromě x86 připojoval i na Versatile
qemu-system-arm -cpu arm1176 -m 256 -M versatilepb \ -kernel kernel-qemu-arm1176-versatilepb \ -initrd ramdisk.cpio \ -hda rpi-wheezy-overlay \ -append "root=/dev/ram console=ttyAMA0" \ -device kvaser_pci,canbus=canbus0,host=can0 \ -virtfs local,path=shareddir,security_model=none,mount_tag=shareddir \ -nographic
Pro otestování by bylo dobré vyzkoušet emulaci na big-endian MIPS architektuře. To asi bude čekat mého studenta, pana Charváta, který implementuje emulaci CTU CAN FD (vývojový GIT na FEL, odesílání již chodí).
Co se týče předmětu APO, tak studenti mohou v laboratoři zkompilovat C a ASM kód překladačem mips-linux-gnu-gcc
a pustit ho stejně jako nativní programy na PC s využitím qemu-mips
/qemu-mips-static
. Pokud použijí náš zjednodušený startup kód nebo kompilují proti musl libc tak mohou jednoduché programy bez přístupu k hardwarovým registrům využívající několik QtMIPS podporovaných systémových volání (open, read, write atd.) tak mohou shodnou MIPS binárku spouštět v "plné" rychlosti s příkazové řádky Linuxu stejně jako v simulátoru QtMIPS.
Ale zde mají jak domácí úkol tak i nástroje na přípravu vlastních cvičných úloh. Připadá mi celkem smutné, že neuronová síť tvora, který se cítí na vrcholu vývojového řetězce prohlašuje za nadměrný výkon postavit se jednoduchému logickému algoritmu, který zvládá několik řádek kódu v jazyce Python.Na jednu stranu chápu, že chtít po lidech, aby mysleli sami, to se málokdy setká s úspěchem. Na druhou stranu mnoho vyučujících si ve svých požadavcích neuvědomuje, že studenti studují víc předmětů současně. Když tak koukám na studijní plán, tak mi to vychází nějakých 20 hodin čistého studijního času týdně. Pokud vezmeme osmihodinovou pracovní dobu jako etalon rozumné zatížitelnosti člověka, tak i se započítáním nějakého nutného času na odpočinek (a přechody mezi učebnami), zbývají na každý předmět nějaké 2.5 hodiny za týden. Počítáte s tím při zadávání domácích úloh a očekávání, že student bude připravovat vlastní cvičné úlohy?
Například v autonomním vozidle zbytečně plně zatížený systém Nvidia Drive PX2 spotřebuje 250W.Není tahle věc v podstatě přerostlá grafárna? 250W mi v takovém případě přijde ještě dobré...
Na jednu stranu chápu, že chtít po lidech, aby mysleli sami, to se málokdy setká s úspěchem. Na druhou stranu mnoho vyučujících si ve svých požadavcích neuvědomuje, že studenti studují víc předmětů současně. Když tak koukám na studijní plán, tak mi to vychází nějakých 20 hodin čistého studijního času týdně. Pokud vezmeme osmihodinovou pracovní dobu jako etalon rozumné zatížitelnosti člověka, tak i se započítáním nějakého nutného času na odpočinek (a přechody mezi učebnami), zbývají na každý předmět nějaké 2.5 hodiny za týden. Počítáte s tím při zadávání domácích úloh a očekávání, že student bude připravovat vlastní cvičné úlohy?
Souhlasím s tím, že zátěž studentů je velká. Zároveň jsem přesvědčený, že teoretické předměty, matematika, teorie řízení atd. jsou pro trénink mozku důležitější a potřebují více vedení.
Ale je vysloveně škoda, že svůj a náš čas často na cvičeních nevyužijí. Když dostanou jednoduché cvičné úkoly, tak existuje nezanedbatelná část studentů, někdy i většina, která nemá zájem se do cvičení zapojit. Přitom se jim v podstatě snažíme ukázat, že se jedná o zajímavou hru.
Další je problém komunikace. V hodnocení z mých cvičení si studenti stěžovali, že se ptám na věci, co ještě neprobírali a jsem nespokojený, že se nikdo nezapojí, mlčí. ve skutečnosti se často ptám přímo nebo na důsledky faktů, které se na přednášce objevily. Ovšem velká část studentů na přednášky nechodí. Nezlobí mě však to, že znalosti nemají a že neumí odpovědět správně. Naopak o co mám největší zájem je, aby zkusili na základě znalostí a představ o tom, jak daná věc pracuje, hledat sami odpověď na otázku a třeba i zkoušeli na věc přijít jen odhadem, zkoušeli se sami na základě již dosažených znalostí stát návrháři procesorů, technik atd. Na cvičení mi v takovém případě vůbec nevadí, pokud odpověď nebude správná a i pokud půjde nesprávným směrem, tak to nevadí. Pokusím se nabídnout další fakta, korekci atd. Pokud potom studenti přijdou na řešení sami, tak věřím, že je to okamžik, kdy si znalost nejlépe osvojí, porozumí jí, ne se ji jen naučí.
Jenže pokud člověk zůstává stát v tichu proti mlčícím stínům, tak není jak úvahu směrovat, rozvést. Znamená to často prozrazovat rovnou pointu a vlastně studenty připravit o to nejhezčí, objevování světa, které člověka těší třeba i v horách, když jde někam, kde již i jiní byli.
Například v autonomním vozidle zbytečně plně zatížený systém Nvidia Drive PX2 spotřebuje 250W.Není tahle věc v podstatě přerostlá grafárna? 250W mi v takovém případě přijde ještě dobré...
protože jsem v roce 2016 odmítl NDA se společností NVIDIA podepsat, tak se na specifikace přímo nepodívám, ale z diskuzí a dostupných informací je to kolo těch 250 až 300 Wattů. Jinak ano, jedna se především o GPU využívané v aplikacích pro počítání hlubokých neuronových sítí. Ale přece jenom embedded nechce integrované topné radiátory, to by se Vám zbortila palubní deska. Hodilo by se to jen v zimě k vytápění v době kdy parkujete a motor je vypnutý. takže je snaha udržet spotřebu na uzdě. Otázka je, kolik nakonec takových systémů bude muset v automobilu být a pokus se proprietární výrobci jednotek a algoritmů nedohodnou mezi sebou a budou se o know how strachovat, tak je dost možné, že jich bude hodně. Alternativa je, že opět vývoj od subdodavatelů převezmou samotné automobilky a začnou vyvíjet SW cestou spolupráce.
Ale i toto nemožné se může stát, peklo zmrzlo a Microsoft přešel s veškerým vývojem na GIT a Volkswagen nechává svého špičkové vývojáře a autora SocketCANu z Volksawagen Research učit celou firmu, jak spolupracovat s komunitou
https://www.volkswagenag.com/en/news/stories/2019/11/the-open-source-missioner.htmlV hodnocení z mých cvičení si studenti stěžovali, že se ptám na věci, co ještě neprobírali a jsem nespokojený, že se nikdo nezapojí, mlčí. ve skutečnosti se často ptám přímo nebo na důsledky faktů, které se na přednášce objevily. Ovšem velká část studentů na přednášky nechodí. Nezlobí mě však to, že znalosti nemají a že neumí odpovědět správně. Naopak o co mám největší zájem je, aby zkusili na základě znalostí a představ o tom, jak daná věc pracuje, hledat sami odpověď na otázku a třeba i zkoušeli na věc přijít jen odhadem, zkoušeli se sami na základě již dosažených znalostí stát návrháři procesorů, technik atd. Na cvičení mi v takovém případě vůbec nevadí, pokud odpověď nebude správná a i pokud půjde nesprávným směrem, tak to nevadí. Pokusím se nabídnout další fakta, korekci atd. Pokud potom studenti přijdou na řešení sami, tak věřím, že je to okamžik, kdy si znalost nejlépe osvojí, porozumí jí, ne se ji jen naučí.
Když jsem chodil na teorii míry, měl přednášející zásadu, že na jedničku by měl student být schopen něco vymyslet sám. Takže když student vypadal, že by si tu jedničku mohl zasloužit, dal mu nějaký dokázat nějaké jednoduché tvrzení, nic složitého, ale bylo to něco, co se přímo na přednášce neukazovalo. Prý bylo docela dost studentů, kteří to ani nechtěli zkusit a rovnou prohlásili, že jim dvojka stačí.
ve skutečnosti se často ptám přímo nebo na důsledky faktů, které se na přednášce objevily. Ovšem velká část studentů na přednášky nechodí.Tohle chápu u předmětů, kde je přednáška úplně k ničemu - nezdravím např. toho šmoulu, co už dneska nejspíš bude na FITu a co nám v prvním semestru přednášel algoritmizaci, kde paměťovou náročnost algoritmu vyřešil slovy, že "paměť neřešíme, máme jí dost". Jestli v životě neviděl mikrokontrolér s 256B RAM... Ale aspoň co si pamatuju, tak tohle byly spíš výjimky a nejvíc se koncentrovaly do nižších ročníků, takže váš případ to nejspíš nebude. A lidi, co nechodili na normální přednášky a pak na cvičení netušili, jak něco řešit, přestože se to na přednášce bralo - což samozřejmě zdržovalo všechny ostatní - jsem většinou měl chuť nakopat...
protože jsem v roce 2016 odmítl NDA se společností NVIDIA podepsat, tak se na specifikace přímo nepodívám, ale z diskuzí a dostupných informací je to kolo těch 250 až 300 Wattů.Já jsem se spíš divil, že to považujete za příliš mnoho. Samozřejmě to málo není, zejména pro elektroauta, ale když si to porovnám s normálními grafikami do PC, kde si výkonnější desktopové kusy vezmou 100W jako nic (a tenhle udělátor asi bude trochu výkonnější než herní grafika), tak mi to zase nepřišlo tak strašné.
Ale zde mají jak domácí úkol tak i nástroje na přípravu vlastních cvičných úloh. Připadá mi celkem smutné, že neuronová síť tvora, který se cítí na vrcholu vývojového řetězce prohlašuje za nadměrný výkon postavit se jednoduchému logickému algoritmu, který zvládá několik řádek kódu v jazyce Python.
Mně zase připadá dost smutné, že někdo, kdo napíše write-only kód funkce s šesti do sebe různě vnořenými cykly (maximální vnoření 4) a následně opovrhuje studenty, že tomu nerozumí, učí na ČVUT...
V historickém okénku mi pak chybí, že prakticky totožný (dokonce i ta optimalizační úloha na cvičeních byla skoro totožná, akorát se místo konvoluční masky počítalo násobení matic) předmět - 36APS - se na FELu (Katedra počítačů) učil už před patnácti lety a přednášky Ing. Bečváře rozhodně patřily k tomu kvalitnějšímu, co se muselo absolvovat. Nejde tedy o žádnou zásadní změnu/novinku. Ale v tom bude předpokládám zase nějaká politika FIT versus FEL.
Volíš Andreje?
Protože tohle je to samé jako dotace/daňové úlevy pro Agrofert akorát v menšim... To, že mi vadí, že jsou veřejní činitelé (obecně z daní placení lidé a instituce) ve střetu zájmů nemá se závistí nic společného. Andrejovi jeho miliardy taky nezávidim, ale vadí mi, jak se k nim dostal...
Tak osobního je na tom akorát to, že jsem tu školu vystudoval. S katedrou řízení jsem se kromě laborek z elektronických systémů, které zajišťovala pro katedru počítačů (a to ještě probíhalo stylem, že "cvičící" doktorand prohlásil: "Měřte si co chcete, ale hlavně se mě neptejte, co máte dělat, já tomu taky nerozumim. My jsme tady jenom abyste nerozkradli přístroje") prakticky nepřišel do styku. S autorem textu pak vůbec. Nicméně pokuď nějaký pedagog ve vztahu ke svým studentům veřejně prohlašuje toto:
Studenti si stěžují na nedostatek materiálů a nedostatečnou přípravu ke zkouškové písemce. Ale zde mají jak domácí úkol tak i nástroje na přípravu vlastních cvičných úloh. Připadá mi celkem smutné, že neuronová síť tvora, který se cítí na vrcholu vývojového řetězce prohlašuje za nadměrný výkon postavit se jednoduchému logickému algoritmu, který zvládá několik řádek kódu v jazyce Python. Analýza vzájemné závislosti dvou instrukcí je vyřešená ve funkci depanalyze() na 13 řádkách kódu. Kompletní analýza sekvence instrukcí je bez použití přeposílání vyřešená ve funkci analyze() na 26 řádkách kódu. Pro případ s přeposíláním ale s latencí jeden cyklus mezi načtením a dostupností hodnoty čtené z paměti pak ve funkci analyze_stall_forward() pak vychází na 43 řádek kódu, ale pro tvora vybaveného přirozenou inteligencí je ještě jednodušší než předchozí případ.
aby se následně ještě ukázalo, že těch "pár řádků" je ve skutečnosti pěknej "guláš", tak to by asi nemělo úplně projít bez povšimnutí bez ohledu na to, jestli se jedná o mojí alma mater či nikoliv.
Co se týče těch "malejch domů", tak to už za doby mých studií bylo veřejným tajemstvím, že to takhle na některých katedrách funguje. Asi bych nad tím, zejména u lidí co pro školu skutečně něco dělají nad rámec průměru, byl ochotný přihmouřit oko, ale pokuď někdo nemá ani tolik sebereflexe, že to není úplně košer a přijde mu to tak samozřejmé, že se tím veřejně "chlubí" na blogu, tak to už prostě přejít nemůžu.
S katedrou řízení jsem se kromě laborek z elektronických systémů, které zajišťovala pro katedru počítačůJo, tak něco takového si taky pamatuju - že si katedra počítačů přistrčila naprosto zbytečný předmět (náplní se překrýval s jiným v následujícím semestru, kde byla problematika vysvětlena pořádně) do nepočítačových studijních programů, ani to nebyli schopní odcvičit, ale hlavně že shrábli prachy za studenty na přednáškách, na které skoro nikdo nechodil. Ale mám za to, že ta p...aní přednášející už odešla na FIT, takže hádám, že od ní a zbytečně zabitých 40 hodin života každého ze studentů už bude pokoj...
Tak přiznávám, že odkazovaný kód nebyl napsaný jako výukový. Je to celkem ve spěchu napsaný nástroj pro to, aby pokud možno žádné dva testy ani na jednom termínu nebyly shodné, kód umí perturbace sekvencí instrukcí, ty dostává ze sady okolo 8 sekvencí pro každý termín.
Omlouvám se za asi příliš ironické konstatování, které je především i výsledkem smutku, že pro některé studenty to, co děláme, stále nestačí. Prosím, podívejte se na slajdy 37 až 45 přednášky o zřetězeném zpracování. Dále na cvičení 6. Pipeline a hazardy a zkuste si kód v odkazovaném simulátoru bez pipeline, s pipeline s různými nastaveními jednotky ošetření hazardů. Přitom výklad odpovídá odkazované učebnici. Pomůžete nám a především dalším studentům, pokud si na výše uvedené uděláte čas a řeknete mi svůj dojem.
Odkazovaný cvičení je napsané pro kompilaci externím mips-elf-gcc kompilátorem, ale loňské přes prázdniny jsem dopsal iterovaný asembler, aby studenti již nemuseli nic kromě
binárky simulátoru instalovat. Nebo dokonce i toho jsou ušetřeni, pokud použijí online verzi. Interní assembler neinterpretuje #define, řádky s #define je potřeba vynechat a místo s0 atd psát $s0. Například addi $a0, $0, 12345
. Zatím změnit text na stránce nemohu, protože se jedná o archivní verzi předchozího běhu. Jak vytvoříme kopii pro přípravu nového běhu, tak to upravím.
Můj zápisek je motivovaný právě zájmem o zpětnou vazbu, poukázku na chyby a nápady jak dále lépe.
Co se týče vašeho silného tvrzení, že výroba kitů je malá domů, tak právě arbitra, aby z mojí firmy nebyla klasifikovaná jako obohacování potřebuji. Pokusím se Vám poslat podrobnější data k zadání a vyúčtování výroby přípravků a věřím, že provedete rozbor a napíšete, jak to vidíte z vaší strany. Nechci veškeré materiály, minimálně zatím, publikovat veřejně, protože bych pak neodpustil přidat některá vlastní silná tvrzení. A můj primární zájem je hledat tu pro studenty a jejich znalosti nejlepší cestu dále.
Hlavní důvod, proč chci pokračovat dále i přes značné problémy, je právě možnost studentům něco předat a to, že z těch asi 800 studnetů předmětu APO a stovky dalších v bývalých předmětech OSP a POS, vím minimálně o 20, u kterých jsem mohl alespoň nepatrně přispět k tomu, že jsou již mnohem lepší než já (návrh HW microtreadingu pro ESA, správa firmware a updatů Turris, vývoj do Linuxového jádra ve firmě Avast, atd..). Někteří z těch již lepších než jsem já, mi nyní přichází zpět do školy pomoci. Chci další generaci dát to nejlepší vedení na cvičeních, které mohu sehnat, a třeba i pokud bych na to již sám neměl, tak i ty nejlepší přednášející.
Různé RAW/WAW/WAR hazardy v pipeline jsem už řešil před 15 lety v 36APS u Ing. Bečváře a dnes nevidím moc důvod si to zopakovat . Je dobré vědět jak to přibližně funguje, ale potřebu jít takhle nízko jsem v praxi nikdy neměl a s narůstající "inteligencí" překladačů a mikrokódu CPU se ta šance každým rokem snižuje. Jestli ale chcete konstruktivní připomínku k předmětu, tak tam jednoznačně chybí paralelní architektury. Před těmi 15 lety byl pro nás multicore CPU SCI-FI, ale dneska je to hlavní směr ve zvyšování výkonu a předmět by to měl reflektovat. Těžko to ale můžete vmáčknout při stávajících nárocích do toho samého předmětu (netušim, jestli je teď na FELu nějaká analogie legendárních PARů, kde by se to probíralo).
Co se týče toho střetu zájmů, tak právě proto, aby nikdo nemusel ty zakázky kontrolovat a hodnotit, jestli je to předražený/výhodný nebo ne (podezření tu bude vždy), je to ve slušné společnosti paušálně zakázáno. Prakticky každá větší firma na to má vnitřní regule a u státu by to mělo platit dvojnásob. Chápu ale, že v zemi, kde premiér do správní rady dosadí manželku a tváří se, že tak nemá žádný vliv, se to těžko vysvětluje...
je to ve slušné společnosti paušálně zakázánoProtože je lepší místo toho, abych dal zakázku někomu, o kom vím, že ji udělá dobře, zadávat zakázky náhodným firmám a doufat... U zakázek za statisíce se tomu vyhnout nejde, ale tohle asi nebude ten případ...
Dobrý den, díky za názor. Předmět 36APS je v zásadě přes pana docenta Šnorka a Michala Štepanovského jedním předchůdců předmětu APO. Protože se jedná v podstatě o základy, tak je dost možné, že určitý překryv i v některých materiálech stále je (v pokročilých architekturách stále referenci na Ing. Bečváře asi na dvou místech uvádíme).
Výklad pipeliningu je ale kompletně nově zpracovaný Michalem Štepanovským. Obrázek procesoru je vlastní grafika podle výklady v knize CA. Grafika pro hazardy vychází přímo rozložením prvjů z knihy.
K muticore: Aktuální průchod studiem OI Povinné předměty programu. Tento průchod zahrnuje ve čtvrtém semestru předmět Paralelní a distribuované výpočty (B4B36PDV). Zároveň popis procesů a vláken je součástí předmětu Operační systémy.
Máte však pravdu, že by bylo dobré informace o více-jádrovém hardware přidat do předmětu APO. Něco málo jsem přidal dříve v přednášce o sítích (SIMD, ...), ten obecný pohled na sítě od WAN po multicore již v APO potřeba možná není, protože studenti mají na sítě jiný předmět. Ale v něm se spíše neuvažuje o tom, že PCI Express a multicore přes HyperTrasport je vlastně také síť a třeba pro PTP znamená větší jitter, než hardwarovým doplňováním a známkováním paketů vybavená Intel ETHERNETová karta.
Popis paralelizmu na úrovni dnešních procesorů a paměťových systémů přináší magisterský předmět B4M35PAP - Pokročilé architektury počítačů. Ani tento předmět jistě také dokonalý není.
Zvážím jak nějaké minimum i do kurzu APO přidat. Alespoň jako "hint" pro ty lepší studenty. Naopak do zkoušky nebo domácích úkolů takové požadavky přidávat vidím jako již zbytečnou zátěž pro již dost zatížené studenty.
Jinak souhlasím s tím, že pipelining je základ a je většinou zvládnutý na úrovni kompilátorů. Je však i určitá šance, že některý absolvent bude do vývoje kompilátoru nebo architektury procesoru přispívat. Hlavní je, aby většina měla spíš přehled, jak HW pracuje. Princip pipeliningu má ale i obecnější využití mezi procesy, uzly cloudu atd.
Dále by mě opravdu zajímalo, jak jako Vy i ostatní jako již profesionál v oboru zhodnotíte naše aktuální učební pomůcky, rád se na to i sejdu. Zaregistroval jsem na letošní https://installfest.cz/if20/ dvouhodinový workshop na téma výuka APO a QtMIPS a rád bych interaktivně zkusil nejlépe i s odborníky projít, co děláme a jaké jsou jejich názory. A rád bych hodně času věnoval otevřené diskuzi. Tak pokud wokshop projede hlasováním, tak rád Vás i ostatní uvidím a vyslechnu si názory a kritiku. Můžete jimi přispět budoucím studentů i těm z aktuálního běhu. Předpokládám, že i někteří z nich přijdou.
Připravuji e-mail s podstatnými informacemi k zhodnocení ceny kitů. Probíhá teď rozhodnutí o dalším nákupu, již za normální cenu, to je desetkrát větší než bylo původní prohlášení za kolik kity dodám aniž mi byl daný prostor k diskuzi, a minimálně o 50% vyšší než byla nakonec na popud kolegy z fakulty zaplacená částka za výrobu mému kolegovi. Možná i stovky hodin vývoje a i ladění s naší technikou nebyly mojí firmě zaplacené nikdy a vzhledem k možnému nařčení z konfliktu zájmu jsem o požadavku platby za vývoj neuvažoval minule ani nyní.
Měl jsem na mysli něco jako je ta druhá půlka B4M35PAP. To co je v B4B36PDV jsou v zásadě o topologie osekané staré PARy a bere se tam něco trochu jiného, než jak funguje moderní vícejádrový CPU. Ale pokuď ten předmět začíná u doplňkového kódu, tak dostat se až tak daleko je asi nereálné. I když některé další části budou asi taky dost "z rychlíku", protože jenom samotná reálná čísla by klidně mohly být na celý semestr...
Dále by mě opravdu zajímalo, jak jako Vy i ostatní jako již profesionál v oboru zhodnotíte naše aktuální učební pomůcky, rád se na to i sejdu.
Ty pomůcky by měli hodnotit především ti, pro které jsou určeny, a kteří s nimi tráví nejvíce času, tedy studenti.
Připravuji e-mail s podstatnými informacemi k zhodnocení ceny kitů. Probíhá teď rozhodnutí o dalším nákupu, již za normální cenu, to je desetkrát větší než bylo původní prohlášení za kolik kity dodám aniž mi byl daný prostor k diskuzi, a minimálně o 50% vyšší než byla nakonec na popud kolegy z fakulty zaplacená částka za výrobu mému kolegovi. Možná i stovky hodin vývoje a i ladění s naší technikou nebyly mojí firmě zaplacené nikdy a vzhledem k možnému nařčení z konfliktu zájmu jsem o požadavku platby za vývoj neuvažoval minule ani nyní.
Právě proto se principielně nedělá, že je někdo někde zaměstnaný a externě tam ještě odvádí další práci. Rozlišit co by mělo být jak placeno prakticky nelze a vždy vzniká obrovský prostor pro spekulace...
Dobrý den, děkuji za diskuzi. Data k posouzení jsem v pondělí poslal na e-mail, který si myslím, že Vám patří.
Souhlasím s tím, že cena je vysoká. Jak mít za daných požadavků použitelný HW za méně jsem nezvládl zařídit.
Stále dosluhují dotované Altera DE2, existují i relativně levné desky se SoC a FPGA, ovšem zadání bylo Xilinx a aby SBC odpovídal architekturou i velkým UltraScale, které jsem vybral a nakoupil pro projekt, který s lidmi odešel (z nichž jsem mnoho do týmu přivedl) z FEL (viz info) na CIIRC[*1]. Obecně pak komunita kolem MicroZed mi připadala silná a další kolegové již Zynq používali a měli znalosti. Jinak za sebe asi raději Quartus než Vivado. Ale s Xilinxem mám více zkušeností. Přitom ty malé education kity pro Linux a VxWorks, které byly požadované pro další předmět, většinou nejsou dobře použitelné.
Pokud máte další dotazy, tak se ozvěte na e-mail. Pokud posouzení provedete a máte zásadní výhrady, tak je můžeme diskutovat zde, nebo se ozvěte panu profesorovi Jiřímu Matasovi, který bude další nákup posuzovat a můžete místo mě jednat s firmou Evermax o ceně dodávky desek a o ceně oživení a kompletace s Ing Petrem Porazilem. Stejně jako minule, se PiKRON účastní pouze nepřímo a pro mě se jendná jen o práci a starosti (+ potěšení z toho, že něco pěkného vznikne pro projekty a studnety) a know how, které stejně převážně vzniklo a vzniká mimo školu, třeba někdy použiji i ve firmě.
[*1]Jak probíhalo vyučování a vyrovnání na úrovni FEL a CIIRC při přesunu projektu nevím a vlastně mě ani nezajímá. Stále mě ještě trochu zajímá, jak je to s právy ke kódům ostatních projektů - často (často se jednalo o DP, do kterých jsem sehnal studenty, vedl je a ve skupině přispíval). S DP v použitelné podobě, ale kvůli (sice neexkluzivním vztahům a obchodování) s průmyslovými partnery v použitelné podobě publikované být po rozhodnutí doktora Michala Sojky a pana profesora Zdeňka Hanzálka nemohly. Když jsem je chtěl nabídnout jiné univerzitě, čekalo jen mlčení a nejspíš již skončily v zamknutém šuplíku včetně praktických výsledků vědeckých prací a demonstrátorů pro firmy, které vznikly na FEL a sloužuïly k propagaci skupiny. Ale cena roků investovaných do těchto prací klesá a nejspíš rozpadnou se stejně v prach, jako mnoho jiného, co jsem pro skupinu dodal, přinesl.
Jinak aby bylo jasno, já si samozřejmě taky myslim, že kvalita dnešních studentů strukturovaného studia je tragická (stejně jako si to o nás myslela ta generace, která ještě musela dělal souborné zkoušky...), ale je diametrální rozdíl jestli to veřejně prezentuje vysokoškolský pedagog o svých studentech v polooficiálním popisu předmětu, nebo já tady v diskuzi...
kvalita dnešních studentů strukturovaného studia je tragickáJenže takové prohlášení je samo o sobě docela k ničemu. Ti studenti za to sami nemůžou, může za to systém studia, který od nich něco (ne)vyžaduje a něco po nich (ne)chce. A jsou profesoři, kteří nad tím jen mávnou rukou a hodí to na studenty a jsou profesoři, kteří se rozhodnout tomu pomoci. Třeba já jsem vystudoval fyziku prezenčně, ale spoustu věcí jsem pochopil a dal si do souvislostí až ze záznamů přednášek profesora Kulhánka, který hned v první hodině prohlásí: zapomeňte na všechno co víte, uděláme to celé znovu od nuly. A udělá to. Stejný přístup někde prezentoval i profesor Putna (v úplně jiném oboru), že nechce být stejný jako ostatní vyučující, ale že on to ty studenty prostě naučí bez ohledu na to, co už mají umět před nástupem do jeho kurzu. A tento přístup je podle velmi správný. Místo rezignovaného "njn, to jsou dnešní studenti" se pokusit s tím něco udělat.
Však ten bohorovnej přístup: "já to dělám dokonale, to jenom ti studenti jsou neschopný" je to, co mě v tom původnim příspěvku tak vytočilo. Protože si stále ještě z doby svých studií pamatuju, že často tomu tak fakt nebylo. Někteří vyučující si ale odmítali byť jenom připustit, že důvod, proč nikdo nechodí na jejich přednášky není, že by na to studenti tak kašlali ale tragická úroveň těch přednášek.
Na druhou stranu k tomu aby si studenty něco naučil tam musíš mít lidi co jsou schopný a ochotný se něco o dané složitosti naučit. Procento těch chytrých/odhodlaných bude v čase +/- stejný, takže pokuď si dáš za cíl zvýšit počet absolventů jako je trend v posledních letech, vede to automaticky na snížení nároků nebo na kolizi s realitou u vyučujících. Ty čtyry společný semestry vyhazovacích předmětů co za nás byly sice nepřinesly moc praktického užitku ale způsobily to, že s moc neschopnejma lidma se tam člověk potom nepotkával.
Takže ten problém není ani tak o kvalitě ale o množství. Těch použitelnejch lidí tam dneska bude stejně jako před 50 lety, ale k nim tam máš i masu dalších, co by tam před 50 lety nebyli (včetně mě). A ty už prostě tím, že půjdeš ve výuce důsledně znovu od základů, "nepořešíš".
Nelze si prostě myslet, že se někam posunemA kam by ses chtěl posunout a proč tomu vadí počty studentů?
Pokusy realizovat populistické heslo "zvýšíme procento vysokoškolsky vzdělaného obyvatelstva" ve výsledku nevedou ke vzdělanější populaciTo asi záleží co se tím myslí a co kdo chtěl za výsledek. Přijde mi zvláštní, pokud by se se zvýšeným počtem studentů na nich přece jen neulpěla nějaká myšlenka nebo znalost. Vlastně moc (možná naivně) nevěřím tomu, že by se do určité kritické masy nedalo nahustit vůbec nic. Viz třeba legendární díl Ano Šéfe S6E02 - Učiliště Trmice, kde i s deckama, nad kterými i ředitel zlomil hůl, dokázal něco udělat a několika z nich změnit kariéru, kterou by jim škola s vyhořelým ředitelem ani omylem nedala.
ke snižování nároků a devalvaci toho, co takové "vysokoškolské vzdělání" znamená.Jasně, ten papír má mnohem nižší hodnotu. Na druhou stranu, pokud někdo chce přikládat váhu papíru, tak asi dělá něco špatně. Já svůj titul nepoužívám, někde po mě chtěli přinést diplom, protože to nemám v občance, tak jsem s tím přestal šermovat.
třeba legendární díl Ano Šéfe
jojo slavný hrníčkový elpaso babičina zlatýho řetízku :D :D :D :D videjko
Ad trmice ... to je nahodou krasna ukazka schopnyho vs neschonyho "ucitele". Vem si, ze se to toci par dnu, zkus si predstavit, ze by si je vzal do parady na par mesicu. A co vic, ono by je to (casto prave ty "odepsany") zacalo i bavit.Ano, přesně z tohoto důvodu jsem to sem dal. A krásný díl je i "Návraty", kde se ukazuje, že ředitel té školy nemá nejmenší páru co tím chtěl Zdeněk vlastně říct. Hlavně že furt blábolí cosi o studijních předpokladech a o tom, proč s výučním listem na kuchaře vlastně nemají umět ani zapnout konvektomat (což je Poly naučil za 5 minut).
A kam by ses chtěl posunout a proč tomu vadí počty studentů?
Směrem k vyspělým (nebo lépe řečeno bohatším) západním státům. V zásadě je toto dnes mainstreamový politický názor, že západ doženeme jenom zvýšením vysokoškolsky vzdělané populace. Já ale dlouhodobě pozoruju, že rozhodující je kvalita, ne kvantita. Pokuď z FELu polezou kvanta programátorů mobilních/webových appek, nikdy nebudeme tou zemí, kde probíhá ten state-of-the-art vývoj, který si můžeš nechat draze zaplatit (protože ho nikdo jiný vůbec nedokáže). Počty pak vadí v tom, že samozřejmě rozmělňujou zdroje (peníze a čas kvalitních pedagogů) vynaložitelné do vzdělání těch "kvalitních" lidí.
Celé to má samozřejmě spoustu otázek, jako například kde je ta hranice "kvalitních" lidí, co s těmi ostatními, případně jak to implementovat (Německý model Univerzita/Fachhochschule?).
Směrem k vyspělým (nebo lépe řečeno bohatším) západním státům.Tomu rozumím, ale nerozumím, proč tomu vadí počty studentů. Česká věda se potýká s úplně jinými problémy, přidělování grantů, publikuj nebo zemři, politická (ne)podpora, vůbec to, jak se ve veřejném prostoru o vědě mluví apod. Tohle nemá s počty nic společného. A přijde mi, že počet studentů je oblíbený zástupný problém uváděný těmi, kdo by stejně tu špičkovou vědu ani nedělali. Jinými slovy, kdybychom nějak snížili počty studentů, tak se na straně jedné sníží dostupnost vzdělání, a na druhé straně se nestane vůbec nic. Protože špičkové týmy na světové úrovni tu máme i dnes a potýkají se s úplně jinými problémy, než je tento.
Pokuď z FELu polezou kvanta programátorů mobilních/webových appek, nikdy nebudeme tou zemí, kde probíhá ten state-of-the-art vývoj, který si můžeš nechat draze zaplatit (protože ho nikdo jiný vůbec nedokáže).Viz výše. Je klidně možné, že ti lidé objektivně na více nemají, takže je lepší, pokud z nich budou alespoň vývojáři webových appek, než nikoliv. A v praxi vidím (na kamarádech i kolezích v práci apod.), že je lepší mít třeba jen rok nedokončeného studia informatiky než ho nemít. Protože už v tom prvním roce narazí na algoritmy a složitosti, na cvičení si uvědomí, že je velký rozdíl mezi O(log(n)) a O(n^2) a alespoň trochu se jim to vleje do mozku. Naopak lidi, kteří tvrdí "já jsem z učnáku s maturitou a na rozdíl od tebe jsem zbytečně neztrácel čas na škole" tohle jen těžko chápou a je jim to vlastně jedno. Takže i webvývojář z FELu je ta lepší varianta.
Celé to má samozřejmě spoustu otázek, jako například kde je ta hranice "kvalitních" lidíAsi tak. Dneska mi YT nabídl tohle video, podle všech studijních předpokladů měl být autoklempířem, dneska místo toho raději učí na Oxfordu. Jsem velmi zvědav, jak tohle někdo zvládne odfiltrovat (ještě před vysokou) a vědět, co je pro koho dobré.
Je klidně možné, že ti lidé objektivně na více nemají, takže je lepší, pokud z nich budou alespoň vývojáři webových appek, než nikoliv.Na to ale nepotřebují vysokou školu, bohatě by stačil jeden nebo dva předměty na vhodně zaměřené průmyslovce.
Procento těch chytrých/odhodlaných bude v čase +/- stejný, takže pokuď si dáš za cíl zvýšit počet absolventů jako je trend v posledních letech, vede to automaticky na snížení nároků nebo na kolizi s realitou u vyučujících.Mě tohle nevadí. Osobně si myslím, že možnost studovat by měl mít vlastně každý a je dobře, pokud co nejvíc lidí alespoň zažije tu zkušenost, to prostředí, ten přístup ke znalostem apod. A taky nikdo dopředu nemůže vědět, na co kdo má a na co nemá, takže nějaká předběžná segregace není dobrý nápad. Ostatně je super, že některé univerzity už i v Česku začínají přednášky natáčet (takže Kulhánek, který to dělá od roku 2003 už není moc sám) a je to tedy přístupné všem. (Jinak přednášky jsou samozřejmě veřejné, ale málokdo tam skutečně chodí, já si vlastně nepamatuju, že by k nám na nějakou přednášku přišla "veřejnost".) Jinak si myslím, že tohle (počty studentů) není téma. Dobrý učitel tohle chápe a ví, že ze všech odborníky stejně neudělá a že jestli z ročníku bude alespoň jeden, kdo výrazně přeroste, tak je to vlastně úspěch. A tohle mnoho odborníků říká svými slovy taky (slyšel jsem to od Grygara, Kulhánka, tuším i Podolského a je spousta lidí, kteří se k tomu pochopitelně nemají potřebu vyjadřovat a jen to tak dělají).
Ideální by bylo, aby si studium mohl vyzkoušet každý a ideálně v takovém kolektivu, ve kterém by byli všichni ostatní jen o něco málo lepší než uvažovaný adept a zároveň aby měl někoho, kdo je zase o něco horší, aby měl důvod mu látku vysvětlovat a tím si naučené znalosti převáděl na pochopené principy.Musím říct, že mě zaráží, že se tohle nedělá (konkrétně mám na mysli základní a střední školy, kde je minimálně ve městech vždy několik tříd v ročníku, takže by to šlo normálně setřídit a rozdělit, a přitom rozdělení bývá maximálně u jazyků), a naopak v současnosti probíraná „inkluze“ jde úplně proti tomu.
Pořád mám sice neodbytný pocit, že počet studentů jsi začal řešit až ty, zatímco ti před tebou mluvili o negativním dopadu snah zvýšit počet absolventů. Snahy zvýšit počet studentů mi až tak moc nevadí, aspoň pokud se to udrží v rozumných mezích.
Ale proč ne, dovolím si rýpnout trochu i do tohoto tématu. Kdo si někdy zkusil přednášet, dobře ví, že kvalita komunikace klesá s počtem posluchačů. Podle mé zkušenosti se to nezastaví u toho, že oborová přednáška pro deset (ale třeba i třicet) lidí je úplně něco jiného než plenární přednáška pro stovku v prvím ročníku. Dvakrát jsem něco přezentoval pro ~300 lidí (globální konference) a jsem přesvědčen, že při takovém počtu už je jakákoli interakce s publikem v podstatě vyloučená (ne, nemyslím obligátní dotazy na konci). Podobně se vyjadřovali spolužáci, kteří současně s matfyzem (v ročníku nás v prváku bylo asi 120, takže na "velkých" přednáškách mohlo být tak 80-100 lidí) studovali VŠE (což byl v té době uznávaný průkopník přístupu "masovostí za rekordy"), také měli pocit, že počty ve stovkách nevyhnutelně vedou k anonymitě, jejímž výsledkem je, že - když to trochu přeženu - přednáška má oproti skriptům nějakou výraznou hodntou jen pro ty, kdo neumějí číst.
Takže si dovolím tvrdit, že i výrazný nárůst počtu studentů může mít negativní vliv na kvalitu výuky. (Což říkám při plném vědomí toho, že takový názor je v dnešní době velmi nepopulární a jde proti tomu, co "se ví".)
Takže si dovolím tvrdit, že i výrazný nárůst počtu studentů může mít negativní vliv na kvalitu výuky.Ja bych byl jeste prisnejsi. Jakou uroven muze mit cviceni, kde to realne zajima 2 lidi z 20? Jakou muze mit uroven skola, kde je hlavni ideou "jenom to zkusit"? Ono se to samozrejme odrazi i v zamereni samotnych studijnich programu, ktere vede k tomu, ze se skola snazi suplovat prakticke kurzy, nebo to co by si mohli zamestnavatele resit sami. Takze po trech letech ti z Bc. vypadne absolvent, ktery toho umi stejne, jak nekdo po roce v praci. Masovost jde proti kvalite, ale tezko s tim bojovat v dobe, kdy kazdy ma pravo na vsechno.
Tak pro QtMIPS vychází délka souborů na serveru
qtmips_gui.html 2.8K qtmips_gui.js 294K qtmips_gui.svg 15K qtmips_gui.wasm 12M
Nativní program pro x86_64 Gnu/Linux pak
text data bss dec hex filename 1344321 56712 25888 1426921 15c5e9 qtmips_gui
To je 1.5 MB, ale sdílené knihovny Qt5 zabírají asi 21 MB. Statický build teď po ruce nemám.
Těch 12 MB nakonec při uvažování zakompilování celých Qt5 (tedy vlastně jen Core, DBus, Gui, PrintSupport, Widgets, a XcbQpa + libelf + libpcre + musl libc) není až tak moc. Na druhou stranu v Kathmandu na slabé síti se to stahovalo snad 10, 20 minut.
Potíž jsou zatím v našem emulátoru grafické artefakty v canvasu. Jestli za ně mohu já, Qt nebo implementace WebGL v některých prohlížečích zatím nevím.
Moderní hipsterský programátor, pro kterého není problém aplikace v Elektronu co na textový chat potřebuje 1GB RAM, se bez těch znalostí samozřejmě obejde, ale od inženýra bych alespoň základní znalost toho, jak moderní processor funguje očekával... Prakticky takové optimalizace možná bude dneska řešit jeden člověk z ročníku, ale pokuď si ty ostatní odnesou alespoň to, že existuje něco jako profiler a je dobré se do něj občas podívat (i když v praxi zjistí, že bottleneck téměř nikdy není někde takhle nízko), tak mi to jako ztráta času nepřijde.
teda presne do okamziku, kdyz pracovaly s nejakou poloprazdnou demodatabaziJsem si vzpomněl na video o novém webu pro jednu takovou firmu. Něco jako Bell, nebo Cell, nebo tak nějak
80% lidí v IT dělá spíš nevývojářskou činnost, ať už je to byrokraticie s psaním dokumentů, dokumentace či manuální testováníI mezi lidmi co na to vystudovali high-endovou školu? Fakt? A pokud ano, není to blbě?
Ve skutecnosti nejde o to, co umi/znaji ITci, ale o to, co zada trh. Prijde mi naprosto padly na hlavu napriklad vyucovat obory/predmety zaobirajici se trebas tvorbou CPU ... protoze to ani ten jeden z toho rocniku delat nebude, jednoduse proto, ze nema jak se k tomu dostat.
Překonat D1 není žádná sranda, ale legendy vyprávějí, že se to některým povedlo. Dokonce jsem i zaslechl, že se v Brně dá trvale žít... Codasip
Do CODASIP se dvěma studenty z minulého běhu předmětu zítra jedu. Dále jedou kolegové, kteří budou cvičit, a Michal Štepanovský z FIT. Připravujeme tým pro switch předmětu na RISC-v.
Jeden z externích cvičících na letošní běh je i Roman Bartosinski, před lety můj diplomant. Kód svojí diplomky stále používá, z několika firem, kde i tento kód používají, byly i nějaké další jeho práce po ukončení studia placené a se mnou pro mojí firmu také jeden čas na větších projektech pracoval. Přesto, že se jednalo o čistě komerční projekt a my žádné dotace nedostali, tak ten zásadní kód, který za peníze psal, měl k dispozici i pro své případné projekty mimo firmu (viz licence). Před časem, když jsem vytvořil pro firmu skupinu na GitLabu, tak jsem i kód, nyní spíš již jen jako archivní, v přidal https://gitlab.com/pikron/sw-base/suitk.
Ve své vlastní firmě ze pak zabývá zpracováním obrazu na FPGA a také pro Evropskou vesmírnou agenturu vyvíjel rozšíření architektury SPARC o microthreading, viz kniha UTLEON3: Exploring Fine-Grain Multi-Threading in FPGAs.
S Jiřím Gaislerem (autorem SPARC Leonu) se zná a sám jsem se s ním také "potkal" v e-mailech při diskutování ohledně RTEMSu.
Takže i přímo pro vývoj architektur se znalosti hodí i pro ty co zůstali v Čechách. Někteří se ale vypraví i za hranice, další můj diplomant u mě pracoval na FPGA a potom jsem mu psal doporučení na zelenou kartu do USA, kde nejdříve u Intelu a potom u Apple navrhoval zpracování obrazu určené pro implementaci v na míru navržených čipech se zaintegrovanou ARM architekturou.
A i pokud vysloveně pipelining nebo low level nepotřebujete ani k té představě, jak počítače chodí, tak minimálně je to hezká a milá rozcvička alespoň trošky paralelizmu a sekvenčního chování. V realitě toto může být u clodových technologií a dalších frameworků na pochopení mnohem složitější a často mnohem hůře dokumentovaný stavový automat, než ten maličký a elegantní RISCový CPU.
Electron framework sám neznám, ale hned v popisu na Wikipedii There is the "browser" process and several "renderer" processes, aha takže fronty požadavků a paralelizmus a třeba i něco jako pipelining, aby busyness logika nebyl trvale brzděná renderingem. Hmm, není to podobné problémům se zparcováním instrukcí. Most of Electron's APIs are written in C++ or Objective-C and then exposed directly to the application code through JS bindings. Hmm, nebude při ladění a třeba někdy i při vývoji potřeba nakonec nahlédnout do zdrojových kódů v jazyce C? Při průchodu dokumentací, to je na dlouhé čtení, opět, kdo nedokáže přečíst pár stránek třeba o pipeliningu, nebude mít starosti i s takto velkým systémem. OK, když bude jen kopírovat a skládat cizí příklady, tak možná nebude dokumentaci muset číst nikdy.
Co se týče velikostí aplikací, tak právě s výše uvedeným kolegou jsme to SuiTk psali jako grafickou knihovnu (včetně signal slotů) pro infúzní pumpy, kam jsme si netroufli v té době dát GNU/Linux. I včetně OS RTEMS byl pak firmware celé pumpy asi v 5 MB kódu, přitom velkou část zabírají zakompilované předrenderované fonty. Jádro knihovny pak zvládá signály a událostmi řízený objektový model i na jiných zařízeních s 64 kB RAM, kam se musí ještě vejít časový program LPC520. Takže věřte, že o kompromisech mezi místem, použitými knihovnami a prostředky jsme se něco naučili.
A ano, dnes pro mnoho zařízení je možné použít třeba Qt a GNU/Linux a je to mnohem jednodušší a graficky povedenější. nebo i tu webovou aplikaci. Na druhou stranu, pokud je potřeba dostat grafiku do vypínače světel, tak se opět z důvodu ceny řeší, jak použít DMA na LPC pro alespoň trochu akceleraci na procesoru s 64 kB RAM a jsou firmy, které takové optimalizace na Embedded Wordu předvádí a nabízí.
PS: Všiml jsem si, že jsem včera večer nadělal překlepů mnohem více než obvykle. Weekend jsem trávil na Tolkienconu a trochu jsem se nechal unést posloucháním koncertování v Roklince a moc se nevyspal. Ale stálo to za to.
Odkaz na pumpu jsem dal špatně, ta odkazovaná má ekvivalent textových turbovisions napsaný v assembleru na 80552 (8051), to je z doby, kdy jsme nemohli slušný procesor pro vyskou cenu do zařízení použít, zdrojový kód té staré pumpy je zde https://gitlab.com/pikron/projects/sw51-pbproj/blob/master/lp2/lp.asm a zde https://gitlab.com/pikron/projects/sw51-pbproj/tree/master/pblib, počáteční verze kódu první pumpy a detektoru LCD4000 https://gitlab.com/pikron/projects/sw51-pbproj/tree/master/sf, pochází z doby, kdy jsem studoval první a druhý ročník na FEL, takže to vlastně odpovídá věku studnetů, které teď sám učím.
Fotka přístroje s LPC1768 a grafickou knihovnou SuiTk je zde http://pikron.com/pages/products/hplc/lcp_5024.html.
Podle mne je především zásadně pochybená už sama představa, že studium na vysoké škole by mělo obsahovat výhradně to, co student následně přímo použije v praxi.A jakým způsobem bys teda určil, co by se mělo a nemělo učit na škole? (Tím tvůj komentář nechci rozporovat, jenom mi to z toho není jasný.)
U vysokých škol bych to nechal z velké části na nich. (S tím, že samozřejmě pořád musí existovat nějaký akreditační proces jako dohled, jestli se někdo nesnaží provozovat samoobsluhu na tituly.)
Můj komentář byl míněn především jako kritika takového toho tvrdě praktického přístupu ve stylu "je nesmysl učit všechny céčko, protože většina v céčku programovat nebude", který se tu občas objevuje. Takový pohled považuju za zhoubný i na technice (která má z podstaty věci k praxi trochu blíž), natož na škole typu MFF UK.
Přitom největší nezájem o předmět vnímám právě u studentů, kteří se vidí jako budoucí významní programátoři mobilních a webových aplikací a cloudových technologií. Neumím si představit, jak chtějí tito, často na svoje schopnosti až příliš spoléhající, programátoři takovéto aplikace navrhovat.Zkuste si nekdy takovou aplikaci naprogramovat. Zkuste si udelat treba nejakou malou appku pro Android, ktera bude pristupovat k nejake cloudove sluzbe. Mozna budete prekvapeny, jak neuveritelne daleko jste od skutecneho hardware a jak odlisne znalosti potrebujete. V takovem prostredi se neda moc uvazovat o cache a poradi instrukci procesoru (a pokud to nekdo dela, je to obvykle spatne). Dtto informacni systemy v jave, webove aplikace v php, cloudove aplikace v pythonu. Co si budem nalhavat, programovani v C, C++ na te nejnizsi urovni je domenou stale mensiho mnozstvi programatoru (i kdyz chapu, ze na CVUT to muzete vnimat jinak). Myslim, ze by tomu sluselo rozdeleni na dva predmety -- to opravdove minimum, ktere by meli znat opravdu vsichni programatori a pak pokrocilejsi partie pro ty, kteri se budou venovat nizkourovnovemu programovani.
programovani v C, C++ na te nejnizsi urovni
Pro zajímavost: aktuální topic našeho IRC kanálu zní
If C is a low level language to you then you have no idea how deep this rabbit hole really goes.
:-)
If C is a low level language to you then you have no idea how deep this rabbit hole really goes.To moc dobre vim, ... teda tusim.
programovani v C, C++ na te nejnizsi urovniDovysvetlim. Byla tim myslena podmnozina programovani, kde clovek opravdu musi resi vlastnosti hardware, cache, atp. Takove programatory taky potrebujeme, ale je dobre, ze vetsina programatoru takove veci uz resit nemusi (ehm, electron, je druhy extrem).
V první řadě děkuji všem za zájem o předchozí zápisek ...Um,... ten je kde?
hele ;D
Druhý úkol je zaměřený na optimalizaci/minimalizaci počtu výpadků vyrovnávací paměti při realizaci algoritmu ostření obrázku. (...) a aby absolventi díky znalostem chování procesorů, vyrovnávacích pamětí i vstupně výstupních subsytémů programovali aplikace s větší propustností, menšími nároky na pamět, energii (baterie) atd.Proč má ten předmět takovej důraz na psaní optimalizovaných programů? Není právě od tohohle předmět Algoritmizace, Pokročilá algoritmizace a podobně?
Do budoucna máme zájem kurz aktualizovat a pro výuku využívat otevřenou procesorovou architekturu RISC-V.Co si myslíš např. o této kritice RISC-V? Můj dojem je, že suverénně hlavní důvod propagace RISC-V je otevřenost a vlastním návrhem se zabývá velmi málo lidí, případně často prosazují dogma o dobrém RISCu a špatném CISCu. Tím nechci říct, že RISC-V je špatná volba. Já tý platformě taky fandim, i přes případné problémy. Že by se s tim ale student setkal později v praxi považuju spíše za nepravděpodobný. O tomhle ale zřejmě víte, vzhledem k tomu, že v úkolech vidím práci s x86.
Nejvíce mě pak zajímají názory těch, kdo již měli možnost znalosti využít v praxi.Tohle je tak obecná otázka, že na to IMO nemůžeš dostat moc dobrou odpověď, resp. dostaneš odpověď podle zaměření daného člověka. Někdo, kdo píše operační systém nebo něco těžce algoritmickýho nebo podobně ti řekne, že to je super, případně, že bys měl ještě přitvrdit. Kdo vyvíjí mobilní aplikace, řekne ti, že zatěžuješ studenty věcma, který nebudou potřebovat. Kdo vyvíjí backend služeb, řekne, že řešit výpadky cache je sice cool, ale reálně potřebuje člověk řešit správně zvolené schéma databáze, správně napsané queries, správně vytvořené indexy a podobně. Osobně pracuju v oblasti, kde low-level věci potřebuju občas řešit (třeba tady jsem potřeboval znalost arm assembly a další příbuzné věci), ale nemam to na každodenním pořádku. Takže ano, věci, které učíš, využiju, ale obecně nevim, co poradit, protože to zaměření je pak v praxi hrozně různé a jiný lidi dělají různými směry diametrálně odlišnou práci. Taky nesouhlasim úplně s tím, že ty znalosti jsou tak hodně přenositelný a že i aplikace v Electronu řeší stejné problémy. Principielně a na velmi obecný úrovni by se dalo asi říct, že jo, ale ty detaily a technologie jsou jiný. Navíc mi to řešení výkonu programů do předmětu 'Architektura počítačů' zapadá jen okrajově. Tam bych viděl spíš jako důležitý principy fungování, s tím, že případný benefit v rychlosti software může být příjemný vedlější efekt. V praxi IMO stejně rychlost softwaru je daná především tím, co je zaměstnavatel programátora ochoten zaplatit / jak moc velkou priroritu je ochoten tomu dát, spíš než tím co se student naučil v druháku na bakaláři.
Druhý úkol je zaměřený na optimalizaci/minimalizaci počtu výpadků vyrovnávací paměti při realizaci algoritmu ostření obrázku. (...) a aby absolventi díky znalostem chování procesorů, vyrovnávacích pamětí i vstupně výstupních subsytémů programovali aplikace s větší propustností, menšími nároky na pamět, energii (baterie) atd.Proč má ten předmět takovej důraz na psaní optimalizovaných programů? Není právě od tohohle předmět Algoritmizace, Pokročilá algoritmizace a podobně?
Sohlasím s dalším, že hlavní smysl je porozumění. Co se týče cache, tak myslím, ta demonstrace za živého sezení z Linuxdays 2019 na úrovni sčítání dvou osmi položkových vektorů je (snad) správnou snahou ukázat problém na mikroúrovni a pak podobný nechat studenty řešit na úrovni aplikační a mohlo by to (snad) prospět k propojování znalostí a uvědomění si té spojitosti.
Do budoucna máme zájem kurz aktualizovat a pro výuku využívat otevřenou procesorovou architekturu RISC-V.Co si myslíš např. o této kritice RISC-V? Můj dojem je, že suverénně hlavní důvod propagace RISC-V je otevřenost a vlastním návrhem se zabývá velmi málo lidí, případně často prosazují dogma o dobrém RISCu a špatném CISCu. Tím nechci říct, že RISC-V je špatná volba. Já tý platformě taky fandim, i přes případné problémy. Že by se s tim ale student setkal později v praxi považuju spíše za nepravděpodobný. O tomhle ale zřejmě víte, vzhledem k tomu, že v úkolech vidím práci s x86.
Když jsem se o RISC-V bavil s Tomasem Gleixnerem, tak měl k jeho paměťovému modelu také výhrady. Něco se trochu mezi verzemi specifikace změnilo, minimálně je prostor pro to nastavovat typ operace s hlediska paměťového modelu. Ale posoudit to komplexně nedokáži.
S tím, že indexace (adresování register + registr ideálně s posunem) chybí, souhlasím. Ale není to tak velký problém, jak je to ukazované. Na ARM/AArch64 to budou dvě 32-bitů dlouhé operace. Přitom u AArch64 o něčem jako Thumb nepřemýšleli a již to nejspíš nejde přidat (volný bit v kódování nečekám). A i ARM32 Thumb je s granularitou celé funkce/bloku. RISC-V přístup jde o hodně dál. Na většině implementací RISC-V (C je většinou počítané) vyjde sekvence nejspíš na 1x 32-bitů a 3x 16-bitů, to není o tolik delší. Stejně tak postinkrement a predekrement, chybí, ale kombinace obyčejného 16-bit kódovaného LW/SW a 16-bit přičtení je OK. Přitom opravdu vyjde dekodér jednodušší a SW pak nemá tři a nebo dokonce víc vstupních závislostí. Takže z hlediska kompromisu, bych celkem věřil, že volby RISC-V jsou v pořádku. Ale jasně, je to jen pocit a ani žádná analýza těch chytřejších, než jsem já, vše nepodchytí. Opravdu to ukáže až čas. A tam je zase problém, že často je technické ohodnocení pokřivené finanční stránkou.
Nejvíce mě pak zajímají názory těch, kdo již měli možnost znalosti využít v praxi.Tohle je tak obecná otázka, že na to IMO nemůžeš dostat moc dobrou odpověď,
jasně, jednu určitě ne, ale vzniká nějaký přehled názorů a ten je důležitý jak pro mě, tak třeba i pro studenty. Ano, jsem si vědom toho, že zde, na ABClinuxu spíš asi ovlivněný ve prospěch předmětu. Ale já nevím, kde jinde se moc zeptat. Znám ROOT, ABClinuxu a pak LWN. Do předloňska jsem na firmu kupoval Chip, abych měl takový ten přehled, co se se zrovna nabízí lidem, spíše ze světa Windows a her, jako zajímavé. Ale přestal jsem mít čas a i chuť se tím probírat. Zaujalo mě tam toho málo.
V praxi IMO stejně rychlost softwaru je daná především tím, co je zaměstnavatel programátora ochoten zaplatit / jak moc velkou priroritu je ochoten tomu dát, spíš než tím co se student naučil v druháku na bakaláři.
V zásadě souhlasím, ale s lidmi bez znalostí a schopnosti znalosti hledat a učit se, to dobře nedopadne.
Pro zájemce o problematiku procesorů, výuky, embedded systémů a RT řízení upozorňuji, že na letošním InstallFestu můžeme v debatě o výuce a našem přístupu pokračovat na wokshopu QtMIPS Hands on Session to Understand Computer Architectures and Discuss Its Teaching, který bude probíhat přímo v počítačové učebně, kde předmět vyučujeme.
Dále povedu workshop Embedded Linux, FPGA and Motion Control Hands-On, kde si budete moct vyzkoušet vývojové kyty MZ_APO. Představuji si, že si z nuly v C napíšeme řízení DC motoru z userspace přes mmap() periferií (něco na způsob mého článku na Rootu na podobné téma pro experimenty s Raspberry Pi). Možná pro IRC napíšeme driver. Dále si budete mít možnost na 16 kitech se Zynqem a budiči DC motorů vyzkoušet high level grafický návrh regulátoru s využitím Matlab/Simulink targetu. Předvedu i jak za běhu Linuxu rekonfigurovat s mainline+RT patch jádrem FPGA design a zavést drivery. Pár desek si i propojím CAN sběrnicí a vyzkoušíme CTU CAN FD open-hardware IP core a příslušné drivery.
Na host počítačích bude Debian Bullseye, na Zynq Buster logn term 4.19-rt jádro, vše z Diskless infrastruktury K13135.
K poslední plánované přednášce o vývoji architektur jsem doplnil odkaz na její přednesení v rámci konference InstallFest21. Vzhledem k výpadku dvou týdnů výuky v letním semestru akademického roku 2019/2020 se již do přednášek v rámci semestru nevměstnala.
Prezentace k přednášce Vývoj architektur procesorů na příkladech inovací od i4004 k Apple M1 a příštím generacím RISC-V jsou k dispozici ve formátu PDF.
Záznam prezentace je pak k dispozici zde na YouTube https://youtu.be/v2vHgf83E-0.
O vlastní samostatné práci na přípravcích MZ_APo a jejich rozšíření o další funkce užitečné k výuce přednesli příspěvek i naši studenti, (viz zprávička na webu IO Studenti OI přednášeli na konferenci InstallFest 2021)
Studenti minulého běhu také připravili propojení zkratek používaných v oboru s našimi prezentacemi a Wikipedií (Abbreviations for Computer Architectures)
V letošním běhu pak přidal videa se zkráceným výkladem pan doktor Petr Štěpán (YouTube kanál). Snahou je soustředit se především na základy nutné pro zvládnutí domácích úloh a práce v semestru a obecně nabídnout výklad vedený někým jiným, který může někomu vyhovova lée než moje snaha předávat především i širší souvislosti.
V tuto chvíli pak připravujeme pro naše studenty virtuální laboratoř pro práci s reálným hardwarem. Koncept byl testovaný v rámci workshopu Distance Hands on Session with Real Embedded Linux, FPGA and Motion Control Systems na konferenci InstallFest21 (YT, PDF). Pár fotek z provozu virtuální/reálné/vzdálené laboratoře je k dispozici na Rajčeti.