[elektro] Hülye okostelefon (HTC Kaiser)

[Xorn]

Én is programozóként kezdtem, és van fogalmam róla, hogy miről is
beszélek. Igaz, vagy 10 éve programoztam utoljára, azóta rendszergazda
vagyok, azóta akár még fejlődhetett is a mutatvány.

Mindenesetre az én tapasztalatom az volt, hogy ha valaminek alá tudtam
menni egy szinttel, le tudtam bontani egy réteget valamiről, akkor
látványosan javult a végrehajtási sebesség - cserébe azért, hogy a
kódolás és a kód későbbi karbantartása bonyolultabb lett.

De manapság csak az számít, mennyi idő alatt készül el a cucc, így
sokszor nincs idő/pénz és ember ilyesmibe belemenni. Ember olyan
értelemben sincs, hogy nincs olyan programozó a cégnél, aki erre képes
lenne...

Best regards,
Andy

2012/8/23 SZIGETI Szabolcs <szigiszabolcs at gmail.com>:
> Egy jó optimalizáló compiler bármiből jó kódot fordít. Amelyik nem, az
> nem jó optimalizáló :-)
>
> Amit szokás keverni, az az, hogy a legtöbb modern nyelv nem csak egy
> valamiből fordítunk assemblyt jelegű dolog, hanem teljes környezet. A
> C-ben kb. a printfnél és a qsortnál megáll a bonyolultság. C++, Java,
> de említhetnénk Python, Perl tulajdonképpen a nyelv részeként rengeteg
> összetett feladatot megvalósító könyvtárat tartalmaz.  Ezek nem csak
> ilyen-olyan rutinok, de ütemezők, szálkezelők, hálózati dolgok stb.
> Ezekkel persze van baj, legfőként az, hogy ismerni kell őket, és ez
> önmagában nagy feladat, de a legtöbbször kiderül, hogy mondjuk az API
> dokumentáció pár órás túrásával több napnyi fejlesztést spórolhatunk
> meg. Aztán az is baj, hogy az idős programozók nem hiszik el, hogy
> ezek használhatóak és jók, a fiatal programozók meg meg vannak
> győződve róla, hogy ők ennél csuklóból jobbat írnak.
> Jópárszor láttam, hogy lelkes ifjú láncolt lista meg dinamikus vektor
> írásával kezdett neki a fejlesztésnek, és amikor megkérdeztük, hogy
> miért is nem használja a Java, vagy a C++ gyárilag meglévő ilyen
> elemeit, a válasz mindig az "az biztosan lassú" volt. Hogy bármilyen
> mérés nélkül miért gondolta, hogy ő jobbat csinál a párszáz mérnökév
> alatt kifejlesztett dolgoknál, azt persze nem tudta megmondani. És
> persze mindig kiderült, hogy nem is lassú.
> Egy ismerős (sok éves assembly tapasztalattal) nekiállt, hogy egy régi
> programját átírja assemblyből C-be, majd C++-ba, majd C++ + template
> library-ba. Megdöbbenve mesélte, hogy az utolsó változat lett
> aleggyorsabb (pedig ez valami képfeldolgozó algoritmus volt) viszont
> kb. egyszázada volt a fejlesztési és debuggolási idő. Persze ő jól
> ismerte az STL-t, tudta, mi mire való, és legfőként nem állt neki
> varászlatokat csinálni, hanem hagyta, hogy a bevett megoldásokra
> kihegyezett optimalizáló compiler tegye a dolgát.
> Ezzel persze nem azt akarom mondani, hogy nincs helye a kézzel
> faragott kódnak, de szerintem ezt gondos mérnöki megfontolások és
> _mérések_ alapján kell tenni. Meg természetesen tudni kell azért, hogy
> melyik feladatra mely nyelv és környezet az alkalmasabb.
>
> Mert legtöbbször nem az az idő számít, ami az enter lenyomásától az
> eredmény megjelenéséig tart, hanem ami a szerződéskötéstől a számla
> kiállításáig. És itt nagyon nem mindegy, hogy a fejlesztés és
> karbantarthatóság mennyire nehéz vagy könnyű.
>
> Szabolcs
>
>
>
> Xorn <toth.endre at gmail.com> írta (2012. augusztus 23. 7:35):
>> Na ja. C-ből tűrhető minőségű assembly kód fordítható egy jól
>> optimalizáló compilerrel. Ezekkel a baxokkal meg... :-(
>>
>> Best regards,
>> Andy
>>
>> 2012/8/23 Karoly Kovacs <koka55 at kabsi.at>:
>>> Szerintem C-ben irtak. A mostaniakat meg objektumorientalt nyelveken.
>>> Vagy ki tudja?
>>>
>>> Karoly
>>>
>>> -------- Original Message --------
>>>
>>>>> ...es megsem eszi meg az elemeket .
>>>>> fantasztikus hova fejlodik a technika .
>>>>
>>>> Két 1000-1200 mAh körüli ceruzaakkuval ha jól emlékszem 2-3 hetet is elment, nem
>>>> sok bekapcsolással. De volt vagy 30 MHz-es procija az s5-nek, a maiak meg GHz
>>>> körüliek. Fogalmam sincs hogyan írták meg az epocot, de kb. annyira volt fürge,
>>>> mint a mai 30-szor gyorsabb processzoron és 60-szor annyi ramon futó android. A
>>>> 400 MHz-en futó wince-t meg körbeszaladja párszor. Pedig tuti nem assemblyben
>>>> írták szénné optimalizálva.
>>>>
>>>> Üdv.: gyapo
>>>>
>>>> -----------------------------------------
>>>>            elektro[-flame|-etc]
>>>>
>>>
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>
> -----------------------------------------
>           elektro[-flame|-etc]