Sziasztok!
> =======================================================
> Felado :  [Hungary]
> Temakor: Re: Instr.ciklusok... ( 18 sor )
> Idopont: Tue Feb 24 17:50:34 EST 1998 CODER #33
> - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
A Pentiumra irt programok assemby szintu optimalizalasanak a
kulcsa: minnel egyszerubb utasitasokkal kell dolgozni.

Oka:
A Pentium csak az egyszeru utasitasokat tudja pipe-olni, azaz
egyszerre egy idoben tobbet vegrehajtani. Termeszetesen csak akkor ha
nincs az utasitasok kozott adatfuggoseg. (Read After Write-> ez a
leggyakoribb)
A RAW-ok esetet csokkenteni lehet, ha a kodot szetkened, azaz a
logikailag egymas utan kovetkezo utasitasok kozott probalsz valami
mast csinalni.
A gyorsasag kedveert a repnz utasitast ugy ahogy van el kell
felejteni. Sokkal gyorsabb ha dec, jnz-vel szervezed meg a ciklust
meg akkor is ha rendszeresen menteni kell regisztereket.
Vannak olyan programok is, amik az asm source kodot optimalizaljak.
En egyel talakoztam, de inkabb magam csinaltam az optimalizalast.

Pentium Pro-n allitolag mar nem kell ezekre ennyire odafigyelni.
Sajnos az AMD es egyebb procikrol sincs infom.

Hatranya:
- Megno a kod meret, de asszem ez mar nem igazan problema, mert a
memoria mar szinte ingyen van es a cache-ek is eleg nagyok.
- Az utasitasok elkenese miatt nehez kesobb megerteni, hogy mit
csinal a program. Tehat a szetkenesnek kell lennie programozas
utolso lepesnek.

Ha jol emlekszem par eve a Dr. Jobs Journal-ban olvastam rola.
http://www.ddj.com/
Pisti

On 24 Feb 98 at 13:15, Nemes Marcus > wrote:

> Sziasztok!

Szia!

> Istvan irja:
>
> : Igen, tudom, hogy Te a legbaloldalibb 1-es bitet mondtad, de ha a
> : byte hatar az 111 sorozat kozepen van, akkor az xor-olt byte-ban a
> : legbaloldalibb 1-es 1->0 atmenet lesz.
[...]
> Az erdekes az elso peldaban az, hogy a 2. byte-ban valoban hulyeseget
> kovetunk el, de az 1. byte-ban mar megtalaltuk a nekunk tetszo atmenenet,
> igy nem kell tovabb keresni.

Jo, Te nyertel :)
Ha a feladat az, hogy az _elso_ feher-fekete atmenetet talaljuk meg,
akkor tenyleg jo.

> A MIN es a MAX kozotti nem sebessegbeli kulonbsegen a hetvegen kettetortem
> az agyam, reszemrol szabad a gazda, esetleg unsubs-olhatok a nem megfelelo
> szellemi szinvonalam miatt. :-)

Ha szabad a gazda, akkor megmondom: A kulonbseg az, hogy a sarkos
erintkezeseknel a MAX korbejarja a sarkosan erintkezo alakot is, mig
a MIN azt kihagyja, ket kulonallo alakzatnak tekinti. Szoval a MIN 4
szomszedos szomszedsaggal dolgozik, mig a MAX 8 szomszedossal, ott a
ferde szomszedok is szomszedok.

Ez elsore nagy kulonbsegnek tunik, valojaban csak az az erdekes, hogy
tudjunk rola, es konzekvensek legyunk. Tehat nehogy a betu bejaro
algoritmus MAX-szal dolgozzon, a lyuk bejaro meg MIN-nel, mert akkor
"egymasba gabalyodnak".

Hogy melyik a jobb? Kinek mi tetszik. Mi a MAX-ot hasznaljuk. A
gyakorlatban nagyon ritka egyebkent a sarkos erintkezes, mert a betuk
vizszintesen vannak nyomtatva. Azert elvekonyodo ferde vonalaknal jol
johet, hogy a MAX azokat a sarkos erintkezeseket is beleerti a
bejarando alakba, szoval valoszinu jol valasztottunk :)

No, akkor az igert folytatas:

Miutan korbejartuk az elso alakot, tovabb kell mennunk, es meg kell
talalni a masikat. Vagyis bejon most az, hogy hol van a rakovetkezo
feher -> fekete atmenet. Raadasul olyan, amit eddig meg nem jartunk
be. Tehat ha az alakzat teteje ilyesmi:

-> X x x x         Y x x x
   x x x x x     x x x x x
   x x x x x x x x x x x x
   x x x x x x x x x x x x

Akkor eloszor beleakadunk az X-be, korbejarjuk, ekozben jarunk az
Y-nal is, tehat amikor majd a masodik alakzatot keressuk, akkor mar
nem szeretnenk megtalalni az Y-t, mint uj feher->fekete atmenetet.

Annak adminisztralasara, hogy mik a mar bejart feher->fekete
atmenetek, a legjobb talan egy parhuzamos bitmap-et fenntartani (mi
ezt konturmap-nek nevezzuk), ahol is bejaraskor bejeloljuk azokat a
feher->fekete atmeneteket (vizszintes atmenetek), ahol mar jartunk.
Igy amikor a vektorunk az Y-tol balra felfele all, akkor beirunk egy
bitet az Y-al parhuzamosan a konturmap-be, es amikor a multkori
feladatban keresett and-shift-xor-stb. algoritmussal keressuk a
feher-fekete atmenetet, akkor abban figyelembe vesszuk ezt a
parhuzamos konturmap-et is.

No, ezek utan akkor a modositott FELADAT: hogyan lehet nehany
bitmuvelettel megtalalni a legelso olyan feher->fekete atmenetet,
ahol eddig meg nem jartunk?

Vegyetek azt is figyelembe, hogy ha a lapon van 1000 betu, akkor uj
feher->fekete atmenetet csak pontosan 1000-szer fogunk talalni
(eltekintettem az ekezetektol), mig mar bejart atmenetet esetleg sok
szazezerszer. Tehat az algoritmus azon reszenek kell gyorsnak lennie,
ami a mar bejart atmeneteket nem fogja megtalalni. Ha mar talaltunk
egy uj atmenetet, annak eldontese, hogy melyik biten kezdodik az,
lehet szinte akarmilyen lassu is, hisz egy lap felismeresekor csak
1000-szer fut le.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --

Kedves Lista && Marosi Istvan!

> > Nem tudom, hogy mi tortenik a nagy fork-olasok kozepette. Tudom, hogy a kod
csak
> > egyszer el, de ha nagyobb a kod, akkor nagyobb helyet fog foglalni a futas
> > kozben??? Hogyan lehetne elerni, hogy csak akkora kod legyen a memoriaban,
> > amekkora szuxeges. Ha a megvalositando feladatokat kulon fv-be teszem, az
> > eleg???
>
> Szerintem nem nagyon kell egy rendes unixon ilyenekkel torodni, ha
> kell a memoria, akkor a kernel ki-swap-ol mindenkit, raadasul a
> kodteruletet swap-olni sem kell, mert gondolom, nem firkalsz bele. :)
> Szoval meg swap teruletet sem nagyon foglal, amikor szukseg van ra,
> visszaolvassa a file-bol.

En ugy hallottam (pontyon infom nincs rola), hogy a Linux (nem tudom, hogy
a HP-UX is e' e) ugy csinalja, hogy csak par lapot olvas be a prog-bol.
Igy nem annyira lenyeges a meret, mert ugy sincs bent minden!

Nem erdemes esetleg shared izekkel megoldani a dolgot, vagy mar megint
huJeseget beszelek?

TIA && udv From:, a melle'kes szereplo

# Minden eronkkel tamogassuk azokat akik keresik az igazsagot...
# ... es menekuljunk azok elol, aki megtalaltak! /Vaclav Havel/

Hasznalja valaki a Blinker 3 vagy a Blinker 4-es szerkeszto-
programot Clipper kornyezetben ugy, hogy a Clipper progit
extended-kent szerkessze? A leiras szerint csak 2 plusz sor
a .lnk allomanyba, de nekem meg sosem sikerult elinditani
az igy leforditott programot. Meg a legegyszerubb 1 soros
progi is kiakad GPF-el.
Van valakinek otlete ?

Koszi

Kesjar Attila

Hali mindenki !

     Keresem a fenti csodatermekben programozo elfajult egyedeket, hatha
     eszmet tudunk cserelni, esetleg megvaltani a vilagot.
     Tudom, hogy van mar ujabb verzio belole, de hat nekem csak ez van.
     Rajta hat !

     Udv : Peter

Sziasztok!

Ha erdekel egy igazi, tisztan szoftveres masolasvedelem
-- pontosabban illegalis alkalmazashasznalat elleni vedelem --
demoja, a http://members.tripod.com/~devpoint/indigo.zip cimrol
letoltheted.

Bar egyelore meg fejlesztes alatt, es meg csak Win95 alatt fut,
a lenyeg kiveheto a demobol: a vedett program KIZAROLAG a
meghatarozott szamitogep(ek)en fog futni. Nincs hattertarolohoz
kotve (!), szabadon masolhato, igy keszitheto rola biztonsagi
masolat is. A vedelem hasznalatahoz nem kell atirni a vedendo
programot, utolag is elvegezheto a telepitese.

A mukodesehez nincs szukseg semmilyen kiegeszitore
-- pl. hardlock, vagy kulcslemez --, enelkul is biztonsagos,
gyakorlatilag nem torheto fel. Hogy miert? Mert a program
belepesi pontjat a futtato szamitogep "kulcsaval" titkositja,
igy a dekodolo resz a nem regisztralt szamitogepeken egyszeruen
nem tudja megallapitani, hogy hol kezdodik a program.

(Termeszetesen NEM erre epul a vedelem kozponti resze, ez csak
azt biztositja, hogy regisztralatlan gepen semmifelekeppen ne
lehessen hasznalni. Mivel azonban egy regisztralt programrol
nyomkovetessel eltavolithato lenne a vedelem, mas, joval
biztonsagosabb modszerek is megtalalhatoak benne, amelyek
garantaljak, hogy a toresi eljaras automatizalasa eseten (!)
is minimum 5-10 evbe kerul a vedelem feltorese.)

Udv, &:]

Suc
]

Hello,

van vkinek vmilyen infoja az ASPI felulet programozasarol.
Konkretan egy Adaptec 2940 kartyan keresztul kellene adatokat kuldeni
es fogadni egy kulso SCSI egysegrol.
Vmi Pascal, vagy C megoldas erdekelne.

-------------------
GZsolt

mail:

2:
UIC: 5688612

Hello,

Beindult egy csak Delphi -vel foglalkozo levlista.

Jelentkezes:


Subject: subscribe

Udv,

awender

Hi!

Nincs meg a teljes CODER archivum (tenyleg, elkuldhetne valaki az 1..25
szamokat tomoritve...), de megkockaztatom, hogy nem mindenki ismeri meg a
Programozok Oazisat. En is az Uj Alaplapbol ertesultem arrol, hogy ilyen
is van. Tele van linkekkel, kis kereses utan barmit meg lehet benne talalni.
A C-t nagyon preferalja, de mas is van benne boven.
Tehat a cim:

http://www.utu.fi/~sisasa/oasis/alternate.html

Jo keresgetest!

  NGabor, az ujrakezdo programozo

>Szoval and-xor-stb.-vel kellene.
>> n := tabla(X) (szogletes zarojel!)
>
>Igen, lehet szo ilyesmirol is.
>
>Most nem erek ra, de mindjart irom a feladat folytatasat, es akkor
>erthetobb lesz, hogy miert kell megis nehany xor bele :)

A megoldas a kovetkezo:
v&((v-1)^0xff)
^ == XOR (ha valaki nem jaratos C-ben) :-)
v == v a vizsgalt byte.
A dolog azert mukodik, mert a kivonas a legelso 1-es bit felettieket
nem bantja, ezek a xor miatt kimaszkolodnak az AND-nel, az elso
1-es bit elotti reszek a kivonas kovetkezteben csupa 1-e valnak, es
oket mar a xor kimaszkolja, mig az elso bit a kivonas kovetkezteben
0-ra megy a Xor vissza viszi 1-be, es mivel az originalban is 1
ez a bit, az AND eredmenye az lesz, hogy ez es csak ez a bit lesz 1.
Megjegyzem ezzel a megoldassal mehetsz gyorsabban is mint 8 pixel,
csak a 0xff-et kell nagyobbra venni, na meg a regiszter meretet. :-)

Ezzel kapcsolatban jut eszembe, van egy hasonlo feladat, es a megoldas
is hasonlo:
hogyan lehet eldonteni gyorsan egy szamrol, hogy 2 hatvanya-e vagy sem.
Megoldast most nem irok, kivancsian varom hogy ismeritek-e.

Annak ellenere hogy kicsit kuriozumnak tunnek ezek a feladatok, meglepo
modon volt mar peldaul a fentire szuksegem.

Biczo Tibor

[fekete feher el megtalalasa :]

Idokozben eszembe jutott egy picivel
elegansabb megoldas:
((v-1)^v)+1
Gyakorlatilag az elmelet ugyanaz mint az elobb.
Utasitasok szamanak szempontjabol is nagyjabol ugyanaz (mindket
megoldasnak 4 muveletre van szuksege), viszont nincs szukseg maszkra
s igy talan vagy egy register-el tobb van, vagy nincs szukseg egy
immediate param-ra a xor-nal.
Eredmeny ugyanaz, ha a vizsgalt adat 0 volt, akkor a kimenet 0,
kulonben az elso bitet adja vissza.
----
Kicsivel kesobb:
i80x86-on az elso megoldas a jobb, mivel van NEG utasitas,
ami pont megegyezik a (v-1)^0xff-el, raadasul mukodik byteon
es szon is.
Na szoval valahogy igy nezne ki: (AL-ben a vizsgalt byte)
MOV BL,AL
NEG BL
AND BL,AL

Utasitasszamban ez mar eleg keves :-), hogy orajelben mi a gyorsabb
azt mar nezzetek meg ti. Nekem csak 386-rol van most hirtelen
keznel info, es itt azt irjak hogy a fenti utasitasok mind 2 orajel
hosszuak, ugyhogy ez az egesz itt 6 orajel alatt lefut elmeletileg
386-on, pentiumon pedig ugy saccolom, hogy olyan 3 orajel lehet.
Ez mar eleg jo nem? :-)

Mas procin elkepzelheto, hogy a masodik megoldast jobban ki lehet
optimalizalni.

Biczo Tibor

>Idokozben eszembe jutott egy picivel
>elegansabb megoldas:
>((v-1)^v)+1

Na igen ezt elirtam... A helyes a kovetkezo :
((v-1)^v)&v

A xor elintezi a felso biteket, es 1-be allitja a keresett bitet,
es az alatta levoket, az and pedig torli a keresett bit alatt levo
biteket.

Hmmm... Most vettem eszre, hogy balrol-jobbra tarto megoldast
kerestek, viszont ezek jobbrol-balra meno megoldasok.
Nem lenne egyszerubb, ha ugy tarolnad a pixeleket, hogy a
legbaloldalibb van a 0-as biten a kovetkezo az 1-esen etc...
Ha igy tarolod, akkor raadasul Intel(little-endian) kornyezetben tudsz wordot
is olvasni, es a bit sorrend helyes lesz ehhez a megoldashoz.
Ha viszont Motorola(big-endian) kornyezetben vagy, akkor persze erdemesebb,
ha ugy tarolod, hogy a legbaloldalibb a legnagyobb helyierteku biten van,
viszont itt erdemes akkor megfontolni, hogy a kep vegig scanneleset
ne balrol-jobbra, hanem jobbrol-balra vegezd...

Biczo Tibor