Keresés

Aktív témák

  • bambano

    titán

    válasz #95904256 #94 üzenetére

    Nincs másodlagos adminisztráció, readonly-ra állítja a lap védelmi kulcsát oszt csókolom.

    A runtime kód hekkelés meg nagyvállalati rendszerben nem szokásos.

  • shev7

    veterán

    válasz #95904256 #94 üzenetére

    hat pedig ha ki kell irni az mondenkeppen tobb ido mintha nem kene kiirni :)

  • bambano

    titán

    válasz #95904256 #85 üzenetére

    Ezzel már offtopic vagyok, ha jól sejtem... sorry.

    A kérdés nem az, hogy a legrégebbi vagy a legritkábban használt lapokat teszi-e ki a swap-re, hanem hogy egyáltalán kitesz-e bármit is.

    A linux kernel úgy gondolja, hogy annak nulla értelme van, hogy egy programkódból két teljesen azonos szektortartalom keletkezzen (hogy két példányban legyen a vinyón, egyik példány az eredeti helye, ahonnan betöltődött, a másik példány a swap), ezért a linux egyáltalán nem pakol ki ilyet a swap-re.

    Egész egyszerűen kihajítja a fenébe, majd ha megint kell, akkor betölti az eredeti helyéről.

    Tehát konkrétan:
    - nem teljesen értelmes oprendszer: betölti diszkről a programkódot és a libeket, ezeknek foglal egy szép nagy adag ramot, és összelinkeli. Majd ha helyhiány van, akkor kipakolgat a swapre (amit helyesebb lenne page-nak nevezni, mert ez nem swappelés), ha megint van hely és kell a lap, visszatölt a swapről.

    - linux: pontosan tudja, hogy a futtatni való program és a szükséges libek melyik része az, amit readonly módban is be lehet tölteni, melyik része az, ami változik (pl. a linkelési infók változhatnak, de a lib nagy része nem), és azt csinálja, hogy a nem változó részeket közvetlenül összerendeli a ram és a diszk között. A változó részeket meg összerakja ugyanúgy, ahogy mások. Ha memóriát kell felszabadítani, mivel tudja, hogy mely lapok nem változhattak, tudja, hogy pontosan ugyanezen lapok hol laktak eredetileg a diszken, ezért ezeket a lapokat nem vési ki a swapre, hanem kihajítja a kukába, és legközelebb nem a swapről, hanem az eredeti helyéről tölti vissza. Így spórol a swapen levő hellyel meg a swap írási területekkel is.

    A diszk-memória összerendelés az majdnem ugyanaz, mint az fread(), de mmap()-nek hívják. Egyes helyeken az fread is lehet mmap.

  • bambano

    titán

    válasz #95904256 #73 üzenetére

    tisztességes os nem pakolgat ki ramból merevlemezre futtatott kódot.

  • Kkocos

    tag

    válasz #95904256 #77 üzenetére

    A 10 ev :C melett elbujhatok, marmint 10 eve meg nem is halottam a Stepx-rol. A lenyegegben egyetertuk :K , es nem csak a levegobe beszeltem. Gyari rutinrol nem beszeltem, az 1 teljesem mas vitatema, bele se megyek, sot altalaban nem is vita.
    Nah itt ragadnam meg a lehetoseget , ha esetleg [link] erre latsz megoldast :R

  • Kkocos

    tag

    válasz #95904256 #73 üzenetére

    PLC-n futo programokrol beszelek. Itt egy kicsit mas a helyzet

  • P.H.

    senior tag

    válasz #95904256 #46 üzenetére

    Round()-ot nem hoztam fel példának, mert az összes Opt. Manual-ban az hozzák fel érvként, hogy a kerekítés az alapértelmezett FPU konvertálás integer-be (a 'la C).

    i:=16;
    atemp:=round(i);

    Delphi:

    mov eax,$00000010
    mov [ebp-$08],esi
    fild dword ptr [ebp-$08]
    call @ROUND

    ...

    @ROUND:
    sub esp,08h
    fistp qword ptr [esp]
    pop eax
    pop edx
    ret

    FLD/FILD Q[ESP]: float -> integer lenne a mondandó, ez pedig nem az.

    Lehet hogy a trunc() nem a legjobb példa, mert én SSE3-as FISTTP-et használok in-line, ellenben a szintén in-line ( és valóban nem funkcióhívás ) Delphi / C trunc() megoldással. Ennek ellenére a FISTTP kontra FSTCW+FLDCW+FISTP(+FLDCW) kombó sebességbeli különbsége elég látványos. Ezzel csak az a baj, hogy én nem sűrűn találkoztam SSE3-képes géppel a célközönségünkben. És holnap annak fogok nekiülni, hogy egy virtualizált, 32 vagy 64 MB memóriával ellátott Linux alatti Wine-s környezet normálisan futtassa a programomat.
    Én »jelenleg« SSE2 felett nem szoktam programot írni nagyközönségnek, mert nincs arra képes hardware (csak itthon).

  • P.H.

    senior tag

    válasz #95904256 #40 üzenetére

    Csak egy egyszerű példa: egyszer nézz bele, hogy egy Delphi hogy oldja ezt (truncate float -> int; Delphiben trunc() ) :)

    fld dword ptr [value]
    call @TRUNC
    ...

    @TRUNC:
    sub esp,0Ch
    fstcw word ptr [esp+00h]
    fldcw word ptr [cwChop]
    fistp word ptr [esp+04h]
    fldcw word ptr [esp+00h]
    pop ecx
    pop eax
    pop edx
    ret

    Ez mindennapos. Egy 1000-es nagyságrendű, trunc() eljárást hívó ciklus vagy sima rutin esetén is ez van. Nem adna gyorsabb kódot ezt egy InitTrunc() (fstcw+fldcw) - 1000-es ciklus (fld - fistp) vagy rutin - EndTrunc() (fldcw) három makróval megoldani?
    Tudom, van Set8087CW Delphi-ben. Vajon megváltozik ettől a trunc() működése?

    Persze itt nem erről beszélünk, ez az Opt. Manual-ok témája inkább.

  • dabadab

    titán

    válasz #95904256 #33 üzenetére

    Milyen hely az, ahol a technikusok belepiszkalhatnak a dolgokba? Azokban a beagyazott rendszereknel, amikkel kapcsolatba kerultem, a technikusoknak sem kepzettseguk, sem lehetoseguk, sem jogosultsaguk nem volt ehhez. Oke, mondjuk egy CNC gep programja eseteben ezt el tudom kepzelni, de barmi rendes programnal?...

  • P.H.

    senior tag

    válasz #95904256 #38 üzenetére

    "Vagy úgy gondolta hogy annyiszor bepötyögi?"
    Legtöbben ezt alkalmazzák, néhány munkatársam is (sajnos). Nagyban függhet ez attól is, hogy az adott nyelv támogatja-e a makrózást (pl. Delphi tudtommal nem).

  • P.H.

    senior tag

    válasz #95904256 #35 üzenetére

    SZVSZ elbeszéltek kissé egymás mellett.

    shev7 azt mondja, hogy egy kódot azért nem érdemes egynél több helyen felhasználni közvetlenül, mert »ha« a kód hibás (vagy később módosítani, fejleszteni kell), akkor egyszerűbb egy helyen azt megtenni. Te azt mondod, hogy ha az a (matematikailag ellenőrzött, letesztelt, esetleg valamire kihegyezett stb.) végleges kód, akkor lehet többször is alkalmazni (ez hatékonyabb is), mert ha mégsem az, akkor úgyis újra kell az egészet írni, esetleg tervezni is.

    A témához - és amivé vált - hozzászólva: egy jól megírt (hatékony, jól karbantartható) kód eljárásalapú kód előbb-utóbb az OOP-szemlélettel hasonló tulajdonságokkal fog rendelkezni (pl. teljesen mindegy, hogy valamit object.procedure(...) vagy procedure(object,...) alakban írunk, ha a végeredmény ugyanaz lesz; az öröklődés még inkább ilyen, ez szinte megkerülhetetlen; nem véletlen lett kidolgozva az OOP elmélete). Ez csak azon múlik, kinek mi áll közelebb a gondolkodásához. Az első dolog mindenképp az kell, hogy legyen, hogy megértsük a lényegét, azt, hogy mire jó, és mit várunk el tőle. Enélkül üres szövegelés a pro és kontra érv-felsorolás mindkét (OOP és POP) oldalról.

    Én pl. nem fognék neki még ma sem OOP-programnak, egyszerűen képtelen vagyok úgy tervezni valamit, hogy annak a központja a feldolgozandó adat struktúrája legyen, ehhez igazítva a kódot, inkább a kódhoz igazítom az adatszerkezetet (talán itt a legnagyobb különbség a kettő között; és az előbbit nem hiszem, hogy csoportos fejlesztésnél meg lehetne tenni komoly kompromisszumok nélkül). De szinte az összes végeredményem teljesíti az objektum-orientáltság követelményeit. És innen visszanézve őket nem mondhatom azt, hogy bonyolultabb lett volna alapból objektumokra alapozva tervezni.

    Ez csak szemléletbeli különbség SZVSZ. Van, aki azonnal nekiugrik leprogramozni egy problémát, van, aki hosszú órákat/napokat tud ülni felette, végiggondolva a lehetséges következő elvárásokat, továbblépéseket, a kód jövőbeli életét.

  • shev7

    veterán

    válasz #95904256 #33 üzenetére

    namost a rekurzio kibontasa, meg egy esetlegesen hibas kod tobb helyre valo beszurasa az nem ugyan az a kategoria :)

    az meg hogy milyen modszerrel fejlesztettek egy programot, es a szervizes a szervizterminalon mit lat szerintem nincs kapcsolat... vagy valamit felreertettem a mondandodban.

Aktív témák

Hirdetés