2. Fórumok
  3. Szoftverfejlesztés
  4. Hogyan / Hogyan ne programozzunk?
  5. (téma lezárva)
Keresés

Aktív témák

  • #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" ? :)

  • #77 #95904256 törölt tag Kkocos #76
    #77
    Ö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 Kkocos #76 üzenetére

    Lassan 10 éve használom a Step7-et, illetve programozok PLC-ket. A PLC-s programokat nem venném egy kalap alá a PC-s programokkal. Merőben mások a feladatok és az eszközök, az egy dolog hogy mindegyiken fut egy program...

    A PLC-ken nem is erőltetném az OOP-t, hacsak az adott objektumokat nem tudja az ember rendszeresen felhasználni. ( Pl. több tíz vagy száz hasonló vezérlést kellene elkészíteni ). De legtöbbször ezek olyan egyszerű ( pár soros ) dolgok hogy inkább a megfelelő helyen beírja az ember vagy komplett gyári objektumot használ.

    Viszont a gyári objektumokat ( pl. soros kommunikáció, motorvezérlés, stb. ) sokkal egyszerűbb használni mint írni egy saját rutint, amihez elég alaposan meg kellene ismerni az aktuális hardvert is...

  • #73 #95904256 törölt tag Kkocos #69
    #73
    Ö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 Kkocos #69 üzenetére

    Tehat valami olyam megoldasra gondoltam hogy neh oroklodjenek folosleges procedurak, ezket en programozaskor ki-be tudjam kapcsolgatni, neh toltsek vele foloslegesen memoriat, elore latva azt hogy ezekre futaskor biztosan nem lesz szukseg!

    Szerintem felesleges lenne ezzel töltened az időt. Az OS úgyis elvégzi helyetted ezt a feladatot. A nem futó programrészeket vagy be sem tölti vagy előbb-utóbb kipakolja a RAM-ból a merevlemezre ha kell a hely.

  • #52 #95904256 törölt tag P.H. #48
    #52
    Ö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 P.H. #48 üzenetére

    A FSTCW+FLDCW+FISTP+FLDCW helyett van gyorsabb TRUNC() megoldás is, most nem ugrik be a teljes kód, régen használtam már. De azért a következő pár sor alapján szerintem kikövetkeztethető a működése:

    FIST D[esp]
    FILD D[esp]
    FCOMPP
    FNSTSW AX
    TEST AH,xx
    Jcc READY
    SUB D[esp],1
    READY:

    Ez még mindig kétszer gyorsabb mint a CW regiszter módosításával működő TRUNC().

  • #51 #95904256 törölt tag P.H. #48
    #51
    Ö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 P.H. #48 üzenetére

    Még ha legegyszerűbb módon is hajtod végre a ROUND()-ot, de függvénnyel, akkor is ott marad a szubrutin hívás költsége, és igazából egy ilyen egyszerű függvénynél ez zavar. Mint megmutattad a TRUNC()-ot a Delphi is kifejtette "in-line", de az egyszerűbb! ROUND()-ot nem.

    szimpla CALL+RET páros átlagos órajeligénye kontra FLD+FISTP órajeligény
    ( a CPU általi utasításvégrehajtásba / ütemezésbe most nem bonyolódnék bele, aki ismeri az arhitektúrákat az úgyis tudja hogy mi merre mennyi )
    Core2: 18.4 / 9.0
    K10: 25.4 / 11.7
    K8: 25.2 / 10.6

    Megjegyezném a példádban szereplő esetben a ROUND()-ot így helyettesíteném:
    MOV EAX,ESI
    CDQ

  • #46 #95904256 törölt tag P.H. #44
    #46
    Ö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 P.H. #44 üzenetére

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

    Jobb példa pl. egy 64 bites lebegőpontos szám kerekítése ( round() ).
    Ezt most szedtem ki egy C kódból:
    PUSH ECX
    PUSH ECX
    FSTP Q[ESP]
    CALL RoundDouble
    POP ECX
    POP ECX
    ...
    RoundDouble:
    PUSH ECX
    PUSH ECX
    FLD Q[ESP+0Ch]
    FRNDINT
    FSTP Q[ESP]
    FLD Q[ESP]
    POP ECX
    POP ECX
    RET

    Ezzel szemben az alábbi négysoros jóval gyorsabb:
    SUB ESP,08h
    FISTP Q[ESP]
    FILD Q[ESP]
    ADD ESP,08h

    szerk.: Természetesen ezt a négysorost lehet makróként is használni...

  • #45 #95904256 törölt tag dabadab #43
    #45
    Ö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 dabadab #43 üzenetére

    Milyen hely az, ahol a technikusok belepiszkalhatnak a dolgokba?

    Pedig sok helyen megcsinálják. Nem mindenütt képesek kivárni míg a gép gyári szervíze a helyszínre érkezik. Szélsőséges eset, de előfordult már olyan is hogy hajnalban riasztottak egy bizonyos német cég viszonylag új masinájához, ami felmondta a szolgálatot. Mert ha tovább ácsorog akkor másnap egy bizonyos japán autómárka futószalagjáról nem fognak legördülni az autók. Mint kiderült egy egyszerű felfutó él figyelést kihagyott az illetékes programozó a programból. Mondanom sem kell hogy a bizonyos német cégtől is 8-10 órán belül megérkezett egy tag aki konstatálta hogy minden rendben van... :)

    Valamint megjegyzném hogy idehaza elég ritka hogy 8-10 órán belül a helyszínre ér külföldről egy szervizes. Sokszor napokat is kell várni, így nem csodálom hogy néha egy-két termelésvezető vagy hasonló beosztású mondmeg ráuszítja az embereit a feladatra. Az megint más kérdés hogy többször okoznak kárt mint hasznot...

    szerk.: Ja igen. Szervizest említettem, nem technikust. A legtöbb helyen a technikusok félnek hozzányúlni a dolgokhoz ( helyesen teszik ), viszont a mérnök emberek annál vérmesebbek. :)

  • #40 #95904256 törölt tag P.H. #39
    #40
    Ö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 P.H. #39 üzenetére

    Szerintem magasszintű nyelven annyira nincs is jelentősége. Ott lehet jelentősége ahol fontos a gyors kód. Pl. egyszerű példa az integer <-> float-point konverzió. Akár kétszer gyorsabb is lehet ha nem kell szubrutint hívni és lekezelni a "minden esetben" dolgot.

  • #38 #95904256 törölt tag P.H. #36
    #38
    Ö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 P.H. #36 üzenetére

    Hali P.H.!

    Gondolkodtam rajta én is hogy hogy érti shev7, de ha egy kódot több helyen alkalmaz az ember, akkor azt makrózza. Vagy úgy gondolta hogy annyiszor bepötyögi? Brr...

  • #35 #95904256 törölt tag shev7 #34
    #35
    Ö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 shev7 #34 üzenetére

    Na most, feltételezem hogy te sem eleve hibás kódot akarsz írni, így a több helyre való kibontás meg a hibás kód nem ugyan az a kategória. :)

    Valamit félre értettél. Feltételezted hogy a programozó olyan szervizterminállal kínálja meg a szervizest hogy abból minden kiderül és a komolyabb gondok is elháríthatóak. A gyakorlatban ez ritka, mert nem fizetik meg, nincs rá idő. A komolyabb balhéknál a szervizes rászorul arra hogy programozó által kellőképpen nem kicsiszolt programot megigazítsa. Bár legtöbbször csak gányolásnak nevezném ezt a műveletet. ( Tisztelet a kivételnek, mert van ilyen is! )

  • #33 #95904256 törölt tag
    #33
    Ö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

    Azzal nem értek egyet hogy nem érdemes bizonyos kódot duplikálva leírni. Jártam már úgy hogy egy önmagát rekurzívan hívó algoritmust kibontva és pár dolgot itt-ott összevonva több mint 50-szeres (nem 50%-os!) sebességnövekedést értem el.

    Ipari vezérlőknél meg kifejezetten jól jön mikor az ember szervizesként rákapcsolódik egy masinára és nem ütközik egy "objektum"-ba, hanem on-line minden állapotot és kapcsolatot átlát. Ezzel gyakran pár perc alatt kiderül a hiba, szemben az elegánsabb módszer több órás műtéti idejével. Ez egy olyan masinánál amelynek a termelési értéke óránként akár több száz ezer forint, elég hasznos tud lenni.

    szerk.: Ennek ellenére plusz egy pont az OOP-nak, mert elegáns és több agymunkát igényel. :)

Aktív témák

Hirdetés