Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Proč se nedivím? Vývojáři si usnadní situaci pro zpětnou kompatibilitu, navíc ušetří čas a tedy další náklady. Nevýhody s tímto stavem jdou za uživatelem. Uživatel sežvejkne všechno, zvláště když netuší, že by ani žvejkat nemusel.
Uživatel i když tuší, že by žvejkat nemusel tak s tím nic nenadělá. Leda by si každou odfláknutě napsanou hru dekompiloval, upravil tak, aby používala příslušnou kompresi textur a pak zase zkompiloval. Situace se vyřeší časem, ale ani největší studia si dnes nedovolí vydat hru která by vyžadovala dx11, většinou se udržuje kompatibilita alespoň s dx10 a spoustu titulů hlavně těch online (například wot) je stále jen dx9 aby vývojáři mohli dostat peníze i od lidí hrajících na kancl pc nebo noteboocích s integrovanou grafikou.
Vzdy lepsie ako chrlit hry vyzadujuce najnovsi pocin z dielne socialnych inzinierov z MS!
Tym by akurat rastol tlak na uzivatelov, akceptovat nechcene OS od MS (vista, W8...), pretoze MS samozrejme veeeelmi rad zneuzije svoj uzavrety DX monopol na pretlacanie svojich novych nepodarkov!
(pri viste s DX10 sa mu to nepodarilo, uvidime ci pohori aj s DX12 ktore urcite nebude v popularnom W7, ale len v nenavidenom paskvile W8 ci `nadeje do buducnosti` W10 - ktore ja ale vobec nadejne nevidim uz len kvoli nevypnutelnosti automatickych updatov v neprofi verzii ci neustalu snahu drbat tam niekde tie sproste `dlazdice`)
na margo zacarovaneho kruhu: vykonnejsi/kapacitnejsi HW <-----> narocnejsi/zravejsi SW dodam:
http://www.dsl.sk/article.php?article=13116 "Smutna odysea 9" a 10, autocitujem:
A to som este nefilozofoval o SW !!!!!!! Kedysi v 60. rokoch bola efektivita pri programovani a vseobecne v SW na dnesne pomery nepredstavitelna. Jednak preto ze sa programovalo na ovela nizsej urovni ako dnes, jednak preto ze HW bol znacne obmedzeny. Efektivita vsetkeho co suviselo s SW bola na samotnej hranici matematicky dokazanej dokonalosti. Doslova islo o kazdy bit, o kazdu skupinku elektronov! S par desiatkami kB pamate a vykonom pocitaca ako maju dnes hodinky (nie mobil, ale debilne naramkove hodinky !!!) pristali na Mesiaci !!!! Co dnes dokazeme s tymi Gigaflopsami vykonu a Gigabajtami kapacity? Toto: http://weknowmemes.com/wp-content/uploads/2012/02/sad-but-true.jpg (smutne ale pravdive).
Vsetko sa zanasa len dalsimi a dalsimi vrstvami SW a frameworkov a pracuje sa na tak vysokej urovni oddelenej od HW, ze postupne zanasanie a nabalovanie dalsich vrstiev stale znizuje efektivitu SW a potrebujeme stale vykonnejsi HW. Spat to uz nikto nevrati, museli by sa prekopat vsetky OS a vsetky SW za posl 40 rokov. Ked to takto pojde dalej, za 1/4 storocia si nezohrejeme pizzu v mikrovlnke, alebo neoperieme zasr**te trenky v pracke bez 64-jadroveho CPU (gigahertzova vojna pre CPU skoncila v 2003, otazne je kedy skonci multijadrova vojna) a 256 GB pamate !!!
Tak si ty vole přepni monitor na černobílo, ty 64kb vopice. Billovi Gejovi se směješ ale sám si ještě o řád větší jelito.
K článku, je to jen otázka času kdy se začnou hry psát unifikovaně pro konzole, tablety, mobily, a PC. Pak se vývojáři zase uskromní co se týče velikosti textur.
Tak sa pozri na tuto hru kkrieger: http://digiex.net/downloads/download-center-2-0/games/4683-kkrieger-96kb...
Ma 95 kB!!! mozes behat, skakat, strielat, mas tam nepriatelov, a grafika je na 96kB uzasna.
Na win7 a viac je asi potrebne dat na .exe prave tlacitko -> Vlastnosti -> kompatibilita -> a vybrat kompatibilitu s WIndows XP.
Ale na takuto efektivitu sa bezne predavane hry nedostanu ani o 20 rokov, pretoze uz mame tej pamati prehnane vela.
Nevidíte ale druhou stranu mince.
Viz http://it-joker.cz/Zapisnik/170-Kdo-je-skutecne-dobry-programator-.html
Ano, v 60. letech se ze směšného výkonu HW dokázaly vytřískat neuvěřitelné věci.
Jenže ta optimalizace není zadarmo.
1. Čím větší optimalizace pro určitý HW, tím horší přenositelnost. V tom „Příběhu o Melovi“ by fungování programu narušilo i to, kdyby ten počítač měl víc paměti, nebo rychlejší paměť. Přenos programu na jiný model počítače (stejného výrobce) v podstatě znamenal ten program napsat znovu.
S důsledně optimalizovaným SW by modulární počítač a platforma PC byly absurdní myšlenky, protože s výměnou čehokoliv v počítači by přestal fungovat software.
Důsledná optimalizace pro hardware nutně znamená počítače s jednotnou konfigurací a vysokou cenou (kvůli velice drahému vývoji aplikací).
Důslednou optimalizaci pro HW si představte tak, že na trhu smartphonů bylo celkem asi deset modelů v ceně 20-50 tisíc, pro každý model by existovalo řádově tisíc aplikací, kompatibilních pouze s tím jedním modelem. Výdrž na baterii by byla podstatně lepší a aplikace rychlejší, ale obsahovaly by více chyb.
2. Optimalizace pro HW trvá a vyžaduje špičkové programátory, takže stojí hromadu peněz.
Jádro zmíněného Příběhu o Melovi je, že špičkový programátor strávil dva týdny práce na triviální úpravě programu pro Blackjack a pak řekl, že to nezvládne.
Přičemž v dnešních „neoptimalizovaných“ jazycích je Blackjack úkol pro začínajícího programátora na víkend.
K raketě na Měsíc: Apollo Guidance Computer byl hlavní zdroj navigačních dat jen když nebylo spojení se Zemí. Jinak data počítalo řídicí středisko (protože to dokázalo přesněji, než AGC) a astronauti je pak zadávali do AGC.
Za prvé, to poslední tvrzení není úplně relevantní - AGC byl sice zbaven velké části zodpovědnosti za zjišťování a průběžnou opravu stavového vektoru lodi (čemuž vy říkáte "navigační data" ;-)), ale pořád měl na starosti řízení celé lodi podle aktuálního stavového vektoru, což obnášelo mnohem víc než jen integraci a opravu stavového vektoru. Za druhé, tato funkčnost byla i tak v zásadě zachována, a Apollo 8 prověřilo její funkčnost (a její přesnost se ukázala jako naprosto postačující). Tedy to, že tato funkčnost nebyla nakonec pravidelně využívána (tím se především snížila zátěž astronautů), nemění nic na tom, že jí bylo na dobovém hardwaru technologicky dosaženo.
Jo na tom neco bude. Super-optimalizacia SW na HW ma aj svoju dan.
To je nesmysl, SW se dá optimalizovat a pořád zůstane přenosný. Chce to jen změnit výchovu.
Například spousta lidí napíše program takto: a = c+g *x +*p_x ? s,d 'd 5*; Čili změť nečitelných klikiháku, subjektivně si myslí krátký zápis = krátký program. Což samozřejmě není pravda a pak se jim to nechce optimalizovat, protože se v tom sami nevyznají.
Hodně za to může i Microsoft a jiní, kteří tvrdí že C a jiné jazyky se dnes vyrovnají assembleru. Ale to není pravda a škoda že jen málo lidí se plodivá jaký hnus vznikne při překladu.
Kdysi jsem zahlídnul na netu příklad. Součet pole.
Většina lidi napíše
for iPole=0 to 32
Ale to je blbost, efektivnější je napsat:
Pole[0]+Pole[1]+Pole[2]......Pole[32]
"Premature optimization is the root of all evil." Z hlediska přehlednosti, udržovatelnosti, pravděpodobnosti chyby je lepší první zápis. Z hlediska výkonu taky, protože loop unrolling je natolik základní, že to umí snad každý rozumný kompilátor. Navíc není samospasitelný, narůstá např. velikost kódu. Kompilátor může určit optimální míru rozbalení cyklu pro každou cílovou architekturu, pokud to nakódujete natvrdo, o tuhle výhodu přicházíte.
No tak zrovna hry jsou stále ještě v kategorii těch efektivnějších programů... ;-) A efektivita programování jako takového (tj. lidské činnosti) byla spíš nepředstavitelně otřesná, tedy pokud člověk nebyl Chuck Moore a nevynalezl si Forth, aby týden tehdejší průměrné programátorské práce zvládl za den. :D
...Este by som dodal, ze v tych nehorazne pretucnenych kodoch je prakticky vylucene aspon akotak vychytat tu spustu chyb...
Aj to je dovod, preco dnes vychadza tak zabugovany SW, a modne `automaticke aktualizacie` mozu pomoct len ciastocne, pretoze to mnozstvo chyb nejde opravit za dobu zivotnosti SW, nova verzia vznika pomaly kazdy den, a kazda zmena ci oprava vyvolava moznosti vzniku dalsich chyb.
Je pravda, ze v roku 1996 som robil zadania do skoly na 486SX 25, 8MB Ram, Word 6. Ten word mal 6 MB. Nejak si nespominam, ze by bol pomaly alebo ze by mi tam nieco vyrazne chybalo. Styly, automaticky obsah & auto cislovanie stran, kreslenie, tabulky. Potom som upgradoval na Am486DX5 a to bol fukot :)
No a pak si do textu potřeboval vložit 3 fotky a zjistil si, že to nefunguje. Jsou lidé kteří potřebovali 30 nebo 300.
To byli zřejmě ti, co tou dobou ještě neobjevili TeX nebo Troff... :-)
To este nie je dobry priklad, v tych dobach totiz este programy tak moc netucneli a prinasali na oplatku zaujimave a uzitocne funkcie!
Niekedy po r. 2000 sa to zacalo zvrhavat, SW zacal udesne nabobtnavat a pritom prinasal vecsinou len kopu balastu ci funkcii, ktore skor obtazovali resp. rovno vselijaky kruto `zmodernizovany` interface...
Preco asi stale pouzivam X rokov stary winamp ci ACDSee? ;o)
Zaujimave pri tom je, ze mame stale lepsie kompilatory. Tj da sa predpokladat ze 20 rokov stary SW pokial by bol prelozeny dnesnym kompilatorom by bezal o povedzme 2-20% rychlejsie a/alebo mal mensiu binarku.
Ked si clovek pozriet kompilatory z 80tych rokov, sme na tom dnes o dost lepsie. Je to aj o tom, ze dnesne kompilatory maju k dispozicii ovela vacsi vykon.
Len ono je objektivne coraz tazsie vobec vymysliet zaujimave a uzitocne funcie v danej oblasti (az na vynimky kde predtym bud nestacil vykon alebo pamet).
A kedze firmy su tlacene furt vydavat nieco nove alebo aspon nove verzie (posadnutost trhu pokrokom) za kazdu cenu a co najrychlejsie,
tak potom logicky tam bud napakuju plno balastu, alebo rovno `revolucne` dokurvia interface :o(
Mensi binarku by urcite nemel, optimalizace na velikost dneska nikdo nedela, naopak. Ale rozdil v rychlosti, zvlast na modernich pocitacich, by casto byl skutecne vyznamny ...
Dnesne kompilery vedia pri spravnom nastaveni dobre optimalizovat na velkost.
Pouzivam momentalne najnovsie gcc v embeded sfere, c++, takze viem o com hovorim. Do 14kB binarky som napchal mnoho a mnoho riadkov kodu, bez optimalizacie na velkost je to 27kB. Napr taky BorlandC++ pouzivany v 80tych a 90tych rokoch zdaleka nevedel tolko optimalizovat na velkost. Ak si pozriete skompilovany kod z Borlandu, tak je to casto skoro len 1:1 preklopeny zdrojovy kod, ziadna velka analyza zbytocneho kodu, ziadne preskupenie kodu ktoremu mozem zmenit poradie ked to algoritmus neovlyvni a usetri to bytes/cycles, samozrejme ziadne automaticke reusovanie kodu, auto inline a neviem co.
Samozrejme ze kdyz uz program obsahoval vsechny uzitecne funkce, tak funkce pridane pote byli k nicemu. Ale kdyz se to vejde, tak se proste funkce pridavaji dokud jsou napady ...<br><br>"Modernizace interface" je oproti tomu naprosto nezavisly jev, casto souvisejici s tim, ze se program upravuje aby byl snaze pouzitelny cvicenou opici, cimz se dosahne toho, ze bezny uzivatel si muze uzit intelektualni prevahy nad ocekavanym uzivatelem.
"Modernizace interface" je oproti tomu naprosto nezavisly jev, casto souvisejici s tim, ze se program upravuje aby byl snaze pouzitelny cvicenou opici, cimz se dosahne toho, ze bezny uzivatel si muze uzit intelektualni prevahy nad ocekavanym uzivatelem. https://diit.cz/clanek/2-gb-graficke-pameti-staci/diskuse#comment-794708 +
Nechapu jednu vec. Programatori nevyuzivaji novych algoritmu, protoze stare karty je neznaji. Nicmene stare karty ani nemaji moc pameti...
Blby je, ze MS svazuje DX s verzi widli :( Pak by nebyl problem vyzadovat nejnovejsi DX nainstalovany, ale pouzit z neho jen nektere ficury a mit v nastaveni moznost volby.
Assassin Creed co ja vim mel take 2 binarky, jednu pro DX9 a druhou pro DX10.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.