Názory k článku Modrá Twibright Ronja: výukový spoj na ČVUT
-
andy (neregistrovaný)
No ono je ale fakt, že k programování člověk ten počítač fakt nemusí otevřít a vůbec nemusí tušit, jak to elektronicky funguje. Nechali byste si operovat slepák od chirurga, který toho zas tak moc netuší o biochemii? Proč ne - operuje na jiné úrovni, biochemie k tomu netřeba.
Pokud člověk neprogramuje zrovna nějaké vysílače nebo přijímače nebo není někde extrémně low-level, tak mu může být fakt jedno, jak ta krabice vypadá zevnitř. -
robotron (neregistrovaný)
Jedna historka k lidem, povazujicim se t.c. za programatorskou elitu (studenti OI FEL, cca ~2013), kterejm je ale zaroven "fakt jedno, jak ta krabice vypadá zevnitř": prevod z/do hexa za pomoci po jednom znaku opakovanejch appendu a novejch dynamickejch alokaci stringu..
Muzete rict, ze to neni tim, ze se nezajimali o zakladni principy HW, ale tim, ze to byli proste debilove. Ale rekl bych, ze nebyli, rozhodne v prumeru nadprumerni jedinci.
Nebo, ze to byla nahoda. Ale ja mam setrvalej a stale silici pocit, ze programatori, kterejm je ukradenej aspon ramcovej princip zeleza, pisou bez vyjimky strasny nepouzitelny sracky. Zel me ted nenapadaji dalsi toto pozorovani podporujici historky (jako ta jedna vyse), ale treba bys mohl hodit do placu protipriklad kvalitniho programu nekoho, kdo se nezajima o princip CPU, pameti, sbernic,...
-
andy (neregistrovaný)
Tak pokud vim, tak na MFF je spousta dobrých programátorů a povšechně o těchhle věcích netuší vůbec nic. Můžeš si klidně přečíst system programming guide k nějakému procesoru, máš velmi dobrou představu, jak ten procesor máš programovat včetně lokality cache, cpu-to-cpu komunikací apod., a přitom vůbec nemusíš tušit, co to je tranzistor.
Pokud jde o ten převod do hexa - to taky nemá s HW nic společného. Nehledě na to, že třeba v jazycích postavených na immutability nad tímhle vůbec nemáš kontrolu - napíšeš to nějak a pak "doufáš", že to překladač zoptimalizuje. -
robotron (neregistrovaný)
Nechtel jsem rict, ze bez znalosti stavby rekneme CMOS hradel nema smysl programovat. Chtel jsem rict, ze programovat -- na jakkoli vysoke urovni -- bez povedomi o tom, kolik asi tak registru ma CPU, jak velky jsou cache, jak aspon zhruba vypada pristup do dynamicke RAM, jak vypada pristup na dve hlavni soudobe architektury disku a aspon zhruba jak vypada zdibec asm vystupu z kompilatoru, podle me *dobre* nejde.
Naprosto nezavisle na tom, ze pisu v necem hodne moc vysokourovnovem.
-
andy (neregistrovaný)
Ale to víš, že jde. Velikost cache a podobně tě zajímá jen u věcí, které vyžadují výkonnost - a to ještě hlavní optimalizací je typicky změna algoritmu - mám tu jeden výpočet, který se díky změně algoritmu podařilo srazit z cca. týdne na "většinou" několik vteřin. Ano, kdybych ho optimalizoval na nějakou úroveň cache apod., tak bych ho možná ještě několikanásobně zrychlil - za cenu naprosté nečitelnosti kódu - ale když to dělat nebudu, tak je to pořád dost dobrý a kód je v pohodě udržovatelný.
Hlavně u spousty věcí fakt řešíš výkonnost ve smyslu "nesmí to být strašně pomalé". Korektnost a udržovatelnost kódu jsou mnohem důležitější než to, jestli jsi schopen to udělat 2x rychlejší. A když jazyk, ve kterém to píšeš, ani nenaznačuje, do čeho se to vlastně zkompiluje, tak k čemu ti je vědět, že procesor vůbec nějaké registry má? K čemu ti je vědět něco o architektuře disků, když tvoje aplikace má rozhraní akorát tak přes webovou službu na databáze?
-
robotron (neregistrovaný)
A když jazyk, ve kterém to píšeš, ani nenaznačuje, do čeho se to vlastně zkompiluje, tak k čemu ti je vědět, že procesor vůbec nějaké registry má? K čemu ti je vědět něco o architektuře disků, když tvoje aplikace má rozhraní akorát tak přes webovou službu na databáze?
Zde se zasadne neshodneme. Tvrdim, ze pokud uzivatel db nevi, co pro db a jeji fungovani znamena, ze je ulozena zcasti v RAM a zcasti na disku a pri jakych radove velikostech a typech dotazu to s tim diskem priblizne co udela, tak hrozi s pravdepodobnosti dosti znacnou, ze zplodi naprosto strasnej a nepouzitelnej program. Kterejch bohuzel kolem sebe vidame vic a vic. "Webovejch aplikaci", ktery na strane prohlizece v JS sezerou 100% CPU a nedelaj *NIC*, nebo na strane serveru chroustaj primitivni vyhledani n minut, vidam dost kazdou chvili. Urcite neni neznalost HW jedinou a asi ani hlavni slabinou "programatoru", ale rekl bych, ze na tom obecnem praseni ma svuj podil.
Naopak se zcela shodneme v tom, ze delat optimalizaci na krev tam, kde to prinese napr. zneprehledneni kodu, aniz by byla dana optimalizace vyzadovana ucelem, je skodlive.
-
andy (neregistrovaný)
> Tvrdim, ze pokud uzivatel db nevi, co pro db a jeji fungovani znamena, ze je ulozena zcasti v RAM a zcasti na disku a pri jakych radove velikostech a typech dotazu to s tim diskem priblizne co udela, tak hrozi s pravdepodobnosti dosti znacnou, ze zplodi naprosto strasnej a nepouzitelnej program.
Jenže to penzum znalostí, o kterých by člověk "měl vědět" je dost triviální. Něco ve stylu "RAM je rychlejší než disk", "velké dotazy se nevejdou do RAM" a "na točivých discích je random přístup pomalý (a pokud je to virtualizovaný, tak je random pomalu všechno)". Pokud tohle člověk neví, tak má opravdu problém, ale zřejmě asi nějaký jiný. Mimochodem, dneska v cloudu máš službu s garantovanou výkonností (podívej se třeba, co nabízí DynamoDB) a tím to končí.
Ale co mu pomůže lokalita cache, jak vypadá south-bridge na PCI sběrnici, jak funguje segmentace paměti? Nebo třeba i něco high-level - jak vůbec funguje context-switch, jak jsou na konkrétním OS implementovány thready apod. Fakt si myslíš, že při programování nějakých - i netriviálních - webových nebo třeba mobilních aplikací - je něco z toho vůbec relevantní?
-
robotron (neregistrovaný)
Jenže to penzum znalostí, o kterých by člověk "měl vědět" je dost triviální. Něco ve stylu (..)
No vida, tady uz se v zasade shodneme. Potiz je, ze ani aktivni povedomi o takoveto zakladni mnozine skutecnosti nekdy na tech programech neni videt.
Nebo třeba i něco high-level - jak vůbec funguje context-switch, jak jsou na konkrétním OS implementovány thready apod. Fakt si myslíš, že při programování nějakých - i netriviálních - webových nebo třeba mobilních aplikací - je něco z toho vůbec relevantní?
Ano, myslim, ze je to naprosto relevantni. Uz treba pri volbe, zda pole o deseti milionech polozek budu zpracovavat jednim vlaknem, dvema vlakny, nebo deseti miliony vlaken.
-
andy (neregistrovaný)
"No vida, tady uz se v zasade shodneme. Potiz je, ze ani aktivni povedomi o takoveto zakladni mnozine skutecnosti nekdy na tech programech neni videt."
Tak to mají asi trošku jiný problém....
"Ano, myslim, ze je to naprosto relevantni. Uz treba pri volbe, zda pole o deseti milionech polozek budu zpracovavat jednim vlaknem, dvema vlakny, nebo deseti miliony vlaken."
Až na to, že pole o deseti milionech položek prostě většina programátorů zpracovávat nebude. Nepamatuju si, že bych kdy něco takového dělal. A veškeré informace, které k tomu potřebuju jsou "existují thready. Běží na více fyzických corech současně".
-
robotron (neregistrovaný)
Až na to, že pole o deseti milionech položek prostě většina programátorů zpracovávat nebude. Nepamatuju si, že bych kdy něco takového dělal.
No ty mozna ne, ale normalni lidi zpracovavaji megapixelove obrazky nebo zvuky naprosto bezne. A jasne, nekomu staci prendat JPEG/MPEG z mista na misto, ale jinej treba potrebuje najit v nem xicht, dopravni znacku, rozpoznat slovo (abych zahral zrovna na dost aktualni struny tech nejproflaklejsich operaci).
A veškeré informace, které k tomu potřebuju jsou "existují thready. Běží na více fyzických corech současně".
Naprosto nedostatecne. Bez aspon velmi hrubeho, ramcoveho prehledu o tom, jaky jsou kvantitativni vlastnosti vlaken, nelze zvolit spravnej pristup.
-
andy (neregistrovaný)
> No ty mozna ne, ale normalni lidi zpracovavaji megapixelove obrazky nebo zvuky naprosto bezne. A jasne, nekomu staci prendat JPEG/MPEG z mista na misto, ale jinej treba potrebuje najit v nem xicht, dopravni znacku, rozpoznat slovo (abych zahral zrovna na dost aktualni struny tech nejproflaklejsich operaci).
???? Kolik procent programátorů tohle podle tebe dělá? 1%?
> Naprosto nedostatecne. Bez aspon velmi hrubeho, ramcoveho prehledu o tom, jaky jsou kvantitativni vlastnosti vlaken, nelze zvolit spravnej pristup.
Co to je "kvantitativní vlastnost vláken"? Jako že "kernel thread stojí hodně" a "user thread stojí málo"? A to je opět asi tak všechno, co je o tom potřeba vědět?
-
robotron (neregistrovaný)
???? Kolik procent programátorů tohle podle tebe dělá? 1%?
To nevim, mezi programatory se bohuzel moc nepohybuju a ani nepracuju jako vedouci SW projektu ci personalista. Jestli je to 1% nebo 50%, to snad neni tak dulezity. Jsou to data a ulohy, ktere jsou dnes aktualni, je v nich cilej vyvoj a zasahuji spoustu oblasti od ciste spotrebni po skoro rekneme prumysl.
Pokud se bavime o programovani, nepredpokladam, ze by byl jakkoli zajimavej (ba toho slova vubec hodnej) nejakej obecnej LAMP lepic, opakujici desettisictou variantu tehoz bez jediny spetky invence. I kdyz je to mozna 99% "programovani".
Co to je "kvantitativní vlastnost vláken"? Jako že "kernel thread stojí hodně" a "user thread stojí málo"? A to je opět asi tak všechno, co je o tom potřeba vědět?
No tak treba aspon ramcovou predstavu, jak velikej je ten kontext nutnej pri prepnuti vlakna, procesu, kolik to asi stoji, kolik si toho muzu dovolit. V urovni cireho matematickeho idealismu bych si prece mohl udelat jedno vlakno (proces, terminologii VHDL) na kazdej datovej drat a spousta veci by se mi vyrazne zjednodusila,...
-
andy (neregistrovaný)
Pokud se bavime o programovani, nepredpokladam, ze by byl jakkoli zajimavej (ba toho slova vubec hodnej) nejakej obecnej LAMP lepic, opakujici desettisictou variantu tehoz bez jediny spetky invence. I kdyz je to mozna 99% "programovani".
Jasně, takže co třeba takové věci, jako je třeba psaní škálovatelných aplikací - třeba a la whatsup. Jeden počítač ti prostě nestačí, takže v konečném důsledku tam máš lidi, kteří řeší, jak vůbec napsat distribuovanou infrastrukturu, která je schopna škálovat. Ti, kteří tohle dělají, nemusí o HW vědět vůbec nic. Nemusí znát, co to je CPU cache, rozdíl mezi točivými a SSD disky, nemusí vůbec znát assembler. Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti. Máš pocit, že to není "to správné programování"?
No tak treba aspon ramcovou predstavu, jak velikej je ten kontext nutnej pri prepnuti vlakna, procesu, kolik to asi stoji, kolik si toho muzu dovolit. V urovni cireho matematickeho idealismu bych si prece mohl udelat jedno vlakno (proces, terminologii VHDL) na kazdej datovej drat a spousta veci by se mi vyrazne zjednodusila,...
Ano, a pokud programuju v nějakém high-level jazyce, tak to přesně takhle udělám. Režie kontext-switche tam totiž není o moc větší, než když budu ten dispatch budu dělat "manuálněů.
-
robotron (neregistrovaný)
Jasně, takže co třeba takové věci, jako je třeba psaní škálovatelných aplikací - třeba a la whatsup. Jeden počítač ti prostě nestačí, takže v konečném důsledku tam máš lidi, kteří řeší, jak vůbec napsat distribuovanou infrastrukturu, která je schopna škálovat. Ti, kteří tohle dělají, nemusí o HW vědět vůbec nic. Nemusí znát, co to je CPU cache, rozdíl mezi točivými a SSD disky, nemusí vůbec znát assembler. Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti. Máš pocit, že to není "to správné programování"?
Urcite je to to spravne programovani. A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole. Jinak totiz nevznikne Whatsup, ale Facebook (mysleno urovni programovani, ne funkcionalitou).
Ano, a pokud programuju v nějakém high-level jazyce, tak to přesně takhle udělám. Režie kontext-switche tam totiž není o moc větší, než když budu ten dispatch budu dělat "manuálněů.
No vidis, to je prece spravne (pomineme-li nepresnost vyjadreni). Udelas to tak a vis, ze je to OK, protoze mas predstavu o tom, co se s tim programem po prekladu *zhruba* stane. Kdybys to nevedel, tak bys mel v nejakejch konkretnich prikladech treba stesti, ze to chodi dobre, v jinejch bys byl Indem, co zere 400% CPU, aniz by program fungoval dle prani usera.
-
andy (neregistrovaný)
Urcite je to to spravne programovani. A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole. Jinak totiz nevznikne Whatsup, ale Facebook (mysleno urovni programovani, ne funkcionalitou).
Ty vážně myslíš, že znalost HW způsobí, že to nebudu psát v PHP, ale v Erlangu a nebudou si bastlit distribuované algoritmy na koleně, ale použiju nějaké existující a dokázané protokoly? Mimochodem, spam-filtr na facebooku je docela pěkná ukázka toho, jak se to má dělat. Výsledkem jejich snažení je mimo jiné třeba tahle knihovna: haxl Co potřebuju vědět za charakteristiky HW, abych něco takového napsal?
-
robotron (neregistrovaný)
Ty vážně myslíš, že znalost HW způsobí, že to nebudu psát v PHP, ale v Erlangu a nebudou si bastlit distribuované algoritmy na koleně, ale použiju nějaké existující a dokázané protokoly?
Muhehe, hezka ukazka obraceni smeru operatoru ⇒, potazmo ⊆. Nekdy tez zvano zenska logika.
Mimochodem, spam-filtr na facebooku je docela pěkná ukázka toho, jak se to má dělat.
Pokud se ta firma hrabe z nekdejsiho nebo stavajiciho hnoje a jeji kultura se zlepsuje, je to urcite pro uzivatele i neuzivatele FB dobra zprava.
Výsledkem jejich snažení je mimo jiné třeba tahle knihovna: haxl Co potřebuju vědět za charakteristiky HW, abych něco takového napsal?
Bohuzel neHaskelluju (a ano, mrzi me to), tak to nejsem s to docenit. Nicmene souhlasim s tim, ze existuji algoritmy, jejichz prakticka ci v asymptotickem smyslu optimalni podoba je na HW do znacne miry nezavisla (uplne taky ne, viz zminka o tom, vuci jakemu n se vubec O(f(n)) pocta). A jiste, existuji ulohy, kde je bud trivialne zajisteno, ze na stiru s prostredky nebudu, nebo mi postaci povsechne povedomi ("kolik mam cca RAM"). Jak moc je mozno nestarat se o realnej dopad behu Haxlu z pohledu tvurce, zel, nejsem kompetentni posoudit.
-
andy (neregistrovaný)
A narozdil od tebe jsem presvedcen, ze to nemuzou konkurenceschopne napsat lidi, co vedi kulovy o pod tim lezicich vrstvach -- vcetne aspon naprosto zakladnich charakteristik HW uplne dole.
Muhehe, hezka ukazka obraceni smeru operatoru ⇒, potazmo ⊆.Já nemám jediný důvod se domnívat, že programátoři navhující a píšící ten systém messagingu vůbec tuší něco o tom, na jakém to vůbec běží HW. Někdo to tam stavěl, tak ten "někdo" o tom HW asi něco ví. Ale třeba jinak: spousta věcí dneska běží v cloudu. Ja absolutně nemám tuchy, na jakém HW to tam běží. Takže kvůli tomu nejsem schopnej něco napsat, když vím kulový co pod tím leží?
Bohuzel neHaskelluju (a ano, mrzi me to), tak to nejsem s to docenit. Nicmene souhlasim s tim, ze existuji algoritmy, jejichz prakticka ci v asymptotickem smyslu optimalni podoba je na HW do znacne miry nezavisla (uplne taky ne, viz zminka o tom, vuci jakemu n se vubec O(f(n)) pocta). A jiste, existuji ulohy, kde je bud trivialne zajisteno, ze na stiru s prostredky nebudu, nebo mi postaci povsechne povedomi ("kolik mam cca RAM").
Ta knihovna není vůbec o tom, aby něco asymptoticky optimalizovala. Ta knihovna je od toho, aby transparentním a jednoduchým způsobem umožnila paralelizovat kód psaný uživateli. On v ní dokonce asi není ani žádný "algoritmus", u kterého by mělo smysl ho nějak "optimalizovat". Celé to je o tom dát uživatelům do ruky nástroj, pomocí kterého budou psát korektní a dobře paralelizovaný kód. A to je taky programování, a fakt docela zajímavé - a netriviální. A ten, kdo tohle psal, fakt nemusel vědět vůbec nic o HW, na kterém to poběží. A věř, že to byl dost dobrý programátor.
-
robotron (neregistrovaný)
Naopak se musí orientovat v takových srandách, jako je PAXOS, distribuované hodiny a podobné čistě teoretické záležitosti.
Hele, ja nemuzu odolat: zrovna timhle prikladem jsi me moc potesil. Sice jsem nedelal nic v PAXOSu (mych redundantnich systemu bylo celkove dost malo a kdyz, tak byly realizovany naprosto stupidne a tesne vazane a zadna slozitost se tam nekonala a bylo to hodne low-level), zato docela aktivne pracuju s distribuovanyma hodinama a to jak na urovni HW nejHWovatejsiho (a sice analogoveho), az po "čistě teoretické záležitosti", jako odvodit matematicky ciste, kolik je v danem uzlu nejlepsi odhad casu. A tvrdim, ze znalost toho HW se fakt hodi.
Jsou lidi, co ji nemaji, a tem se deji zajimave veci, napriklad rozkmitany NTP. Zazil jsem, v realnem nasazeni v prumyslu.
-
andy (neregistrovaný)
Měl jsem na mysli vektorové hodiny a podobný distribuovaný srandy.... ale třeba konkrétně k tomuhle: https://aphyr.com/tags/jepsen
A teď mi zkus vysvětlit, k čemu se mi v tomhle hodí znalost HW. Předpokládám, že jako dostatečnou znalost HW asi nemyslíš "sítě jsou nespolehlivé".Co potřebuješ znát je rozhraní, nad kterým pracuješ. "Jak to funguje" pod tím rozhraním může být drtivé většině lidí ukradené. Pokud zrovna neděláš nějaké relativně triviální performance-oriented věci, tak pro tebe může být assembler a všechno kolem CPU sprosté slovy. U složitějších věcí to stejně nebudeš schopnej zorganizovat rozumně, případně se ti nebude chtít vylézt s třeba dost high-level jazyka, ve kterém to píšeš. Jako je hezké psát něco o cache-locality, ale když v tom jazyce nemáš možnost ty alokace ovlivnit, nebo provádíš optimalizace nad nějakým větším grafem, který nejde nějak rozumně reprezentovat kompaktněji, tak je ti celá tahle teorie na nic.
-
robotron (neregistrovaný)
Měl jsem na mysli vektorové hodiny a podobný distribuovaný srandy...
No to jsem pochopil. Znalost chovani hodin (tj. HW) mi dokaze rict, jaky drifty a jaky chyby muzu cekat a jak s tim nalozit, s masterem, bez mastera,...
třeba konkrétně k tomuhle: https://aphyr.com/tags/jepsen
A teď mi zkus vysvětlit, k čemu se mi v tomhle hodí znalost HW. Předpokládám, že jako dostatečnou znalost HW asi nemyslíš "sítě jsou nespolehlivé".Urcite se bude hodit vedet, jake druhy nespolehlivosti ta sit ma. Tj. treba, ktery vrstvy a konkretni protokoly si muzou dovolit prehazet zpravy, duplikovat, nedorucit, pokazit obsah zpravy (zamena bajtu za jiny) a jaka je toho pravdepodobnost. Co se deje v krizovejch a chybnejch situacich, jestli to nejak ovlivni, kdyz je v ceste VPN apod. Jak funguje fragmentace a udrzovani spojeni...
A nechod na me s tim, ze zaslani zpravy je vysokourovnova operace. Jinak ti smele navrhnu, ze zalohovani databaze na vzdalenej stroj provedeme atomickou operaci server2.db = server1.db a ahoj. Je to prece formalne v poradku, ne?
-
andy (neregistrovaný)
No to jsem pochopil. Znalost chovani hodin (tj. HW) mi dokaze rict, jaky drifty a jaky chyby muzu cekat a jak s tim nalozit, s masterem, bez mastera,...
Ehhh.... ne, tohle jsem myslel: https://en.wikipedia.org/wiki/Vector_clock - A vector clock is an algorithm for generating a partial ordering of events in a distributed system and detecting causality violations. To nemá s hodinama nic společného....
Urcite se bude hodit vedet, jake druhy nespolehlivosti ta sit ma. Tj. treba, ktery vrstvy a konkretni protokoly si muzou dovolit prehazet zpravy, duplikovat, nedorucit, pokazit obsah zpravy (zamena bajtu za jiny) a jaka je toho pravdepodobnost. Co se deje v krizovejch a chybnejch situacich, jestli to nejak ovlivni, kdyz je v ceste VPN apod. Jak funguje fragmentace a udrzovani spojeni...
No... vlastně vůbec ne. Když to je postavené nad TCP protokol, tak z hlediska chování podle toho CAP v podstatě řešíš akorát "chodí/nechodí/chodí pomalu". O HW pod tím nepotřebuješ vědět vůbec nic.
A nechod na me s tim, ze zaslani zpravy je vysokourovnova operace. Jinak ti smele navrhnu, ze zalohovani databaze na vzdalenej stroj provedeme atomickou operaci server2.db = server1.db a ahoj. Je to prece formalne v poradku, ne?
No...... jo. A jako v čem je problém? Přes 2-PC se to asi celkem v pohodě dá implementovat?
-
ac (neregistrovaný)
Sakra co ja bych za to dal kdyby tohle nekde chteli a pri praci resili :-(
Dost mozna jsem se jenom jeste nenaucil hledat zajimavou praci ale zatim me zivi spise hrabani v polofunkcnim hnoji a partyzanska udrzba i pres aktivni snahu vedeni projekt pohrbit (cim rychleji a hloubeji, tim vyssi bonusy?).
Kolik ma CPU registru? Spise: Proc ten nas bazmek co mame udrzovat segfaultuje uz pri krivem pohledu?
Jak vypada vystup z prekladace? Spise: Proc se tvarime, ze nemit zadnou dokumentaci je zasadni konkurencni vyhoda?
Jak velke jsou cache? Spise: Jak slepit tohle open-source kladivo s timhle nasim legacy sroubovakem aby s tim slo posekat zahradu?Asi mam predvanocni krizi. Ale vedet o praci kde vladne selsky rozum a je vyzadovane neco zajimaveho a netrivialniho (ne webiky! ne appky! ne chytra splachovatka na zachod!), tak se naucim "cokoliv", sam ve svem volnem case a ve zkusebce si zrusim vikendy.
Myslim to vazne.
ac86761disp@protonmail.com
-
yenn (neregistrovaný)
Mám jeden příklad z ČVUT, kdy náš vyučující sice perfektně rozuměl HW, ale vyznat se v jeho kódu byl docela problém. Šlo o předmět zaměřený na nízkoúrovňovou optimalizaci algoritmu pro konkrétní procesory (maximální využití instrukcí procesoru, ruční řízení řízení lokality cachí, apod.).
Sice uměl hezky optimalizovat kód na železo, ale kód se každý týden měnil a obsahoval spoustu nedokumentovaného chování (které se navíc často měnilo, takže bylo těžké poznat, čí vinou algoritmus skončil předčasně), z knihovny, nad kterou jsme stavěli svůj kód, lezly věci co měly zůstat schované v implementaci (např. mám nastavovat se afinitu na procesor v mém kódu nebo by to měla dělat knihovna?) a kód byl z velké části nedokumentovaný, takže různé low-level optimalizace akorát ztěžovaly pochopení ukázkového kódu "klienta" (protože tam vlastně vůbec být neměly), z kterého jsme měli pochopit API knihovny.
Tomu vyučujícímu jsem po chvíli navrhl, že existuje existuje něco jako verzovací systém a že distribuce kódu stylem adresář pro každou verzi na disku jednoho serveru je fakt na houby, zvlášť když je kód neustále ve vývoji. Nemusím asi dodávat, že o nové verzi kódu jsme se často dozvěděli se zpožděním (ústně, mailem), což bylo super, když mi padal kód kvůli chybě v knihovně a strávil jsem tak spoustu času laděním úplně zbytečně, když ta chyba byla už opravená v nové verzi.
Osobně mám pocit, že tihle lidé si vybrali specifickou oblast zájmu (jít blíž k železu) a pak se moc (nebo vůbec) nezajímají o vysokoúrovňové koncepty, které k psaní software patří, protože píšou převážně malý experimentální software, kde o čitelnost a rozšiřitelnost kódu ani tolik nejde, protože na malých programech to člověka moc nekousne. Samozřejmě čest výjimkám.
A jinak jsem jedním z těch pojídačů koláčů, co moc do železa nevidí, ale mám doufám aspoň rámcový přehled o tom, že se dá programovat líp přímo pro to železo. Třeba nepsat zbytečně zběsilé algoritmy, které si svoje data budou neustále vyhazovat z cache, když nemusí. Nicméně spoléhám na to, že to kompilátor kód optimalizuje za mě :)
-
m (neregistrovaný)
jo, bez problemu ... znam spoustu vybornych programatoru ktere bych nenechal na HW sahnout
ve skutecnosti je mnoziva problemu kde musite znat HW pro dobre naprogramovani velmi mala
a pokud optimalizujete prilis na HW dopadnete s casem blbe ... HW se vyviji celkem rychle a pravdy o optimalizaci kodu co platily loni jsou uz dnes totalne mimo
-
robotron (neregistrovaný)
Optimalizovat "prilis" na HW je urcite v obecnych pripadech zle, pokud nejde opravdu o specifickou aplikaci.
Jeden priklad "pravdy o optimalizaci kodu co platily loni jsou uz dnes totalne mimo" by byl? (Pokud nemas na mysli pravdu, co platila o optimalizaci kodu pred 30 lety [tam bych se nehadal], ale skutecne loni, nebo aspon pred 5 lety.)
-
robotron (neregistrovaný)
Uznavam, ze SSD se chova jinak a ma svoje ctnosti a vady odlisne od magnetickeho disku.
Nicmene sekvencni cteni oproti ad hoc ma porad hodne navrch, protoze ten SSD je porad pripojen komunikacnim rozhranim disku a ne mapovan jako pamet. Muzeme se samozrejme bavit o tom, zda je tenhle anachronismus dobre ;-) (Uprimne: myslim si, ze celej koncept deleni pameti na feritovou a bubnovou je prezitek a tesim se na OS a jazyky, kde bude tento rozdil smyt. Doziju-li se.)
-
andy (neregistrovaný)
Jo. Spousta lidí dneska dává mnohaterové databáze na SSD pole, protože to prostě stejně nebyli schopni zoptimalizovat tak, aby to běželi na točivých discích a nemuseli tam mít 300 točivých disků, kdy z každého používali 30%. A ano, v momentě, kdy to dáš na SSD, tak prostě spousta optimalizací na sekvenční čtení přestane mít smysl a můžeš tu databázi dělat jinak.
-
A ano, v momentě, kdy to dáš na SSD, tak prostě spousta optimalizací na sekvenční čtení přestane mít smysl a můžeš tu databázi dělat jinak.
Take to muze byt tak, ze soudruzi to tak blbe zoptimalizuji (nezoptimalizuji vubec), ze aby se to aspon nejak plazilo, odvezou stavajici pole do elektrosrotu a misto nej musi nasadit funglnove SSD pole. A docela si umin predstavit, ze by to slo zoptimalizovat natolik blbe, ze se ty SSD disky osoupou tak rychle, ze tam pomalu budou mit diskjockeye, ktery bude jen menit disky a rebuildovat pole.
-
andy (neregistrovaný)
Blbě se dá dělat všechno, ale bohužel někdy zjistíš, že prostě ten random přístup rychle potřebuješ. Jeden tenhle starter brick má 150.000IOPS a 40TB. Random. Nemáš pocit, že tím pádem se můžeš na veškeré sequential vs. random optimalizace vybodnout a jít dělat něco smysluplnějšího?
-
sir (neregistrovaný)
To je argument? takze nasazenim 10x rychlejsi (skutecne?) technologie jsi problem zprovodil ze sveta? Tak to neni zapotrebi uz nic resit - zere to RAM? dokoupime, nestiha HDD? poridime SDD, nestiha SDD? hmm vono se neco najde. Ja si tedy dovolim tvrdit, ze problem lokality dat je dneska vsudypritomny, od cache pres disky, RAIDy az po distribuovana reseni a vzdycky bude zapotrebi nekdo, kdo vi jak to funguje o jeden ci vic levelu niz.
-
andy (neregistrovaný)
Ano, to je argument. V diskovém poli s rychlými HDD se počítá 200IOPS na disk (většinou spíš míň). Takže 300 disků * 200 = 6000IOPS. Když potřebuješ 6000 IOPS na přístup třeba k 1TB databázi, jeden disk má třeba 300GB, tak se ti tam točí spousta zbytečných disků.
Jeden tenhle brick má 150.000 iops. Paradigm-shift?
-
sir (neregistrovaný)
Tim jsi dosel jen k tomu, ze jsi pro tvoji ulohu pouzil sofistikovany HW, ve kterem uz nekdo povolanejsi ty low-level algoritmy nacvakal. Jinak to neni posun paradigmatu, ale pouziti odlisne technologie, kterym obecne NEZMIZELA potreba v pripade potreby optimalizaci na urcity typ storage, pouze zmizela vam. Ostatne to muzu posunout dal a tvrdit, ze pro pitomy 1TB bude levnejsi a rychlejsi pouzit in-memory DB. A na druhe strane spektra jsou porad aplikace, kde mas miliony pasek a roboty, co je on demand vymenuji :)
-
andy (neregistrovaný)
Otázka zněla na příklad, zda zmizela potřeba pro určité optimalizace. Ano, zmizela - vzhledem k cenám SSD a paměti obecně prostě pro spoustu úloh fakt nemusím sekvenční vs. random přístupy řešit. Navíc, vzhledem k tomu, že dneska všechno běží na virtuálech, tak je velmi často i sekvenční přístup vlastně dost random. Stejnou úlohu prostě budu dneska řešit úplně jinak než před 5 lety.
-
andy (neregistrovaný)
Za pár krejcarů to není, ale zkus si porovnat cenu diskového pole s 300 disky, kdy z každého disku používáš jen určité procento vs. nějaká SSD technologie. Když vyžaduješ vysoké IOPSy, tak tě ty SSD vyjdou levnějc - ještě si přidej náklady na chlazení. Zkus se třeba podívat, jak bys třeba řešil s disky přístup k 400GB databázi, kde bys potřeboval 20.000 IOPS před 5 lety? Asi by ses snažil hodně optimalizovat, abys tam nemusel rvát naddimenzované diskové pole. Jak bys to řešil dneska? V podstatě to narveš do paměti a budeš optimalizovat něco úplně jiného, než je sekvenční čtení z disků.
-
JN (neregistrovaný)
Já jsem se vždy zajímal o HW. Dneska si dokážu lecos postavit. Jenže HW bez programování je na nic.
Takže jsem se naučil i to, nechtěl jsem pověsit na hřebík umělecké sklony a tak dělám i to.Pointa?
Podle mě je zcela zásadní aby člověk měl vizi (co má být na konci) a věděl jak k tomu dojde. Pokud to druhé neví potřebuje někoho kdo mu cestu ukáže a nalajnuje. Pokud neví ani to první... opět to za něj někdo udělá.
A rázem máme programátora co nepřemýšlí, jen programuje a netuší o co jde.Proto jsem se nikdy nestal fulltime programátorem, proto nejsem fulltime HW specialistou, proto nejsem fulltime grafikem/fotografem/designerem.
Proto takové lidi většinou řídím. Mám vizi a znám cestu.
Přesto si myslím, že i programátor by měl mít představu jak to železo funguje, pak totiž nevymýšlí pitomosti a chová se jako racionální člověk. -
Ivan Nový (neregistrovaný)
Optimální rozdělení zdrojů není maximální optimalizace algoritmu vzhledem k použitému procesoru. To říci můžeme, ale optimum stejně neznáme, to hledáme za pomoci kompromisu i s jinými optimalizačními kritérii.
Mnohem větší problém bývá rozpoznat, že ten převod do hexa vůbec v daném kontextu nepotřebujete.
Obvykle takové výstupy, jaké popisujete, jsou výsledkem špatného zadání vyplývající z ignorování psychologie interpersonální komunikace. Pokud jste to chtěl jinak, měl jste říci, že chcete co nejoptimálnější variantu vzhledem k využití HW. Váš chybný předpoklad je, že toto kritérium při řešení úkolu je samozřejmé. Není.
Když bych zadával práci já vám, požadoval bych po vás explicitně omezení optimalizací, protože vidím, že se jimi nepřiměřeně excitujete :-)))
-
robotron (neregistrovaný)
Cest kapitalu, ja jsem nastesti v zminenem prikladu nebyl ani jednou ze stran vyucovaciho procesu.
Nicmene: psani jakehokoli programu, jakoz i obecneji plneni pracovniho ci skolniho ukolu, je vzdy vicekriterialni optimalizaci, kde samozrejme doba psani, namaha hlavy aj. jsou tez kriterii. Je ale neoddiskutovatelne, ze kdo vyresi ukol blbe po vsech strankach (nasobne delsi, hnusnejsi, kod, kterej se vykonava o nekolik radu pomaleji a sezere o rad vic pameti), nemuze svoje reseni povazovat za dobry.
No jasne, ze neni potreba nekdy cisla prevadet do/z hexa. Stejne, jako treba neni casto potreba prevadet je do desitkove soustavy. Nekdy to zas potreba je. Odmyslime-li si zakotveni hexa v nekterych souborovych a datovych formatech (co treba takove zadavani RGB barev, tam se v hexa bavi uz i nepocitacovi "tvorivi" grafici), pak je to porad v mnoha pripadech skvely kompromis pro mnoha rozhrani clovek-stroj.
-
hefo (neregistrovaný)
Avšak stále o tom hexa príklade nevieme (hoci áno, zjavne to veľmi pokročilý či zručný programátor nebol), v akom kontexte sa ten prevod robil, a aký vplyv to malo na celkový výkon programu. Lebo ak to bola operácia, ktorá sa robí raz za minútu, jej vplyv na výkon bol nula celá prd.
-
Pavel Pisa (neregistrovaný)
Možná má robotron na mysli případ, kdy bylo potřeba dva osmibitové byte složit do 16-ti bitového čísla
int concat16(int h, int l) { return (h<<8)|l; }Student zcela správě podle svých vysokoúrovňových znalostí vyhledal kombinaci operací, která vedla ke správnému výsledku
int concat16(int h, int l) { char s[20]; snprintf(s,sizeof(s)-1,"%02x%02x",h,l); s[sizeof(s)-1] = 0; return strtol(s,NULL,16); }Ovšem takovýto vysokoúrovňový přístup by v medicíně znamenal, že jsme všichni již od narození mrtví, protože zavázání pupeční šňůry by trvalo dva dny a případná transfúze týden.
-
muf (neregistrovaný)
Protože mám doma člověka od medicíny, můžu prohlásit, že operovat lékařem bez základních znalostí biochemie(aspoň na úrovni základních kurzů na fakultě) bych se tedy fakt nenechal. Tedy pokud bych měl šanci vědět, komu jsem se vlastně pod ten skalpel dostal.
Taková operace by odpovídala polním podmínkám ve válečném stavu s felčarem na místě skutečného lékaře se všemi riziky s tím spojenými.
On je ten obor dost komplexní a má- li se dělat poctivě nelze se spokojit s tím, že jsem někdy na vyšší vrstvě.Platí to pochopitelně i pro naši práci. Kdykoliv jsem programoval a věděl toho málo o tom, co je níže, byl výsledek většinou horší než v případě alespoň základní znalosti.
-
dannak (neregistrovaný)
"Prostě od určité úrovně to znát fakt nemusíš."
Spis bych rekl, ze nektere problemy lze vyresit, tj. nalezt NEJAKE reseni, i bez detailni znalosti nizsich vrstev. Jina otazka je, jak kvalitni je to nalezene reseni.
<sarcasm>
Ale ono nakonec jednomu preci muze byt jedno, jak funguje HW dole; kdyz napisu SQL, db optimizer to stejne prehaze jak uzna za nejlepsi, CPU ty instrukce provede out-of-order a dnesni disky si ty pozadavky taky prehazujou jak potrebuji, takze proc vubec uvazovat o necem co nemam pod kontrolou :)
</sarcasm>
Nebo bych se starat radeji mel? Za me jo, je dulezite aspon tusit, co se deje o par levelu niz - dobra otazka je kolik ? - nez se aktualne pohybuji. Napr. kdyz nevim, co vsechno DB musi udelat, abych ziskal, nebo aktualizoval jeden radek, nebo milion radku, tezko pak muzu navrhnout a/nebo naprogramovat dostatecne robustni a vykonne reseni, ktere nespadne pri prvni trochu vetsi zatezi, pripadne po nejake dobe v provozu, kdy naroste objem zpracovavanych dat. -
andy (neregistrovaný)
Nebo bych se starat radeji mel? Za me jo, je dulezite aspon tusit, co se deje o par levelu niz - dobra otazka je kolik ? - nez se aktualne pohybuji.
A potřebuješ k tomu vědět, jak funguje (nebo vůbec, že existuje) context switch? Potřebuješ vědět kolik má registrů ten procesor, na kterým to zrovna běží? Že existují nějakě L1/L2 cache? Že existují nějaké pipeliny? Víš na co reaguju?
Když jsem studoval Matfyz, narážel jsem na lidi, kteří měli sofistikované teoretické znalosti z informatiky, ale netušili, jak PC nebo procesor uvnitř fungují a PC v životě zřejmě vůbec nikdy neotevřeli
Fakt na tohle potřebuješ vědět, jak PC nebo procesor uvnitř fungují?
Napr. kdyz nevim, co vsechno DB musi udelat, abych ziskal, nebo aktualizoval jeden radek, nebo milion radku, tezko pak muzu navrhnout a/nebo naprogramovat dostatecne robustni a vykonne reseni, ktere nespadne pri prvni trochu vetsi zatezi, pripadne po nejake dobe v provozu, kdy naroste objem zpracovavanych dat.
A co myslíš - je lepší tohle řešit na úrovni "cache procesoru", nebo na úrovni "jsem schopen to řešení škálovat", "potřebuju atomické operace nad DB", jaká je O() složitost operací, které dělám? Když programuješ v nějakých hodně high-level jazycích tak doopravdy vůbec netušíš, co z toho leze. Škálování děláš na úrovni architektury řešení. Ano, občas ti tu a tam vypadne nějaká věc, kde o výkon jde, tak holt se pak musíš vzdělat - ale to je možná 1% věcí.
-
atarist (neregistrovaný)
Tak ale s cache souvisi i to, jestli ctes pole (nebo bitmapu) po radcich ci po sloupcich, a to je operace, ktera je v mnoha jazycich precizne popsana (stejne jako zpusob ulozeni prvku). Jinak prohozeni cteni po radcich/sloupcich bude mit hodne velkej vliv, a to i na ostatni aplikace (kterym nebudes tak casto vyhazovat cache line).
-
robotron (neregistrovaný)
Nekdy jo, tady bych ale rekl, ze Clockova samochvala Ronji je docela opodstatnena. Je to mozna zapojeni pofiderni (udajne nebylo snadny rozjet to na pcb), nicmene funkcni -- a jak psano pod minulou sebechvalou, jsou tam i korektne, byt neintuitivne reseny nektery veci, jako TIA s prekvapive uzkym propustnym pasmem.
Zato vsechny ostatni Clockoprispevky za dobu poslednich nekolika let jsou ciste z rise WTF.
-
vitas (neregistrovaný)
Mohl bych vědět, kdo byl ten profesor na matfyzu? Přijde mi to jako urban legend, nebo pořádně vytržené z kontextu (např. pokud se budeme bavit o násobení matic v grafice, kde se používají výhradně vektory a matice do rozměru 4x4, tak násobení matic bude samozřejmě konstantní). Jako i na matfyzu jsou různí lidé, ale takhle hloupého přednášejícího jsem nezaznamenal.
-
Karel (neregistrovaný)
Ono to obvykle nebývá urban legend, ale lidová slovesnost. Student něco blbě pochopí (vidí generalizaci tam, kde není), stydí se zeptat, ale kamarádům pak vypráví, jakou kravinu učitel řekl. Setkal jsem se s tím v průběhu studií mockrát. Učitel řekne při rozebírání konkrétního schematu něco typu "před LED není potřeba dávat rezistor, protože výstup dá právě 10mA". No a student slyší jen "před LED není potřeba dávat rezistor", vrtá mu to hlavou, považuje to za kravinu. Ale učitele se nezeptá. Proto se nedozví, že "tenhle integrovaný obvod má přece na výstupních pinech zdroje konstantního proudu". A pak to poví kamarádům večer u piva/v knihovně, ale už bez náležitého kontextu. Ti mu samozřejmě potvrdí, že je to úplná kravina a shodnou se, že učitel je dement.
-
Další hezký článek této série. Pravda, některé historky beru s rezervou, např. profesora na Matfyz, když neznáme kontext, ve kterém to řekl. Ale i tak je to dobré.
Můj názor na závěr - podle mě jsou Matfyzáci neprávem přecházeni. Ve svém teamu mám dva. Jeden je perfektní analytik a to, že má Matfyz, jsem se dozvěděl až později. Druhý je perfektní na složitý úkol, kdy dostane zadání a pak může sám zkoumat a bádat a nestalo se, že by něco nevyřešil. Výsledek se pak sice musí občas upravit, ale to na věci nic nemění.
-
Quark66 (neregistrovaný)
ad 1) Tomáš Egi, Elektrikář · Haunstetten - Siebenbrunn, Ludwig-Martini-Straße 11, 86343 Königsbrunn, Německo.+49 8231 9290250 měl tedy štěstí, že se chytil zajímavého zařízení.
ad 2) těžko porovnávat matfyz s felem. jedni používají tunelovou diodu a druzí vědí, proč tak funguje. Jedni mají konstanty ve vzorcích a prakticky je využívají a jiní vědí, že lze s omezujícími předpoklady chování nějaké součástky popsat nějakou konstantou... Jedni znají teoretické (i praktické) důsledky Maxwellových rovnic v elektrotechnice, druzí vědí, že elektrika a magnet jsou kolmé a k nim kolmá nějaká síla a že se magnetický monopól moc nevyužívá :-)
ad 3) pohledem na eletrické schéma lze těžko usuzovat, zdali zařízení funguje, nebo ne. Možná lze odhadnout blbě zapojenou diodu, nebo tak. -
Karel (neregistrovaný)
Roky (možná dodnes) byla na ČVUT, fakultě strojní, vitrína s jistým mechanismem z několika kloubů a hřídelí. Bylo tam tlačítko, kterým se to uvedlo do pohybu a točilo se to. A k tomu povídání, že se již několik lidí pokusilo vypočítat k tomu pohybové rovnice a všem vyšlo, že se to prostě točit nemůže.
-
Prezdivka (neregistrovaný)
Vzkaz autorovi:
Jo jo, ke ztrate kontaktu s realitou dochazi docela casto. Treba si predstavte, ze se tady na Rootu (server se zamerenim na IT), jeden z autoru pokousel propasovat sociologicke studie na tema slovniku jisteho Fina. To je prdel, co? Asi ztratil kontakt s realitou a zapomnel, ze tohle neni Vitalia. -
Hm, jsem rad, ze po odchodu pana Bednare, se nasel dustojny zastupce, ktery zaplni diru v oblasti sociologickych uvah a ukoji tak hlad ctenaru Rootu, ktery posledni dobou presahoval unosnou miru. Na modrou Ronju jsme se podivali v tom smyslu, ze je v clanku nejaka fotka. Nevadi, hlavne ze jsme se seznamili s palcivymi problemy neblahych pomeru na CVUT, kvuli kterym se v noci budime vlastnim krikem z nocni mury, zbroceni studenym potem.
Nicmene bych uvital, kdyby autor alespon okrajove zminil i nejake ty mene podstatne veci, jako napriklad proc Ronja modra a ne radsi cervena, kdyz z predchoziho clanku o podmorske Ronje jsem ziskal spise dojem, ze pouziti modre barvy prinasi akorat problemy.
-
Myslíš situaci okolo rektora a Elfmarka?
Tak to urcite take, i kdyz nevim, jaka situace to ma byt, kdo je Elfmark a co s tim ma delat rektor. Ale pomery jsou celkove strasne, treba jeden student nechapal jak funguje tranzistor. A navic je tam dabel skryty v detailech a asi bude nutne zavolat exorcistu, o cemz se docteme v pristim dile.
-
jinej muf (neregistrovaný)
Tenhle článek byl fakt o Ronji? Našel jsem v něm spoustu informací o frustraci autora ohledně výukových metod nějakých učitelů na VŠ z jeho i cizích historek, ale ohledně Ronji a nějakých objektivních, věcných informací jsem tam nenašel téměř nic... Tak doufám, že se někdy příležitostně dočkáme i povídání o Ronji a jejích technologiích...
-
Kiwi (neregistrovaný)
1. Který vyučující konkrétně a v jakém kontextu to tvrdil? Jsem čím dál více alergický na tyto anonymní výroky. Budu-li mít konkrétní problém, v němž rozměr matice nefiguruje jako parametr, pak skutečně z hlediska tohoto konkrétního problému mohu maticové operace považovat za elementární, jak už zde bylo zmíněno. Při analýze časové složitosti nějakého grafového algoritmu na předmětech typu Techniky programování asi málokoho napadne tvrdit, že násobení dvou čísel je přece taky nekonstantní, neboť závisí na počtu bitů. V kontextu tohoto problému to je elementární operace se složitostí O(1).
2. Vysvětlit jak a proč funguje bipolární tranzistor není zas tak jednoduché. Však za to také byla udělena Nobelova cena za fyziku třem lidem. Ostatně mohu parafrázovat samotného autora - "dvě diody od sebe (resp. proti sobě), to by přece nemělo vůbec fungovat!" A taky nebude, pokud to není zrealizováno v rámci jednoho krystalu.
3. Zapojení, která při letmém pohledu nefungují, je plná červená řada Amatérských rádií. Taková zapojení se dělí na dva druhy: ta, jež nestandardním, ale chytrým způsobem využívají nějaké vlastnosti (sice to není nejvhodnější příklad, ale napadá mě např. generátor videosignálu v počítači Ondra), a ta, jež fungují spíš náhodou, jsou nešikovná, potenciálně nespolehlivá (večer si při práci na to rozsvítíte stolní lampičku a po pár minutách zapojení záhadně přestane fungovat). Obávám se, že Ronja patří spíše do té druhé kategorie, což bylo ostatně v komentářích k jiným článkům o tomto projektu zmiňováno a rozebíráno konkrétně.
-
robotron (neregistrovaný)
Obávám se, že Ronja patří spíše do té druhé kategorie, což bylo ostatně v komentářích k jiným článkům o tomto projektu zmiňováno a rozebíráno konkrétně.
Taky si to myslim. Ale k tomu nam s pravdepodobnosti hranicici s jistotou autor nic nerekne, nebot jeho mysl oddriftovala daleko od konstruktivniho mysleni, ktere paradoxne v dnesnim clanku, asi coby nostalgickou vzpominku na lepsi casy, tak vyzdvihuje.
Hodnotu Ronji spatruju v tom, ze prisla ve vyhodne dobe a byla otevrena, proto se dockala mnoha realizaci a ukazala zajimavou alternativu. A inspirovala par skupin a lidi, aby to zkusili udelat poradne. Jednoznacnej prinos.
-
sir (neregistrovaný)
1. přesně, navíc pokud to bylo v kontextu SIMD, tak tam se mnohdy násobení matic 3x3 a 4x4 (což je v praxi asi tak nejvíc vidět) provede s O(1). A i sčítání může mít složitost O(n) (GMP...)
2. záleží i na poměru dotací báze, kolektoru, emitoru, geometrii atd. Podle mě lidi lépe pochopí unipolární tranzistor. ale "náhradní" zapojení tranzistoru jako dvou diod proti sobě je ... blbost.
-
Karel (neregistrovaný)
Přiznávám, že já, coby absolvent elektro průmyslovky a ČVUT FEL, jsem tranzistor také pochopil až náhodou ve svých 35 letech. Do té doby jsem si vystačil s tím, co učí ve škole. A co tak vidím kolem sebe, tak většina lidí ho nechápe dodnes. Což jim nebrání ho správně použít, jen jsou odkázáni na vzorečky a vždy se musí nejprve zamyslet, který použít. Holt "dvojbran", "společný emitor" atd. si vybírá svou daň. Fyzikální podstatu chápe málokdo. Naštěstí pro praktické použití stačí vědět, jak se ta součástka chová. Proč se tak chová je podružné. Ale zajímavé a hlavně už si pak řadu věcí člověk odvodí sám.
-
Miloslav Ponkrác (neregistrovaný)
Já jsem tranzistor pochopil už před desítkami let. Je jen otázka co se pod tím termínem skývá. Já objevuji nové a nové věci o tranzistoru snad několikrát do roka. Protože tranzistor je nelineární součástka - má řadu parazitních kapacit, indukčností, odporů. Kromě toho se chová jako generátor šumu, na různých místech má své limity pro průraz. Na různých cestách má různá zpoždění a nelineární náběhy, atd. Dále jsou to tepelné závislosti tranzistorů a vlastní změny charakteristik vlivem vlastního i cizího tepla. Kromě toho jsou zpětné charakteristiky, kdy výstupní hodnoty ovlivňují vstupní hodnoty. A to jsem nezmínil mnoho dalších věcí, které je dobré o tranzistoru znát, aby ho člověk znal dokonale, a věděl jak se chová v jakémkoli případě použití.
Pro praxi, tedy to co většina lidí chápe jako "vím, jak se tranzistor chová", jej stačí znát velice povrchně. Pokud člověk neleze do vyšší frekvencí, neleze do impulsních věcí, neleze do malých či velkých signálů, atd. stačí slabikářová jednoduchá představa.
V nejjednodušší (nepřesné) představě je tranzistor 1) z hlediska napěťových úbytků dvojice diod, 2) jinak je to převodník proud na vstupu na výrazně násobený proud na výstupu (pokud se provozuje v přibližně lineární oblasti a v rámci SOA) - tedy proudový zesilovač.
Nicméně článek, pod kterým reagujeme, je o tom, že autor je poněkud slavoman. Když jsem viděl schéma ronji, tipl bych si, že autoři neznají tranzistor příliš dokonale.
Miloslav Ponkrác
-
peter (neregistrovaný)
Možno si autor potrebuje trochu zlepšiť nejaké ego na úkor renomovaných profíkov ... Ak sa na nejakú schému, ktorá je plná všelijakých hackov pozrie profesionál, vedomý si všetkých obmedzení a doporučení z katalogových listov komponentov, nemá žiadne zábrany prehlásiť zapojenie za nefunkčné - minimálne z pohľadu potenciálnych rizík, ktoré takéto riešenie predstavuje. Osobne nemám žiaden prolém napr. prehanať cez praveký tranzistor KSY62B (tuším Ic=100mA / Uce=30V) v lavínovom režime prúd 1.5A pri 80V Uce po dobu 1 nsec do záťaže 50 Ohm, môžem si to ale dovoliť tak maximálne v nejakom testovacom prípravku na stole (ak napr. potrebujem nsec a sub-nsec testovacie impulzy), do ostrého produkčného zariadenia takéto čosi nepatrí. Pokiaľ autorovi článku nevadí raz za čas behať po streche internátu a sem tam čosi vymeniť, tak je to ok, nech ale čosi takéto skúsi spraviť v nejakej, najlepšie svojej, firme a rýchlo ho to prejde ...
-
peter (neregistrovaný)
Neviem, či autor článku ja autorom Ronji resp. do akej miery je do projektu zapojený, onoho času som sa o to trochu zaujímal a pôvodní autori všetky špeciality ich zapojenia veľmi podrobne vysvetlili a skomentovali, dovolím si tvrdiť, že na profesionálnej úrovni. Ale začínať článok tým, že sa začne navážať a zhadzovať názory iných ľudí, ktorí majú zrejme už dačo za sebou nesvedčí o nejakej miere empatie a úcte, dá sa to tak ospravedlniť u nejakého pubertiaka, ktorý si myslí, že mu patrí svet. Ak sa raz autor dostane do situácie, kedy sa riešenie problému, pred ktorý je postavený, nebude dať vygoogliť, čínske modulíky budú nepoužiteľné a nebude mať od koho ťahať rozumy, potom mu (možno) niečo docvakne ...
-
Prezdivka (neregistrovaný)
"Nebo mu v tom Svycarsku siblo, oni Svycari nepatri k nejsympatictejsim lidem."
S tim si dovolim zasadne nesouhlasit. Znam tady ve Svycarsku hodne milych a sympatickych lidi. Nebal bych se dokonce Svycary v nekterych ohledech doporucit jako vzor. (Samozrejme ne ve vsech.)
Napriklad po prvni svetove se nove vznikajici Ceskoslovensky stat skutecne dival na Svycarsko jako na svuj vzor, kde v jednom state vedle sebe dobre funguje vice narodnosti aniz by si prekazely (nemecka, francouzska, italska).
V soucasnosti na Svycarech ocenuji, ze si svoje firmy drzi ve svych rukach, zatimco v Cesku je hodne velkych firem vlastneno zahranicnim majitelem. S tim souvisi i takove "drobnosti" jako je clenstvi v EU. V mediich se obvykle dela bububu (naposledy v souvislosti s brexitem) jak bez clenstvi v EU je stat prakticky odepsany, ale priklad Svycarska krasne ukazuje, ze byt pouze v Schengenskem prostoru bez toho, aby byl stat clenem EU, je krasne mozne.
-
S tim si dovolim zasadne nesouhlasit. Znam tady ve Svycarsku hodne milych a sympatickych lidi. Nebal bych se dokonce Svycary v nekterych ohledech doporucit jako vzor. (Samozrejme ne ve vsech.)
Tak ja nerikam, ze Svycari jsou nesympaticti upln vsichni. Nicmene vzhledem k cizincum se obvykle chovaji dost rezervovane a cizinez ve Svajcu proste zustane cizincem. Pokud si najde pratele, nejspis to budou take cizinci. A to, ze jsou prikladem v nkterych ohledech opravdu nesouvisi s tim, jestli jsou nebo nejsou sympaticti. Treba Italove jsou obvykle dost sympaticti, ale za priklad bych je daval v malocem.
Jinak znam osobne Svycara, ktereho bych dal za priklad odpadu lidske spolecnosti, jaky se hned tak nenajde. Jeho zivotni kredo je, ze clovek musi tvrde makat, aby se vyskrabal nahoru a odtamtud mohl plivat na ty, co jsou pod nim. Krome toho je to odporny prasak a od doby, kdy ho vyhodili z prace, zije vylozene jako parazit.
-
Yarda (neregistrovaný)
Co se týká součástek a jak fungují, kdysi se mi dostala do rukou příčurka, kde si autoři dali práci, aby to srozumitelně vysvětlili - tady je ukázka:
http://www.ebastlirna.cz/modules.php?name=Forums&file=viewtopic&t=58186&highlight= -
JardaA (neregistrovaný)
A nebo se dokonce záměrně překračují katalogem stanovené mezní hodnoty, ovšem definovaným způsobem.
Vzpomínám si na "Stroboskop pro seřizování předstihu" (Amaterské rádio 10/1979; byl osazen výbojkou pro fotoblesk a vestavěn do futrálu od baterky na plochou baterii, 13,80 Kčs ;-)). Výbojka potřebovala vysoké napětí, které vyráběl měnič. To bylo přiváděno na diodu, která po dosažení potřebné hodnoty napětí (asi 90 V) začala vést, načež se měnič zastavil. Zenerky na takové napětí nebyly, autor ale použil běžnou diodu (KA206) v závěrné směru. Ta by se normálně při překročení závěrného napětí prorazila a nevratně zničila, avšak autor omezil proud na několik uA, takže jí to nevadilo (tedy přežila). Řada kutilů však měla s oživením stroboskopu problémy - Tesla totiž ony diody vyráběla s výrazně vyšším napětím závěrným napětím oproti katalogovým hodnotám; chtělo to použít jinou diodu a hlavně udělat si přípravek a měřit. -
Ondra (neregistrovaný)
Jsem rád že sem Clock dal tento článek, a to minimálně kvůli této větě:
Nechali byste si operovat slepé střevo od doktora, který má sice sofistikované znalosti z lékařských sympozií, ale v životě neviděl pacienta uvnitř?
Silně mi to přijde jako argument ad hominem, navíc analogie je to hrubě nepřesná. Teoretická informatika je spíše matematická disciplína než technická, a pokud se někdo věnuje třeba teorii automatů nebo teorii grafů, neznamená to nezbytně že zná technikálie aktuálních procesorů a jiného HW. Pokud by tedy Clock chtěl trvat na analogii z medicíny, mohl by napsat třeba:
Nechali byste vyšetřit od psychologa, který má sice sofistikované znalosti z lékařských sympozií, ale v životě neviděl pacienta uvnitř?
Na což klidně odpovím - ano, nechal. -
Prezdivka (neregistrovaný)
"Jsem rád že sem Clock dal tento článek ..."
Ja ani moc rad nejsem. Z toho clanku mam silny pocit, jako by z nej co chvili vykukovalo ego. Jako by s nim autor tak nejak cely zivot zapasil, ale stale by se mu nedarilo ho dostat pod kontrolu. Takove clanky, kde ego nejakym zpusobem vystrkuje ruzky se mi nectou dvakrat dobre. Autora vubec neznam, jen mam z toho clanku proste tento pocit, coz je samozrejme subjektivni vec a jini lide to muzou videt jinak.
ČLÁNKY DO MAILU