[elektro] Hülye okostelefon (HTC Kaiser)

[SZIGETI Szabolcs]

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]