SME
Streda, 25. november, 2020 | Meniny má KatarínaKrížovkyKrížovky

Načítavam moment...
Momentálne nie ste prihlásený

Stvorili najmenší šachový program, má len 487 bajtov (Späť na článok)

Pridajte priamu reakciu k článku

1 2 3 4 5 > >>

Hodnoť

 

"Autor tohto projektu Olivier Poudade tvrdí, že programátori by sa aj dnes mali držať namiesto moderných programovacích jazykov Asembleru, v ktorom možno optimalizovať kód k úplnej dokonalosti." - tak to je programagor :-)
 

 

ked pocujem slovko programator, tak si vzdy spomeniem na staru tatramatku
 

Zato ty si expert

ktory vsak ani netusi, aku pravdu ten ***** vyslovil.
 

 

pravdu..?
v praxi sa to proste neda...
ako si to predstavujes..? idem kodit webovu aplikaciu , tak si zacnem pisat v assembleri web server...
idem pisat uctovnicky softver tak si najprv napisem v assembleri programovaci jazyk..:-/

pretoze dobre navrhnuty softver by ten assembler tak ci tak zapuzdril na nejaky "framework" tj. na iny progr. jazyk..
 

Účtovníctvo

A čo si mám myslieť o dnešných účtovných softvéroch, ktoré zaberajú na disku gigabajty a pritom funkčne slúžia na to isté ako niekdajšie DOSovské účtovníctva, ktoré zaberali niekoľko magabajtov, teda boli 100-krát menšie. To je zvláštny prínos tých frejmworkov ako .net a podobných grcov. Samozrejme máme omaľovánky, každé okno má v sebe iné zbytočné obrázky, farby, tiene a iné blbosti.

Som rozčúlený, lebo som nedávno testoval moderné účtovníctvo Omega a potreboval som urobiť update na najnovšiu verziu a mal som ho na disku, kde bolo voľné "len" 700 MB a ani po uvoľnení na 1 GB program nedokázal urobiť update pre nedostatok miesta. Keď bude zaberať každý používaný softvér na disku gigabajty (bez dát), tak kam sa niekde v procese vývoja frejmworkov stala nenapraviteľná chyba a treba hľadať inú cestu.
 

problem moze byt (?) aj v tom, ze

miesto na HD velmi zlacnelo a dari sa zvysovat rychlost procesorov. Preto je lacnejsie a efektivnejsie nechat programatora zbuchat rychle program, nez ho platit za optimalizaciu programu.
 

Pokial pisete progarmy, ktore

nahanaju nanosekundy, tak min . C-cko je potrebne

A JSI (anglicky Assembly language) vyznamne rastie na trhu jazykov pouzivanych porfikmi , ktori nechaju svoj kod (min. v prelozenej) nechat auditovat
http://www.tiobe.com/index.php...
 

Asembler

alebo strojovy kod su zakladne porgrmaviacie jazyky. Vsetko co teraz "programator" nasklada z modulov z netu sa musi prelozit do strojoveho jazyka. cize ak to napises v strojovom jazyku nepotrbujes to zapuzdrovat, nepotrbujes interpreter.
 

 

a o ale budes to programovat 50x tak dlho... kodit rozsiahlejsie apliakcie v assembleri dnes je hlupost - aspon v komercnej urovni, samozrejme ako nejaky hobby projekt pre zabavu to je daco ine... a to hovorim ako programator co pred rokmi v assembleri pod dosom v textovom mode kodil graficke dema :-))))

samozrejme su oblasti (audio aplikacie, virtualne efekty a syntezatory) kde si clovek pre lepsiu optimalizaciu na rychlost pomaha pisanim casti kodu a citlivych rutin v asm.. ale celu velku aplikaciu napisat cisto v asm - nepredstavitelne...
 

 

Tak tak, na nejaký processing audia, obrazu, meshov alebo 3D scanov, tam má stále nejaká dobre napísaná SIMD rutina zmysel, pretože síce rastie výkon, ale aj rozlíšenie a objem dát, ale to sú úzko špecializované aplikácie. Ale aj ako píšu ostatní, keď mám účtovnícky softvér, kde je na klientskej strane najnáročnejšia operácia násobenie a ledva to reaguje, tak to je zas druhý extrém.
 

 

Bohuzial mas pravdu, a aj to je dovod preco je slovo `KOMERCNE` brane dnes ako nadavka!
(a to zdaleka nie len v IT oblasti)

Potom vysvetlujem okoliu, preco pani majstri ehm `profesionali` jednoducho z principu neodvedu kvalitnu robotu -> dnes je trend spravit tu cast, co najviac vidno a s detailami ci trvanlivostou sa nekaslat!
O optimalnosti a optimalizacii uz ani nehovorim...
Dnes sa s vecami `nehrajka` -> ale sa sekaju normohodiny a v podstate je to z velkej casti aj chyba na strane dopytu.
Mnohi ludi este nieco ani nie je hotove a uz to rozd..bu, pretoze vymyslaju zas nieco nove!
 

 

No, ten francuz ma pravdu len ciastocne.
Osobne som tiez zastancom kvalitneho kodovania (programovania), aby program bol optimalizovany a bol napisany co najprehladnejsie, aby bol fakt odladeny. Je tu vsak par ale:
- prvým ALE je to, ked sa tym zivite. Dostanete za ulohu naprogramovat nejaku DB aplikaciu k nejakemu projektu. Je na to vyhradeny balik penazi, ktory je vsak vo vacsine pripadov nizsi nez by bolo potrebne. Vtedy proste programujete tak, aby sa urobil co najlepsi program v pomere uzitkova vlastnost/naklady. Na odladenie na 100% proste peniaze uz nie su a ak sa tym mate zivit, robit zadarmo nie je najlepsie riesenie
- druhym ale je zmysel kodovania v Assembleri. Tiez som pred cca 20-timi rokmi riesil vlastné grafické rozhranie na 386/486 a pisal som to vsetko v assembleri, pocital som procesorove cykly na jednotlive instrukcie a oprimalizoval to (a trosku sa pochvalim - bezalo to fakt super rychlo). Dnes uz by som sa tomu ale urcite nevenoval, lebo rychlost procesorov a kapacita diskov, pamati je tak predimenzovana, ze nevidim vyznam cele dni sa trapit pre vystup grafiky v assembleri, ked to proste namalujem ako vektorove ciary a bude to tak rychle, ze ani okom nemrknem ... Ale na druhej strane, zasa ked som riesil komunikaciu cez I/O porty, tak tam sa da v assembleri celkom slusne vyhrat ... :-) (hlavne ked protokol bol zdokumentovany pre Assembler).
Samozrejme, druhym extremom je zasa pisanie programov stylom "Hallo word", ktory po skompilovani ma 3 MB .... :-) Ze sa proste do programu nahadze vsetko mozne a vyzera to ako by to pisalo prasa, nema to ani hlavu ani patu a aj vykonny stroj ma co robit, aby to utiahol .... :-)
 

 

Ja som rád za obdobie mladíckeho experimentovania a optimalizácií v assembleri - človeku to dá vhľad do vecí, ako fungujú pod kapotou a potom aj k písaniu high-level kódu pristupuje pragmaticky a neprodukuje naboptnané a pomalé "prasárny" a má cit pre algoritmické vychytávky. Ako hovoríš, kto si niekedy napísal napr. vlastný rasterizér, ten sa neskutočne veľa naučil a z mnohých fínt môže čerpať aj dnes, aj keď v inej podobe. Tieto krátke programy a demoscénové "intrá" su viac o zábave a zisťovaní nových fínt. Súhlasím s tým, že v bežnom profesionálnom živote je dôležitejšie optimalizovať iné parametre - cenu, zložitosť vývoja a testovania, menežovateľnosť kódu, rozšíríteľnosť na iné platformy a pod. Sám som kedysi rád písal 256 bajtové grafické demá a s kamarátmi sme trávili brutálne veľa času súťažením a brainstormovaním. Ale treba to brať tak, o čom to naozaj je - zábavka a súťaživosť. Nejaký assemblerovský fundamentalizmus je hovadina, treba na správnu vec použiť správny nástroj. Napríklad na vektorových jednotkách PlayStation 2 by si človek s jazykom vyššej úrovne ani nep*dol, ale to neznamená že v tom treba písať weby, kancelárske aplikácie alebo databázy :)
 

Blby preklad / reinterpretacia autora

Povedal: "[It] demonstrates why assembly language is still the language of choice to excel [at] in programming," he said."

Samozrejme az na fakt vynimocne situacie nema zmysel v nom nieco pisat, ale stale je treba ho poznat, rozumiet ako veci funguju pod kapotou.
 

 

Ja tomu nerozumiem tiez. Rychlost aplikacie nevychadza z toho ci bola napisana v asm alebo inak. Programator aj tak pozna prekladac jeho vyssieho kodu, bez toho aby sa trapil pisanim asm. Optimalizacia spociva na inych veciach ako na tom v com je program napisany.
 

 

To platilo tak pred 20 rokmi, kedy sa v assembleri dala napisat rutina, ktora naozaj bola nasobne rychlejsia ako cokolvek v high level jazyku. Dnes su procesory, kompilatory, profilery niekde uplne inde, a "rucna" optimalizacia v assembleri je nanic, pokial clovek detailne nepozna architekturu, branch/loop predikcie a ine vychytavky, moze byt aj kontraproduktivna.

Vratit sa k assembleru je nemyslitelne, ale uplne by stacilo, keby programatori vedeli ako taky pocitac funguje a tuto znalost aj vyuzivali a obcas svoje dielo aj prehnali cez profiler. Zobrat nejaky framework a nieco v tom zbachat vie kazdy. Potom clovek vidi nehoraznosti, nad ktorymi zostava stat rozum:
- dlhsie spusteny skype zerie 200MB, prehliadac ani nehovorim
- nemenovany e-commerce framework pocita DPH jedneho produktu 1.87 sekundy a spravi cez 2000 queries do databazy (lebo presne v tolkych obmenach sa produkt v rovnakej cene predava)
- nemenovane IDE v kludovom stave reaguje v radovo sekundach

Tym nechcem znevazovat assemblerovu demo scenu, su to skutocne majstrovske diela, ale pre produkciu je tento pristup dnes uz naozaj nepouzitelny
 

 

Preco nemenovany? Vsak normalne napis co to je a comu sa pripadne vyhnut.
 

 

Sanduhr-Anzeige-Programm, teda SAP :-)
 

 

Magento? :)
 

 

Magento.
 

1 2 3 4 5 > >>

Najčítanejšie na SME Tech