LINUX
Vajk Fekete
halaloszto at yahoo.co.uk
Tue Mar 29 23:08:15 CEST 2005
azert erre tudok egyszeru peldat mondani.
ha a programod egy kicsit is multithreaded, es kellenek szemaforok, meg
szalak kozotti ertesites es kommunikacio, akkor mekkora az esely ra,
hogy c-ben vagy assemblyben ket het alatt olyan hatekonyra megirod, mint
amilyenre a java fejlesztoi megcsinaltak? Raadasul - itt jon a poen - ha
Te megcsinalod c-ben, az a c fordito szamara csak kod, amit
optimalizalni kell, viszont javaban a fordito tudja hogy az egy
szemafor, tudja hogy itt egy alvo thread ertesitese folyik, es igy tovabb.
a vita azert parttalan, mert a vitatkozok egy resze nem hajlando
atlatni, hogy a pic-tol az unix alapu webszerverig olyan szeles a skala,
hogy nagyon primitiv allitasoktol eltekintve nincs olyan ami mindenhol
igaz lenne. igy barki barmit mond van ra ellenpelda.
vajk
VFX wrote:
>Hali!
>
>
>
>>a problema ugyanaz, mint az assembly kod optimalizalasanal: ha
>>azt nem tudjak megcsinalni tisztessegesen (ezalatt ertsd:
>>elegge altalanosra es hatekonyra) semmilyen architekturara,
>>akkor a jvm gepi kodjat miert tudnak (plane futasi idoben)
>>jobban optimalizalni? a java2jvm kod transzlacio meg nem latom,
>>miert lenne jobban optimalizalhato, mint a c2asm, mikor mindket
>>magasszintu nyelv azonosan altalanos.
>>
>>
>
>Na igen ezt nem ertem meg mindig.
>Ha a java2jvm -> gepikod optimalizalhato es jo,akkor a c2asm -> gepikod
>miert lehetettlen? Miert futna gyorsabban az elozo es lassabban az
>utobbi?
>
>De ez termeszetesen koltoi kerdes volt!
>
>
>UDV. VFX.
>http://www.vfx.hu
>
>-----------------------------------
> Szponzorunk: http://tonerbolt.hu/
>
>
>
>
More information about the Elektro
mailing list