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