- Út Korea turistaparadicsomába, amiről talán még sosem hallottál: Csedzsu-sziget
- Perplexity Pro AI képszerkesztési limit -egy képgenerátor függő tapasztalatai
- Adattár lemez előkészítése távlati Windows telepítéshez
- Jelszóvédett IBM Thinkpad R50e működőképessé tétele.
- ATK Blazing Sky X1 Ultimate Metallic Red gamer egér
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Gurulunk, WAZE?!
- GoodSpeed: Sapphire Radeon RX 9070 XT Pulse - út a harmadik AMD korszakig.
- GoodSpeed: iPadOS 26 A Liquid Glass varázsa
- sziku69: Szólánc.
- sellerbuyer: Te tudod, mi mennyit fogyaszt az otthonodban?
- eBay-es kütyük kis pénzért
- Doky586: Adattár lemez előkészítése távlati Windows telepítéshez
- sziku69: Fűzzük össze a szavakat :)
Aktív témák
-
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.
-
Kkocos
tag
válasz
#95904256 #77 üzenetére
A 10 ev
melett elbujhatok, marmint 10 eve meg nem is halottam a Stepx-rol. A lenyegegben egyetertuk
, 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 -
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
retFLD/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
retEz 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.
-
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 #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
- Apple Watch Ultra - első nekifutás
- Azonnali informatikai kérdések órája
- EAFC 26
- Milyen okostelefont vegyek?
- Gumi és felni topik
- Harmincadik születésnapja alkalmából megújult az AIDA64
- Kína betilthatta az NVIDIA AI gyorsítók vásárlását
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Részesedést vásárolt az Intelben az NVIDIA
- iPhone topik
- További aktív témák...
- Nvidia Quadro P400/ P600/ P620/ P1000/ T400/ T600/ T1000 - Low profile (LP) + RTX A2000 6/12Gb
- GYÖNYÖRŰ iPhone 11 Pro 256GB Midnight Green -1 ÉV GARANCIA - Kártyafüggetlen, MS2253,95% Akkumulátor
- Telefon szerviz helyben - Gyors javítás, akár 30 perc alatt!
- Samsung Galaxy A53 128GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 13 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3509, 100% Akkumulátor
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest