Coding was:Re: Horizontal Lamerz se rozpadli :(((((((

["Filip Doksansky" <glassim@mbox.vol.cz>]

> Ja osobne, kdyz si chci vyzkouset nejaky napad, tak to udelam na pc.
> Nejsem tam tolik svazovan (nedostatek barev, c2p, nutnost delat vylucne
> v assembleru, neustale resety pri chybach). Ackoliv vim, ze se zvedne
 K tomuto vyctu bych rad prihodil katastrofalni situaci co se tyce
developerskych nastroju. To co se prezentuje jako nejprofesionalnejsi
IDE pro AmigaOS development je spise aprilovym zertem prezentujicim
naprostou impotenci H&P vyvojoveho tymu. Navic ve verzi s assemblerem
a prekladacem pro PPC stoji cca 14 tisic. Pro vetsinu lidi imho ponekud
nedostupne... Jeste pro 68k se da o jakesi podpore hovorit (SAS/C ,
Devpac Assembler apod je pomerne kvalitni...) ale co se tyce PPC tak je
to neco neskutecneho. Vubec nechapu jak se da vyvijet software bez
debuggeru ! Sam jsem si to vyzkousel a jak to dopadlo je evidentni -
naproste
znechuceni zakoncene prodejem Amigy. Duvod proc tady brecim neni
proto abych jen bohapuste drzkoval, ale proto aby lidi videli duvody
vyvojaru kteri amigu opustili.Rozhodne to neni o nejak zradcovstvi ci
pohodlnosti....

> vlna odporu, ktera bude tvrdit, ze to je lenosti a neochotou
> optimalizovat, tak musim upozornit, ze soucasne graficke algoritmy jsou
> uz prece jen tak slozite, ze jejich low-level optimalizace velmi
> znesnadnuje jejich programovani, spravu a taky odvadi pozornost od
> "high-level" optimalizace na urovni samotneho algoritmu.
> Neco jsem si z PC prevedl na Amigu a musim za sebe rict, ze optimalizace
> na urovni rozvrzeni instrukci, vyuziti registru a pristupu do pameti mi
> pri uz vymyslenem algoritmu zabrala i dvakrat vic casu nez jeho samotne
> vymysleni na PC. A prave vymysleni algoritmu povazuji za opravdu tvurci
> praci! Koneckoncu ne nadarmo se uz nekolik desetileti tvori prekladace a
> metody strojove optimalizace kodu.
 S timto naprosto souhlasim. Ve chvili kdy jsem 68k asm povesil na hrebik a
zacal delat pouze v C/C++ jsem dosahl mnohanasobne vetsi produktivity
at uz proste proto, ze psat v C je podstatne rychlejsi, ale hlavne proto, ze
jsem
misto ztraceni casu hledanim nejoptimalnejsi kombinace pouziti registru jsem
se venoval celkove koncepci a algoritmum. Ve vysledku jsem casto
dosahl rychlejsiho kodu proste proto ze jsem vymyslel lepsi algoritmy, nez
abych se napriklad mazal s parovanim CPU/FPU instrukci :-P Kdyz tak koukam
na to co jsem vyplodil, tak vidim, ze je to to samy cos napsal ty Defore :-)
 Jeste bych chtel poznamenat pro zaprisahle nepratele hi-level jazyku, ze v
pripade
dnesnich procesoru (ne, opravdu nehovorim o pomalych crapech typu 68030 :-)
je programovani v assaku naprosty nesmysl , protoze clovek proste neni
schopen
efektivne vyuzivat novych vlastnosti CPU, jako je vice pipelines, pripadne
vybirat nejvhodnejsi instrukce z bohatych instrukcnich setu (krasny priklad
je PPC)
Jako posledni vec je take to, ze dnesni CPU je tak rychle, ze se stejne ceka
spis
na ramku a to neovlivni sebelepsi kod.... V tomto bode si musim sypat popel
na
hlavu, protoze pred nejakym rokem ci dvouma jsem obhajoval pravy opak...asi
mozna proto, ze prave na 68k je situace paradoxne opacna :-)

    Fido