Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Hogyan / Hogyan ne programozzunk?
  5. (téma lezárva)
Legfrissebb anyagok
Mobilarena témák
PROHARDVER! témák
IT café témák
GAMEPOD témák
Keresés

Aktív témák

  • #97 P.H. senior tag bambano #96
    #97
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    P.H.

    senior tag

    válasz bambano #96 üzenetére

    Az lehet árulkodó jel, hogy az K10-es TLB-hiba Linux patch-e azt csinálja, hogy a lapozásból felhozott vagy újonnan allokált/feltöltött lapot a kernel automatikusan megjelöli Accessed-ként - ha csak olvasható a lap - vagy Dirty-ként - ha írható is az (ebből gondolom, eddig nem tette). Tehát eszerint a Linux lapoz csak olvasható memóriaterületeket is, ami lehet konstans-tábla vagy kód, más nem nagyon. Illetve még egy eset lehetséges: Linux és Windows egyaránt használ bizonyos spekulatív prefetch-algoritmusokat a HDD-re tárolt lapokra (más esetben kizárt, hogy visszaolvasott lap ne legyen legalább Accessed). Linux-ban nem vagyok járatos, a Windows nem különbözteti meg ezeket (sőt, a verem és a - dinamikus - adatterület is futtatható, én pl. használom is, futás közben létrehozott kódok - timer - esetén).

    Továbbá az x86/x64 csak a fenti szinten nyújt hardware-es segítséget (Accessed+Dirty, DEB/NX ill. nem 'Present' lap esetén egy-egy megszakítás kiváltása), tehát ha ez így van, akkor az mégis külön táblázatok és software-es háttéradminisztráció létét feltételezi.

    #92: az mmap()-et hogyan kell kiadni futtatható kódokra? (nézegetem pl. itt, méret is szükséges hozzá; a fordítók adják ezt?)

    akosf: mindkét korábbi kód (@TRUNC és @ROUND) külön hívott belső Delphi eljárás, Delphi 4-ben kiírtam a disassembly-ablakból (a Delphi Enterprise Edition-ok mellé adják gyárilag a teljes fordítási forráskódot - VCL és runtime libraries -, a 4-es verzió felett még komplexebb a @TRUNC). Ha jól meggondoljuk, akkor gyorsabb truncate-sorozat a
    Set8087CW($xxxx); + ...round() hívások sorozata
    de ha valaki FPU control word-ot módosítgat, akkor már teheti assembly-ben is az egészet. De magas szinten is van gyorsabb 4-esben is, de ez meg ellentmond(?) a C-s szabványnak, hogy int_a=float_b mindig a kerekített értéket adja.

  • #94 #95904256 törölt tag bambano #92
    #94
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    #95904256

    törölt tag

    válasz bambano #92 üzenetére

    Ez valóban off-topic... így OFF on :)

    Amit leírtál az eddig is ismert volt számomra, de nem egészen értek egyet a véleményeddel. Méghozzá itt:

    - 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.

    Azt megértem hogy furcsán hat hogy ugyanaz a programkód két helyen szerepelhet a merevlemezen, de ez nem feltétlenül jelent hátrányt. Amennyiben a memória kiterjesztését (virtuális memória mentés/töltés) automatikusan végzi a memóriakezelő úgy nem kell egy másodlagos adminisztációt elvégezni hogy az adott blokk honnan származik, az módosult-e már azóta. Persze mindenki döntse el maga hogy ez neki előny vagy hátrány. Annyit még hozzátennék hogy nem csak read-only programterület létezik. Ennek a mentős/töltögetős módszernek ez sem jelent plusz feladatot.

  • #85 #95904256 törölt tag bambano #82
    #85
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    #95904256

    törölt tag

    válasz bambano #82 üzenetére

    Pl. Van x mennyiségű memória egy gépben ami futtat egy rakás kódot és adatot. Egyszer csak betelik a véges memória, de újabb kódot/adatot kell behozni a RAM-ba, ilyenkor mit csinál a "tisztességes" OS?

    Szerintem illene a nem / legritkábban / legrégebben használt adatokat, programkódokat a merevlemezen lévő swap-ba tennie.

    Vagy küldjön egy üzenetet hogy: "Out Of Memory" ? :)

  • #84 Kkocos tag bambano #82
    #84
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Kkocos

    tag

    válasz bambano #82 üzenetére

    Erre vonatkozoan tudsz egy eljarast amihez 1 gepre 2 operacios rendszert (Windows+Linux) feltehetek. Az elsodleges a Windows legyen. Ezt a particiot szerentem a tarolasra is hasznalni! Soha se probaltam FAT, vagy NTFS en kivul ket kulombozo particiorol Bootolni (nah persze nem 1ccere)?

  • #80 Kkocos tag bambano #79
    #80
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

    Kkocos

    tag

    válasz bambano #79 üzenetére

    Windows nem ezt csinalja?? Nekem pedig ugy remlik hogy a RAM-ban varakokozo kodot eleg rendszeresen kuldi ki, pilanatnyilag nem hasznalt dll-t, stb. Aztan meg varhasz mig ujra betolti ha szukseg van megint ra! De ha' nem is foglalhat RAM-ot epp hasznalaton kivuli kod, legyen az akrami

  • #63 dabadab titán bambano #61
    #63
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dabadab

    titán

    válasz bambano #61 üzenetére

    Akkor szedjuk kette a dolgokat:

    1. Az, hogy sok es bonyolult koddal kell egyuttmukodni, az nem az OOP resze. Futottam ossze ilyennel sima proceduralis nyelvnel is, volt, hogy egy fel ev(!) utan jutottam el oda, hogy kodot irjak (es akkor ez meg viszonylag jo eredmeny volt).
    2. Az OOP nem a legkezenfekvobb modszer. Ugy jott ki, hogy nagyjabol olyan sorrendben talalkoztam nyelvekkel, ahogy a programozasi paradigmak is fejlodtek (BASIC, Assembly -> Pascal, C -> C++, Java), igy ertettem, hogy milyen problemakra adtak megoldast. Addig, amig valaki nem fut bele az adott paradigma korlataiba, addig a kovetkezo siman tulbonyolitasnak tunhet. Ezzel tulzottan sokat nem lehet kezdeni, ha csak a budira akarsz kimenni, akkor a Concorde felesleges bonyolitasnak tunik. :)

  • #62 S.P.Q.R. csendes tag bambano #61
    #62
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    S.P.Q.R.

    csendes tag

    válasz bambano #61 üzenetére

    Teljesen egyetértek veled, valóban fenn áll az a gond sajnos, hogy j2ee-s porgam megírása nem kispályás ügy, és sokezer oldalnyi kód és specifikáció no meg oktatási anyag kell hozzá és nem árt pár év gyakorlat sem. Több hónap alatt szokták a programozókat j2ee-re oktatni nagyobb cégek, és elötte pl a szakirányu végzettséget meg is követelik, netán 1-2 év gyakolatot is, pont a fent említett dolgok miatt. Ugyankkor látni kell azt is, hogy egy nagyobb j2ee-s program mennyire komplex, ugyanez értendő a .net keretrendszer kontra c#-ra is. Rengeteg dolog be van építve, sokminden plusszt tud a rendszer, szóval nem árt ezekkel tisztába lenni, de az eredméyn nagy és látványos tud ezáltal lenni. Valamit valamiért elven :D

    Ettöl függetlenül én sem kedvelem a katt ide katt oda desinerrel tervezd gui-t féle megoldásokra, pl amiket az MS visual studio-ja és a segédprogramjai kínálnak...De valaki erre esküszik, mondván fene akar ezzel is törődni. Nos én azt mondom ki-ki a saját íze szerint, illetve amit megkövetelnek tőle a cégnél. :K

  • #60 dabadab titán bambano #59
    #60
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    dabadab

    titán

    válasz bambano #59 üzenetére

    A mire?...

Aktív témák

Hirdetés