Új hozzászólás Aktív témák

• #657 Fire/SOUL/CD félisten Sk8erPeter #656

  Új Válasz 2009-05-18 15:26:06 #657

  Új hozzászólás

  Ö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

  

  Fire/SOUL/CD

  félisten

  válasz Sk8erPeter #656 üzenetére

  Hali!

  Azt konkrétan nem tudom, hogy az adott progik milyen elven működnek, de pár információval szolgálhatók a sebbesség beli különbségek okára. Alapvetően programozástechnika az egész.(persze az adott hardver is fontos)
  Egy "hétköznapi" fájl másolása a következő szerint zajlik(nagyon általánosan):
  1. Megnyitom a forrást olvasásra
  2. megnyitom a célt írásra
  3. lefoglalok memóriát az adatok számára(puffer)
  4. forrásból olvasok a pufferbe
  5. pufferból kiírom cél-ba
  6 lezárom forrást, lezárom célt.

  A régi időkben(DOS, Assembler, Pascal, C) nagyon fontos volt, hogy a lefoglalt puffer mérete 512Kbyte többszöröse legyen, illetve még az is gyorsított a másoláson ha a kettes számrendszer szabályait alapul véve 1024, 2048, 4096 KByte-os puffereket alkalmaztál.
  Szóval még akkor is volt sebességbeli különbség, ha pl 5120KB(10x512KB-t) foglaltál le, vagy 4096Kb-tot, utóbbi esetben volt gyorsabb.
  Ez abból adódott, hogy az akkori HDD-k olyan elven működtek, hogy ezt az 512KB vagy annak töbszörösét alkalmazva tudták leggyorsabban "előbányászni" az adatokat....
  Ezt a szabályt a mai napik betartják, csak azóta új technikák is vannak.

  Aztán ebből adódóan, az is számít, hogy mekkora puffer-t foglalsz le a másolás számára.
  (Ha tudod, hogy a HDD 80MB/sec-et tud példul, akkor nyílván nem 4MB-tot foglalok le, hanem pl 16MB-t...)
  Lehet hogy az Unreal ragaszkodott az alapelvekhez, és úgy írta meg a másolási procedúrát, hogy az a legrégebbi HDD-ken is ugyanúgy megy , mint az ujabbakon.
  (Nem nézi meg a HDD paramétereit pl)

  Az Intéző az "arany közép út", azaz úgy írták, hogy mindennel optimálisan működjön

  A TC már más tészta. Az egyik külföldi forúmon olvastam, hogy a TC végez egyfajta gyors tesztet a HDD-n(tényleg nagyon gyors tesztet), amiből közelítő értéket kap a HDD sebességéről, adatairól. Ennek függvényében állítja a pufferméretet, használja (programozza) az UDMA-t stb és még sok dolgot.(és az is számít, hogy hány darab puffert hozok létre, bizonyos technikák esetén sokkal hatékonyabb alkalmazni 20 darab 32KB-os puffert, mint egy 640KB-ost)

  Az a funkciója, hogy "Nagy fájlok másolása" nézd meg, ott már nagyon nagy puffert használ, illetve a korábbi változatok esetében oda volt írva, hogy nem biztonságos...
  Ezt ki is szedték belöle, mert valóban nem volt biztonságos. Un. sector by sector módszert alkalmaztak, azaz Direct Access-t. Ennek az a lényege, hogy( mint egy particiónáló progi) nem az adott OP. rendszer által kínált állományműveleti függvényeket használja, hanem közvetlen módón éri el a HDD szektorait.
  Fogja a forrás adott szektorát, megnézi hol van üres szektor a HDD-n, aztán célként ráírja az adott szektorra. (DOS környezetben a DOSNavigátor tudta ezt nagyon jól )
  Azonbam amikor szektort írok, nem tudhatom, hogy más alkalmazás nem ír-e ugyanarra a szektorra(pl maga az Op. rendszer), ezért a végén előfordul, hogy mégsem az került oda aminek kellene..
  Az Op. rendszer felügyel szektorokat(Pagefile.sys, MBR stb) tehát ami számára kell, de a többivel "szabadon" lehet garázdálkodni.
  (Régen a DOS-nál nem volt ilyen gond, mivel egy progi futott, azt kész )

  Szóval röviden, valószínűleg programozástechnikai különbségekből, a fent említett módszerek használta/nem használatából és még sok más (általam nem ismert ok miatt) vannak ezek a különbségek...

  Fire.

  UI: Bocs, ha untattalak volna a technikai részletekkel...

Új hozzászólás Aktív témák